EDIT

This is the same for taxa and names.

Katja Luther wrote:

The problem seems to be that we have to use the @transactional(readonly=false) and this means that the commit is called automatically after finishing the method call.
If we remove the @transactional annotation the deletion is not commited at all because for the whole taxonService transactional is set to readOnly=true.
Maybe it can be solved by using another parameter for this annotation.

Why should we use another parameter? Without knowing the concrete details readOnly=false seems reasonable to me as delete is not a readonly transaction.

Andreas Müller wrote:

Katja Luther wrote:

The problem seems to be that we have to use the @transactional(readonly=false) and this means that the commit is called automatically after finishing the method call.
If we remove the @transactional annotation the deletion is not commited at all because for the whole taxonService transactional is set to readOnly=true.
Maybe it can be solved by using another parameter for this annotation.

Why should we use another parameter? Without knowing the concrete details readOnly=false seems reasonable to me as delete is not a readonly transaction.

But then it is saved right after calling the method it not possible to undo the delete call by not saving the editor. As long as we don't have a better solution I will change the bulk editor that the dirty flag is not set, after deleting the object.

Katja Luther wrote:

Andreas Müller wrote:

Katja Luther wrote:

The problem seems to be that we have to use the @transactional(readonly=false) and this means that the commit is called automatically after finishing the method call.
If we remove the @transactional annotation the deletion is not commited at all because for the whole taxonService transactional is set to readOnly=true.
Maybe it can be solved by using another parameter for this annotation.

Why should we use another parameter? Without knowing the concrete details readOnly=false seems reasonable to me as delete is not a readonly transaction.

But then it saved right after calling the method it not possible to undo the delete call by not saving the editor.

I don't want to change the readonly=false, but maybe it is possible to avoid the automatic commit.

Katja Luther wrote:

Katja Luther wrote:
I don't want to change the readonly=false, but maybe it is possible to avoid the automatic commit.

This is not possible. As we do have single short transactions now we can't keep them open. A possible solution is to handle it similar to the deduplication algorithm where the entities to delete are remembered and are deleted/deduplicated only on save.
Another solution is to force save whenever a persisted object is deleted.

Whatever solution we choose please cover it with an according test.

I adapted the deletion to the merging and added the delete configurator to the lineAnnotation. Now the objects are annotated as deleted and the real deletion takes place when the whole bulk editor is saved.
Before the object is annotated as deleted the isDeletable method is called.

While testing I found 3 other issues that might be related. #6174, #6175, #6176. Please check if they are regressions before closing this ticket.

The media bulk editor is fixed now see Revision f1a1a089. The problem of deleting a transient object still exists.