feat(preferences): Add “Collection Preferences” page with role-gated access #7464

Gitesh307 · 2025-10-01T01:24:46Z

This PR introduces a new feature Collection Preferences page that consolidates collection-level settings such as picklists, attachments, tree management, statistics, Specify Network integration, and catalog number inheritance. Updated localization handling to use explicit function calls, resolving scanner issues. No database changes; existing preferences migrate automatically at the collection level.

Checklist

Self-review the PR after opening it to make sure the changes look good and
self-explanatory (or properly documented)
Add relevant issue to release milestone

Testing instructions

Verify the new Collection Preferences menu is visible only to authorized roles, settings can be saved and persist per collection.
Modify values in each section, ensure they save and persist after reload, and verify that the Reset button restores defaults correctly.

Test each option and verify application behavior responds to the setting

General

Scope "Entire Table" Picklists
Make Attachments Public By Default

Tree Management

If enabled, this allows users to add children to synonymized parents and to synonymize a node with children.

Statistics

Show Preparation Totals
Auto-Refresh Rate (Hours)
The following two cannot really be tested at the moment...
GBIF Publishing Organization Key
GBIF Data Set Key

Catalog Number Inheritance

Enable Catalog number Inheritance From Primary Collection Object
Enable Catalog number Inheritance From Parent Collection Object

specifyweb/frontend/js_src/lib/components/Preferences/CollectionDefinitions.tsx

specifyweb/frontend/js_src/lib/localization/preferences.ts

specifyweb/frontend/js_src/lib/components/Preferences/Editor.tsx

specifyweb/frontend/js_src/lib/components/Preferences/index.tsx

specifyweb/frontend/js_src/lib/components/Preferences/Editor.tsx

specifyweb/frontend/js_src/lib/components/Preferences/index.tsx

specifyweb/frontend/js_src/lib/localization/tree.ts

emenslin

After opening up the branch I have some concerns about testing with this being the only check:

Verify the new Collection Preferences menu is visible only to authorized roles, settings can be saved and persist per collection.

The original issue seems to cover a lot of things, which I don't think is captured within the testing instructions. One of the first things I noticed when opening up the PR was that in the original issue it says that the collection preferences page should be accessible via the user tools menu, in this PR it is only accessible by going into app resources first, then opening the collection preferences, if this is expected that's fine, I just think it should be explained in this PR. I also noticed that when opening collection preferences each line includes a link to documentation, however, the link does not take you to relevent documentation, additionally there is no mention of these links in the testing instructions. I think the testing instructions should be expanded on before any further testing reviews to make sure that everything is covered and that any issues can be caught within this PR.

Actions

Triggered by e9b8f26 on branch refs/heads/issue-7440

Triggered by 579a30b on branch refs/heads/issue-7440

grantfitzsimmons · 2025-11-05T14:09:49Z

From my last review on the rebased PR for context:

General

Scope "Entire Table" Picklists

This setting seems to have no effect. I defined a pick list named "COTTypes" that is based on the CollectionObjectType table, which should return all options if it is not scoped.

It still shows 2 results when unchecked despite there being many in the database:

Make Attachments Public By Default

Works exactly as expected. IsPublic is checked when adding a new attachment when enabled, it is not checked when it is not.

Tree Management

If enabled, this allows users to add children to synonymized parents and to synonymize a node with children.

Note: Immediately after setting this, I received the errors described for Storage for Taxon both when adding a child to a synonym and when trying to merge synonyms. Only after logging out and back in was I able to do this without errors... @Gitesh307 do you have the same issue?

Taxon

Storage

Synonymizing nodes with children:

errorOnSynonymy.mov
('Synonymizing node "316cd2" which has children', {'tree': 'Taxon', 'localizationKey': 'nodeSynonimizeWithChildren', 'node': {'id': 5812, 'rankid': 375, 'fullName': '316cd2', 'children': [{'id': 7029, 'fullname': 'Different Child, 316cd2'}]}, 'parent': {'id': 5810, 'rankid': 375, 'fullName': '24e0f0', 'parentid': 1, 'children': [{'id': 7028, 'fullname': 'Test, 24e0f0'}]}})
Specify 7 Crash Report - 2025-10-31T16_28_43.133Z.txt

Adding a Child:

`ValueError** at /api/specify/storage/ 'Storage' instance needs to have a primary key value before this relationship can be used.

errorOnChild.mov

Specify 7 Crash Report - 2025-10-31T16_27_01.097Z.txt

Going to hold off testing the other trees until this is fixed.

Statistics

Show Preparation Totals

Regardless of the setting, I am not seeing preparation totals:

Catalog Number Inheritance

Enable Catalog number Inheritance From Primary Collection Object

Doesn't seem to be respected:

Enable Catalog number Inheritance From Parent Collection Object

Will test remainder once these are fixed.

grantfitzsimmons · 2025-11-05T14:12:23Z

CarolineDenis · 2025-11-12T15:18:46Z

specifyweb/backend/trees/extras.py

+        'sp7.allow_adding_child_to_synonymized_parent.ChronosStrat',
+        'sp7.allow_adding_child_to_synonymized_parent.ChronoStrat',
+    ),
+    'ChronosStrat': (


Why 2? See line 34

Older deployments saved the Chronostrat synonym preference under two different keys, ChronosStrat (the legacy table/view name) and ChronoStrat (the shortened label used in global properties). If we drop one of them, any collection that previously saved the preference under that spelling would lose the ability to add children to synonymized Chronostrat nodes. Keeping both entries ensures _synonym_pref_keys continues to read whatever was persisted historically.

CarolineDenis · 2025-11-12T15:51:59Z

specifyweb/frontend/js_src/lib/components/Preferences/index.tsx

+            const props = {
+              className: `
+                flex items-start gap-2 md:flex-row flex-col
+                ${canEdit ? '' : '!cursor-not-allowed'}


is this secure enough?

That just affects cursor/UX. The real permission check comes from canEdit flowing into the ReadOnlyContext, which disables the inputs and prevents writes. That matches how the existing user-preferences UI enforces permissions, and the server still validates everything, so the security level is the same as production.

grantfitzsimmons

Verify the new Collection Preferences menu is visible only to authorized roles, settings can be saved and persist per collection.

After looking at this some more, can you provide some more insight here? It seems like we need to expand or clarify the permission for CollectionPreferences as this is not explicitly added as an option.

What is the criteria for "authorized roles" in this case?

Modify values in each section, ensure they save and persist after reload, and verify that the Reset button restores defaults correctly.