Community
Participate
Working Groups
4.3 master as of commit d2985af. The CDOItemProvider hasChildren(Object) method is careful to check whether a CDOResourceFolder is readable before trying to determine whether it has any nodes. However, there is no such guard in the getChildren(Object) method. Some clients of the ITreeContentProvider API do not check hasChildren before asking the content provider for an object's children, so NoPermissionExceptions can arise. For example, in the editor I am developing for bug 418452, I am using a FilteredTree from JFace. In applying a filter, it asks for children of the elements of the tree without first checking hasChildren. In general, it is not required by the ITreeContentProvider protocol to ask hasChildren before getChildren.
Ugh. Once again, I messed up the attempt to push a review to Gerrit and ended up pushing my commit to master because it has been so long since I last did it. I followed that up with a revert. I have pushed a new Gerrit review with a fix: https://git.eclipse.org/r/17236
I hope that I come to your review today (after being in France for a week). Please not that recently I've added exceptional handling (they're now always accessible even if the containing object is not) for the three features that form the resource/folder tree: 1. EObject.eContainer (since this is an "Ecore system feature" it has always been readable and writable, but in this special case it implements the CDOResourceNode.folder feature) 2. CDOResourceNode.name 3. CDOResourceFolder.nodes The reason is that the resource loading mechanism always (in a slithly suboptimal manner) uses to traverse down to the loaded resource from the root. See AbstractCDOView.getResourceNodeID(CDOID, String) for details.
Hi, Eike, Thanks, I look forward to your review. My fix is quite simple: it just does exactly the same permission check in getChildren() as in hasChildren() for folders. Do you mean that I have missed some cases? Perhaps the hasChildren() also needs some more work?
commit ee878758bbff4a2d719788b20667f8bc759b0f73
Closing.
