| Summary | assignee parameter in task (nag) raises php-error on task objects create with former nag versions |
| Queue | Kolab |
| Type | Bug |
| State | Not A Bug |
| Priority | 1. Low |
| Owners | |
| Requester | m.gabriel (at) das-netzwerkteam (dot) de |
| Created | 01/27/2009 (6009 days ago) |
| Due | |
| Updated | 01/28/2009 (6008 days ago) |
| Assigned | |
| Resolved | 01/28/2009 (6008 days ago) |
| Github Issue Link | |
| Github Pull Request | |
| Milestone | |
| Patch | No |
State ⇒ Not A Bug
Priority ⇒ 1. Low
Patch ⇒ No
Milestone ⇒
Queue ⇒ Kolab
Summary ⇒ assignee parameter in task (nag) raises php-error on task objects create with former nag versions
Type ⇒ Bug
State ⇒ Unconfirmed
,,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...).