Access Control

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.

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.

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

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

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...