Project

General

Profile

Actions

bug #9816

closed

Implement correct handling of more than one element for a character

Added by Katja Luther about 1 year ago. Updated about 1 year ago.

Status:
Closed
Priority:
New
Assignee:
Category:
taxeditor
Target version:
Start date:
Due date:
% Done:

100%

Estimated time:
Severity:
normal
Found in Version:

Description

Implement correct handling in the character matrix, if two or more elements exist for one character. If one of the elements are emtpty, this element should be deleted and the other should be displayed and if two filled elements exist both should be shown, but the field should be disabled.


Files

picture997-1.png (1.59 KB) picture997-1.png Andreas Müller, 11/02/2021 08:53 AM

Related issues

Related to EDIT - bug #9800: Open issues for character matrixIn ProgressKatja Luther

Actions
Actions #1

Updated by Andreas Müller about 1 year ago

  • Tags set to matrix, additivity
Actions #2

Updated by Katja Luther about 1 year ago

  • Status changed from New to In Progress
Actions #3

Updated by Katja Luther about 1 year ago

  • Status changed from In Progress to Resolved

The disabling of the fields for two or more elements per feature is implemented.

Actually if one of the fields is empty it is handled the same, this need to be handled in a separate ticket.

Actions #4

Updated by Andreas Müller about 1 year ago

  • Target version changed from Release 5.37 to Release 5.28
Actions #5

Updated by Katja Luther about 1 year ago

  • Assignee changed from Katja Luther to Andreas Müller
  • Target version changed from Release 5.28 to Release 5.37

Tested with Structured DDS Test:

  • For Descripta prima there exist two elements for "bush property", they are greyed and not editable.
  • Additional Tests to avoid regressions:
    • adding a new categorical element
    • add a state to an existing element
    • removing one state and all states
    • adding a new quantitative element
    • adding a new value to a quantitative element
    • removing one/all values of a quantitative element
Actions #6

Updated by Andreas Müller about 1 year ago

  • Target version changed from Release 5.37 to Release 5.28
Actions #7

Updated by Andreas Müller about 1 year ago

  • Status changed from Resolved to Feedback
  • Assignee changed from Andreas Müller to Katja Luther
  • % Done changed from 0 to 70

This works as expected. Only a few minor thinks:

  • for users it might be unclear why the cell is greyed. So maybe we could add a tooltip saying "Multiple data exist. Editing only possible in factual data view of specimen" or "... taxon" depending on the description type.
    Later we should also add an "open in" for each cell which opens the according factual data view. Can you create a ticket for this if not yet exists. The ticket could be more generic, also for complete rows (specimen description + taxon descriptions and taxa)

  • the grey color is the same as for cells covered by a default value, we should distinguish them somehow. Best would be do show for default values simply a light grey text with the defined default value, but this might be not trivial to implement => new ticket, so maybe for now the default value cells could be made light brown or any other color (but not a strong color). This is because grey indicates that a cell is not editable while default cells are actually editable

Please decide what needs to be done in a new ticket and what can be done immediately with not much effort.

Actions #8

Updated by Katja Luther about 1 year ago

Andreas Müller wrote:

This works as expected. Only a few minor thinks:

  • for users it might be unclear why the cell is greyed. So maybe we could add a tooltip saying "Multiple data exist. Editing only possible in factual data view of specimen" or "... taxon" depending on the description type.
    Later we should also add an "open in" for each cell which opens the according factual data view. Can you create a ticket for this if not yet exists. The ticket could be more generic, also for complete rows (specimen description + taxon descriptions and taxa)

  • the grey color is the same as for cells covered by a default value, we should distinguish them somehow. Best would be do show for default values simply a light grey text with the defined default value, but this might be not trivial to implement => new ticket, so maybe for now the default value cells could be made light brown or any other color (but not a strong color). This is because grey indicates that a cell is not editable while default cells are actually editable

Please decide what needs to be done in a new ticket and what can be done immediately with not much effort.

for this release a tooltip for the disabled field is implemented and the grey of fields with default value is a little bit brighter.

Actions #9

Updated by Katja Luther about 1 year ago

  • Related to bug #9800: Open issues for character matrix added
Actions #10

Updated by Katja Luther about 1 year ago

  • Status changed from Feedback to Resolved

Katja Luther wrote:

Andreas Müller wrote:

This works as expected. Only a few minor thinks:

  • for users it might be unclear why the cell is greyed. So maybe we could add a tooltip saying "Multiple data exist. Editing only possible in factual data view of specimen" or "... taxon" depending on the description type. Later we should also add an "open in" for each cell which opens the according factual data view. Can you create a ticket for this if not yet exists. The ticket could be more generic, also for complete rows (specimen description + taxon descriptions and taxa)

