Several months ago, I was tasked with creating some way to assign roles to users in groups. I installed the og roles module. What I discovered was that this module simply assigned a role to a user, not to a user in a particular group. I realized what I needed was a way to assign a role to a user in a way so that the user would only have this role in this particular group, not sitewide and certainly not in all groups. To do this, I needed to understand Drupal permissions and Access Control worked. My progress on this particular task is here: http://drupal.org/node/87679
Fast forward a few months later, when I was trying to use OG and Taxonomy Access Control (TAC). To my horror, I discovered that if a node was posted to a group, a user who was not in the group could access the node if he had access to the Taxonomy term. And, vice versa, if a user was in a group that the node belonged to, but DID NOT have access to the Taxonomy term, he could still access the node. This, in my opinion, was two Access Control systems tolerating each other, not working together. My progress on ths particular task is noted here: http://drupal.org/node/122712
So, I set about, merrily hacking my way through, until I had resolved both issues. Unfortunately, hacking Drupal core code is not a very good long term solution. And, when I applied for a project for my og user roles module, Drupal Admin told me as much.
What I needed was an environment where I could discuss my ideas with like minded folk who wanted to achieve the same goal: Get Drupal Access Control to open up so that various ACS (access control systems) from various modules could work together instead of at cross purposes as they do now.
That's why I created this discussion group. My first task is to work on getting og user roles approved as a project. For that, I need to figure out how to get it working without hacking the user_access function in the user.module.
That's the plan.
Addition of permission for read/write ability based on topic/blog entry for each user
I am in involved in a customization of Drupal 5.2 for our company. I need the following things to be
done:
-
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. -
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.
Using Content Access and ACL with OG User Roles
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.
Read moreOverriding taxnomony_access_db_rewrite_sql()
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.
Read moreOG User Roles now official Drupal Project
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.
Read moreAnother aproach
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:
Read more
Helpful hint to access control module users
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.
Read more
Openmusic:a barter Social Network for Musicians, Bands and Fans
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.
Content Access 1.0 released!
Yet another node access module..
Read more at http://more.zites.net/content_access
How to Make OG and TAC Work Together: Step 3
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 OGUR distribution:
http://cvs.drupal.org/viewcvs/drupal/contributions/sandbox/somebodysysop...
Instructions for OGUR Release 5.x-3.0 and higher
Once OG User Roles module is downloaded and installed, you must:
<
ol>
This patch is included in OGUR Release 5.x-3.0 and higher. It is also available from here:
Read moreHow to Make OG and TAC Work Together: Step 2
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.
Read morenodeaccess module for 5.x
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.
Read moreHow to Make OG and TAC Work Together: Step 1
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:
Read moremy goal in joining
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 :)
Read more
deny is possible
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.
Read moreOG User Roles
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:
Read more- « first
- ‹ previous
- 1
- 2
- 3
- 4
