Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

ACL is not fine grained enough for many usecases #742

Open
djay opened this issue Jun 30, 2016 · 3 comments
Open

ACL is not fine grained enough for many usecases #742

djay opened this issue Jun 30, 2016 · 3 comments

Comments

@djay
Copy link
Contributor

djay commented Jun 30, 2016

User problem

Scenarios like #568 aren't well supported. Others include

  • designer can design but not view anyones sensitive data
  • author can create forms but not see anyones elses data
  • coder can edit formulas but not change the design
  • editor can not create new documents

Options

independent roles

Similar to Plone, plomino 2 should be switched to independent roles. ie, author is not automatically a reader, editor is not automatically an author, designer is not automatically an editor etc.
Roles can always be used in combination so not ability is lost.
An upgrade step might have to be used to fix older databases.

@ebrehault
Copy link
Member

We already have solutions to address those cases:

  • regarding designer access to data: designers can work in a dev db with no sensitive data, they export the design and deliver to the prod db manager
  • regarding authors not being readers, you use Plomino_Readers field
  • regarding editor not being able to create new docs, you can use beforeCreateDocument

I don't think we should create something similar to Plone workflow, because:

  • it is difficult to implement
  • it already exists, we can enable specific plone workflow on Plomino form or views
  • it would make Plomino less approachable to beginners

@djay
Copy link
Contributor Author

djay commented Jun 30, 2016

I'm not suggesting anything to do with workflow. or about Plomino_Readers.

I'm saying that it is unnecessary and confusing and creates more work to make your ACLs not independent. If an Author wasn't automatically a Reader then its trivial to setup things such that one group can view the data, and another can add to it (without reading). Not special coding required. And if you want the current setup then you just give those users BOTH Author and Reader.

It is an enhancement that makes many use cases much simpler with no downside (except backwards incompatibility).

@djay
Copy link
Contributor Author

djay commented Jun 30, 2016

For example here is another scenario thats currently hard to solve. All Authors can see the list of all views. Even if I can use Plomino_readers to hide the documents from an Author (and the views themselves will appear empty), I can't hide the list of Views itself.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants