Support for update and delete permissions in tac_lite

Happy to give this a test run! You should make a version 2 dev module, you'd get a lot more eyeballs then.

So I have installed this patch and it seems, from my very limited testing, to work OK for the read access side of things. I now have two schemes. My first Scheme gives view permissions to one role, my second Scheme gives view permissions to another role. That seems to work well.

However, I can't figure out the update or delete permissions.

If I give "update" permissions to a role, nothing seems to happen. Should they be able to edit stories/content? Do they need any other special permissions flagged in the Access Control settings?
Currently they have nothing special. Giving them delete access doesn't seem to have any effect either, the nodes still appear to be ready only.

Edit: I have checked with the Devel Node Access block and the articles are getting the right permissions assigned. I think I just need to understand better.

Edit2: Ok, so I am totally stupid. I won't even explain my stupidity. This is working correctly - This post can basically be ignored

I apologise for what probably are dumb questions, but I can't find anywhere on the Druapl site where it's documented how these two new roles should work and if they need to work in conjunction with other permissions. Can anyone give me some pointers here?

I do like the new admin interface though, it was quite intuitive to work with.

Tim

Yea, as I said, you can ignore that whole post pretty much.

I was not setting the permissions correctly, thus why update wasn't working.

I now have two Schemes, one for Read Access and one for Edit Access. I haven't tested Delete access sorry.

They seem to be working well and "playing together" properly.

Nice! :) :) :)

I'll test it in a minute. One question though, you mention update and delete permissions. Does update mean create too, or would that be another separate permission?

hmm, how can i create a new Scheme under Access Control for tac_lite? Also, see the attached screen shot on how formated the selected vocabulary when under Scheme 1. I think each list should be under its corresponding role heading...

Ok, you can ignore my previous post, I didn't install the diff patch correctly, now things seem to be working ok :)

So, in testing, it seems like the update permission is not the same as "create" permission. A user can tag a node with a taxonomy that he doesn't have update permission, but then later can't update it...

Dave, I am wondering what made you decide to omit a create permission (since that would be extremelly useful). FYI, my knowledge of Drupal's backend is very limited, I've been getting the hang of things for a couple of months now.

Hi Dave, thanks for the thorough reply.

What makes more sense to me is to be able to separate view and create, let me explain why.

I imagine that in most organizations, there are users that have permissions to add certain info to certain sections on their website, while everyone has access to see it. Like the manager of a team should be able the only person allowed to create (and also update/delete) a post in the team's taxonomy. However, everyone should have access to see what has been posted. I can think of dozens of examples like this, where a single user needs create/update/delete permission for a tag, while everyone in the company should be able to access the content of said tag.

I understand what you said about create permissions and how Drupal works in the back-end, and the fact that tac_lite wants to leave minimal footprint upon installation, which it already does nicely since it doesn't create tables in the database...

What you suggest sounds pretty good, a hook_form_alter that simply limits what is shown in the dropdown list of tags to what the user has rights to "create". This wouldn't be hard coded into Drupal since if someone tried to alter the form and post it, it would go through without issues.... What do you think? It would pose as a security issue? I think this solution would work for 99% of the Drupal users out there.

Oh, and regarding your other question. Obviously, the nice thing would be to have update and create separate, but integrating the hook_form_alter under the update permission is good too... I don't see a scenario where the author of a node shouldn't be allowed to edit it. Of course, the first solution gives more options to the administrator for complex permission schemes, which is always nice.

And a suggestion on how the interface in the admin/user/access/tac_lite could be, if you decide to implement the hook_form_alter method.

Under "Schemes", there can be a "Update -> Create?" title, and a checkbox that says "Mimic update permissions as create permissions. If checked, when the user wants to create a node, he/she will only see taxonomy words that he/she has permission to update. Note that this feature will simply modify the outputed form to the user, and not set any actual "create" permissions as the Drupal system sees it. As such, an advanced user could post a modified form and go past this."

Or something like that...

I don't understand your example. Following what you said:

User X tags a story with "dogs" and "animals"
User Y can't view or update "dogs" nor "animals"

Then you say "Then user Y updates that node..."

How can User Y update that node if they can't update "dogs" nor "animals" ?

Why would the node be tagged only cats once Y updates it? This is normal Drupal behavior?
The node looses the other two tags?

I imagine that by using the Taxonomy Access Control module (http://drupal.org/project/taxonomy_access), using your example above, you'd run into the same problem?

How about the cascading of permissions?

If my vocabulary is as shown below,

Vocab > Term > Term
Animals > dogs > german shepboard

In the case where I have permission to view, edit, delete animals tags, will the permission cascade down to german shepard tags?

I can see this module being used together with taxanomy_default which will allow the fixing of permission for a particular content type. This will then make it similar (functionally) to content access... Which is a more efficient way to do things?

Oh ok. I understand it now. Thanks.

Are you ready to relaese tac_lite with the 2 new permission of update + edit?

Meanwhile, I will go take a look at the individual user permission UI to see if I have any suggestions.

Do you propose to find a fix for the problem you name in #16?

In response to your request for opinions in #9, my personal opinion is that having the create permission functionally equivalent to the update permission (even if you do this with a hook_form_alter rather than hook_access) is signficantly more intuitive than having it influenced by the view permission. If that doesn't make TAC lite much less lite, I'd be in favour of doing that.

In the meantime, I will have a go at the hook_form_alter within my own custom node types...