6.0.0-git
2020-01-29

[#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 2007-01-31 (4746 days ago)
Due
Updated 2010-04-22 (3569 days ago)
Assigned 2007-06-15 (4611 days ago)
Resolved 2007-06-18 (4608 days ago)
Milestone Turba 2.2
Patch No

History
2007-06-18 05:03:45 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.
2007-06-17 03:23:34 Chuck Hagenbuch Summary ⇒ Flatten Turba shares to not rely on Share hierarchy or use custom attributes
 
2007-06-17 03:23:09 Chuck Hagenbuch Summary ⇒ Flatten Turba shares to not rely on Share hierarchy
 
2007-06-17 03:15:55 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)
2007-06-15 20:03:39 Chuck Hagenbuch Comment #3
Assigned to Chuck Hagenbuch
Assigned to Horde DevelopersHorde Developers
State ⇒ Assigned
Priority ⇒ 3. High
Reply to this comment
This really needs to be done for Turba 2.2.
2007-01-31 17:49:05 Chuck Hagenbuch Comment #2
Summary ⇒ Use horde.shares.turba.sourcename so Turba can use baseline Share driver
State ⇒
Priority ⇒ 2. Medium
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!
2007-01-31 14:54:32 wrobel (at) pardus (dot) de Comment #1
Type ⇒ Bug
State ⇒ Unconfirmed
Priority ⇒ 1. Low
Summary ⇒ Turbas handling of shares is problematic
Queue ⇒ Turba
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