Support for Drupal 7 is ending on 5 January 2025—it’s time to migrate to Drupal 10! Learn about the many benefits of Drupal 10 and find migration tools in our resource center.
Hi,
I wrote a plugin that grants access by users domain id. It only has the option to Negate the rule. It's very usefull in panels as selection rule. Does this module the same? According to the snapshot you have a select list of domains. If any interest, I will send it to you, but I will never touch cvs, sorry.
Comment | File | Size | Author |
---|---|---|---|
#7 | domain_access_cleanup.patch | 11.55 KB | hefox |
#7 | domain_ctools_access_cleanup.patch | 2.68 KB | hefox |
#3 | domain_ctools_domain_edtior_p1.patch | 2.22 KB | Ghostthinker |
Comments
Comment #1
Ghostthinker CreditAttribution: Ghostthinker commentedmymodule/plugins/access/domain.inc
Comment #2
agentrickardThe current access filter is universal, not per-user.
http://drupal.org/patch/create
Please patch against HEAD.
Comment #3
Ghostthinker CreditAttribution: Ghostthinker commentedI made a patch. It (should) simply add a new file plugins/access/domain_editor.inc
At the moment I am using my own module (that does the same than domain_ctools plus the ability to control access per user) but I would drop it if this goes into yours.
Comment #4
agentrickardNice. Hopefully I can review and add this in.
Comment #5
hefox CreditAttribution: hefox commentedTesting patch at the moment.
Initial thoughts: small detail, but in general patches are done via the root of the module, not the directory the file is in.
The views access plugin has these joined together, what are the reasons for having them separate in ctools, other than the added complexity? Perhaps domain_ctools and.. domain_views? could share some functions on checking access so to avoid duplication.
To the patch itself, eyeballing the patch looks good other than some random spacing, brief testing looks good :)
Comment #6
hefox CreditAttribution: hefox commentedHm looking at the domain_views and domain_ctools, and looking at my own use case my preference would be
Create/move two functions into the main domain module for easy reusability:
(My use case is a custom field permission module that checks if the user and node is part of the current domain before letting em view certain fields, so I could use the first function using node's domains and member = true.)
Comment #7
hefox CreditAttribution: hefox commentedThrowing it to domain; throw it back here if prefer the earleir approach.
Patch 1 for domain/domain views puts 2 functions into domain module, and has the views access plugin use them; the second is for domain ctools.
Comment #8
agentrickardI think it's too late to clean this up for D6, and these modules are stand-alone in D7.
Comment #9
agentrickardMoving versions.
Comment #10
agentrickardThis is totally out of date and I have forgotten the original use-case.