-
Bug
-
Resolution: Fixed
-
High
-
None
NOTE: This bug report is for JIRA Service Desk Server. Using JIRA Service Desk Cloud? See the corresponding bug report.
If an administrator removes a Connect addon user from all the groups that have use permissions in JIRA, `RedirectExternalCustomerToPortalFilter` will redirect all the REST calls done by the Connect addon to the customer portal.
It would be possible to detect if the user is a connect addon user, and skip the redirect. (Atlassian connect does its own scope based permission check, so this is not going to cause any problems)
- relates to
-
-
- Closed
-
- causes
-
AC-1829 Failed to load
- is duplicated by
-
AC-1417 Loading...
- is related to
-
- was cloned as
-
DESK-3818 Failed to load
-
| Form Name | |||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|
[JSDSERVER-970] Service desk sometimes treats Connect addon users as external customers
dzagorovsky1 is this issue still happening for any of your customers? We do not expect this problem to be happening anymore.
At least two of our customers experiencing the issue with JIRA REST calls redirecting to /servicedesk/customer/portals now. How to resolve this issue?
We have vendor reports that this is occurring again. Has anything changed that would be causing this? See https://ecosystem.atlassian.net/browse/AC-1417?focusedCommentId=167462&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-167462
Hi Eero, thanks for the clarification (I understand the intent, fingers crossed on actual 
). But the outcome remains, SD installed in JIRACloud seems to break all AC addons, requiring a manual fix to permissions that breaks other things. Even though we've kind of worked around this its not perfect and does have impact. Asking all users to make such a change also doesn't deliver a great end user experience, given last update was in November, any update on what's being done to get this fixed so AC addons don't break with a default SD install?
Hi Andy,
For customers with 10 users already, they will not have the option of given addon users to 'right to use' without paying the next tier, so outcome for us is likely to be to just not use our addon at all
I think there has been a small misunderstanding with the workaround. We treat the afdon users as system users, so they should not be consuming licenses.
Also, we do assign the addon users to the default jira users group when they are created, so this issue should only affect customers who have changed the permissions on the default groups.
Cheers,
Eero
This is hitting us now, its a blocker issue for us, as the combination of ServiceDesk and AC addons causes big problems.
| If users have JIRA and JSD installed | Remote ac addon rest calls get redirected and fail with a 406 response. This affects all users now. AC addon rest requests will fail for SD enabled projects (for our requests). |
|---|---|
| If we get the addon user added as a 'right to use' user | the JSD modified permissions scheme treats the addon user as a customer, which causes ACJIRA-286 (breaking any AC addon trying to create issues setting the reporter), and related ACJIRA-287 |
We have pushed some fixes to fallback to some default behaviour so that we can deal with not setting the reporter, but its not great.
Asking customers to work around this bug isn't going to go down well. For customers with 10 users already, they will not have the option of given addon users to 'right to use' without paying the next tier, so outcome for us is likely to be to just not use our addon at all 
Can we get an update on this issue?
We got pinged about this issue again today: <https://groups.google.com/forum/#!topic/atlassian-connect-dev/VbmNcgvRFe4>.
ezhang can we raise the priority of this issue?
The attribute name is also a bit too general, we should change that. You would need to deploy code to set the request attribute, or were you thinking of another way to fake it?
Yes, the issue still happening.