[Tickets #14698] Error in new feature: export of tags as iCal categories

[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/14698
------------------------------------------------------------------------------
  Ticket           | 14698
  Erstellt Von     | wahnes at uni-koeln.de
  Zusammenfassung  | Error in new feature: export of tags as iCal categories
  Warteschlange    | Kronolith
  Version          | 4.2.23
  Typ              | Bug
  Status           | Unconfirmed
  Priorität        | 2. Medium
  Milestone        |
  Patch            | 1
  Zuständige       |
------------------------------------------------------------------------------


wahnes at uni-koeln.de (2017-09-26 10:22) hat geschrieben:

The new feature introduced in Kronolith 4.2.23 that is supposed to  
allow better access to tags assigned to an event when accessing via  
CalDAV (iCal export) does not work realiably. Tags are supposed to be  
mapped to iCal Categories and in the code of kronolith/lib/Events.php  
there is a special case that handles events that have got exactly one  
tag (or category, for that matter).

When running version 4.2.23 of Kronolith, there will be loads of error  
messages in the log file that read like this when users use CalDAV to  
access Kronolith:

NOTICE: HORDE [kronolith] PHP ERROR: Undefined offset: 0 [pid 12345 on  
line 799 of "[...]/kronolith/lib/Event.php"]

This error is introduced by the fix for bug #14057 or more precisely  
the commit  
https://github.com/horde/horde/commit/72560bfc1e01282cec6e9c8fdbdebfbe39a5809f#diff-89c46998429999e8bfbc8f5d372bf0d0

 From my perspective, it looks like there two things wrong with this  
code change:

1. The right parenthesis seems to be at the wrong spot when calling count().
2. The assumption that an array with only one element will have that  
element at position 0 does not hold.

The attached patch does fix the issue at hand in a way, but it does  
this by accessing "$this->_tags" directly instead of using  
"$this->tags" so this is probably not good coding. Unfortunately, I  
don't know how to do it the right way.

The problem with using "$this->tags[0]" as in the current version is  
that the tag/category in the "$_tags" array is not guaranteed to be at  
index 0 of the array. When debugging this and adding a line that reads

Horde::debug($this->tags);

one can see from the debug output that the $this->tags array may look  
like this in practice:

array(1) {
   [242]=>
   string(10) "Geburtstag"
}

array(1) {
   [283]=>
   string(6) "Urlaub"
}

So even though that the array has got exactly one element, there is no  
"$this->tags[0]"