[Tickets #12442] Re: Show available task lists in "Quick Add" window
noreply at bugs.horde.org
noreply at bugs.horde.org
Thu Jul 11 08:56:12 UTC 2013
DO NOT REPLY TO THIS MESSAGE. THIS EMAIL ADDRESS IS NOT MONITORED.
Ticket URL: http://bugs.horde.org/ticket/12442
------------------------------------------------------------------------------
Ticket | 12442
Updated By | Jan Schneider <jan at horde.org>
Summary | Show available task lists in "Quick Add" window
Queue | Nag
Version | Git master
Type | Enhancement
State | Feedback
Priority | 2. Medium
Milestone |
Patch | 1
Owners |
------------------------------------------------------------------------------
Jan Schneider <jan at horde.org> (2013-07-11 10:56) wrote:
>>> 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.
More information about the bugs
mailing list