Access Control

Something I have had issues with on multiple sites I have worked on is administrative areas and permissions.

Example:
If I build a site for a client and then decide I want the client to be able to edit certain areas of the admin panel ("/admin/settings/site-information") but I don't want them to have full access to the administration area then there really isn't a good solution.

So, I ask... What exactly can be done about the issue? What would be some of the best work arounds?

Some time ago I proposed a new access control system for Drupal, which would allow the creation of access rules based on various criteria, kind of like the filters in Views.

I created a list of content permission modules that I have encountered with their weights on my system.

1. Can we create a comprehensive list?
2. How can they work together or should they. From your experience, what has been the worst and best combinations ?
3. what effect does module weight have on implementation of access? is it true that if access is already granted, it will not be restricted by another module that comes into play later?

Weight/ Name/ Version/ Brief description

0 Content Permissions 6.x-2.x-dev Set field-level permissions for CCK fields.
(admin determines)

Hi,

I am planning a multisite project where I want to be able to share users and some content between sites.

All sites will be more or less clones of each other, but they will have different target markets (countries mainly).

What I want to do is:

<

ul>

Hi to all,

Our organisation recently decided to change our CMS from Joomla to Drupal. We would like to use groups on our site and organic groups seemed the obvious choice. I suggested this to our site designer but he immediately flag a concern with incompatibility of the Organic groups module with the ACL module as he found information in the OG handbook stating that "you can't use this module with other node access modules". He sent a query 2 weeks ago at http://drupal.org/node/384094 but has so far received no replies.

I also found a thread at http://drupal.org/project/og_user_roles which states that the OG user roles modules supports ACL. Does "support "mean that it is compatible? And does this mean that the OG module is as well?

Is the Organic groups module compatible with the ACL module? How can we use both OG and ACL modules together?

Domain Access and You

Building networked sites with Domain Access. Check the BoF board for details.

http://drupal.org/project/domain

Hi,

Currenty i upgrade my version 5.9 to 6.2. What r the changes in my own module for drupal 6.7. What is the difference between 6.2 to 6.5. If u know any document recommend to me.

thanks & regards,
Gnanasekar Boju

I just downloaded the content access module and installed it, it was late and I was pretty sure that it was working, but this morning when I tried to check the module and start playing with it, and I can't find it any longer, the module is still there and enabled, I was pretty sure that I saw it in Administer > Content management > content type where there was a tab, but today I couldn't see it any longer, I've been through the whole menu and couldn't see it and couldn't find detailed documentation.

Joomla has announced availability of new ACL: http://is.gd/iA5B and they seem pretty excited about it. Is that something for Drupal community to be jealous of?

If you come from a Java/J2EE background the clear answer is: NO (yes, in capital letters). You have to actually suffer from a structured, strict ACL to really appreciate the simplicity of a security system like that of Drupal.

Now, you may argue that Drupal security is slightly over-simplistic and too code-oriented (makes us, the developers happy) for "business" use.

I've been working on an LDAP help module to help admins configuring ldap integration ( http://drupal.org/project/ldap_integration ).

I use Microsoft Active Directory for LDAP. I wanted to get some people who were using other ldaps together to:
1) test andgive me feedback so I can finish the help modules
2) work with me to update the documentation for ldap_integration: http://drupal.org/node/62217

Its functionality is based on what support requests from the ldap integration issue que:
- to make support and bug reports better by getting a more complete set of information

