Edit Access rights on Where-To articles

7 replies [Last post]
andras salamandra
Joined: 02/24/2009
User offline. Last seen 4 weeks 20 hours ago.
Printer-friendly version

It appears that the author of an article can edit it (and I assume the site admins can), but no one else can.
I don't think that's the appropriate security setting for "Where To:" documents, as each person who knows about a supplier should be encouraged to add them to the document.
Will the site support a more open editing policy for specific "Where To:" style documents?
If so, I'll be glad to create empty stub documents for each category so it's easy for the site admins to set the security all at once.
 

andras salamandra
Joined: 02/24/2009
User offline. Last seen 4 weeks 20 hours ago.
If the site software allows

If the site software allows it, perhaps the author of the article can choose which groups can edit the software?

Admin
Joined: 02/01/2009
User offline. Last seen 44 weeks 1 hour ago.
The article system (such that

The article system (such that it is, major improvements are high on my priority list) wasn't intended to work like a wiki. It's actually a pretty trivial change to allow everyone to edit everyone else's documents but I'm not going there unless/untill I get an official pronouncement that this is the way to go from the webminister and/or their Excellencies. I really don't want to have to deal with refereeing a bunch of "so and so killed my document" crap and the recursive revision management that comes with it.
 
For the time being it it shouldn't be difficult (via private message, forums, email, whatever) to contact the document's owner and request an update.

andras salamandra
Joined: 02/24/2009
User offline. Last seen 4 weeks 20 hours ago.
I'm suggesting the

I'm suggesting the following:

  1. The default security setting is "It's my article and you can't mess with it.",
  2. The article author can grant edit rights to one or more individuals, and/or to all individuals in one or more security groups (i.e., all registered users, all Attilium users, all Fighters).
  3. If the article author grants edit rights to others and those others mess up the article, the webminister's one and only required response is "I'm sorry for you.  I hope you will fix the document or find someone to do it.  Have a nice day."
andras salamandra
Joined: 02/24/2009
User offline. Last seen 4 weeks 20 hours ago.
If I create an article and

If I create an article and want to transfer ownership of it to someone else, is that a problem?  Pass the torch, if you will?

Admin
Joined: 02/01/2009
User offline. Last seen 44 weeks 1 hour ago.
 That's not a common feature

 That's not a common feature in web-based CMS's and definitely isn't supported natively in Drupal. It can definitely be done, but I'd either have to install a module for it or write some custom code to automate the process.

andras salamandra
Joined: 02/24/2009
User offline. Last seen 4 weeks 20 hours ago.
My experience with a CMS is

My experience with a CMS is www.DotNetNuke.com.  It has the security groups and access rights similar to what I've described built into the CMS framework.
It's not just a matter of changing a record value in a table from one user id to another?
The reason I asked was I could get the Where To: articles started from here in Addis Ababa, but I can't finish them.  I don't want to do a partial job and then make it harder for someone to finish it due to the security issues.  Nor do I want to be the owner of all Where To articles for all topics for all time! :)  
Hmmm...  Maybe they could just create their own article, copy my contents into it, and send me a message to delete mine.  That would work.
 

Admin
Joined: 02/01/2009
User offline. Last seen 44 weeks 1 hour ago.
There's several ways to go

There's several ways to go about this, the most simplistic being changing the uid column value that corresponds to the article in question in the node table. Trivial, but it only gets you semi-permanent ownership transfer to a single user. For delegation rights you have to have groups & group permissions stored in the db plus some kind of API to get at these, you need group membership tables, you also need a record of who has delegated authority to a given article on a node-by-node basis. OR you could hack the taxonomy module to permit delegating editing rights to user groups for all content in a given taxonomy. Or you could do it by vocabulary, OR you could have content associated with groups via the OG module and have content moderators assigned to groups, OR you can have sitewide content moderators, or some combination of the fifteen million other possible approaches to this problem space. What you're describing isn't particularly complex on the face of it, and it can definitely be implemented in short order with little or no coding involved on my part (there are modules available that do everything I've mentioned so far and a bunch more, especially Organic Groups). 
 
The other side of this equation is managing complexity. A lot of the features you're requesting are totally awesome, but hideously under-utilized, and every time I bolt on another module we take a slight performance hit (and the admin menu gets a little more complicated). We're approaching a point where I no longer have the luxury of installing features simply because someone thinks they're cool (even if that someone is me). I have to look at ROI at this point lest page load times creep up to unacceptable levels and sections of the admin menu start timing out. So far I have a single power user requesting this feature. If there are others in the community that think this would be useful now would be a good time to speak up.