this is already part of #9800

  • the grey color is the same as for cells covered by a default value, we should distinguish them somehow. Best would be do show for default values simply a light grey text with the defined default value, but this might be not trivial to implement => new ticket, so maybe for now the default value cells could be made light brown or any other color (but not a strong color). This is because grey indicates that a cell is not editable while default cells are actually editable

Please decide what needs to be done in a new ticket and what can be done immediately with not much effort.

for this release a tooltip for the disabled field is implemented and the grey of fields with default value is a little bit brighter.

Actions #11

Updated by Katja Luther about 1 year ago

  • Assignee changed from Katja Luther to Andreas Müller

Katja Luther wrote:

Katja Luther wrote:

Andreas Müller wrote:

This works as expected. Only a few minor thinks:

  • for users it might be unclear why the cell is greyed. So maybe we could add a tooltip saying "Multiple data exist. Editing only possible in factual data view of specimen" or "... taxon" depending on the description type. Later we should also add an "open in" for each cell which opens the according factual data view. Can you create a ticket for this if not yet exists. The ticket could be more generic, also for complete rows (specimen description + taxon descriptions and taxa)

this is already part of #9800

  • the grey color is the same as for cells covered by a default value, we should distinguish them somehow. Best would be do show for default values simply a light grey text with the defined default value, but this might be not trivial to implement => new ticket, so maybe for now the default value cells could be made light brown or any other color (but not a strong color). This is because grey indicates that a cell is not editable while default cells are actually editable

Please decide what needs to be done in a new ticket and what can be done immediately with not much effort.

for this release a tooltip for the disabled field is implemented and the grey of fields with default value is a little bit brighter.

tested with Structured DDS Test for taxon and specimen descriptions

Actions #12

Updated by Andreas Müller about 1 year ago

  • Status changed from Resolved to Feedback
  • Assignee changed from Andreas Müller to Katja Luther

I found an open issue: The literature description of Descripta prima in the test dataset for bush color has 1 record with only "yellow" and another one with "Yellow, Blue" the resulting shown record is "Yellow, Blue" which leads to a strange result in aggregation where both records are countet. So aggregation leads to "Yellow(2), Blue" plus additional values from other records. Do we use different label providers for aggegated data and for greyed data? Or is there another reason?

If not I guess we should try to use the same label provider to avoid confusion.

Actions #13

Updated by Katja Luther about 1 year ago

Andreas Müller wrote:

I found an open issue: The literature description of Descripta prima in the test dataset for bush color has 1 record with only "yellow" and another one with "Yellow, Blue" the resulting shown record is "Yellow, Blue" which leads to a strange result in aggregation where both records are countet. So aggregation leads to "Yellow(2), Blue" plus additional values from other records. Do we use different label providers for aggegated data and for greyed data? Or is there another reason?

If not I guess we should try to use the same label provider to avoid confusion.

The label is created in RowWrapperDto and is the same for aggregated and greyed data.

Actions #14

Updated by Andreas Müller about 1 year ago

Then the ticket is not correctly implemented as there is yellow 2x in existing as described above. I also cannot believe that it is the same as aggregated data always show the count in brackets but greyed data don't show

Actions #15

Updated by Katja Luther about 1 year ago

Andreas Müller wrote:

Then the ticket is not correctly implemented as there is yellow 2x in existing as described above. I also cannot believe that it is the same as aggregated data always show the count in brackets but greyed data don't show

The count is integrated in the description elements and is filled during aggregation, it is not the count of the description elements belonging to a feature in one description.

Actions #16

Updated by Andreas Müller about 1 year ago

Katja Luther wrote:

The count is integrated in the description elements and is filled during aggregation, it is not the count of the description elements belonging to a feature in one description.

Ok, I understand. I forgot that we have an explicit count attibute now. However, we should think about a solution. Data like

are confusing for the user (at least for me they were).

However, as such data exist not very often it has not highest priority if difficult to implement.

Actions #17

Updated by Andreas Müller about 1 year ago

KL:

die schnelle Lösung wäre, dass einfach alle Daten, auch doppelte angezeigt werden

Actions #18

Updated by Katja Luther about 1 year ago

  • Status changed from Feedback to Resolved
  • Assignee changed from Katja Luther to Andreas Müller

Please do short review whether we can close this ticket.

Actions #19

Updated by Andreas Müller about 1 year ago

  • Status changed from Resolved to Closed
  • Assignee changed from Andreas Müller to Katja Luther
  • % Done changed from 70 to 100

Works as expected.

Actions

Also available in: Atom PDF