Tickets :: Comment on [#4960] Flatten Turba shares to not rely on Share hierarchy or use custom attributes

* Your Email Address
* Spam protection	Enter the letters below: . .. .. ,._..___. \|__\|\| \| \./ \| _/ \| \|\|__\| \| _\|_./__.
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)
Attachment
Watch this ticket