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

Better permission manager #13

Open
aviriel opened this issue Sep 13, 2016 · 0 comments
Open

Better permission manager #13

aviriel opened this issue Sep 13, 2016 · 0 comments

Comments

@aviriel
Copy link
Member

aviriel commented Sep 13, 2016

Current implementation is working but is not intuitive enough:

  • Permissions for workflow package are in task models.
  • Permissions for files in the package are in beans properties in context.

We need to keep these options for backward compatibility, but we also need better permissions configurations (most probably, everything should be configured from the model).

Two special use cases from the related ticket ALV-705:

  • It would be great if I could set also a custom role I created, not only the standard Alfresco roles. Example: Let's say I have a custom role, which provides edit permission to change properties, but only read access for the content. This cannot be covered by a standard Alfresco role.
  • If I understand correctly, now the customizing is workflow specific - better said workflow instance specific - so the user has access rights to the documents regarding the concrete workflow instance (Process ID). Would it be possible to enhance it as task-specific? So you will be able to define 2 tasks in the same WF definition with different behavior, e.g. factual approval with read-write permission, and after this another task for a different user for business approval with read-only access. As far as I know this cannot be achieved now in the same WF definition.

P.S. Migrated from http://issues.itdhq.com/browse/ALV-727

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

1 participant