Project

General

Profile

Actions

feature request #7920

open

Possibility to define area specific status selection

Added by Katja Luther about 4 years ago. Updated over 1 year ago.

Status:
Feedback
Priority:
Highest
Assignee:
Category:
taxeditor
Target version:
Start date:
Due date:
% Done:

70%

Estimated time:
Severity:
critical

Description

We need a possibility to define status selection lists depending on the area. For example in euro + med the status list for the EuroMed area should contain only endemic, not endemic and endemism unknown, for all other areas the standard status list should be available

implemented:

  • the status dropDown of the distribution editor evaluates whether there exist an preference for the selected area and when it exist display the status allowed.

still open:

  • possibility to define preference for area specific status in the preference pages
  • evaluation of preference in the details view of the distribution

Related issues

Related to EDIT - feature request #7932: Implement subject resolver for CdmPreferencesResolvedAndreas Müller

Actions
Related to EDIT - feature request #7860: [Master] Remaining E+M editor issuesNewKatja Luther

Actions
Related to EDIT - feature request #8256: Show all status preferences as tableFeedbackKatja Luther

Actions
Related to EDIT - feature request #8309: Implement preferences with predicate and subject in local preferencesNewKatja Luther

Actions
Actions #1

Updated by Andreas Müller about 4 years ago

  • Assignee changed from Katja Luther to Andreas Müller

Result of discussion: we use the subject part of the CdmPreferences. By defining something like /taxeditor/NamedArea:uuid .
With same predicate.

For this we need to further develop the evaluation of the subject within the service layer and also for the caches (Taxeditor preference cache and CdmPreferenceLookup used by vaadin/taxongraphdao).

A class representing the subject evaluation algorithm will be added to eu.etaxonomy.cdm.model.metadata. It can be used by the caches and by service layer then.

Actions #2

Updated by Andreas Müller about 4 years ago

Changed Assignee as I will try to implement the algorithm class first.

Actions #3

Updated by Andreas Müller about 4 years ago

  • Tags set to euro+med
  • Assignee changed from Andreas Müller to Katja Luther
Actions #4

Updated by Andreas Müller about 4 years ago

Actions #5

Updated by Andreas Müller about 4 years ago

  • Subject changed from possibility to define areaspecific status selection to Possibility to define area specific status selection
  • Description updated (diff)
Actions #6

Updated by Andreas Müller about 4 years ago

  • Severity changed from normal to critical
Actions #7

Updated by Katja Luther almost 4 years ago

  • Target version changed from Release 5.5 to Release 5.6
Actions #8

Updated by Andreas Kohlbecker almost 4 years ago

Is this feature request really only specific to the taxeditor?

To me it sounds like a preference for a project in general which should also be available to the vaadin distribution editor and to other clients. From this point of view it seems too restrictive to name the subject like /taxeditor/NamedArea:uuid

The provision of the filtered Term list per NamedArea should of course be due to the service layer as already stated in comment 1.

Actions #9

Updated by Andreas Müller almost 4 years ago

Andreas Kohlbecker wrote:

Is this feature request really only specific to the taxeditor?

To me it sounds like a preference for a project in general which should also be available to the vaadin distribution editor and to other clients. From this point of view it seems to restrictive to name the subject like /taxeditor/NamedArea:uuid

The provision of the filtered Term list per NamedArea should of course be due to the service layer as already stated in comment 1.

No, it is not specific to TaxEditor and also in the description it is not mentioned to be specific. Only in note-1 an example is given how it could look like. But this is only an example. The same way you can use /vaadin/NamedArea:uuid or /NamedArea:uuid . But this requires #7932 to be implemented by clients (caches) and in general is more related to #7932. The service is also implementing it but as clients primarily use the caches these are most important.

Actions #10

Updated by Andreas Müller almost 4 years ago

  • Target version changed from Release 5.6 to Reviewed Next Major Release
Actions #11

Updated by Andreas Müller almost 4 years ago

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

This is urgent for E+M and should be handled very soon. Latest in 5.7 but if possible in 5.6

Actions #12

Updated by Andreas Müller almost 4 years ago

Actions #13

Updated by Katja Luther almost 4 years ago

  • Status changed from New to In Progress
Actions #14

Updated by Katja Luther almost 4 years ago

  • Target version changed from Release 5.6 to Release 5.7
Actions #15

Updated by Katja Luther over 3 years ago

  • Description updated (diff)
Actions #16

Updated by Katja Luther over 3 years ago

  • Target version changed from Release 5.7 to Release 5.8
Actions #17

Updated by Katja Luther over 3 years ago

Actions #18

Updated by Andreas Müller over 3 years ago

  • Status changed from In Progress to Feedback
  • % Done changed from 0 to 70

To me this looks like being solved including the open issues. Please check and move open issues to a new ticket if needed.

Actions #19

Updated by Andreas Müller over 3 years ago

An open issue is that it should also be available for local prefs (where it is maybe more difficult to implement because of the key-value storage of these preferences. See also #8045#note-17.

Actions #20

Updated by Andreas Müller over 3 years ago

  • Related to feature request #8309: Implement preferences with predicate and subject in local preferences added
Actions #21

Updated by Andreas Müller over 1 year ago

  • Tags changed from euro+med to euro+med, preferences
Actions

Also available in: Atom PDF