[Tickets #7907] assignee parameter in task (nag) raises php-error on task objects create with former nag versions

[bugs at horde.org]

DO NOT REPLY TO THIS MESSAGE. THIS EMAIL ADDRESS IS NOT MONITORED.

Ticket URL: http://bugs.horde.org/ticket/7907
------------------------------------------------------------------------------
  Ticket             | 7907
  Created By         | m.gabriel at das-netzwerkteam.de
  Summary            | assignee parameter in task (nag) raises php-error on
                     | task objects create with former nag versions
  Queue              | Kolab
  Type               | Bug
  State              | Unconfirmed
  Priority           | 1. Low
  Milestone          |
  Patch              |
  Owners             |
------------------------------------------------------------------------------


m.gabriel at das-netzwerkteam.de (2009-01-27 17:40) wrote:

i upgraded a kolab driven nag version without support for the  
,,assignee'' field (it has been recently added, hasn't it?) to a nag  
version that implements the ,,assignee''-field (cvs checkout from  
20081223).

when opening the task list with the cvs-20081223 nag version i get the  
following php-error:

Warning: in_array() [function.in-array]: Wrong datatype for second  
argument in  
/usr/local/share/_horde-versions_/horde4-cvs+git-20081223/horde/nag/templates/list/task_headers.inc on line  
33

i have looked at the code a bit and it looks like the Nag_Task object  
construction completely relies on the fields in the storage backend.  
in my case i have ,,old'' kolab task objects that miss the  
,,assignee''-field. if only the fields of my old kolab task object  
form the properties of my horde Nag_Task object then of course the  
,,assignee''-field is missing in the Nag_Task object that ends up with  
the above php-error.

to my point of view a Nag_Task object construction should setup the  
properties from backend, if missing there null properties should be  
created in the Nag_Task. currently, something similar seems to be done  
when saving the Nag_Task object back to the kolab backend (it is done  
in the kolab backend, i think...).