User does not have permissions to view this workitem 'XXXXX'
CLM 5.0.1
The user have the right license and is the member of the Project and Team where the work item exists.
I have tried to playing with the licenses and roles in the Project/Team with no avail.
What could be the problem?
From ccm.log:
2014-11-25 10:28:20,125 [WebContainer : 2 @@ 10:28 odedm /ccm/service/com.ibm.team.workitem.common.internal.rest.IWorkItemRestService/workItemDTO2] WARN .team.repository.servlet.AbstractTeamServerServlet - CRJAZ1163I TeamRepositoryException processing GET request for com.ibm.team.workitem.common.internal.rest.IWorkItemRestService.getWorkItemDTO2(). CRJAZ1170I The request was made by user "odedm" from "l-odedm.redbend.com".CRJAZ1166I The stack trace hash is C19511E1164BC78D10D5E914A5E77C6885C4370F.
com.ibm.team.repository.common.TeamRepositoryException: CRRTC0344E: User does not have permissions to view this workitem '25327'.
at com.ibm.team.workitem.service.internal.rest.WorkItemRestService.getWorkItem(WorkItemRestService.java:2073)
at com.ibm.team.workitem.service.internal.rest.WorkItemRestService.getWorkItemDTO2(WorkItemRestService.java:350)
at sun.reflect.GeneratedMethodAccessor892.invoke(Unknown Source)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:37)
at java.lang.reflect.Method.invoke(Method.java:611)
at org.eclipse.soda.sat.core.internal.record.ExportProxyServiceRecord.invoke(ExportProxyServiceRecord.java:361)
at org.eclipse.soda.sat.core.internal.record.ExportProxyServiceRecord.access$0(ExportProxyServiceRecord.java:347)
at org.eclipse.soda.sat.core.internal.record.ExportProxyServiceRecord$ExportedServiceInvocationHandler.invoke(ExportProxyServiceRecord.java:56)
at com.sun.proxy.$Proxy1762.getWorkItemDTO2(Unknown Source)
at sun.reflect.GeneratedMethodAccessor891.invoke(Unknown Source)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:37)
at java.lang.reflect.Method.invoke(Method.java:611)
at com.ibm.team.repository.servlet.AbstractTeamServerServlet.doModelledRestService(AbstractTeamServerServlet.java:543)
at com.ibm.team.repository.servlet.AbstractTeamServerServlet.handleRequest2(AbstractTeamServerServlet.java:2287)
at com.ibm.team.repository.servlet.AbstractTeamServerServlet.handleRequest(AbstractTeamServerServlet.java:2079)
at com.ibm.team.repository.servlet.AbstractTeamServerServlet.service(AbstractTeamServerServlet.java:1889)
at javax.servlet.http.HttpServlet.service(HttpServlet.java:668)
at org.eclipse.equinox.http.registry.internal.ServletManager$ServletWrapper.service(ServletManager.java:180)
at org.eclipse.equinox.http.servlet.internal.ServletRegistration.service(ServletRegistration.java:61)
at org.eclipse.equinox.http.servlet.internal.ProxyServlet.processAlias(ProxyServlet.java:126)
at org.eclipse.equinox.http.servlet.internal.ProxyServlet.service(ProxyServlet.java:76)
at javax.servlet.http.HttpServlet.service(HttpServlet.java:668)
at org.eclipse.equinox.servletbridge.BridgeServlet.service(BridgeServlet.java:120)
at com.ibm.team.repository.server.servletbridge.JazzServlet.service(JazzServlet.java:74)
at javax.servlet.http.HttpServlet.service(HttpServlet.java:668)
at com.ibm.ws.webcontainer.servlet.ServletWrapper.service(ServletWrapper.java:1230)
at com.ibm.ws.webcontainer.servlet.ServletWrapper.handleRequest(ServletWrapper.java:779)
at com.ibm.ws.webcontainer.servlet.ServletWrapper.handleRequest(ServletWrapper.java:478)
at com.ibm.ws.webcontainer.servlet.ServletWrapperImpl.handleRequest(ServletWrapperImpl.java:178)
at com.ibm.ws.webcontainer.filter.WebAppFilterChain.invokeTarget(WebAppFilterChain.java:136)
at com.ibm.ws.webcontainer.filter.WebAppFilterChain.doFilter(WebAppFilterChain.java:97)
at com.ibm.team.repository.server.servletbridge.BridgeFilter.processDelegate(BridgeFilter.java:165)
at com.ibm.team.repository.server.servletbridge.BridgeFilter.doFilter(BridgeFilter.java:198)
at com.ibm.ws.webcontainer.filter.FilterInstanceWrapper.doFilter(FilterInstanceWrapper.java:195)
at com.ibm.ws.webcontainer.filter.WebAppFilterChain.doFilter(WebAppFilterChain.java:91)
at com.ibm.ws.webcontainer.filter.WebAppFilterManager.doFilter(WebAppFilterManager.java:960)
at com.ibm.ws.webcontainer.filter.WebAppFilterManager.invokeFilters(WebAppFilterManager.java:1064)
at com.ibm.ws.webcontainer.servlet.CacheServletWrapper.handleRequest(CacheServletWrapper.java:87)
at com.ibm.ws.webcontainer.WebContainer.handleRequest(WebContainer.java:909)
at com.ibm.ws.webcontainer.WSWebContainer.handleRequest(WSWebContainer.java:1662)
at com.ibm.ws.webcontainer.channel.WCChannelLink.ready(WCChannelLink.java:200)
at com.ibm.ws.http.channel.inbound.impl.HttpInboundLink.handleDiscrimination(HttpInboundLink.java:459)
at com.ibm.ws.http.channel.inbound.impl.HttpInboundLink.handleNewRequest(HttpInboundLink.java:526)
at com.ibm.ws.http.channel.inbound.impl.HttpInboundLink.processRequest(HttpInboundLink.java:312)
at com.ibm.ws.http.channel.inbound.impl.HttpICLReadCallback.complete(HttpICLReadCallback.java:88)
at com.ibm.ws.ssl.channel.impl.SSLReadServiceContext$SSLReadCompletedCallback.complete(SSLReadServiceContext.java:1784)
at com.ibm.ws.tcp.channel.impl.AioReadCompletionListener.futureCompleted(AioReadCompletionListener.java:175)
at com.ibm.io.async.AbstractAsyncFuture.invokeCallback(AbstractAsyncFuture.java:217)
at com.ibm.io.async.AsyncChannelFuture.fireCompletionActions(AsyncChannelFuture.java:161)
at com.ibm.io.async.AsyncFuture.completed(AsyncFuture.java:138)
at com.ibm.io.async.ResultHandler.complete(ResultHandler.java:204)
at com.ibm.io.async.ResultHandler.runEventProcessingLoop(ResultHandler.java:775)
at com.ibm.io.async.ResultHandler$2.run(ResultHandler.java:905)
at com.ibm.ws.util.ThreadPool$Worker.run(ThreadPool.java:1862)
Accepted answer
For a single work item problem where nothing made sense, I found that the category's access restriction had been changed twice somewhat recently (was set to project, then changed to team, then back to project). To resolve my problem, I set the filed against value to something else and change it back to the original value. In the work item history, I can see the Access Restriction changed once, and it did not change again when I moved it back to the same category as at first. I am not sure if the access restriction is part of the index, but if it is, I imagine the index just got out of sync on this particular work item??
Comments
Right. This is the one I mentioned in my previous comment.
There is an attribute "Restricted access" that is always available (but does not have a presentation, by default). The Attribute can be manually set or it can be set by the category based automation. The attribute stores a context value which is later used to check if the user has access to that context (e.g. is member of the access group, the team area or has access to the category related team). See https://rsjazz.wordpress.com/2016/01/27/manage-access-control-permissions-for-work-items-and-versionables/ for some more information.
I don't think the index is an issue, but maybe somehow you could end up with strange values or cache situations.
One other answer
Is restricted access based on categories or access groups enabled? What are the Access Control Settings of the project area?
Comments
The access is restricted based on categories. The user is a member of the team area which is mapped to the category.
The access control is set to -
Members of the project area hierarchy
You sure the category does not select a sub team of the team he is member of?
I have verified it again. The configuration seems OK.
I might be missing something.
We are facing additional permissions issues. I will open a PMR.
Comments
Dave Evans
Sep 16 '16, 10:45 a.m.Did you ever resolve your problem?
We have one where the user can view many other work items with the same Filed Against category, but one particular work item he "does not have permission to view". Just for fun, we checked his licenses, his repository permissions, ensured that the category the work item is filed against does not have restricted access, and he is a member of the project... to no avail. Did you just need to do something like maybe reindex CCM?
Liora Milbaum
Sep 16 '16, 11:17 a.m.Yes. The problem was resolved back than. There is a work item attribute which is hidden. This attribute controls the work item permissions.