-
Bug
-
Resolution: Duplicate
-
Low
-
None
-
Severity 3 - Minor
-
Issue Summary
When editing the fields on a request type in Classic projects, you can set a default value (this default value is mandatory if you are hiding the field from the portal).
If you search for and add a user that has a different username and userkey in the app_user table in the database, then that user cannot be added as an approver and it will show an error to say "Could not find usernames: <user-key>".
Steps to Reproduce
- Create a classic Service Desk project (e.g. using the Internal Service Desk project template)
- Invite an agent to the project (or any user who can be added as an approver).
- Go to the app_user table in the database and update the "user_key" column for the agent to something other than their "lower_user_name". (e.g. UPDATE app_user SET user_key="not-user-name" where lower_user_name="user-name") - Note: For historical reasons some customers naturally end up in this state. It's not necessarily the case that their database was manually updated. It may have happened on import, or some other reason. This is just a simple way to reproduce the issue for testing.
- Go to project settings > request types and edit the fields on the "Travel Request" request type (any request type with an approver field will do)
- Hide the field from the customer portal. This will pop up a dialog to set the default approver.
- Search for the user you added in Step 2 and try to set them as the approver.
Expected Results
The user is added as the default approver.
Actual Results
An error is displayed "Could not find usernames: not-user-name"
Workaround
None
- duplicates
-
JSDCLOUD-8583 Renamed users cannot be selected as preset user in Request Type configuration
-
- Closed
-
- relates to
-
JSDCLOUD-8505 Changing the Assignee on an Automation rule or request type will display the assignee as "Automatic" even though there is a specific user selected.
-
- Closed
-