[Tickets #11310] Re: Kolab_Storage: Multiple folders (=shares) with the same name get ignored

[bugs at horde.org]

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

Ticket URL: http://bugs.horde.org/ticket/11310
------------------------------------------------------------------------------
  Ticket             | 11310
  Updated By         | Gunnar Wrobel <wrobel at horde.org>
  Summary            | Kolab_Storage: Multiple folders (=shares) with the same
                     | name get ignored
  Queue              | Horde Framework Packages
  Version            | Git develop
  Type               | Bug
-State              | Unconfirmed
+State              | Assigned
  Priority           | 1. Low
  Milestone          |
  Patch              |
-Owners             |
+Owners             | Jan Schneider
------------------------------------------------------------------------------


Gunnar Wrobel <wrobel at horde.org> (2012-08-21 12:09) wrote:

Known problem and I consider the Horde applications (or the share  
system) to be the bottleneck here.

I did not analyze the situation in detail again. But as far as I know  
the display of shares does not take duplicate names into account. It  
also varies between the different Horde groupware applications. Within  
the applications the display of share names is usually constructed  
within the specific view. As a result you have some views that display  
the share owner and some don't.

Kolab suggests the following scheme for displaying resources:

http://wiki.kolab.org/UI-Concepts/Folder-Listing

The underlying share system would provide the necessary information to  
render the short hand notation described on the page linked above. But  
I don't think it makes much sense to implement this in each and every  
groupware application.

I think the easiest way to allow Kolab users to distinguish the  
various resources is to extend the Share system so that it can provide  
a clean list of display names. This would then be used within the  
different application.

In any case I think it makes more sense if Jan takes a closer look at  
this one.