A client of ours -- a university -- has quite an extensive hierarchical menu structure. They want the ability to take a top-level menu item, such as "Current Students" and control which roles can manage (create/edit/delete, based on their role's permissions under admin/user/permissions) and view the content under that section. Permissions should cascade down to sub-items in the tree unless explicitly overridden. They also need to then restrict access to adding new pages underneath menu items they do not have access to.

Here's a mock-up that describes what we're after, since it's easier than me explaining. :) Also, I should point out that this is for Drupal 6.

Hello access control group,

I have been tapped with setting up an e-learing site with the following characteristics:

1. Super administrator must manage (setup, delete) intructors.
2. Instructors must administer (invite, accept, delete) all students to their class/group. Ideally, there is a way for the instructor to customize the registration/login page for their students.
3. Once a student has access, they all have access to the same exact content (a set of lessons).

Hi, I sent this question to Drupal forums but dint get a response. I think this group is more apprpriate for it. Based on what I read here, seems like thr OG User roles is designed to do what I'm trying to accomplish, but couldn;t get it to behave as expected. I'm pretty new to this so just might need some clarifications on how to get this working.

Basically, I want to setup certain users with permissions to submit blogs only for specific groups (not system wide).

So here's what I did.

As admin:

Hi,

I'm a little bit frustrated by the User access implementation proposed for OG, it's too much complicated and i don't think that TAC/CA/ACL/OG combination with many many many hacks is the right way (but it's a very very good work too).

So, i really need for my project, this simple things:

1) Organic Group
2) User can post in Public or in their suscribed groups
3) AND they must have the possibility to grant other users that can be outside of his group

Hello,

I'm building a multi-lingual site, where I would like different translation groups/roles to be able to work on their language (and only their language) to translate source content. In some cases translating in response to content being posted, and at other times originating the content.

It appears that agentrickard has created the solution to the problem for which the Access Control Group was originally created: The Multiple Node Access Logic Patch: http://drupal.org/node/196922

I have used this patch to successfully get TAC and OG working together. I'm including it in the next release of OG User Roles (5.x-3.0): http://groups.drupal.org/node/3700

As great as I think this patch is, it probably won't make it into Drupal core, for a variety of reasons.

I had a notion the other day of a module to bypass node_access. It seems if you had a module with a very heavy weight and hook_node_access_records, it could fire after all the other hook_node_access_records calls. Then it could:

1. Copy all the other modules' node_access records into a table of its own with the same structure as node_access.
2. Set all the other modules' node_access records to DENY for everything.

Hi folks,

I'm following up on promises I made during the Birds of a Feather sessions at Drupalcon Boston to post a case study of how we're using Drupal at Amherst College. We've developed a module to facilitate hierarchical content creation and permission control that's also of potential interest to folks outside of the academic community.

Preamble aside - about 3 years ago the college decided to fundamentally change the way it was approaching the web, and a little over 2 years ago we started building on top of Drupal. The project had some broad goals:

Here's my setup: I have a network with different forums and different content but shared users on one codebase on the same database with different prefixes.

What I'm hoping for is a way for all of these sites to share the same 'off-topic' category but different overall forums. What's the best way to achieve this? Thanks.

Here's my setup: I have a network with different forums and different content but shared users on one codebase on the same database with different prefixes.

What I'm hoping for is a way for all of these sites to share the same 'off-topic' category but different overall forums. What's the best way to achieve this? Thanks.

I have a project that has been started and the current programmer is too swamped at the moment. He will be willing
to work with you once he finishes out a current project.

We are under a deadline and need to get the site built out. Must sign an NDA prior to getting the full site description.

Details:
1) Html and design work is complete.
2) Partial site has been built.
3) Required back end where corresponding consumer Inputs (answers to questions etc.) will generate outputs in a Personal Plan / Format for the person.
4) Project is Patent Filed.

I have a project that has been started and the current programmer is too swamped at the moment. He will be willing
to work with you once he finishes out a current project.

We are under a deadline and need to get the site built out. Must sign an NDA prior to getting the full site description.

Details:
1) Html and design work is complete.
2) Partial site has been built.
3) Required back end where corresponding consumer Inputs (answers to questions etc.) will generate outputs in a Personal Plan / Format for the person.
4) Project is Patent Filed.

This is a loose checklist of items that need to be taken care of to get Version Control API working on drupal.org. The bulk of the required work has been done, and the current plan is to get the 6.x-1.x branch deployed on drupal.org before the d.o redesign is done.

