Hello, netzmacht.
Now workflow transactions can define ACL in several ways:
1) define ACL resource on the transition level, f.e. in https://github.com/orocrm/crm/blob/master/src/OroCRM/Bundle/SalesBundle/Resources/config/oro/workflow/b2b_flow_sales_funnel/transitions.yml#L9:transitions:
start_from_lead:
label: 'Start from Lead'
step_to: new_lead
is_start: true
is_unavailable_hidden: true
acl_resource: orocrm_sales_salesfunnel_create
display_type: page
This transition will be available only if current user has permission to access orocrm_sales_salesfunnel_create resource. By default transition is allowed to all users. Also you can specify custom ACL error message using key “acl_message”. This specific transition creates new SalesFunnel entity, so ACL check was added.
2) add condition @acl_granted, f.e.:@acl_granted: ['acl_resource_identifier'] # is ACL identifier 'acl_resource_identifier' allowed
# OR
@acl_granted: ['EDIT', $opportunity.contact] # is user has permission to edit current contact of opportunity
(in fact defining of ACL identifier on transition level automatically converts to @acl_granted condition during workflow assembling).
This condition can be used as a precondition (i.e. before form rendring), as a condition (f.e. user must select only contact what can be accessed by him on business unit level), inside post action (f.e. after some transition – if user has right to create tasks, it must be created).
3) create your own condition that will cover any specific ACL case (@acl_granted can be used as an example), f.e. if you need to check some additional ACL from external API.
Another interesting ACL feature of workflow is that you can define entity level ACL for specific step or/and attribute, f.e. in https://github.com/orocrm/crm/blob/master/src/OroCRM/Bundle/SalesBundle/Resources/config/oro/workflow/b2b_flow_sales_funnel/steps.yml#L7:steps:
new_lead:
label: 'New Lead'
order: 10
entity_acl:
lead:
delete: false
allowed_transitions:
- qualify
- disqualify
In means that if root entity (in out case it’s SalesFunnel) has lead, and entity now in this step (in our case its “New Lead”), then this lead can’t be deleted (the same thing can be done for update). Also you can define the same thing not on step level, but on attribute level – it will mean that if selected entity participating in workflow it can’t be updated/deleted.
Now let’s return to your cases:
> Allow write access only for a defined workflow transaction. This means the user acutally can not edit the entity but can fill in the fields provided by the workflow transaction.
You can restrict access to editing, but do not set ACL to transition – and that’s all: user can’t edit entity, but can do transition.
> Limit permission for each transaction. A role should not do
You can create custom ACL resource and set it (or don’t set it) to role, and then use this resource as transition ACL – so, transition will be available only to roles that have this resource. If you don’t want to create new ACL resource, you can reuse existing one (f.e. transition should be available only if user has right to create opportunities).
> Provide an extension point where I can customize which workflow transactions are allowed for the user.
You can override @acl_granted condition, or create your own condition and use it – there you’ll have current user, so you can do anything you want with it and with it’s ACL. Another option is to trigger some events during transition processing, so external listeners can modify existing logic – for now it’s not implemented, but I’ll create task and put it in our backlog
Unfortunalety, for now these ACL rescrictions can’t be set from UI (you have to customize workflow configuration YML files), but in future we are going to add this functionality.
Bhavesh Tailor 7 years, 4 months ago.
