The core Drupal permission system is nice for simple permissions but not up to the detailed level of permissions that a good forum needs. We need not only global permissions but also forum-specific ones. For example:
create threads
create threads in foo
create threads in bar
create foothreads [a subtype of thread]
create foothreads in foo
create foothreads in bar
etc...
In addition, we need to be able to hook into OG's permission system for group forums.
Trying to handle all that in hook_permission() is insanity.
So we need a better system. Concept of a hierarchical permission system looks interesting but is in early discussion with no existing implementation for me to follow. I haven't looked at it carefully and taken the time to really try to understand it but, on a quick read, it was a bit over my head, especially #14.
I could really use some help in this area with anything from brainstorming to code.
Thanks,
Michelle
Comments
Hi, i'm still new to drupal,
Hi, i'm still new to drupal, and not a coder as yet, but couldnt in tie in with acl for the permissions
http://drupal.org/project/acl
already ported to d8
just a thought anyway
edit. or i thought it had. cant seem to find it now, my bad. sorry
Possibly
I don't really know anything about it and it doesn't have a useful readme. The project description says it's for nodes. I have no idea if it could handle this sort of thing but I can try digging into the code to see unless someone who is familiar with it pops up with more info. :)
Thanks,
Michelle
to some up, alongside
to some up, alongside http://drupal.org/project/forum_access it allows you to give moderator rights by role or by specific user on a forum by forum basis ,works well with adv forum (your old puppy :) ) and basic forum, well, on my test site anyway, (sorry nothing to show yet)
hook_access
Using hook_perms would certainly grow out of administrative control very quickly.
Now this is probably stating the obvious ... but it seems to me that you could build a custom permission system that ties in to a custom access hook checked for every forum/thread entity ... the trick being that your access hook needs to either know or be passed the context under which the entity is being accessed (in other words, what $operation is currently being invoked). Tying things to an access callback instead of permissions callback also frees you up to design/implement your own admin UI.
It looks like http://drupal.org/project/accessapi may have started something along these lines, but the project description indicates they ended up going a different direction ... it may be worth hunting down IceCreamYou and picking their brain with regards to the topic.
Also worth keeping an eye on
Also worth keeping an eye on http://drupal.org/node/777578 to see where that develops
More thoughts
I read the other responses and will look into those, thanks.
Had some other thoughts as well, though (which may dupe what was said above as I haven't looked, yet)... The rather than a hook, couldn't we just ask the entity if the user can do X to it? The entity knows itself and its context. So it seems like it could handle it. This is just a thought at this point... I haven't played with any code and, unfortunately, have someplace to be tonight.
Michelle
.
As mentioned earlier in this discussion, I've taken a stab at new access models. My particular use case was trying to create a generic framework to support user-controlled privacy settings. After 4 attempts I think I have an architecture that will work, but I haven't actually implemented it so I can't prove it.
Anyway, I've at least thought a lot about access control. When designing a new access control system you need to ask a few questions:
My experience is that writing a new access control system is a really hard problem, especially making it generic. There can be shortcuts though; ideally you can simplify things down to relationships in database tables that don't exist for the purpose of access control. In other words you want to be able to add e.g.
WHERE nid IN (SELECT nid FROM {users} WHERE uid = %d)to a Views query instead of having to deal with updating access records manually all the time. Problem is as soon as you start doing that then you end up with humongous queries that have to take into account every possible case, particularly when you start mixing in User Relationships/Flag Friend etc.In terms of the code in hook_permissions, it really shouldn't be that bad for the most part. All you have to do is loop over your (sub-)content-types and substitute their data into a template that you push onto the permissions array. It's the same kind of thing that Views does to let people create blocks and pages through the UI.
Also note:
.
I think that's what it comes down to here. While there will be some overlap, Artesian is going to have a lot of very specific needs. I think trying to use (or, worse, write!) a generic access control module for this is going to be more headache than it's worth. I normally try to avoid re-inventing the wheel but sometimes you have to do that when you make a vehicle that won't work with existing wheels without a lot of hacking.
The CUD part of CRUD shouldn't be that complex to control. (Famous last words? LOL!) It's the R that gets tricky. A given entity may be read in many different ways, included in lists, etc. All the CUD action is going through Artesian; R access needs to account for stuff outside of Artesian. I'm pretty sure I'm going to need more help with that but will start out with the CUD and see how it goes.
As for hook_permission, the code may not be so bad but the UI would be absolutely horrendous if I use core's permissions for this. There would be pages and pages worth just for Artesian. I think I'm better off doing my own thing and modeling the UI after what forum apps do.
As for your questions:
1 - Depends on which permission. Many of them make sense to put right on the forum configuration.
2 - For the most part, it will be role X has permission Y in forum Z.
3 - Generally speaking, just role based. I'm not going to try to get into UR and that headache. If someone wants to, patches welcome. ;)
4 - I don't know, yet. As I said above, I'm likely going to need help there.
5 - This is the cause of my saying "for the most part" and "generally speaking". The wrench in the role based philosophy is that I want to integrate with OG so I need to latch onto their perms as well. Since I don't, yet, know how their permissions work, I have no idea how hard that will be. That's one of the things I need to research.
Thanks for the "food for thought" :)
Michelle
.
Right. Yeah.
One option, if you want mostly a role-based model, is to leverage the {role_permissions} table manually without actually using hook_permissions(). That might make it possible to make all your access decisions as SQL conditions as well as probably use user_access() without every having your custom permissions show up in the permissions form.
Hmmm
Now that's something I hadn't thought of. I definitely am going to use roles as those are roughly the same as user groups in forum apps but I never thought about using its permission table directly. Will have a look at that.
Thanks!
Michelle
Michelle, how about Taxonomy
Michelle, how about Taxonomy Access Control or TAC Lite?
http://drupal.org/project/taxonomy_access
http://drupal.org/project/tac_lite
[EDIT]Sorry. I saw now that this post belongs to a new forum project. My bad.[/EDIT]