1. Script for migrating from cvs.module to versioncontrol_cvs -- partially done
2. http://drupal.org/node/346362 -- Print warning message after branch creation to update workspace (port over from cvs.module) -- done

So I am researching Taxonomy Access Control (TAC) and Domain Access (DA) integration (though this applies to Organic Groups (OG) and other modules as well). And here's the problem.

node_access_rebuild(), as far as I can tell, is only designed to work with a single access control system.

So I am researching Taxonomy Access Control (TAC) and Domain Access (DA) integration (though this applies to Organic Groups (OG) and other modules as well). And here's the problem.

node_access_rebuild(), as far as I can tell, is only designed to work with a single access control system.

There's a new tutorial at http://drupal.org/node/200631 which is a different approach to Taxonomy Access Control than I have seen, a very different approach to Groups (as a concept), and multiple Domains (hence a multisite solution). I am trying to discern what is going on with og, mulltisite, domain access, and TAC generally.

There's a new tutorial at http://drupal.org/node/200631 which is a different approach to Taxonomy Access Control than I have seen, a very different approach to Groups (as a concept), and multiple Domains (hence a multisite solution). I am trying to discern what is going on with og, mulltisite, domain access, and TAC generally.

Currently, within OG, all the group settings are set sitewide for all types of group nodes. We are looking to implement group type by group type default permissions to allow for different types of groups within the same site --

We will be working out a solution to this issue and releasing the code back as a contrib module -- however, before we start coding we want to get some feedback/see if anyone else was thinking along similar lines.

The issue is here: http://drupal.org/node/192933 -- please centralize any discussion on the issue queue.

Cheers,

Bill

Currently, within OG, all the group settings are set sitewide for all types of group nodes. We are looking to implement group type by group type default permissions to allow for different types of groups within the same site --

We will be working out a solution to this issue and releasing the code back as a contrib module -- however, before we start coding we want to get some feedback/see if anyone else was thinking along similar lines.

The issue is here: http://drupal.org/node/192933 -- please centralize any discussion on the issue queue.

Cheers,

Bill

OK, so I'm working on integrating Domain Access with OG.

Problem is, the current node_access system uses OR based permissions. What I really need is the option to set AND based permissions. For example:

-- Current node_access rules

-- Desired rules

See http://drupal.org/node/191375 for a full discussion and some possible options.

OK, so I'm working on integrating Domain Access with OG.

Problem is, the current node_access system uses OR based permissions. What I really need is the option to set AND based permissions. For example:

-- Current node_access rules

-- Desired rules

See http://drupal.org/node/191375 for a full discussion and some possible options.

OK, beta6 is out and the release is looking pretty good.

But I introduced the Domain Prefix module -- it creates a UI for dynamic table prefixing. So, for example, each of your subdomains can have a different watchdog table. The $db_prefix array is dynamically set on bootstrap.

Two big issues -- notwithstanding the lack of pgSQL support, which I'll get to shortly.

• I have not found a way to run a function any time hook_uninstall() is run.
  Attempts to add a #submit handler using hook_form_alter() failed. As a resut

OK, beta6 is out and the release is looking pretty good.

But I introduced the Domain Prefix module -- it creates a UI for dynamic table prefixing. So, for example, each of your subdomains can have a different watchdog table. The $db_prefix array is dynamically set on bootstrap.

Two big issues -- notwithstanding the lack of pgSQL support, which I'll get to shortly.

• I have not found a way to run a function any time hook_uninstall() is run.
  Attempts to add a #submit handler using hook_form_alter() failed. As a resut

For a project, we just came up with another way to skin the multisite problem.

Domain Access is a node access module that enables multiple sites to be run from one installation.

The beta has been released.

See the module in action at http://skirt.com/map

For a project, we just came up with another way to skin the multisite problem.

Domain Access is a node access module that enables multiple sites to be run from one installation.

The beta has been released.

See the module in action at http://skirt.com/map

Hello,
I'm here because it seems like the only place I am likely to find some help with Access Control, having scoured the internet for help elsewhere...

