Bug 552385

Summary:	EMFDeleteServiceImpl contradicts model's item providers
Product:	[Modeling] ECP	Reporter:	Christian Damus <give.a.damus>
Component:	EMF Forms	Assignee:	Christian Damus <give.a.damus>
Status:	CLOSED FIXED	QA Contact:	Eugen Neufeld <eneufeld>
Severity:	major
Priority:	P2	Keywords:	api, test
Version:	1.22.0
Target Milestone:	1.23.0
Hardware:	All
OS:	All
See Also:	https://git.eclipse.org/r/151632 https://git.eclipse.org/c/emfclient/org.eclipse.emf.ecp.core.git/commit/?id=3ac69b52d43418160870f6a19d174a1794fb3a15
Whiteboard:

Description Christian Damus

2019-10-24 12:57:10 EDT

I have a model in which the item providers do not provide executable remove commands in some cases (there are conditions on when an object may be removed from a certain container).  The default DeleteService implementation contradicts the model's edit providers by just going ahead to force deletion of an object even when the editing domain does not provide an executable delete command.

The delete service should respect the model's edit providers and only attempt deletion without a command in the case that there is no editing domain.

Comment 1 Eclipse Genie

2019-10-25 10:21:36 EDT

New Gerrit change created: https://git.eclipse.org/r/151632

Comment 2 Eclipse Genie

2019-10-25 18:18:41 EDT

Gerrit change https://git.eclipse.org/r/151632 was merged to [develop].
Commit: http://git.eclipse.org/c/emfclient/org.eclipse.emf.ecp.core.git/commit/?id=3ac69b52d43418160870f6a19d174a1794fb3a15

Comment 3 Christian Damus

2019-10-25 18:20:01 EDT

(In reply to Eclipse Genie from comment #2)
> Gerrit change https://git.eclipse.org/r/151632 was merged to [develop].

## TESTING INFORMATION
### Summary of the critical part of the change

The default implementation of the DeleteService protocol now implements a new optional ConditionalDeleteService protocol that can tell clients whether objects can be deleted or not (according to enablement of the commands provided by the EditingDomain).  For clients that don't care to check, it still will forcibly delete objects for which EMF.Edit provides unexecutable commands.  But a few EMF Forms components do now check and disable their delete functions where applicable.

### Potential regressions

Regression may occur in UI applications that previously assumed or required that the delete action was always enabled, where now it may not be if the model's edit providers don't offer executable deletion commands.

### Affected areas / use cases

- delete action in the context menu of the tree rendered by the
  TreeMasterDetailSWTRenderer
- delete button in the action bar of tables rendered by
  TableControlSWTRenderer and its subclasses (e.g. for Grid)
- delete button in the link control rendered by the
  MultiReferenceSWTRenderer

The TreeMasterDetailComposite used by the GenericEditor is not affected, as in fact it was already relying on the command provided by the editing domain to enable or disable the Delete action.  So it was already correct but not in agreement with other UI elements.

### Things that shall be tested

Deletion of objects in editors that use tables or the multi-reference link control to present contained objects:

- that root objects (having no containers) now correctly disable
  the UI (they could not be deleted before, but the UI didn't
  indicate that)
- that contained objects still can be deleted if their EMF.Edit
  providers allow it
- that the delete buttons are disabled for objects that are not
  permitted by their EMF.Editor providers to be deleted (there
  may not be examples of this in the ECP project's test models)

Comment 4 Christian Damus

2019-10-28 15:04:35 EDT

Verified in the 1.23 integration build 1230_201910281527.