6.0.0-alpha14
6/19/25

[#4960] Flatten Turba shares to not rely on Share hierarchy or use custom attributes
Summary Flatten Turba shares to not rely on Share hierarchy or use custom attributes
Queue Turba
Queue Version HEAD
Type Bug
State Resolved
Priority 3. High
Owners chuck (at) horde (dot) org
Requester wrobel (at) pardus (dot) de
Created 01/31/2007 (6714 days ago)
Due
Updated 04/22/2010 (5537 days ago)
Assigned 06/15/2007 (6579 days ago)
Resolved 06/18/2007 (6576 days ago)
Github Issue Link
Github Pull Request
Milestone Turba 2.2
Patch No

History
06/18/2007 05:03:45 AM Chuck Hagenbuch Comment #5
Taken from Horde DevelopersHorde Developers
State ⇒ Resolved
Reply to this comment
Hallelujah, this is done. Might be kinks but those can be separate bugs.
06/17/2007 03:23:34 AM Chuck Hagenbuch Summary ⇒ Flatten Turba shares to not rely on Share hierarchy or use custom attributes
 
06/17/2007 03:23:09 AM Chuck Hagenbuch Summary ⇒ Flatten Turba shares to not rely on Share hierarchy
 
06/17/2007 03:15:55 AM Chuck Hagenbuch Comment #4 Reply to this comment
Right now Turba relies on custom attributes that we need to go away
for it to work with a generalized share driver. The fix as far as I
can tell is to use the source name as part of the group_uid instead
of as an attribute.
Mostly for my own benefit: this wasn't quite right. Turba relies on 
hierarchical shares, meaning that the share ids carry way too much 
meaning. It also relied on a number of custom share attributes. Both 
of these prevent us from using a generalized, fast SQL share driver, 
for example, and when it was a possibility for that driver to be 
written soon, Turba needed its own code so it wouldn't break.



From further looking, we're going to need some sort of 'params' key 
in any future Share driver so that things like virtual address books 
can be stored as shares and not require a separate database, so I'll 
be putting some things back localized in that key. The list of 
attributes that share backends will be required to store is:



owner

name

desc

params



(that doesn't include either "share name", which is really an id, or 
the numeric id currently; this should be localized to one id value 
which isn't carrying excess meaning so that the backend can assign it 
as necessary, and it doesn't include permissions)
06/15/2007 08:03:39 PM Chuck Hagenbuch Comment #3
State ⇒ Assigned
Assigned to Horde DevelopersHorde Developers
Assigned to Chuck Hagenbuch
Priority ⇒ 3. High
Reply to this comment
This really needs to be done for Turba 2.2.
01/31/2007 05:49:05 PM Chuck Hagenbuch Comment #2
State ⇒
Priority ⇒ 2. Medium
Summary ⇒ Use horde.shares.turba.sourcename so Turba can use baseline Share driver
Reply to this comment
Right now Turba relies on custom attributes that we need to go away 
for it to work with a generalized share driver. The fix as far as I 
can tell is to use the source name as part of the group_uid instead of 
as an attribute.



Btw, this is an issue so I'm changing the summary, etc., but please 
ask development questions on the dev list initially. Thanks!
01/31/2007 02:54:32 PM wrobel (at) pardus (dot) de Comment #1
Priority ⇒ 1. Low
Type ⇒ Bug
Summary ⇒ Turbas handling of shares is problematic
Queue ⇒ Turba
State ⇒ Unconfirmed
Reply to this comment
The way turba currently handles shares differs from the other 
groupware applications. From the commit message when the turba share 
driver was splitted from the Share package 
(http://cvs.horde.org/co.php?r=1.1&f=turba%2Flib%2FShare.php) I 
understand that there have been specific reasons for this split but it 
is not completely clear to me what these reasons were. Is this a very 
complex issue or something that could be resolved by fixing turba at 
two or three different places?

Saved Queries