[#12442] Show available task lists in "Quick Add" window
Summary Show available task lists in "Quick Add" window
Queue Nag
Queue Version Git master
Type Enhancement
State Assigned
Priority 2. Medium
Owners Horde Developers
Requester josh@ha.cr
Created 2013-07-10 (2524 days ago)
Due
Updated 2016-01-28 (1592 days ago)
Assigned 2016-01-28 (1592 days ago)
Resolved
Milestone 5.0.0
Patch Yes

Comments
josh@ha.cr 2013-07-10 01:57:17
The "Quick Add" window is very useful, since many nontechnical users 
find that forms with many fields are overwhelming. In order to 
encourage these users to add tasks to the proper list, I've included a 
patch that displays a drop-down list of available task lists below the 
entry form.

A working patch is attached. I'm currently using it in production and 
would be open to any suggestions.

Thanks!

Jan Schneider <jan@horde.org> 2013-07-10 14:45:15
I'm inclined to reject it, because this form should really be kept as 
simple as possible. Where should we draw the line? What if anybody 
thinks that the form is fine, but only a field to set the priority 
would be missing? Why is the tasklist different from that?

josh@ha.cr 2013-07-11 01:52:03
> I'm inclined to reject it, because this form should really be kept 
> as simple as possible. Where should we draw the line? What if 
> anybody thinks that the form is fine, but only a field to set the 
> priority would be missing? Why is the tasklist different from that?

I can definitely understand the desire to keep the form as simple as 
possible. However, in my organization shared task lists are used to 
manage various projects and so its important that new tasks are added 
to the correct list. In other organizations perhaps it would be as 
simple as tagging tasks appropriately.

I can see a couple of compromises:
1.  With some added text processing to Nag::createTasksFromText, users 
could set the task list per-item, eg by prefixing it with part of the 
task list name "shared: make a birthday card"
2. Add a preference for additional fields on the "Quick Add" form, 
including the task list, priority, and anything else that may seem 
relevant.

Option 1 involves possibly breaking backward compatibility and is 
therefore dangerous, although it is a nice feature IMHO. Option 2 is 
probably a better choice, since it allows a system policy to be made 
by administrators and is more straightforward to the user -- although 
it does seem to be pushing the definition of "Quick".

I can code up one of those solutions, if you'd consider accepting it. 
If not, I can totally understand your motivation.

Michael Rubinsky <mrubinsk@horde.org> 2013-07-11 02:35:49

> I can see a couple of compromises:
> 1.  With some added text processing to Nag::createTasksFromText, 
> users could set the task list per-item, eg by prefixing it with part 
> of the task list name "shared: make a birthday card

We already do something similar for tags in the quick add form.
I'd be for extending this to specifying the task list.

> Option 1 involves possibly breaking backward compatibility and is 
> therefore dangerous,

why?


josh@ha.cr 2013-07-11 03:03:42
>> Option 1 involves possibly breaking backward compatibility and is
>> therefore dangerous,
>
> why?

The Nag::createTasksFromText() method takes a $tasklist argument. The 
documentation for that method states:

> @param string $tasklist The tasklist into which the task will be 
> imported.  If 'null', the user's default tasklist will be used.

I'm not familiar with the usage of this method outside of the Quick 
Add list, so it may be completely safe. Perhaps the next question, 
then, is how should the API be changed to support the new feature 
while still allowing the old behaviour? To follow up, is there any 
situation in which a tasklist specified in the text should *not* 
override the $tasklist param, or vice-versa?

I'd personally tend toward adding a boolean argument indicating if the 
task list should be forced to the non-null value passed as the 
$tasklist param, or if the text can specify a task list. If someone 
more familiar with the codebase can confirm that the Quick Add form is 
the only place where this method is used, that would not be a 
necessary addition.

Jan Schneider <jan@horde.org> 2013-07-11 08:56:11
>>> Option 1 involves possibly breaking backward compatibility and is
>>> therefore dangerous,
>>
>> why?
>
> The Nag::createTasksFromText() method takes a $tasklist argument. 
> The documentation for that method states:
>
>> @param string $tasklist The tasklist into which the task will be 
>> imported.  If 'null', the user's default tasklist will be used.
>
> I'm not familiar with the usage of this method outside of the Quick 
> Add list, so it may be completely safe. Perhaps the next question, 
> then, is how should the API be changed to support the new feature 
> while still allowing the old behaviour? To follow up, is there any 
> situation in which a tasklist specified in the text should *not* 
> override the $tasklist param, or vice-versa?

It's an internal Nag method, so all usages of that method can be 
easily covered if necessary. That being said, there is no need to 
change the signature at all. Either a tasklist can be parsed from the 
text, then it's being used, otherwise it falls back to the current 
behavior.

> I'd personally tend toward adding a boolean argument indicating if 
> the task list should be forced to the non-null value passed as the 
> $tasklist param, or if the text can specify a task list. If someone 
> more familiar with the codebase can confirm that the Quick Add form 
> is the only place where this method is used, that would not be a 
> necessary addition.


josh@ha.cr 2013-07-12 04:00:18
I've attached a patch to parse a tasklist from the text by prefixing 
the line with a partial task list name, followed by a colon. For 
example,

> josh: This goes on my personal tasklist (ie, "Task list of Josh Leder")
> shared: This is a task on the shared tasklist
>   Child tasks are forced to use the parent tasklist

I haven't run any of the unit tests, however -- if someone can point 
me to any docs on the test harness I'll give it a go.

Also if this is accepted the "Quick Add" form should be updated to 
include a description of the new feature. That would require new 
translations, unfortunately. I can contribute Spanish, at least...