6.0.0-git
2019-01-21

[#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 (at)
Requester josh (at) ha (dot) cr
Created 2013-07-10 (2021 days ago)
Due
Updated 2016-01-28 (1089 days ago)
Assigned 2016-01-28 (1089 days ago)
Resolved
Milestone 5.0.0
Patch Yes

History
2016-01-28 15:59:54 Jan Schneider Assigned to Horde DevelopersHorde Developers
State ⇒ Assigned
Milestone ⇒ 5.0.0
 
2013-07-12 04:00:18 josh (at) ha (dot) cr Comment #7
New Attachment: 0001-parse-task-list-in-createTasksFromText.patch Download
Reply to this comment
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...
2013-07-11 08:56:11 Jan Schneider Comment #6 Reply to this comment

[Show Quoted Text - 17 lines]
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.
2013-07-11 03:03:42 josh (at) ha (dot) cr Comment #5 Reply to this comment
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.
2013-07-11 02:35:49 Michael Rubinsky Comment #4 Reply to this comment
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?

2013-07-11 01:52:03 josh (at) ha (dot) cr Comment #3 Reply to this comment
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.
2013-07-10 14:45:15 Jan Schneider Comment #2
State ⇒ Feedback
Reply to this comment
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?
2013-07-10 01:57:17 josh (at) ha (dot) cr Comment #1
Type ⇒ Enhancement
State ⇒ New
Priority ⇒ 2. Medium
Summary ⇒ Show available task lists in "Quick Add" window
Queue ⇒ Nag
Milestone ⇒
Patch ⇒ Yes
New Attachment: 0004-show-tasklist-list-on-quick-add-form.patch Download
Reply to this comment
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!

Saved Queries