Access Control

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.

Overview

Ripple Effects Interactive (REI) is looking for an independent contractor or service to provide short-term (30 - 90 days) help with a client’s Drupal-based social networking web site. The position will require approximately 20-30 hours a week, possibly more.

Project Description

We are redesigning a social networking website that is currently using Drupal 4.6.2. We would like to continue to leverage this version of Drupal and essentially need to apply a new GUI, update the navigation schema, and add some new custom features such as:

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.

NOTE: This effort has been postponed until after the d.o is upgraded to D6. There's too much here and the versioncontrol* suite is just not yet ready for prime time.

1. script for migrating from cvs module to versioncontrol_cvs -- in progress
2. script for migrating from cvs module to versioncontrol_project -- done, but could use more testing

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

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 OGR releases prior to 5.x-3.0. As of OGR 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.

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:

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.

Yet another node access module..
Read more at http://more.zites.net/content_access

The patch for modifications I discussed in TAC/OG Integration Step 2 (http://groups.drupal.org/node/3700) is located here as well as the latest OGR distribution:

http://cvs.drupal.org/viewcvs/drupal/contributions/sandbox/somebodysysop...

Instructions for OGR Release 5.x-3.0 and higher

Once OG User Roles module is downloaded and installed, you must:

<

ol>

This patch is included in OGR Release 5.x-3.0 and higher. It is also available from here:

Notes as of OGR Release 3.0 and higher

This has been a long process. In short, I've been able to get TAC (Taxonomy Access Control) and OG (Organic Groups) working together with OGR (Organic Groups User Roles). The history of this process is discussed below under Notes previous to OGR Release 3.0. I feel it is important to maintain this documentation. If you are considering using TAC/OG Integration, you should read it to understand the background and important issues of this project.

I've put some work into a 5.x nodeaccess module. It could be the superior from the current nodeaccess module, and perhaps also from the simple_access module. I'm waiting for feedback from the authors..

So my module provides extended role based access control per content type, but it can be configured to manage per user access control per node - it does this by integrating with the ACL module, as well as role based per node access control.

Like simple_access it doesn't touch any permissions when it's activated. It also does some performance optimizations and tries to keep the UI simple.

Read a more detailed description or download and test the module at http://drupal.org/node/135693.

As I stated in the Group Description, my goal is to figure out how to make various access control mechanisms work together. I started this by trying to make OG and Taxonomy Access Control work together: http://drupal.org/node/122712

I now intend to share with you all exactly what I did. There are a number of hacks involved that I'm sure most of you won't want to get involved with, but the idea here is to demonstrate what I did, step by step, in order to solicit ideas from others on betters ways to accomplish the goal.

Step 1:

Hey Folks, you got another members. Here's is why I joined. I am new to drupal, and loving it. I have an install that is using OG, and again, I am loving it. I have added a wiki content type, and have started to create some wiki pages... and am loving it :)

perhaps some people don't realize that any module can propose a DENY for a given nid. just implement hook_node_access_records() and return a 0 0 0 grant with priority = -10 and you will effectively deny access. it doesn't matter that user is a member of a group or has access to a term.

My first step is to figure out a way to open up user_access so other modules can add roles as they deem necessary. Here is the request for assistance I posted to the Drupal Development list which describes what I'm trying to do. Any asisstance will be highly appreciated and help move this project forward: