I want to start working on an implementation for the Node Permissions that have been talked about. While I have no idea just yet how I'll do it all, I have an idea of how the project can be divided into manageable "parts". Node Permissions, as it is, will probably result in a lot of refactoring in the Drupal core (and I'm not familiar enough with the system to be the sole designer).

I've been randomly thinking, and I've broken down the idea into smaller, hopefully more-manageable parts that can be integrated on an incremental basis.

  1. Users can belong to Multiple Roles. I started this and then gave up when I realised I didn't know what I was doing, but I'll probably start it up again. A new database table (something like "users_in_roles" needs to be added that maps the uid to an rid. (Right now, the user table maps directly to the role table.) All of the SQL will need to be changed, of course. My primary problem with this, as of now, is Serialization in the user.module. I don't know what it does. I have a feeling that it might have to do with authentication in the Drupal Network - if that's the case, then adding Multiple Roles might break cross-compatibility.
  2. Adding a moderator to roles. Assuming that people like the idea of appointing a moderator to look after a user role, this would be one next 'feature' step.
  3. Adding permissions per taxonomy We can adapt the node system to start checking permissions baesd on the taxonomy permissions. Not sure what needs to be done here, though.
  4. Adding the set of "standardized" permissions. The Permission Requirements thread mentions a few schemes for standardized permissions, and I think this is a great idea - it'll cut down on the "maintain book" vs. "edit book" vs. "administer book" kind of permissions we see right now. This will also probably break every
  5. Customized User Groups. This should be done in tandem with per-node permissions, since one without the other isn't very useful.
  6. Per-node Permissions. When taxonomy permissions are set, then per-node permissions shouldn't be a big deal.

I'm really just brainstorming at this point and I haven't looked too much in detail for many of the above issues (especially permissions). However, if we plan to implement this well, I am very confident that database renormalization must occur (therefore breaking a lot of SQL) and the Module APIs for permissions will change (therefore requiring a lot of module rewrites). As a result I plan to start looking at the code in detail so that, if we do make major changes, there'll be plenty of time before Drupal 4.5.0 is released to look at the design issues.

Yeah, so as I said, I'm sort of thinking out loud here, but if anyone has any insights please share them.

So that reminds me - what kind of necessary steps are needed to propose changes to the core Database tables?


killes@www.drop.org’s picture

Working code has proven a good tool to get something into Drupal core.

irwin’s picture

It's difficult to make a change that affects so much of the User Module which is why I was asking for advice - especially with the serialization of the user data, which I don't understand the purpose of. :)

-- Irwin

moshe weitzman’s picture

the design choice to use a serialized 'data' column came from

- admins don't want to change their schema often
- if we can avoid joining to a second table, do so.

that design choice hasn't worked out too well, and in fact dries is currently rewriting profile.module as a result.

irwin’s picture

I'm planning to replace the rid field (it is an int) that you see a lot in thge user.module with an array of the rids. I think, if I get that up, it'll automatically compensate for the serialized data (since PHP will automatically change arrays). It doesn't SEEM like that will have a grave effect on the system (no more anyway than completely modifying tables around).

Drupal, in its Drupal Network ID passing, doesn't actually send User Role information, right? If the scope of user table changes is limited to the local site then life will be a lot easier.

I'm in the process of editing tables and moving queries around - I haven't had the opportunity to make it all work yet, but it's moving.

Thanks for your reply,

-- Irwin