So I have set up a test environment and started the research into best practices, and here is the first big question.

Normally, modules that use hook_access() do not declare the 'view' $op. Project module does and so does Project Issue -- and with good reason in some cases, such as viewing one's own project. The effect, in part, is that Project* will not work cleanly with other node access modules.

The implementation begun here also disregards node access modules by default, but allows them to be used _instead_ of Project Access. The system devised introduces a hook that will allow Project Access (and, conceivably other modules) to alter the default permissions set in project_project_access() and project_issue_access().

CommentFileSizeAuthor
#6 Project Actions.xlsx_.zip34.65 KBagentrickard
#1 Project Actions.xlsx_.zip34.54 KBagentrickard

Comments

agentrickard’s picture

agentrickard
he/him
Primary language English
Location Georgia (US)
commented
StatusFileSize
new Project Actions.xlsx_.zip34.54 KB

Attached is a permissions matrix, both for the current Project suite, and the proposal. (Document is in Word XML format and may need tweaking.)

Note also that turning off PA in favor of other node access modules is sort of silly. Just disable the module instead.

agentrickard’s picture

agentrickard
he/him
Primary language English
Location Georgia (US)
commented

Note that the 'view' case in project_project_access() and project_issue_access() may need refactoring. Node authors are granted permission to view their own posts by default. The question is how to handle special cases for administrators.

See http://api.drupal.org/api/function/node_access/5 for details.

dww’s picture

dww
we/he/they
commented

I just opened up the XLS file, and I have to admit I find it incredibly hard to understand what you're trying to communicate. ;) Please turn up the Tufte knob on your data presentation. ;) In particular, I don't know what the "Access" and "Owner" columns under the "Proposed" heading mean, especially in light of what you're saying at #234463-4: Remove 'access * project *' permissions where you advocate removing "access own *" entirely. Oh, I just found the note at the bottom that explains the "Access" column (I hadn't scrolled down all the way), so that much makes a little more sense, but I still don't really get what you're saying, nor how this solves the "access own *" problem.

Sorry if I'm being dense. ;)

agentrickard’s picture

agentrickard
he/him
Primary language English
Location Georgia (US)
commented

This was an internal brain dump. I will try to translate.

The point right now is that permissions are scattered all over the suite of modules.

dww’s picture

dww
we/he/they
commented

That much is indisputable. :) Thanks.

agentrickard’s picture

agentrickard
he/him
Primary language English
Location Georgia (US)
commented
StatusFileSize
new Project Actions.xlsx_.zip34.65 KB

Revised. The spreadsheet is designed as two horizontal pages. The first tracks the module permissions as they currently stand. The second is a proposal for revision.

In the revised version, the owner specific 'view' privileges are removed, which would let the normal node access system handle view permissions (in all cases). We would only issue a deny in the case that the user cannot 'access projects' or 'access project issues'. By default, users would still be able to view issues that they created, unless another access module intervenes.

As a result, the revised spreadsheet removes the 'owner' permission column entirely from the proposed changes.

A key to the column headers is at the bottom of the sheet, copied here:

Module	-- Indicates the module where the access logic is currently defined
Actions	-- Indicates the user action to be performed	
Default	-- Indicates the default permission needed to perform this action	
Administrator	-- Indicates an administrative permission that overrides the default	
Owner	-- Indicates an owner permission that overrides the default.	
Inherit Access	-- Indicates whether the action should inherit permissions from the parent project

Note that the second page introduces some new permissions and changes some current permissions to be more consistent.

vendeka’s picture

vendeka commented

subscribing...