Question about Drupal ACLs
Hello, I'm new to the mailing list so I'm sorry if this has been covered before. I'm curious to see if there are built in mechanisms or maybe other modules that will allow me to assign ACLs to specific nodes. In particular I want to show or hide menu items and restrict access to their linked nodes based on a user's role. So far I haven't found anything (that works) fitting this description in Drupal or it's modules. So my question is: Did I miss it, and if I didn't would people in the community be interested in a module that provided this level of access control? Thanks for your time! -- Nick Whalen <nick@gottathink.com> Gottathink, LLC
Organic groups might be what you're looking for? I think of it as like the node access by role except with an extra level of indirection. If not, it might at least provide some interesting ideas about manipulating the node_access table. - Alan On 7/10/06, Nick Whalen <drupal_acls@gottathink.com> wrote:
Hello,
I'm new to the mailing list so I'm sorry if this has been covered before.
I'm curious to see if there are built in mechanisms or maybe other modules that will allow me to assign ACLs to specific nodes. In particular I want to show or hide menu items and restrict access to their linked nodes based on a user's role.
So far I haven't found anything (that works) fitting this description in Drupal or it's modules. So my question is: Did I miss it, and if I didn't would people in the community be interested in a module that provided this level of access control?
Thanks for your time!
-- Nick Whalen <nick@gottathink.com> Gottathink, LLC
-- Alan Dixon, Web Developer http://alan.g.dixon.googlepages.com/
I'm curious to see if there are built in mechanisms or maybe other modules that will allow me to assign ACLs to specific nodes. In particular I want to show or hide menu items and restrict access to their linked nodes based on a user's role.
So far I haven't found anything (that works) fitting this description in Drupal or it's modules. So my question is: Did I miss it, and if I didn't would people in the community be interested in a module that provided this level of access control?
To do this in a module, I guess you'd need to do something like this: 1. Add a role selection element to the node edit forms through form_alter, plus a #submit function that saves into a table with fields nid, rid. 2. Add a function example_node_roles($nid) to return the roles with access to a given node. 3. In a _menu hook, something like this: global $user; if (!$may_alter) { if (arg(0) == 'node' && is_numeric(arg(1)) && !arg(2)) { $items[] = array( 'path' => 'node/'. arg(1), 'access' => count(array_intersect(array_keys($user->roles), example_node_roles(arg(1)))) ? TRUE : FALSE ); } }
To do this in a module, I guess you'd need to do something like this:
4. example_db_rewrite_sql() add a join on the new table and betwen the new table and {role} rl and a where clause like WHERE rl.rid IN ('. implode(',', array_keys($user->roles) .')';
When editing a node you are given the opportunity to change the Authored by and Authored on fields. In many cases I have multiple people changing pages and would rather show Changed by and Changed on, but both should be present in the node. So there are really two changes necessary. One to add the new fields and default them to the current logged on person and current date and the other to somewhere in settings say whether the created or changed info should be shown. Currently you can either show created or not.
Walt Daniels wrote:
When editing a node you are given the opportunity to change the Authored by and Authored on fields. In many cases I have multiple people changing pages and would rather show Changed by and Changed on, but both should be present in the node. So there are really two changes necessary. One to add the new fields and default them to the current logged on person and current date and the other to somewhere in settings say whether the created or changed info should be shown. Currently you can either show created or not.
You can easily show changed on info via theming. You could quite easily create a module which adds a 'changed_by' using hook_nodeapi. These aren't things everybody wants, but I can see where many sites could use them.
I see a created field and a changed field in the node table, but I think these are dates not authors. There is also a uid which I suspect is the author, perhaps tied to the authmap table?? But no change author. So what I want may not be as simple as you imply.
-----Original Message----- From: development-bounces@drupal.org [mailto:development-bounces@drupal.org] On Behalf Of Earl Miles Sent: Wednesday, July 12, 2006 10:44 PM To: development@drupal.org Subject: Re: [development] Created vs modified
Walt Daniels wrote:
When editing a node you are given the opportunity to change the Authored by and Authored on fields. In many cases I have multiple people changing pages and would rather show Changed by and Changed on, but both should be present in the node. So there are really two changes necessary. One to add the new fields and default them to the current logged on person and current date and the other to somewhere in settings say whether the created or changed info should be shown. Currently you can either show created or not.
You can easily show changed on info via theming.
You could quite easily create a module which adds a 'changed_by' using hook_nodeapi.
These aren't things everybody wants, but I can see where many sites could use them.
Walt Daniels wrote:
I see a created field and a changed field in the node table, but I think these are dates not authors. There is also a uid which I suspect is the author, perhaps tied to the authmap table?? But no change author.
So what I want may not be as simple as you imply.
It is as simple as: Creating a table with the fields you need (in this case, as I said, 'changed_by'), and a 'nid' to tie it to the node table. Implementing hook_nodeapi for 'insert' and 'update' events, writing the appropriate information (in this case, putting $user->uid into changed_by) for 'load' events loading the appropriate information. And do the rest via theming. It is as simple as I say (not imply).
Ok, I will try to do that but I have never written a module so it is not going to be as easy as you make it sound. It looks like I could also add a reason field to the table and let the changer explain what they did, but that would need something more complicated to keep track of the history of changes, rather than just the last change. It all sounds like something someone has already done. For example how do wikis keep track of what happens?
-----Original Message----- From: development-bounces@drupal.org [mailto:development-bounces@drupal.org] On Behalf Of Earl Miles Sent: Wednesday, July 12, 2006 11:33 PM To: development@drupal.org Subject: Re: [development] Created vs modified
Walt Daniels wrote:
I see a created field and a changed field in the node table, but I think these are dates not authors. There is also a uid which I suspect is the author, perhaps tied to the authmap table?? But no change author.
So what I want may not be as simple as you imply.
It is as simple as:
Creating a table with the fields you need (in this case, as I said, 'changed_by'), and a 'nid' to tie it to the node table.
Implementing hook_nodeapi
for 'insert' and 'update' events, writing the appropriate information (in this case, putting $user->uid into changed_by)
for 'load' events loading the appropriate information.
And do the rest via theming.
It is as simple as I say (not imply).
On Wed, 12 Jul 2006, Walt Daniels wrote:
Ok, I will try to do that but I have never written a module so it is not going to be as easy as you make it sound. It looks like I could also add a reason field to the table and let the changer explain what they did, but that would need something more complicated to keep track of the history of changes, rather than just the last change.
It all sounds like something someone has already done. For example how do wikis keep track of what happens?
Yes, this inded sounds like something already done. The revision system keeps track of previous versions. Just not the user who changed something. Gabor
Even the "reason" field already exists in the node_revisions table...it's called 'log'. On 7/13/06, Gabor Hojtsy <gabor@hojtsy.hu> wrote:
On Wed, 12 Jul 2006, Walt Daniels wrote:
Ok, I will try to do that but I have never written a module so it is not going to be as easy as you make it sound. It looks like I could also add a reason field to the table and let the changer explain what they did, but that would need something more complicated to keep track of the history of changes, rather than just the last change.
It all sounds like something someone has already done. For example how do wikis keep track of what happens?
Yes, this inded sounds like something already done. The revision system keeps track of previous versions. Just not the user who changed something.
Gabor
It doesn't sound like a bad extension to the existing node revision system. It would probably be useful to a lot of people, having an audit trail with revisions... On Thu, 2006-07-13 at 10:32 -0400, Earl Dunovant wrote:
Even the "reason" field already exists in the node_revisions table...it's called 'log'.
On 7/13/06, Gabor Hojtsy <gabor@hojtsy.hu> wrote: On Wed, 12 Jul 2006, Walt Daniels wrote:
> Ok, I will try to do that but I have never written a module so it is not > going to be as easy as you make it sound. It looks like I could also add a > reason field to the table and let the changer explain what they did, but > that would need something more complicated to keep track of the history of > changes, rather than just the last change. > > It all sounds like something someone has already done. For example how do > wikis keep track of what happens?
Yes, this inded sounds like something already done. The revision system keeps track of previous versions. Just not the user who changed something.
Gabor
He might want to use the vid from node_revisions in the new table instead on nid. On 7/12/06, Earl Miles <merlin@logrus.com> wrote:
Walt Daniels wrote:
I see a created field and a changed field in the node table, but I think these are dates not authors. There is also a uid which I suspect is the author, perhaps tied to the authmap table?? But no change author.
So what I want may not be as simple as you imply.
It is as simple as:
Creating a table with the fields you need (in this case, as I said, 'changed_by'), and a 'nid' to tie it to the node table.
Implementing hook_nodeapi
for 'insert' and 'update' events, writing the appropriate information (in this case, putting $user->uid into changed_by)
for 'load' events loading the appropriate information.
And do the rest via theming.
It is as simple as I say (not imply).
On Wed, 2006-07-12 at 20:32 -0700, Earl Miles wrote:
Walt Daniels wrote:
I see a created field and a changed field in the node table, but I think these are dates not authors. There is also a uid which I suspect is the author, perhaps tied to the authmap table?? But no change author.
So what I want may not be as simple as you imply.
It is as simple as:
Creating a table with the fields you need (in this case, as I said, 'changed_by'), and a 'nid' to tie it to the node table.
or vid....
Implementing hook_nodeapi
for 'insert' and 'update' events, writing the appropriate information (in this case, putting $user->uid into changed_by)
for 'load' events loading the appropriate information.
And do the rest via theming.
It is as simple as I say (not imply).
participants (8)
-
Alan Dixon -
Darrel O'Pry -
Earl Dunovant -
Earl Miles -
Gabor Hojtsy -
Nedjo Rogers -
Nick Whalen -
Walt Daniels