L3 - Default What are the steps to reproduce your problem?
- Use LDAP as an Identity Provider (Users and Groups are not stored in Camunda DB)
- Have a process instance with UserTask and candidateUser or candidateGroup set
What is the problem?
- Users and Groups not present in Camunda DB are not shown in the filter
- Users and Groups not present in Camunda DB cannot be used in the filter
What would be the expected behavior:
- It is possible to use the technical id of users/groups that are not present in Camunda DB in candidateUser and candidatgeGroup filters
- If possible, identities that are present in instance data but not in Camunda DB should also be shown in filter dropdown selection (with ID only)
Hints (optional):
It seems that the endpoint which was added with OPT-4664 and OPT-4666 specifically searches the identityCache (/engine if not present) for the given identityIds, eg to retrieve the name of a group. If the ID cannot be found in the engine data, nothing is returned.
To allow users to filter for users and groups not present in the engine we should default to return the identity with ID only if we cannot find the name - this may need some FE adjustment as well to display identities with ID rather than name if the name is null.
This is the controller panel for Smart Panels app
[OPT-5283] Identities that are not present in the engine cannot be used in filters
| Affects Version/s | New: 3.4.0 [ 16594 ] | |
| Affects Version/s | New: 3.3.0 [ 16194 ] |
| Description |
Original:
What are the steps to reproduce your problem?
# Use LDAP as an Identity Provider (Users and Groups are not stored in Camunda DB) # Have a process instance with UserTask and candidateUser or candidateGroup set What is the problem? * Users and Groups are not shown in the filter What would be the expected behavior: * It is possible to use the technical id in candidateUser and candidatgeGroup filters Hints (optional): |
New:
What are the steps to reproduce your problem?
# Use LDAP as an Identity Provider (Users and Groups are not stored in Camunda DB) # Have a process instance with UserTask and candidateUser or candidateGroup set What is the problem? * Users and Groups are not shown in the filter What would be the expected behavior: * It is possible to use the technical id in candidateUser and candidatgeGroup filters Hints (optional): It seems that the endpoint which was added with To allow users to filter for users and groups not present in the engine we should default to return the identity with ID only - this may need some FE adjustment as well to display identities with ID rather than name if the name is null. |
| Mentioned Roles |
| Mentioned Groups |
| Summary | Original: Technical id cannot be used in filters | New: Identities that are not present in the engine cannot be used in filters |
| Description |
Original:
What are the steps to reproduce your problem?
# Use LDAP as an Identity Provider (Users and Groups are not stored in Camunda DB) # Have a process instance with UserTask and candidateUser or candidateGroup set What is the problem? * Users and Groups are not shown in the filter What would be the expected behavior: * It is possible to use the technical id in candidateUser and candidatgeGroup filters Hints (optional): It seems that the endpoint which was added with To allow users to filter for users and groups not present in the engine we should default to return the identity with ID only - this may need some FE adjustment as well to display identities with ID rather than name if the name is null. |
New:
What are the steps to reproduce your problem?
# Use LDAP as an Identity Provider (Users and Groups are not stored in Camunda DB) # Have a process instance with UserTask and candidateUser or candidateGroup set What is the problem? * Users and Groups not present in Camunda DB are not shown in the filter * Users and Groups not present in Camunda DB cannot be used in the filter * What would be the expected behavior: * It is possible to use the technical id of users/groups that are not present in Camunda DB in candidateUser and candidatgeGroup filters Hints (optional): It seems that the endpoint which was added with To allow users to filter for users and groups not present in the engine we should default to return the identity with ID only - this may need some FE adjustment as well to display identities with ID rather than name if the name is null. |
| Mentioned Roles |
| Mentioned Groups |
| Description |
Original:
What are the steps to reproduce your problem?
# Use LDAP as an Identity Provider (Users and Groups are not stored in Camunda DB) # Have a process instance with UserTask and candidateUser or candidateGroup set What is the problem? * Users and Groups not present in Camunda DB are not shown in the filter * Users and Groups not present in Camunda DB cannot be used in the filter * What would be the expected behavior: * It is possible to use the technical id of users/groups that are not present in Camunda DB in candidateUser and candidatgeGroup filters Hints (optional): It seems that the endpoint which was added with To allow users to filter for users and groups not present in the engine we should default to return the identity with ID only - this may need some FE adjustment as well to display identities with ID rather than name if the name is null. |
New:
What are the steps to reproduce your problem?
# Use LDAP as an Identity Provider (Users and Groups are not stored in Camunda DB) # Have a process instance with UserTask and candidateUser or candidateGroup set What is the problem? * Users and Groups not present in Camunda DB are not shown in the filter * Users and Groups not present in Camunda DB cannot be used in the filter What would be the expected behavior: * It is possible to use the technical id of users/groups that are not present in Camunda DB in candidateUser and candidatgeGroup filters * If possible, identities that are present in instance data but not in Camunda DB should also be shown in filter dropdown selection Hints (optional): It seems that the endpoint which was added with To allow users to filter for users and groups not present in the engine we should default to return the identity with ID only - this may need some FE adjustment as well to display identities with ID rather than name if the name is null. |
| Mentioned Roles |
| Mentioned Groups |