[Tickets #14067] selecting from a large number of to-dos

[noreply at bugs.horde.org]

BITTE NICHT AUF DIESE NACHRICHT ANTWORTEN. NACHRICHTEN AN DIESE  
E-MAIL-ADRESSE WERDEN NICHT GELESEN.

Ticket-URL: https://bugs.horde.org/ticket/14067
------------------------------------------------------------------------------
  Ticket           | 14067
  Erstellt Von     | birnbacs at gmail.com
  Zusammenfassung  | selecting from a large number of to-dos
  Warteschlange    | Horde Groupware
  Version          | 5.2.7
  Typ              | Enhancement
  Status           | New
  Priorität        | 2. Medium
  Milestone        |
  Patch            |
  Zuständige       |
------------------------------------------------------------------------------


birnbacs at gmail.com (2015-07-28 07:19) hat geschrieben:

This concerns Nag and especially its Nag_Api.

Retrieving tasks via getTasks() involves fetching all to-dos of a  
tasklist from the backend and sieving through the results. The only  
parameter for effectively restricting the search is the completed  
flag. There is no support for $start and $end parameters. Over the  
years a user's to-do list may accumulate a large number (thousands) of  
entries so that fetching to-dos from the backend will be an  
unnecessarily expensive operation. This may be relevant for displaying  
a user's "current status" that includes uncompleted to-dos as well as  
completed to-dos from the past week or so.

As retrieving a to-do may involve calculating recurrences, a simple  
parametrisation of the backend driver for $start and $end dates may  
not suffice. I suggest using an archive() function that marks a to-do  
as historic if it is marked as completed and there are no more  
recurrences in the future. This way all to-dos are kept in the  
tasklist and synchronising is not affected.

The archive() function could be called automatically on any change  
operation to a to-do, with a selectable threshold of age (e.g. all  
to-dos with a due-date in the past and a completed-date more than 4  
weeks ago is marked as historical).

getTasks() should support a corresponding parameter indicating if a  
search is to be made on live or archived to-dos.