Re: [Tsheetx-developers] Customizable default tasks

[Peter L. <pal...@gm...>]

I haven't looked at the code yet. The situation could simply be handled by
saying: no tasks, no projects. But then additional code could be needed in
some sql selects to ignore incomplete clients and projects. Perhaps that;s
prefereable to forcing the addition of a project when creating a client, or
jumping to add new task just after a new project is created.
Peter

On 26 August 2011 00:54, Scott Miller <sco...@gm...> wrote:

> I believe the default task, project and client entries were created as a
> solution to the problem of "how should the system handle a user that has no
> clients, projects or tasks?".  This particular answer meant the system
> didn't have to handle that problem as there should never be a time when a
> user didn't have at least one of each.
>
> FWIW, I dislike them as well, and I'm hopeful that they can be removed.
>
> -Scott
>
>
> On Thu, Aug 25, 2011 at 7:10 AM, Peter Lazarus <pal...@gm...>wrote:
>
>>  I don't like these default things either. Will investigate.
>>
>> On 08/25/2011 09:47 PM, David Thompson wrote:
>>
>>  Back on the list...
>>
>> I think "no/any client" is handled ok, I have set up an install with
>> clients turned off completely.
>> Default project and default task worry me. Do we really need these? It
>> gets confusing when times are entered against them.
>>
>> Dave
>>
>>  ------------------------------
>> Date: Wed, 24 Aug 2011 19:31:48 +1000
>> From: pal...@gm...
>> To: tom...@us...
>> CC: ma...@rw...; 2n...@ak...;
>> sco...@gm...
>> Subject: Re: [Tsheetx-developers] Customizable default tasks
>>
>> David,
>> what are you referring to in special handling of defaults? Do you mean
>> that a default task, project, client are currently inserted in the database
>> and show up in lists?
>> Peter
>>
>> On 08/24/2011 06:08 PM, David Thompson wrote:
>>
>> Peter
>> Without looking at the code, but from your good analysis, I agree
>> that your suggestion is better. Scott was working on a new config style (in
>> the V2 branch?) anyway, so extending the old config table that is earmarked
>> for removal is not useful.
>>
>> So a good design sounds something like you said: a set of (potential)
>> standard tasks, that can be checkboxed when creating tasks in a project,
>> together with a UI to manage that list of standard tasks (add, delete,
>> modify).
>>
>> Can we also get away from special handling of defaults here (default task,
>> default project, no/any client)?
>>
>> Cheers
>> Dave
>>
>>
>>
>