Hello,
I'm here because it seems like the only place I am likely to find some help with Access Control, having scoured the internet for help elsewhere...

I am in involved in a customization of Drupal 5.2 for our company. I need the following things to be
done:

1. When a user creates a blog or a forum topic, he/she needs controls to give access to other users
   who would be able to read the blog, read & reply comments etc for each blog/forum topic. The access
   control should be in the format of a) Public or Private b) Company c) Department/Division d) Individ
   ual.

2. Any reply comments or new creation of blog/forum topic should be send as emails to the particular
   user email ids as in the case above.

I am in involved in a customization of Drupal 5.2 for our company. I need the following things to be
done:

1. When a user creates a blog or a forum topic, he/she needs controls to give access to other users
   who would be able to read the blog, read & reply comments etc for each blog/forum topic. The access
   control should be in the format of a) Public or Private b) Company c) Department/Division d) Individ
   ual.

2. Any reply comments or new creation of blog/forum topic should be send as emails to the particular
   user email ids as in the case above.

The following documentation was originally written for OGUR releases prior to 5.x-3.0. As of OGUR Release 5.x-3.0, the "Multiple Node Access logic patch" http://drupal.org/node/196922 is used for TAC/OG/CA/ACL Integration.

As of this writing, I know that CA (Content Access) and ACL (Access Control List) now work with TAC/OG Integration http://groups.drupal.org/node/3700. But, because of the new way this integration is achieved (using the multinode_access table), there are now a variety of ways you can now configure access.

This is complicated stuff, but I'm going to try.

I've posted this in the Drupal Forums, but want to post it here as well.

As you know, I created patches to the node, og, and taxonomy_access modules which allow them to work together: http://groups.drupal.org/node/3700

What I want to do now is start removing some of these patches by putting the functionality I need into one separate module.

I've posted this in the Drupal Forums, but want to post it here as well.

As you know, I created patches to the node, og, and taxonomy_access modules which allow them to work together: http://groups.drupal.org/node/3700

What I want to do now is start removing some of these patches by putting the functionality I need into one separate module.

The OG User Roles module is now finally a Drupal project: http://www.drupal.org/project/og_user_roles.

The TAC/OG access control has now been added to the og_user_roles module, and the module is now required for implementation of this functionality. The TAC/OG patches are now located here: http://cvs.drupal.org/viewcvs/drupal/contributions/sandbox/somebodysysop... and have now been modified to reflect this change.

The OG User Roles module is now finally a Drupal project: http://www.drupal.org/project/og_user_roles.

The TAC/OG access control has now been added to the og_user_roles module, and the module is now required for implementation of this functionality. The TAC/OG patches are now located here: http://cvs.drupal.org/viewcvs/drupal/contributions/sandbox/somebodysysop... and have now been modified to reflect this change.

Hi:

I've read the posts about having TAC and OG access control systems working together...
I think you have done a great job with t¡hose patchs but I like to avoid using patch as much as possible so I have been thinking in a way of doing the same with existing modules...

Modules used:
- OG promote
- TAC
- OG
- Node Auto Term [NAT]

The idea is to use the way TAC works with multi term nodes. From admin/help/taxonomy_access:

Hi:

I've read the posts about having TAC and OG access control systems working together...
I think you have done a great job with t¡hose patchs but I like to avoid using patch as much as possible so I have been thinking in a way of doing the same with existing modules...

Modules used:
- OG promote
- TAC
- OG
- Node Auto Term [NAT]

The idea is to use the way TAC works with multi term nodes. From admin/help/taxonomy_access:

I am reporting some findings that I hope will help others who decide to try any access control module currently available to Drupal 5.1 or earlier.

I am reporting some findings that I hope will help others who decide to try any access control module currently available to Drupal 5.1 or earlier.

Greetings fellow Drupallers!
I began working on OpenMusic, a social network that aims at letting fans help music artists. By giving appropriate roles to its fans - thus getting them involved - an artist can build a network of valuable friends where each can provide a service to help the artist.