Alter taxonomy on OWN X content permission?
Rosamunda - January 20, 2009 - 03:16
| Project: | Comment alter taxonomy |
| Version: | 5.x-1.x-dev |
| Component: | Code |
| Category: | feature request |
| Priority: | normal |
| Assigned: | Unassigned |
| Status: | active |
Jump to:
Description
This module rocks!
The only think that I think misses is more permissions, so in example, only the author´s node can change terms.
Something as "alter taxonomy on OWN X content" and "alter taxonomy on ALL X content"
#1
Do you mean that you want to have the option that the author of a node is the only one that can alter the terms of the node via comments? What's your use case for that? Why not just alter the terms of the node itself by editing the node?
#2
I see. But I imagine this useful as a easier, lighter ticketing system for, ie. bugtracking.
So, people on role "client" can create a new node of the type "problem".
When user A creates a problem, only himself (and i.e. role "support") can change the status to "closed", and not other clients, that can view the node, but not close it.
#3
* bump *
:)
#4
There's no need to bump this. I'm not really interested in making comment_alter_taxonomy into a more lightweight bug tracking system, since we already have a few real bug tracking systems (like project/project_issue and casetracker), so I'm tempted to won't fix this request. I'm pretty sure the project_issue module can do exactly what you request because you can configure the permissions for what roles can set issues to any particular status.
However I haven't had a chance to look at the code and see how difficult it would be to implement this request. One potential problem is that the module already creates a lot of permissions (one per content type). This request would instead result in 3*n permissions, where n is the number of content types. That's a lot of permissions for one module to provide.
#5
I see. I´m sorry for bumping this, Adam, I just wanted to know what did you think about the info that I´ve added to this issue.
I think that you´re right about the bug tracking system, this module shouldn´t be just another bug tracking system. But...
Those other modules are, as you´ve saig bug tracking systems. Primarily used for software / hosting sites. If people has a consulting firm, or want to use this in education, as a issue tracking system for particular classes, this module is far better, because doesn´t have a domain specific objective.
Anyway, I understand that the feature that I´ve requested maybe isn´t esencial, nor important, or maybe there aren´t out there enough users who would want this. And could be a lot of work or complexity added.
#6
I think this makes sense. Shouldn't be that hard to implement. Volunteers?