Project

General

Profile

task #7843

blocking registrations can get lost when first TaxonNamePopupEditor with new name is not saved

Added by Andreas Kohlbecker about 1 year ago. Updated 2 months ago.

Status:
New
Priority:
Priority14
Category:
cdm-vaadin
Start date:
10/23/2018
Due date:
% Done:

0%

Severity:
normal
Tags:

Description

Consider the following situation:

  1. Registration Workingset Editor: user starts creating a new name
  2. From the TaxonNamePopupEditor for new name the user creates a new name as basionym.
  3. Saving the name to be used as basionym will create and persist a blocking registration which is stored in a local variable of the RegistrationWorkingsetEditor (see #7630).

Saving new initially started TaxonNamePopupEditor would create a new registration and the blocking registration would be added to the new registration. But the user can click Cancel in the first editor or can close the browser window, tab. In both cases the blocking registration would not be added to the main registration.

The user can start the registration of the new name from scratch, the basionym name now exists an can be selected from in the combobox.

This is not a big problem, but could cause situations in which requirement to solve the blocking registrations first before the main registration can be published is undermined.

Some options of how to deal with this:

  1. Curator is responsible for adding the 'lost' blocking registrations to the main registration
  2. When a blocking registration is created the new name in the initially opened editor is saved and the according main registration is created so that the blocking registration can be attached to it.
  3. When a name which is directly or indirectly related to a Registration in progress (e.g. basionym, or new genus of a basionym) an existing registration of the related name is considered as blocking when in one of the states (PEPARATION, CURATION) progress. So it is added as blocking registration to the main registration. What if the submitter of the blocking registration is different from the submitter of the main registration? (AK: only registrations of the same user should be used as blocking registrations)

Related issues

Related to Edit - bug #8462: NoSuchElementException accessing Optional<RegistrationDTO> in RegistrationWorkingsetPresenter.findRegistrationInContext() Closed 08/13/2019

History

#1 Updated by Andreas Kohlbecker 12 months ago

  • Priority changed from New to Priority14

#2 Updated by Andreas Kohlbecker 10 months ago

  • Target version changed from Release 5.5 to Release 5.6

#3 Updated by Andreas Kohlbecker 9 months ago

  • Target version changed from Release 5.6 to Reviewed Next Major Release

#4 Updated by Andreas Kohlbecker 2 months ago

  • Related to bug #8462: NoSuchElementException accessing Optional<RegistrationDTO> in RegistrationWorkingsetPresenter.findRegistrationInContext() added

#5 Updated by Andreas Kohlbecker 2 months ago

  • Description updated (diff)

#6 Updated by Andreas Kohlbecker 2 months ago

  • Description updated (diff)

#7 Updated by Andreas Kohlbecker 2 months ago

  • Description updated (diff)

#8 Updated by Andreas Kohlbecker 2 months ago

  • Description updated (diff)

I consider strategy 3 from above the most user friendly and robust solution

Also available in: Atom PDF

Add picture from clipboard (Maximum size: 40 MB)