Project

General

Profile

bug #7849

Improve DB Preferences handling and saving in TaxEditor

Added by Andreas Müller about 1 year ago. Updated 5 months ago.

Status:
Feedback
Priority:
New
Assignee:
Category:
taxeditor
Target version:
Start date:
10/23/2018
Due date:
% Done:

90%

Severity:
critical
Found in Version:

Description

Currently it often happens that DB preferences are not (correctly) saved if pressing OK or Apply in DB preferences dialog.

We need a framework that makes it easy to always handle save of preferences correctly.

The framework may include:

  • a registry which returns a list of all available pref.predicates, including the expected default values (for all predicates allow override = true must be part of the default value)
  • when opening TaxEditor and when opening the DB preferences view all registered values are freshly read from DB
    • when opening pref view all values are written to the UI including values for allow override
    • when saving cache is emptied and reloaded for registered list of predicates, all values are read from the UI (if available there), only those values NOT yet handled via UI must NOT be deleted from cache (theses might be experimental feature with no configuration UI available yet)
    • when saving all predicates of the registration are saved to database
      • if value+allowOverride = default value => delete
      • otherwise: save value (API will decide if create or update is needed

====

This ticket should also include a check for all existing UI pages if they work and throw no exceptions (especially with a DB with empty CdmPreference table), see also #7848

====

Further improvements:

  • buttons "Apply" and "OK" should be disabled if no changes are available since last save, this also holds for the local prefs dialog => #8385

Related issues

Related to Edit - feature request #7810: DB preference to make all Specimen functionality/menu items invisible Feedback 10/08/2018
Related to Edit - bug #7848: Exceptions for some cdm preference pages Closed 10/23/2018
Related to Edit - feature request #7901: Make PreferencePredicates an interface to allow multiple implementations (e.g. for client apps, for grouping, for data type specific instances, etc.) Closed 11/12/2018
Related to Edit - bug #7236: Make available distribution status a database preference for TaxEditor distribution editor Feedback 02/01/2018
Related to Edit - bug #7880: Implement centralized preference default loading strategy Closed 10/30/2018
Related to Edit - bug #7856: Allow local override for distribution vocabularies Closed 10/23/2018
Related to Edit - feature request #8062: Make default preferences deletable serverside In Progress 02/04/2019
Related to Edit - feature request #8045: Improve handling of default values and override in local preferences Feedback 01/31/2019
Related to Edit - bug #8385: Open issues in DB preferences Feedback 07/18/2019
Blocked by Edit - feature request #7902: Allow default values for PreferencePredicates In Progress 11/12/2018
Copied to Edit - feature request #8092: set default for term and vocabulary selection preferences in selection wizard Closed 02/11/2019
Copied to Edit - feature request #8089: improve abcd preference page New 02/09/2019

Associated revisions

Revision 53d9aad0 (diff)
Added by Patrick Plitzner about 1 year ago

fix #7810 Fix saving of specimen DB preferences

  • failed to save when initally no preferences were set

Revision d3ec20ed (diff)
Added by Patrick Plitzner about 1 year ago

ref #7849 String externalization and label adjustment

Revision 5e3a2c94 (diff)
Added by Patrick Plitzner about 1 year ago

ref #7849 Set override flag to true if no pref was found

Revision cdad4890 (diff)
Added by Patrick Plitzner about 1 year ago

ref #7849 Set allowOverride to true

Revision e974354a (diff)
Added by Patrick Plitzner about 1 year ago

ref #7849 Fix potential NPE

Revision 39a72cef (diff)
Added by Patrick Plitzner about 1 year ago

ref #7849 Always show override checkbox in name details admin prefs

Revision 986b34c8 (diff)
Added by Patrick Plitzner about 1 year ago

ref #7849 Temporarily removed general DB preferences

Revision 923fbf1e (diff)
Added by Katja Luther about 1 year ago

ref #7849: save ABCD configuration with correct preference subject

Revision bf0c676a (diff)
Added by Patrick Plitzner about 1 year ago

ref #7849 code refactoring

Revision b123c0b7 (diff)
Added by Katja Luther about 1 year ago

ref #7849: move general db preferences to its own tab to avoid saving if not edited

Revision 432276e4 (diff)
Added by Katja Luther about 1 year ago

ref #7849: harmonize admin and local preferences for distribution editor and use drop down instead of radio buttons

Revision c130c5fe (diff)
Added by Katja Luther about 1 year ago

ref #7849: do not save preferences if page was not edited

Revision a51915c2 (diff)
Added by Katja Luther about 1 year ago

ref #7849: handle exception if value of preference not in Enum for areaDisplay

Revision 185eb33b (diff)
Added by Katja Luther about 1 year ago

ref #7849: improve DB preference handling and use editorpreferencePredicates keys also for local preferences

Revision 9181d281 (diff)
Added by Katja Luther about 1 year ago

ref #7849: continue adapt db and local preference pages

Revision 12d75812 (diff)
Added by Katja Luther about 1 year ago

ref #7849: remove OVERRIDE constants from IPreferenceKeys and handle it by method

Revision fbd932cc (diff)
Added by Katja Luther 12 months ago

ref #7849: disable apply button until something was changed in preference page

Revision ebb78401 (diff)
Added by Katja Luther 10 months ago

ref #7849: fix problems in specimen preference page

Revision 42aae678 (diff)
Added by Katja Luther 10 months ago

ref #7849: fix problems in preferences

Revision 31bef991 (diff)
Added by Katja Luther 10 months ago

ref #7849: minor changes specimen related preferences

Revision 8db3ccd6 (diff)
Added by Katja Luther 10 months ago

ref #7849: correct enabling of local prefs with no allowOverride and sortOrder for areas in distr. editor

Revision faa0d5c5 (diff)
Added by Katja Luther 10 months ago

ref #7849: add missing override button to status selection

Revision b5f2ab89 (diff)
Added by Katja Luther 10 months ago

ref #7849: do not set details part of specimen pref page invisible

Revision c50a3625 (diff)
Added by Katja Luther 10 months ago

ref #7849: correct enabling/disabling of override buttons

Revision e5b6bb85 (diff)
Added by Katja Luther 10 months ago

ref #7849: show db preference for status and area vocabularies if no local prefs exist

Revision ed86aee4 (diff)
Added by Andreas Müller 10 months ago

ref #7849 add byKey() to TermDisplayEnum

Revision 724c93bd (diff)
Added by Andreas Müller 10 months ago

ref #7849 use TermDisplayEnum.byKey()

Revision bf95f6e9 (diff)
Added by Andreas Müller 10 months ago

ref #7849 make byKey() static

Revision b7544987 (diff)
Added by Katja Luther 10 months ago

ref #7849: fix correct saving in common name area selection

Revision cec27740 (diff)
Added by Katja Luther 10 months ago

ref #7849: fix problems with preferences

Revision fab52cf2 (diff)
Added by Katja Luther 10 months ago

ref #7849: check all voc if no pref exist

Revision 852ab2c5 (diff)
Added by Katja Luther 10 months ago

ref #7849: add message to term selection wizard that no selection -> all terms available, smaller adapation in areaselection dialogs

Revision d9ff01e1 (diff)
Added by Katja Luther 10 months ago

ref #7849: identation for sec preferences

Revision 88785766 (diff)
Added by Katja Luther 10 months ago

ref #7849: nomenclatural code change allowOverride -> apply activated

Revision 00e51d7a (diff)
Added by Katja Luther 10 months ago

ref #7849: fix problems with nomenclatural code preference

Revision ba924c16 (diff)
Added by Katja Luther 10 months ago

ref #7849: fix problems with nomenclatural code preference continue

Revision 85bd68d3 (diff)
Added by Katja Luther 10 months ago

ref #7849: add correct handling for restoreDefaults in DB preference pages

Revision ff8dd44d (diff)
Added by Katja Luther 10 months ago

ref #7849: update name details page when restore default

Revision dd2e9b75 (diff)
Added by Katja Luther 10 months ago

ref #7849: default values in local preferences

Revision 9445fcdc (diff)
Added by Katja Luther 10 months ago

ref #7849: if term selection is null the default value is used -> delete pref from db

Revision 6855b870 (diff)
Added by Katja Luther 10 months ago

ref #7849: set default for term selection on local preferences

Revision f54da8eb (diff)
Added by Katja Luther 10 months ago

ref #7849: minor

History

#1 Updated by Andreas Müller about 1 year ago

AM:

Grundsätzlich ist das Problem nicht ganz trivial, da das Zusammenspiel zwischen Default Werten, geänderten Werten und Cache funktionieren muss.

Wenn ein Wert geändert wurde und somit vom Default abweicht, muss er bei „Apply“ oder „OK“ sowohl in der DB als auch im Cache gespeichert werden.
Was allerdings möglichst nicht passieren sollte ist, dass Werte, die gar nicht geändert wurden auch gespeichert werden. Das war am Anfang der Fall, da hat Katja quasi alle möglichen Werte ausgelesen und in die DB geschrieben, es sollen aber möglichst nur die Abweichungen rein.

Zu diskutieren wäre dann noch, ob Werte die zurück geändert werden auf den Default Wert aus der DB gelöscht werden sollen, oder ob sie drin bleiben sollen, wenn einmal existent (was vermutlich leichter ist zu implementieren).

Ich fände es übrigens auch gut, wenn beim Öffnen des DB Preferences Dialogs grundsätzlich alle Werte aus der DB ausgelesen werden und der Cache gelernt und mit den aktuellsten Werten gefüllt wird. So ist man auf der sichereren Seite, auch, wenn mal mehrere Leute an den Preferences arbeiten.

#2 Updated by Andreas Müller about 1 year ago

  • Description updated (diff)

#3 Updated by Andreas Müller about 1 year ago

  • Related to feature request #7810: DB preference to make all Specimen functionality/menu items invisible added

#4 Updated by Andreas Müller about 1 year ago

  • Description updated (diff)

#5 Updated by Andreas Müller about 1 year ago

  • Related to bug #7848: Exceptions for some cdm preference pages added

#6 Updated by Andreas Müller about 1 year ago

  • Description updated (diff)

#7 Updated by Andreas Müller about 1 year ago

  • Description updated (diff)

#8 Updated by Andreas Müller about 1 year ago

Das Problem ist aber eher, dass zuviel gespeichert wird.
Wenn man nur den DB Preferences Dialog öffnet und wieder schließt werden bereits 5 Preferences gespeichert.
Unter anderem die, welches common name area Vokabular verwendet werden soll, nämlich KEINS. Override nicht möglich.

Das führt beim Versuch einen Common Name Area auszuwählen dann z.B. zu:

java.lang.NullPointerException
    at eu.etaxonomy.taxeditor.ui.dialog.selection.CommonNameNamedAreaSelectionDialog.getAvailableVocabularies(CommonNameNamedAreaSelectionDialog.java:74)
    at eu.etaxonomy.taxeditor.ui.dialog.selection.CommonNameNamedAreaSelectionDialog.init(CommonNameNamedAreaSelectionDialog.java:64)
    at eu.etaxonomy.taxeditor.ui.dialog.selection.AbstractFilteredCdmResourceSelectionDialog.<init>(AbstractFilteredCdmResourceSelectionDialog.java:103)

Das ist ein grundsätzliches Problem, dass etwas gespeichert wird auch wenn der User überhaupt nichts geändert hat, welches auch zeigt, dass an der Architektur noch etwas nicht stimmt.
Ich glaube, ohne Default Werte zu hinterlegen (wo auch immer), kommen wir da nicht weiter.
Am besten sollten diese gar nicht erst gespeichert werden, aber wenn etwas gespeichert wird, dann sollte wenigstens der hinterlegte Default gespeichert werden, so dass man nicht versehentlich eine Preference anlegt, die man gar nicht wollte.

#9 Updated by Patrick Plitzner about 1 year ago

"Änderungen an ABCD Import werden nicht gespeichert, außer allowOverride, aber auch das wird nicht richtig reloaded beim erneuten Öffnen"

#10 Updated by Andreas Müller about 1 year ago

If the NomenclaturalCode is once set it can not be removed anymore in the DB Pref display even if the Preferences is manually removed from the database. It looks like the dropdown uses the local preference for display.
Also the AllowOverride is implemented in the wrong way here. In DB Pref UI there is no checkbox while in local Prefs there is a checkbox saying "use local xxx"

#11 Updated by Katja Luther about 1 year ago

Andreas Müller wrote:

If the NomenclaturalCode is once set it can not be removed anymore in the DB Pref display even if the Preferences is manually removed from the database. It looks like the dropdown uses the local preference for display.

The preferred nomenclatural code is set when the editor is started, in the wizard the actual code is set to this preferred nomenclatural code if the pref does not exist.
But maybe it is better to keep it empty.

Also the AllowOverride is implemented in the wrong way here. In DB Pref UI there is no checkbox while in local Prefs there is a checkbox saying "use local xxx"

#12 Updated by Katja Luther about 1 year ago

Patrick Plitzner wrote:

"Änderungen an ABCD Import werden nicht gespeichert, außer allowOverride, aber auch das wird nicht richtig reloaded beim erneuten Öffnen"

this again was the wrong preference subject

#13 Updated by Andreas Müller about 1 year ago

  • Assignee changed from Patrick Plitzner to Katja Luther
  • Target version changed from Release 5.4 to Release 5.5

#14 Updated by Katja Luther about 1 year ago

The general DB preferences are moved now to an extra page so they are not stored, if not opened.

#15 Updated by Andreas Müller about 1 year ago

#16 Updated by Andreas Müller about 1 year ago

  • Related to feature request #7901: Make PreferencePredicates an interface to allow multiple implementations (e.g. for client apps, for grouping, for data type specific instances, etc.) added

#17 Updated by Andreas Müller about 1 year ago

  • Related to bug #7236: Make available distribution status a database preference for TaxEditor distribution editor added

#18 Updated by Andreas Müller 11 months ago

  • Related to bug #7880: Implement centralized preference default loading strategy added

#19 Updated by Andreas Müller 11 months ago

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

Can this be reviewed?

#20 Updated by Andreas Müller 11 months ago

??

#21 Updated by Andreas Müller 11 months ago

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

If default value is selected and allow override = true the preference is still not deleted from the database. This is not really critical but problematic as it requires that some chooses "override" in the local prefs to make local prefs work, though nobody really set a DB preference (with no DB preference set override should not be required to make local prefs works, otherwise we could remove the "override" from local prefs)

#22 Updated by Andreas Müller 11 months ago

If override is not set in local prefs the value can be changed but it is not saved with Apply/OK. Is this wanted behavior? It is not intuitive and unexpected for the user. If something can not be changed, it should be disabled. Needs discussion if editing should be allowed in this case. Tested with distribution editor.

With specimen page I tested if this is also the case if no DB pref is set and it looks like if no DB pref exists changes are persisted. This is critical especially because currently default value DB prefs are stored in the DB even if nobody set them on purpose (see above).

Personally I think, the value should always be editable and persisted (except for the case when override is not allowed)

#23 Updated by Andreas Müller 11 months ago

Special case in Specimen page of local prefs: In a fresh database "Zeige specimenbezogene Views und Menüeinträge" is disabled but shouldn't (default is to show specimen menüs).

Also: if the above ceckbox is unchecked the below 4 checkboxes are still shown after reopening the preferences but shouldn't. Behavior when opening the preferences should be same as when changing the value of the above checkbox.

#24 Updated by Andreas Müller 11 months ago

It looks like in the DB prefs specimen page the 4 below prefs are not set to allow override by default. ALL preference should by default allow override.

#25 Updated by Andreas Müller 11 months ago

  • Severity changed from normal to critical

Critical: DB prefs for Name Details View do not seem to exist anymore

#26 Updated by Andreas Müller 11 months ago

  • Related to bug #7856: Allow local override for distribution vocabularies added

#27 Updated by Katja Luther 10 months ago

Andreas Müller wrote:

It looks like in the DB prefs specimen page the 4 below prefs are not set to allow override by default. ALL preference should by default allow override.

this is fixed.

#28 Updated by Katja Luther 10 months ago

Andreas Müller wrote:

Critical: DB prefs for Name Details View do not seem to exist anymore

this is fixed

#29 Updated by Katja Luther 10 months ago

Andreas Müller wrote:

Special case in Specimen page of local prefs: In a fresh database "Zeige specimenbezogene Views und Menüeinträge" is disabled but shouldn't (default is to show specimen menüs).

Also: if the above ceckbox is unchecked the below 4 checkboxes are still shown after reopening the preferences but shouldn't. Behavior when opening the preferences should be same as when changing the value of the above checkbox.

this is fixed

#30 Updated by Katja Luther 10 months ago

Andreas Müller wrote:

If default value is selected and allow override = true the preference is still not deleted from the database. This is not really critical but problematic as it requires that some chooses "override" in the local prefs to make local prefs work, though nobody really set a DB preference (with no DB preference set override should not be required to make local prefs works, otherwise we could remove the "override" from local prefs)

but this should be handled on serverside?

#31 Updated by Katja Luther 10 months ago

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

Katja Luther wrote:

Andreas Müller wrote:

If default value is selected and allow override = true the preference is still not deleted from the database. This is not really critical but problematic as it requires that some chooses "override" in the local prefs to make local prefs work, though nobody really set a DB preference (with no DB preference set override should not be required to make local prefs works, otherwise we could remove the "override" from local prefs)

but this should be handled on serverside?

I would move this to a new ticket because it is an cdmlib issue?

the rest should be fixed.

#32 Updated by Andreas Müller 10 months ago

#33 Updated by Andreas Müller 10 months ago

Katja Luther wrote:

Andreas Müller wrote:

If default value is selected and allow override = true the preference is still not deleted from the database. This is not really critical but problematic as it requires that some chooses "override" in the local prefs to make local prefs work, though nobody really set a DB preference (with no DB preference set override should not be required to make local prefs works, otherwise we could remove the "override" from local prefs)

but this should be handled on serverside?

Unfortunately this is more difficult then expected because CdmPreference does only contain a String as Predicate. So the default value is missing. For enum values available on server side this can be handled, but for others it is not possible. Created new ticket for this issue #8062

#34 Updated by Andreas Müller 10 months ago

  • Related to feature request #8045: Improve handling of default values and override in local preferences added

#35 Updated by Andreas Müller 10 months ago

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

On Specimen page, when "Show specimen related views" is unchecked but allow override = true the specific preferences like "Collecting areas in general section" should still be visible. This is because if allow override is selected local preference may still define these preferences and then you need to be able to still define certain preferences DB wide.

#36 Updated by Andreas Müller 10 months ago

Andreas Müller wrote:

On Specimen page, when "Show specimen related views" is unchecked but allow override = true the specific preferences like "Collecting areas in general section" should still be visible. This is because if allow override is switched local preference may still define these preferences and then you need to be able to still define certain preferences DB wide.

Same applies for Name Details View (and similar pages in future).

For distribution editor this is already implemented, BUT here we could think about hiding the page if "Enable Distribution Editor" is unchecked and also "Allow override" is unchecked". In this case it does not make sense to allow defining any specific preferences.

#37 Updated by Andreas Müller 10 months ago

Distribution Editor page: "Show rank in..." and "Sort areas by order ..." are local enabled even if allow override is unchecked in DB prefs. This is not correct. For "Display of areas .." it seems to be correct.

#38 Updated by Andreas Müller 10 months ago

Distribution Editor page local prefs: "override" is missing in distribution status selection, seems to be correct in area selection

#39 Updated by Katja Luther 10 months ago

Andreas Müller wrote:

Distribution Editor page: "Show rank in..." and "Sort areas by order ..." are local enabled even if allow override is unchecked in DB prefs. This is not correct. For "Display of areas .." it seems to be correct.

this should be fixed

#40 Updated by Katja Luther 10 months ago

Andreas Müller wrote:

Distribution Editor page local prefs: "override" is missing in distribution status selection, seems to be correct in area selection

is fixed

#41 Updated by Katja Luther 10 months ago

now for specimen, name details and distribution editor the details are only disabled not invisible when the more global preference is unchecked.

#42 Updated by Andreas Müller 10 months ago

I would expect if DB pref distribution status is set with allow override and local prefs are not yet set that when opening the dialog the dialog is prefilled with the DB pref status list.

#43 Updated by Andreas Müller 10 months ago

Katja Luther wrote:

now for specimen, name details and distribution editor the details are only disabled not invisible when the more global preference is unchecked.

for distribution editor preferences are still editable if "Show ..." and "allow override" are both unchecked, but should not be editable

for specimen and name details the specific prefs are still not yet editable if "allow override" is checked but should be editable

#44 Updated by Andreas Müller 10 months ago

I think everything else is fixed. Open issues note-33 (maybe needs discussion) and note-42 and note-43

#45 Updated by Katja Luther 10 months ago

Andreas Müller wrote:

Katja Luther wrote:

now for specimen, name details and distribution editor the details are only disabled not invisible when the more global preference is unchecked.

for distribution editor preferences are still editable if "Show ..." and "allow override" are both unchecked, but should not be editable
this is fixed

for specimen and name details the specific prefs are still not yet editable if "allow override" is checked but should be editable

the name details can be edited, but first the use of the simplified view has to be checked to be able to edit the details

Do I understand correctly that the specimen prefs all are only depending on the allow override? So if "Show specimen related views" is unchecked the other prefs should still be editable?

#46 Updated by Katja Luther 10 months ago

Andreas Müller wrote:

I would expect if DB pref distribution status is set with allow override and local prefs are not yet set that when opening the dialog the dialog is prefilled with the DB pref status list.

is implemented

#47 Updated by Katja Luther 10 months ago

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

note-42 and note-43 are implemented, so I set the ticket to resolved.

#48 Updated by Andreas Müller 10 months ago

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

After trying to set values to default values I could not open the preference page anymore:

login : admin
editor version : 5.5.0.201902072350
server : test.e-taxonomy.eu (edit-test) / test1
schema version : 5.0.0.0.20180514
os : Windows Server 2012 R2 6.3 amd64
java : 1.8.0_121
java.lang.IllegalArgumentException: No enum constant eu.etaxonomy.cdm.model.metadata.TermDisplayEnum.Label
    at java.lang.Enum.valueOf(Enum.java:238)
    at eu.etaxonomy.cdm.model.metadata.TermDisplayEnum.valueOf(TermDisplayEnum.java:1)
    at eu.etaxonomy.taxeditor.preference.ChecklistEditorGeneralPreference.createContents(ChecklistEditorGeneralPreference.java:362)
    at eu.etaxonomy.taxeditor.databaseAdmin.preferencePage.ChecklistEditorGeneralAdminPreference.createContents(ChecklistEditorGeneralAdminPreference.java:32)
    at org.eclipse.jface.preference.PreferencePage.createControl(PreferencePage.java:241)
    at eu.etaxonomy.taxeditor.preference.menu.CdmPreferencePage.createControl(CdmPreferencePage.java:57)
    at org.eclipse.jface.preference.PreferenceDialog.createPageControl(PreferenceDialog.java:1430)
    at org.eclipse.jface.preference.PreferenceDialog$9.run(PreferenceDialog.java:1197)
    at org.eclipse.core.runtime.SafeRunner.run(SafeRunner.java:42)
...

#49 Updated by Andreas Müller 10 months ago

The above is fixed with commits ed86aee4 ff but still should be reviewed by KL.

#50 Updated by Andreas Müller 10 months ago

Again I get "The currently displayed page contains invalid values" for a DB with no DBprefs defined and also no local prefs defined for page "Distribution Editor" on DB prefs. This is critical.

#51 Updated by Andreas Müller 10 months ago

This seems to be the reason:

java.lang.NullPointerException
    at eu.etaxonomy.taxeditor.preference.ChecklistEditorGeneralPreference.createContents(ChecklistEditorGeneralPreference.java:315)
    at eu.etaxonomy.taxeditor.databaseAdmin.preferencePage.ChecklistEditorGeneralAdminPreference.createContents(ChecklistEditorGeneralAdminPreference.java:32)
    at org.eclipse.jface.preference.PreferencePage.createControl(PreferencePage.java:241)

#52 Updated by Andreas Müller 10 months ago

Common name areas: when opening the dialog it is always empty but should show the vocabularies selected before

#53 Updated by Andreas Müller 10 months ago

Andreas Müller wrote:

Common name areas: when opening the dialog it is always empty but should show the vocabularies selected before

Maybe it is not stored correctly in the cache. Even if 1 vocabulary is selected all vocabularies are shown for selection in common name area selection dialog.

#54 Updated by Andreas Müller 10 months ago

Also it is not possible to delete this preference by setting it to default. If no vocabulary is selected an empty string is persisted. Default is null this might be the reason why it is not recognized as default.

Generally we need to discuss how to set the vocabulary/term-list selections to default. Is it by a certain selection, or with a button (in dialog or on preference page)?

Also we need to discuss if an empty list should be allowed at all or if we disable "Finish" if no entry has been selected

#55 Updated by Andreas Müller 10 months ago

Also, if no preference exists yet (default) all vocabularies should be selected in the selection dialog as this is similar to default.

#56 Updated by Andreas Müller 10 months ago

Also for common names there is "Allow override" in the dialog and on the page. Preferred is on the page, but definetely only 1 should exist (or they need to be synchronized but currently they aren't)

#57 Updated by Andreas Müller 10 months ago

The "Restore Default" generally does not seem to work for DB Prefs. We should either disable/remove it or make it working.

#58 Updated by Katja Luther 10 months ago

Andreas Müller wrote:

Common name areas: when opening the dialog it is always empty but should show the vocabularies selected before

this should be fixed

#59 Updated by Andreas Müller 10 months ago

The predicate "model.editor.NDV" always gets persisted once DB prefs are opened and saved even if NDV page was not opened or touched at all. Additionally "allow override" is set to "false" here. Default should always be "true".
This is critical as it prevents users to define there own reduced name details view.

#60 Updated by Andreas Müller 10 months ago

Nomenclatural Code: Changing allow override does not set "Apply" to enabled.

#61 Updated by Andreas Müller 10 months ago

Name Details View: by default when switching to "simplified" only NameCache, AuthorCache and Approbation is selected. By default I would expect all to be selected.

#62 Updated by Andreas Müller 10 months ago

Name Details View: "Secundum Ref Details and Secundum activated should have identation to make clear that they belong to "Taxon". Also they should have a different order, first Secundum activated then Secundum Ref Details.

#63 Updated by Andreas Müller 10 months ago

Critical: Name Details View: changes in DB prefs have no effect. Unselected controls are still shown in the view.

#64 Updated by Andreas Müller 10 months ago

I did not check the ABCD stuf as I am not so familar. Can you please check yourself?

Only minor issues:

  • Nomenclatural Code is missing a label there.
  • The "New Provider" field is missing a label, e.g. "New provider".
  • Adding a provider leads to an empty line in the first text field if it was the first provider.
  • The new provider should be in the first line in this case.
  • No URL check is done, you can also enter "aaa".
  • The list field is to small (height) if > 1 providers are entered
  • "Add provider" button should be disabled if "New provider" text field is empty
  • "Remove provider" should be disabled if no provider is selected in provider list

#65 Updated by Katja Luther 10 months ago

Andreas Müller wrote:

After trying to set values to default values I could not open the preference page anymore:

login : admin
editor version : 5.5.0.201902072350
server : test.e-taxonomy.eu (edit-test) / test1
schema version : 5.0.0.0.20180514
os : Windows Server 2012 R2 6.3 amd64
java : 1.8.0_121
java.lang.IllegalArgumentException: No enum constant eu.etaxonomy.cdm.model.metadata.TermDisplayEnum.Label
  at java.lang.Enum.valueOf(Enum.java:238)
  at eu.etaxonomy.cdm.model.metadata.TermDisplayEnum.valueOf(TermDisplayEnum.java:1)
  at eu.etaxonomy.taxeditor.preference.ChecklistEditorGeneralPreference.createContents(ChecklistEditorGeneralPreference.java:362)
  at eu.etaxonomy.taxeditor.databaseAdmin.preferencePage.ChecklistEditorGeneralAdminPreference.createContents(ChecklistEditorGeneralAdminPreference.java:32)
  at org.eclipse.jface.preference.PreferencePage.createControl(PreferencePage.java:241)
  at eu.etaxonomy.taxeditor.preference.menu.CdmPreferencePage.createControl(CdmPreferencePage.java:57)
  at org.eclipse.jface.preference.PreferenceDialog.createPageControl(PreferenceDialog.java:1430)
  at org.eclipse.jface.preference.PreferenceDialog$9.run(PreferenceDialog.java:1197)
  at org.eclipse.core.runtime.SafeRunner.run(SafeRunner.java:42)
...

this is fixed.

#66 Updated by Katja Luther 10 months ago

Andreas Müller wrote:

Critical: Name Details View: changes in DB prefs have no effect. Unselected controls are still shown in the view.

this should be fixed with last commit

#67 Updated by Katja Luther 10 months ago

Andreas Müller wrote:

The predicate "model.editor.NDV" always gets persisted once DB prefs are opened and saved even if NDV page was not opened or touched at all. Additionally "allow override" is set to "false" here. Default should always be "true".
This is critical as it prevents users to define there own reduced name details view.

this is fixed

#68 Updated by Katja Luther 10 months ago

Andreas Müller wrote:

Also, if no preference exists yet (default) all vocabularies should be selected in the selection dialog as this is similar to default.

for the presenceAbsence term selection this is critical at the moment because we can't store all term uuids in the db.

#69 Updated by Katja Luther 10 months ago

Katja Luther wrote:

Andreas Müller wrote:

Also, if no preference exists yet (default) all vocabularies should be selected in the selection dialog as this is similar to default.

for the presenceAbsence term selection this is critical at the moment because we can't store all term uuids in the db.

now for vocabularies it is implemented that all vocs are checked if no preference exist but for terms it is still all unchecked.

#70 Updated by Andreas Müller 10 months ago

Katja Luther wrote:

Andreas Müller wrote:

Also, if no preference exists yet (default) all vocabularies should be selected in the selection dialog as this is similar to default.

for the presenceAbsence term selection this is critical at the moment because we can't store all term uuids in the db.

Hmm, generally this is not related to default values but to long lists, but will be solved with next model change (one reason why I wanted the model changes within this milestone).
And my idea was not to always store the complete list but to say that default is that all terms are shown and therefore opening the dialog the first time it should show the default state which is all terms selected. However, it is difficult then to distinguish that someone selects all values explicitly from simply default mode.
As selecting NO term does not make much sense using "No terms selected" = default = "All terms are available" is maybe easier to handle. If we decide to do it this way we at least should leave an explicit note in the dialog saying that No selection means any existing term is available. Though this is not really intuitive.
Alternatively we could add a checkbox labeled "All" and if the checkbox is checked. The termlist is disabled and all terms/vocabularies are checked. If "All" is unchecked the terms are shown as currently with first state all terms being selected. During save "All" checked is taken as default value => null is stored (with allow override = true it is even deleted), otherwise handling like always.
I prefer the second solution.

#71 Updated by Katja Luther 10 months ago

Andreas Müller wrote:

Katja Luther wrote:

Andreas Müller wrote:

Also, if no preference exists yet (default) all vocabularies should be selected in the selection dialog as this is similar to default.

for the presenceAbsence term selection this is critical at the moment because we can't store all term uuids in the db.

Hmm, generally this is not related to default values but to long lists, but will be solved with next model change (one reason why I wanted the model changes within this milestone).
And my idea was not to always store the complete list but to say that default is that all terms are shown and therefore opening the dialog the first time it should show the default state which is all terms selected. However, it is difficult then to distinguish that someone selects all values explicitly from simply default mode.
As selecting NO term does not make much sense using "No terms selected" = default = "All terms are available" is maybe easier to handle. If we decide to do it this way we at least should leave an explicit note in the dialog saying that No selection means any existing term is available. Though this is not really intuitive.
Alternatively we could add a checkbox labeled "All" and if the checkbox is checked. The termlist is disabled and all terms/vocabularies are checked. If "All" is unchecked the terms are shown as currently with first state all terms being selected. During save "All" checked is taken as default value => null is stored (with allow override = true it is even deleted), otherwise handling like always.
I prefer the second solution.

Actually it is only the status selection wizard and for this I would prefer to have a message that if nothing is selected all terms are available. For the next release I already implemented that for a not existing preference all terms are checked.

#72 Updated by Katja Luther 10 months ago

Andreas Müller wrote:

Name Details View: "Secundum Ref Details and Secundum activated should have identation to make clear that they belong to "Taxon". Also they should have a different order, first Secundum activated then Secundum Ref Details.

is implemented

#73 Updated by Katja Luther 10 months ago

Andreas Müller wrote:

I did not check the ABCD stuf as I am not so familar. Can you please check yourself?

Only minor issues:

  • Nomenclatural Code is missing a label there.
  • The "New Provider" field is missing a label, e.g. "New provider".
  • Adding a provider leads to an empty line in the first text field if it was the first provider.
  • The new provider should be in the first line in this case.
  • No URL check is done, you can also enter "aaa".
  • The list field is to small (height) if > 1 providers are entered
  • "Add provider" button should be disabled if "New provider" text field is empty
  • "Remove provider" should be disabled if no provider is selected in provider list

move this to an extra ticket #8089

#74 Updated by Katja Luther 10 months ago

#75 Updated by Katja Luther 10 months ago

now the setting of defaults is implemented for db and for local preferences.

For setting the term/vocabulary selections to default the button of the preference page has to be used. Maybe we should move this to the selection wizard in next release -> new ticket ( #8092)

#76 Updated by Andreas Müller 10 months ago

Andreas Müller wrote:

Also it is not possible to delete this preference by setting it to default. If no vocabulary is selected an empty string is persisted. Default is null this might be the reason why it is not recognized as default.

Generally we need to discuss how to set the vocabulary/term-list selections to default. Is it by a certain selection, or with a button (in dialog or on preference page)?

Also we need to discuss if an empty list should be allowed at all or if we disable "Finish" if no entry has been selected

This is not yet correctly implemented. The list of common name vocabularies is deleted as preference when no vocabulary is selected. But when reopening all vocabularies are selected as this is considered to be the default value. I added this to the follow up ticket #8045

#77 Updated by Andreas Müller 10 months ago

With empty preferences when only the DistrEditor page is opened without any change afterwards the preferences for displayStatus and area are stored with value "Label". Default value handling seem not yet correct here.

#78 Updated by Andreas Müller 10 months ago

ON DB prefs page Name Details View the taxon sec attributes are disabled if NDV is disabled but they are not grey. Only when uncheck NDV display on the page they are also grey as all others => #8385

#79 Updated by Andreas Müller 10 months ago

On local prefs Name Details View page the "Restore Defaults" button seems to be enabled even if NDV does not allow override on server side. This is unexpected. I did not check if it also has any effect to press the button in this case.

#80 Updated by Andreas Müller 10 months ago

Restore defaults on local prefs restored the defaults stored in the predicates. One could also expect the current DB prefs (which allow override) to be set as default. However, this problem will probably be solved automatically in #8045 with new implementation so it is not so important.

#81 Updated by Andreas Müller 10 months ago

Nomenclatural Code in DB prefs can not be deleted by setting to defaults. Something wrong with the deleting if value is default. => see #8045#note-10

#82 Updated by Andreas Müller 10 months ago

  • Target version changed from Release 5.5 to Release 5.6

#83 Updated by Andreas Müller 10 months ago

  • Target version changed from Release 5.6 to Release 5.5

#84 Updated by Andreas Müller 5 months ago

  • Related to bug #8385: Open issues in DB preferences added

#85 Updated by Andreas Müller 5 months ago

  • Description updated (diff)

#86 Updated by Andreas Müller 5 months ago

  • Copied to feature request #8092: set default for term and vocabulary selection preferences in selection wizard added

#87 Updated by Andreas Müller 5 months ago

Andreas Müller wrote:

With empty preferences when only the DistrEditor page is opened without any change afterwards the preferences for displayStatus and area are stored with value "Label". Default value handling seem not yet correct here.

seems to be fixed

#88 Updated by Andreas Müller 5 months ago

Andreas Müller wrote:

On local prefs Name Details View page the "Restore Defaults" button seems to be enabled even if NDV does not allow override on server side. This is unexpected. I did not check if it also has any effect to press the button in this case.

seems to be fixed

#89 Updated by Andreas Müller 5 months ago

#90 Updated by Andreas Müller 5 months ago

#91 Updated by Andreas Müller 5 months ago

  • % Done changed from 60 to 90

To me this ticket seems to be fixed and open issues are moved to new tickets. In general the structure for handling default values and override are implemented - not always like in the ticket description but according to what we have discussed in the meanwhile. So we can close this very large ticket I think. Can you please double check if something is still open and not in another ticket?

Also available in: Atom PDF

Add picture from clipboard (Maximum size: 40 MB)