fix: apply farm ID and queue ID settings correctly #151
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
What was the problem/requirement? (What/Why)
The error message "AccessDeniedException" was appearing during login, settings, and creation flows with no actionable error message.
Resolves #117
What was the solution? (How)
Updated the flows to check whether the farm and queue IDs are set before calling Deadline Cloud APIs. Use a shared function for consistent behaviour.
Now, customers will only see error messages if they attempt to submit without a farm and queue ID set. The ROP creation, login, and settings flows will not show an error message if the farm and queue ID are not set.
What is the impact of this change?
Avoids customer confusion from access denied exceptions
How was this change tested?
deadline config set defaults.farm_id ""
anddeadline config set defaults.queue_id
Before: access denied error appears
After: no error
Before: access denied error appears, even though login succeeded
After: no error
Before: access denied error appears, even though there was no action by the user
After: no error
deadline config set defaults.farm_id <farm ID>
Before: access denied error appears
After: no error
Before: access denied error appears, even though login succeeded
After: no error
Before: access denied error appears, even though there was no action by the user
After: no error
deadline config set defaults.queue_id <queue ID>
Was this change documented?
No, not required
Is this a breaking change?
No
By submitting this pull request, I confirm that you can use, modify, copy, and redistribute this contribution, under the terms of your choice.