Mechanism of management rights on the start of process.

Here is the patch to add the requested functinality

Could you elaborate on what exactly you mean by "to have a mechanism of management rights on the start of process"?

Now start the process can be any user. It is not possible to specify a list of users or groups who are eligible to run processes.
Accordingly, I see two problems:
1. Ability to define lists of users and roles that could potentially start the process (or if you have not specified the process runs any user)
2. Obtain an API for checking the user rights to run the process and obtain a list of users authorized to start process.
The easiest way (I think) to give the possibility to determine the for point of START lists of roles and users.
Then give the opportunity to obtain these lists before you start the process (now, in my opinion, this is not possible)
Saeid Mirzaei patch in my opinion gives the (seemingly) the minimum required functionality. Thank Saeid Mirzaei.

We took the general decision that the activiti engine does not do any security management / access control. That aspect can be handled outside of the engine, by an application.
There are just too many different ways to do this.

So unfortunately we cannot accept this patch.

You can add that functionality to your application, as a combination of a BpmnParseListener and other customization. But we cannot add it to the core engine.

It turns out that the whole thing in a name? Let's call it the possibility to obtain information about the initial performers (users or roles) before the start of the process. So we will be able to bypass your stringent rules?

If that is so necessary, I can create a issue with a different name.

If that is so necessary, I can create a issue with a different name.
Title is not linked to security issues.

This is the part we do not want activiti to handle:

 // an undefined user should not be able to start process
+    identityService.setAuthenticatedUserId("unauthorizedUser");
+    try {
+      runtimeService.startProcessInstanceByKey("potentialStarter");
+
+    } catch (StartAuthorizationException ae) {
+
+    } catch (Exception e) {
+      fail("Wrong exception caught. StartAuthorizationException expected, " + e.getClass().getName() + " caught.");
+    }

As an embeddable engine, we do not want activiti to perform these kinds of checks. If you want to support something like this in the BPMN xml:

<extensionElements>
+			<activiti:potentialStarter>
+				<resourceAssignmentExpression>
+					<formalExpression>group2, group(group3), user(user3)</formalExpression>
+				</resourceAssignmentExpression>
+			</activiti:potentialStarter>
+		</extensionElements>

You can add that support on your own, using a BpmnParseListener. The Listener can add this information it to the ProcessDefinition as properties. You can then retrieve these properties and do the checks.

Daniel.
I also think that the engine is not necessary to support this functionality. I'm talking about the need to provide through the API to get a list of potential perpetrators before starting the process. This will provide an opportunity to display user-specific list of tasks in which it is listed as a potential initiator. Everything else (including the display of the full list of processes) is given for the solution applied to the application.

Daniel
Are these so called general decisions listed somewhere ? and if it is such a decision, why there is an identity service and login functions ?

I talked it through a bit further with Daniel and we need to make a small change to the patch, but the functionality remains the same.
We want to approach it in the same way as the user task solution.
So we allow users to define potential starters and candidates but we don't enforce this in the Engine itself (so that check should be removed).
Then in the Activiti Explorer and REST application we can query on the potential starter and candidates and implement the security checks.
So I think this means that the functionality will be almost the same as in the patch, but we won't do the authorisation checks with the authenticated user.
Andrey, Saeid WDYT?

How if someone is not going to use Rest API or explorer ? one just like ourselves.
I personally find it more useful for a company like us, implemented in Engine itself.
I think current implementation uses the same mechanism and structure as in Tasks, is backward compatible.
Users not caring for security, can continue to use it like before, and no change in Explorer and Rest API is necessary.

I was not able to fully understand your decision.
I do not want to use for my task Activiti Explorer and REST. Maybe in the future for any administration.
I, first of all, interested in the presence of engine API features a list of potential initiators of processes. And most importantly, before the start of processes.
If this problem is solved, the more I do not want to.

Let me explain a bit more in detail what we want to implement for this issue.

1. Add potential and candidate starter config on a process
2. Get a list of potential starters for a specific process definition
3. Query for all process definitions that can be started by a specific user.

We may also add some logic to the Explorer and REST API to support this, but this is all part of the Activiti Engine.

What we won't add at this moment is an actual check against the authenticated user if he/she may start a new process instance.
This logic should be implemented outside the Engine, for example in the Explorer and REST API or your own solution.

OK. I believe that this implementation will be sufficient and will not break the balance of the engine. I like it.

So we would happily accept a patch that implements this feature.

Personally I don't like the name "starter". We could go with "initiator" since that concept already exists in activiti.

I also prefer the to use the name "initiator"

I have already sent the patch which does the parsing and also check the authorization the the starting process.
Now considering the new discussion, will remove the check on start part, register the authorization data somewhere on data base and implement query API function.

about starter or initiator, I chose the name because the API uses the term "start" for starting or initiating the process and not "initiate". I thought maybe it is better to keep the analogy.

It seems to me that the term "start" is well suited to the action of the process. The term "initiator" is more suited to determining the role of the user.

these changes are made to fulfill the above mentioned requirements in r3408.

1. The authorization checking logic is removed from the starting process. now in starting a process, start authorizations are not checked. logic was mainly written in AtomicOperationActivityStart. If somebody needs the feature anyway, he could revert changes 3403 and 3407

2. Column ACT_RU_IDENTITYLINK.PROC_DEF_ID added ans scripts updated accordingly
3. functions potentialStarter added to UserQuery and GroupQuery. Having this function causes only the starter users or groups for the given process definition to be listed.
4. functions UserManager.findPotentialStarterUsers and GroupManager.findPotentialStarterGroups added.
5. Unit tests are in StartAuthorizationTest

Just committed the patch by Saeid. I made some small refinements and added additional functionality to the RepositoryService and a couple of unit tests. Thanks for the patch Saeid.