Community
Participate
Working Groups
In the 4.3 (Luna) development stream, the plugin.xml contributions of actions for creating resource folders and nodes of various kinds, as well as deleting resource nodes, were updated to contribute them only on resource nodes that are writable (according to the ObjectProperties 'writable' property). The problem is that the 'writable' property is false for objects in read-only views. However, these actions have always (and continue to) supported invocation in a read-only view context by opening a background transaction in which to do their work. Therefore, these action contributions should not be conditional on the 'writable' property but on the 'permission' property only. The consequence of this change in Luna is that when updating the CDO plug-ins in an Eclipse installation that has the Papyrus CDO integration (Kepler version), the Papyrus Model Repositories view-part no longer shows any of these creation and deletion actions: users can, most importantly, no longer create or delete folders, text resources, etc. The Model Repositories view-part uses a read-only CDOView to present the resource tree from each repository.
I have a fix in the works for this.
I have pushed a proposed fix to Gerrit: https://git.eclipse.org/r/17835
You're right, I forgot about the async resource node creation. We can continue to support that, but we should ensure that creation is only possible in views with view.getTimeStamp() == CDOBranchPoint.UNSPECIFIED_DATE. It would be good to have a new property "historical" in ViewProperties.
(In reply to Eike Stepper from comment #3) > > possible in views with view.getTimeStamp() == > CDOBranchPoint.UNSPECIFIED_DATE. It would be good to have a new property > "historical" in ViewProperties. That' same good point, if I understand correctly. Do you mean that a UI view could be showing a CDO view that is pinned on a past revision? It makes sense that this not be editable, indeed. So, the tip of a branch is indicated by having an unspecified creation date? That makes a sort of sense; I can see that a revision is not "created" yet until it is frozen in time.
(In reply to Christian W. Damus from comment #4) > Do you mean that a UI view could be showing a CDO view that is pinned on a past revision? Yes, when pinned on a past *time*. Note that a historical view can still link an object to the latest revision (in the target branch) if that's the one that's valid at that time. > So, the tip of a branch is indicated by having an unspecified creation date? You mean the creation time of a revision? That's always != 0. I refer to the (target) time of a view.
(In reply to Eike Stepper from comment #5) > (In reply to Christian W. Damus from comment #4) > > Do you mean that a UI view could be showing a CDO view that is pinned on a past revision? > > Yes, when pinned on a past *time*. Note that a historical view can still > link an object to the latest revision (in the target branch) if that's the > one that's valid at that time. Ah, right. Thanks, now I understand. This is taking an ad hoc baseline in time, which intersects the individual object histories *between* revisions. Got it. I have some actions in Papyrus that will need to test this same property!
Perfect ;-)
(In reply to Eike Stepper from comment #7) > Perfect ;-) Heh heh. Thanks. I have updated the Gerrit change with a new patch set that rebases the changes on the latest master and adds a check that the current selection is not an historical revision as determined by the view timestamp. I have tested this in normal head views and in audit views on a past time. In the former case, the actions are enabled as appropriate for the permissions on the selected object (or its container); in the latter case, none of these actions are enabled.
Fixed on git master. Thanks, Eike, for your help and reviews! commit 11b735eb878cd508e647e56b9358fb554616803a
Closing.
