Hello Chris,
This Content Management Module is outstanding. And the Content Tab is exactly what we need to manage content per user.
One question though.
If a role (for instance authentificated user) is granted the "view user content list" right, the Content Tab doesn't display on the My account page of any user of that role.
Shouldn't the user be able to access the tab and list, access and edit his own nodes ?
On the other hand, if any role is granted the "filter and manage site content", any user of that role can :
- display the Content Tab on his My account page
- list, access and edit his own nodes
- list all nodes he is NOT granted to access or edit - (though he can't access or edit them)
This works fine.
Regards,
Pascal
Comments
Comment #1
Pascal.K commentedSorry, I meant CMF.
Comment #2
nunoveloso commentedHi Pascal!
Check your cache settings, please.Indeed it can be a good idea for a future implementation. But a similar feature already exists on the core.
But I will think about it.
What would you propose to improve this?
Tank you for your feedback!
BTW I didn't figured out why you said hello to Chris, there isn't any over here :-)
Comment #3
halcyonandon commentedI agree, what's great about this module is that it breaks from the "administer nodes" permission issue and allows none-administrators to manage content when they have the appropriate permissions to do so.
However, the user shouldn't see nodes unless that user has permission to edit... or there should be an additional field that shows whether the user can edit or not.
Currently, the only way a user can know which content items they can edit is to click the item, which brings them to the "you dont have permission to do that" message.
Comment #4
halcyonandon commentedI fixed this issue kind of on the fly, if someone wants to create a patch, by all means. Below is the code that replaces the while loop on and around line 55 of node.inc. What it does is adds a conditional that first displays all node content if the user's role has the permission to administer nodes, since that overwrites any specific permissions assigned to individual nodes. Then in the else statement, within the while loop it creates a variable that is defined as "edit any $node->type content". So then it uses this variable in a conditional where if the user has permission to edit a node, then build the table with only the permissible nodes...
Hope this helps.
Comment #5
nunoveloso commentedhalcyonandon, thank you for your collaboration. This is a good solution for the access management. I will try to add this feature in a next stable version of CMF, but I would prefer a DB oriented solution, i.e., a query that does not load all nodes that won't be displayed.
Great job!
Comment #6
Leeteq commentedFor sites where this is relevant, it is important that users does not see titles (or even get to know of their mere existence) of posts they are not allowed access to.
Comment #7
bomarmonk commentedDid anyone get this to work in Drupal 5? This is exactly the functionality I am looking for. I tried replacing the "while loop" at line 43 of node.inc for the Drupal 5 version: node.inc,v 1.1.2.2 2008/12/03 (the closest one I could find to what is described in post #4). Now the user CMF page returns zero nodes for my user. I'm not sure if I put this in the wrong place or if this needs some changing to work in Drupal 5. If someone can suggest how to do this in Drupal 5, I could possibly role a patch for node.inc. Thanks for the great module!
Comment #8
halcyonandon commentedThanks nunoveloso18,
Noticed something else... certain permissions don't fit the "edit any $node->type content" syntax, so keep that in mind if you're doing this...
I had to use
if (user_access($permType) || user_access('edit any blog entry') || user_access('edit announcements'))instead ofif(user_access($permType))So, this isn't the most elegant solution, especially if you're using a number of custom modules with unique permission names that need to be considered in this.
Comment #9
bomarmonk commentedI would also like to see the "node type" and "category filters" respect the access rights for the user's role. If so, the user specific CMF becomes much more user friendly. Why make the user sift through categories and node types that he or she can't touch? Thanks again for the great module!
Comment #10
nancydruI think we need to see if there is any value in using node_access().
Comment #11
nancydruSee also #485744: Users able to publish any content regardless of permissons via CMF's 'Update Options'. for an additional symptom.
Comment #12
KoCo commentedI agree with #8.
When for instance you want someone to edit only the publish/unpublish option, but they can't edit the node type.
The node types will not show up on the list.
I think it's better to use the conditional to toggle the edit link in the table, and additionaly a filter could then let the user choose wether or not they want the non-editable nodes listed.
p.s. you know, a great feat, would be a joint venture between the cmf and node override module.
Comment #13
nancydru@KoCo: You are probably right, but the two, as I understand it, operate at different times. But it is worth looking into. Please open a new feature request for both modules.
Comment #14
nancydruSee also #379366: Publish Settings, a permission?.
Comment #15
nancydruLooking at a database solution, the first problem is that we would have to know if they actually intend to update, because the access privilege depends on that. What I am thinking right now is that we can query the db for any nodes that the user has "view" access for and then we would have to further check for "update" before adding the "edit" link. I'm not crazy about all that extra overhead, so I am open to suggestions.
Comment #16
nancydruSince we have not found a good database solution here, I'm going to mark this as "won't fix." I revisit that status on occasion to see if I've changed my mind.
Comment #17
bomarmonk commentedAs the node access permissions are key to how my users are able to edit content on my site, this feature is important if I'm ever going to use CMF. Could you review the possibility of this feature again, as some time has passed? Thank you.