| 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 (5344 days ago) |
| Due | |
| Updated | 2010-04-22 (4167 days ago) |
| Assigned | 2007-06-15 (5209 days ago) |
| Resolved | 2007-06-18 (5206 days ago) |
| 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)
Assigned to Chuck Hagenbuch
Assigned to
State ⇒ Assigned
Priority ⇒ 3. High
Summary ⇒ Use horde.shares.turba.sourcename so Turba can use baseline Share driver
State ⇒
Priority ⇒ 2. Medium
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!
Type ⇒ Bug
State ⇒ Unconfirmed
Priority ⇒ 1. Low
Summary ⇒ Turbas handling of shares is problematic
Queue ⇒ Turba
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?