-
Bug
-
Resolution: Not a bug
-
Low
-
None
-
3.1.7
I'm running into problems with most attempts to use the p2 component JSD API.
For example:
Lookup Service Desks for a given user
If a Portal User is registered and in the Service Desk Customers role, I would expect the following to return an actual value:
PortalService ps ComponentAccessor.getOSGiComponentInstanceOfType(PortalService.class); Portal portal = ps.getPortalForProject(portalUser, projectObj).getOrNull();
It returns a null with a left() error of:
Either.Left(AnError{httpStatusCode=403, errorCode=none(), message='sd.portal.error.permission : 'You do not have permission to view this Portal.''})
On the outside chance, I tried asserting that portalUser via JiraAuthenticationContext with identical results.
Using the alternate non-deprecated method search by ID:
PortalService ps ComponentAccessor.getOSGiComponentInstanceOfType(PortalService.class); Portal portal = ps.getPortalForId(portalUser, projectObj.getId()).getOrNull();
Same results...
I even tried this where the current (logged in user) and the 'target' user was the same user, an Agent in the target project, and still get null.
I can't see what could be done differently, if I'm missing something please point it out 
At the very least, the error messages about lacking permissions really need more detail adding given the 'complex' nature of how that decision could be reached.
- is caused by
-
JSDSERVER-3962 JSD docs need to mention customer context prominently
- Gathering Interest
- is related to
-
-
- Closed
-
| Form Name | |||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|
[JSDSERVER-3950] P2 Component API not working for portal users (eg portal lookup by project)
You're right, inCustomerContext(Callable) was deprecated in the 3.2 branch, in favour of runInCustomerContext(NoExceptionsCallable), sorry for not picking this up earlier
Sure, was saying that if I have a given user 'userid' but auth context is userY (I'm running as a service, not interactively) that this code uses the provide 'userId' rather than making assertions about the JIRA Auth context (as well).
Just trying this now, the runInCustomerContext method isn't visible in Java, the CustomerContextService has (JSD API 3.1.6)
// Compiled from CustomerContextService.java (version 1.8 : 52.0, no super bit)
public abstract interface com.atlassian.servicedesk.api.customer.CustomerContextService {
public abstract java.lang.Object inCustomerContext(java.util.concurrent.Callable arg0);
public abstract boolean isInCustomerContext();
public abstract java.lang.Object outOfCustomerContext(java.util.concurrent.Callable arg0);
Leads me to think I need something working through inCustomerContext, but what, Im unsure of.
In this code, I retrieved the user from JiraAuthenticationContext.getLoggedInUser(). CustomerContextService doesn't pass it in transparently.
OK, yes, I can see that, thanks! For the record, can I assume that the loggedInUser passed in is the context for the operation, and that I don't have to fiddle with the JIRAAuthenticationContext?
I'll close this now, as I reckon this will be fixed by documentation with JSD-3962. Don't hesitate to reopen if this doesn't work for you !
This is very similar to the issue you had in JSD-3907 - for the record, I'll put my comment and sample code up again for anyone following this.
Code that needs to be executed with elevated permissions for customers (i.e customer accounts don't have those permissions in JIRA, but are branded as "customers"), you need to run it within "customer context". eg:
import com.atlassian.servicedesk.api.customer.CustomerContextService [...] private final CustomerContextService customerContextService; [...] final Either<AnError, ServiceDeskComment> result = customerContextService.runInCustomerContext(() -> { return addSampleComment(loggedInUser, issueId, isCommentPublic); } );
... where addSampleComment is pretty much the code you had above. You will notice that customers are able to add “public” comments but not “private” ones, whereas agents can do both through API as well.
OK, no problem, forewarned is forearmed, I'll be sure to update when 3.2 gets released.