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 |
Taken from
State ⇒ Resolved
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.
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)
State ⇒ Assigned
Assigned to
Assigned to Chuck Hagenbuch
Priority ⇒ 3. High
State ⇒
Priority ⇒ 2. Medium
Summary ⇒ Use horde.shares.turba.sourcename so Turba can use baseline Share driver
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!
Priority ⇒ 1. Low
Type ⇒ Bug
Summary ⇒ Turbas handling of shares is problematic
Queue ⇒ Turba
State ⇒ Unconfirmed
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?