Allow disabling Scope Entire Table PickLists preference

[melton-jason]

Fixes #7589

See related #4989.

Previously when the "Scope Entire Table PickLists" Collection Preference was disabled, PickLists of type "Entire Table" would still only be unscoped if they tables were one of Institution, Division, Discipline, or Collection.

The preference is located within CollectionPreferences and is shown below (highlighted by the red box):

From the home page of Specify, it is accessible by the following:

Screen.Recording.2026-09-15.at.9.02.06.AM.mov

This PR makes it such that the preference can be disabled for all tables if desired.

If you need a refresher on what "scoping" something means in Specify:

What does it mean for something to be scoped in Specify?

Given that all of the data of a Specify instance is housed in the same database, most data in Specify is really only useful when filtered to a specific context.
For example, when looking at more than one CollectionObjects it usually only makes sense to see CollectionObjects within one Collection (usually the CollectionObjects the user is logged into).

When you build/run a Query in the QueryBuilder, it looks at the Collection it was run within (the Collection you are logged into) and only shows you records belong to that Collection.

That is, the QueryBuilder should never show you CollectionObjects in other Collections, Loans in other Disciplines, etc.

The following diagram (taken from Table Scoping Hierarchy) shows what the most common tables are "scoped" to within Specify.

Put another way, "scoped to" can be referred to as "belongs to".
Most trees (all except Storage at the moment) are "scoped to" or "belong to" a Discipline. This means that when discussing or reviewing any particular Discipline-scoped tree (Taxon, Geography, Lithostrat, Chronostrat), it can be relevant to include which discipline the tree belongs to (is scoped to) to differentiate it from other trees in the same Specify instance.
When you are logged into a Collection and go to the Tree Viewer or Query for one of the aforementioned trees, you will only see the trees that exist for the Collection's Discipline.

In the context of Entire Table PickLists, scoping the PickLists (enabling the preference) means the results shown/given to you will be relevant to the Collection you are currently logged into.
For example. Entire Table PickLists searching for PrepTypes will only show you PrepType records from your currently logged-in Collection when they are scoped.
Entire Table PickLists searching on Loans or Gift will show you Loans/Gifts from all Collections within the Discipline of your currently logged in Collection.
If Entire Table PickLists are unscoped, then Specify will give you results from all Collections, regardless of the table's scoping or where the records are.

If you want more information, feel free to review the Full Table Scoping and Table Scoping Hierarchy sections of the Specify Institutional Scopings document on the Speciforum!

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
• Add pr to documentation list
• Add automated tests

Testing instructions

• Find or create a PickList of type Entire Table where the table that can be scoped
  • You can use the default PrepType PickList assigned to the relationship Preparation -> prepType
  • Alternatively, when creating a PickList of type Entire Table, use a table with scoping lower than Institution in the Table Scoping Hierarchy diagram in this PR description (or see Table Scoping Hierarchy)
  • You can optionally create a new Table Formatter for the desired PickList's table and use that within the PickList to customize how the PickList items will look. Otherwise, Specify will the table's default formatter.
• Ensure that at least one record exists within the currently logged in Collection
• Ensure that there is at least one record of the PickList's table that exists outside of the scope of the current Collection
  • For example, if the table is at a Collection scope then ensure at least one record exists in another Collection
  • If the table is at Discipline scope, log into a Collection in a different Discipline than the currently logged in Collection (the same applies if the table is scoped to Division: log into a Division that is different than the currently logged in Collection).

With the preference enabled

Specify should only include records that belong to/are scoped to your currently logged in Collection. If the table belongs at higher level, like Discipline, Specify will show you records from all Collections within that higher level (e.g., Discipline) of your currently logged in Collection.
e.g., All Collections with the Discipline of your currently logged in Collection if the table is scoped to Discipline. All Disciplines and their Collections within the Division of your currently logged in Collection if the table is scoped to Division, etc.

• Log back into the Collection where you created the PickList
• On a DataEntry Form containing the PickList, ensure records created outside of the scope of the table do not appear and are not selectable

With the preference disabled

Specify should include all records in the database, even those in other Collections, Disciplines, etc.

• Log back into the Collection where you created the PickList
• On a DataEntry Form containing the PickList, ensure records created outside of the scope of the table do appear and are selectable

Summary by CodeRabbit

• Bug Fixes
  • Corrected pick list filtering so results are scoped appropriately based on table relationships and the configured scoping preference.
  • Improved handling of table names regardless of capitalization when loading field-based pick lists.

[coderabbitai]

No actionable comments were generated in the recent review. 🎉

ℹ️ Recent review info

⚙️ Run configuration

Configuration used: Organization UI

Review profile: CHILL

Plan: Advanced

Run ID: 7f855b5d-368f-49c9-aff2-525694085e78

📥 Commits

Reviewing files that changed from the base of the PR and between 2c3012d and 23a7a9b.

📒 Files selected for processing (1)

• specifyweb/frontend/js_src/lib/components/PickLists/fetch.ts

Included review availability: Your plan provides up to 2 included reviews per hour; 1 remains after this review.

---

📝 Walkthrough

Walkthrough

Changes

Pick-list scoping

Layer / File(s)	Summary
Resolve tables and apply scoping specifyweb/frontend/js_src/lib/components/PickLists/fetch.ts	fetchFromTable reuses the resolved table and scopes queries only when the preference is enabled and a scoping relationship exists. fetchFromField reuses the resolved table while preserving its existing domain-level and relationship checks.

Priority: ➖ Normal

Change: Bug fix · Severity of issue fixed: Medium

Merge Risk: ⚪ Minimal · up to 23a7a

The changed Entire Table PickList path correctly honors the disabled preference, and no merge-blocking defect was established.

🚥 Pre-merge checks | ✅ 5 | ❌ 1

❌ Failed checks (1 warning)

Check name	Status	Explanation	Resolution
Automatic Tests	⚠️ Warning	Automatic tests are necessary for this behavior change, but the PR changes only specifyweb/frontend/js_src/lib/components/PickLists/fetch.ts. The existing fetch.test.ts is unchanged from the base.…	Add Jest regression tests in specifyweb/frontend/js_src/lib/components/PickLists/__tests__/fetch.test.ts. Use a table with a scoping relationship that is not one of the domain-level tables, set sp7_scope_table_picklists to false, and as…

✅ Passed checks (5 passed)

Check name	Status	Explanation
Linked Issues check	✅ Passed	Issue #7589 requires sp7_scope_table_picklists to control scoping for Entire Table PickLists. In fetchFromTable, the code reads this preference and sets domainFilter to true only when the prefer…
Out of Scope Changes check	✅ Passed	The reviewed change is limited to pick-list fetching in specifyweb/frontend/js_src/lib/components/PickLists/fetch.ts. It changes scoping decisions for table and field pick-list queries. This directl…
Testing Instructions	✅ Passed	The reviewed diff changes fetchFromTable scoping for Entire Table PickLists and only refactors the equivalent table lookup in fetchFromField. The PR instructions identify an Entire Table PickList,…
Description Check	✅ Passed	Check skipped - CodeRabbit’s high-level summary is enabled.
Title check	✅ Passed	The title clearly describes the main change: allowing the Scope Entire Table PickLists preference to be disabled for all tables.

Full details: Automatic Tests

Explanation

Automatic tests are necessary for this behavior change, but the PR changes only specifyweb/frontend/js_src/lib/components/PickLists/fetch.ts. The existing fetch.test.ts is unchanged from the base. Its disabled-preference case uses Collection, which is one of the four domain levels and already produced domainFilter=false with the old code. The existing Locality case tests only the scoped/default path. Therefore, the PR has no regression test for disabling the preference on a lower-level scoped table, which is the stated bug.

Resolution

Add Jest regression tests in specifyweb/frontend/js_src/lib/components/PickLists/__tests__/fetch.test.ts. Use a table with a scoping relationship that is not one of the domain-level tables, set sp7_scope_table_picklists to false, and assert that the request uses domainfilter=false and returns records outside the current scope. Also retain or add the enabled-preference assertion for the same table. Restore the original collection preference after each test.

• Fix all pre-merge checks with AI

✨ Finishing Touches

🧪 Generate unit tests (beta)

• Create PR with unit tests
• Commit unit tests in branch issue-7589

---

Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out.

❤️ Share

• X
• Mastodon
• Reddit
• LinkedIn

_{Comment @coderabbitai help to get the list of available commands.}

[melton-jason]

@coderabbitai review

[coderabbitai]

⚠️ Action not completed

Already reviewed the last commit. Use @coderabbitai full review to rerun a review of the entire changeset.

Note: CodeRabbit is an incremental review system and does not re-review already reviewed commits. This command is applicable only when automatic reviews are paused.

[g1rly-c0d3r]

Testing instructions

With the preference enabled

• On a DataEntry Form containing the PickList, ensure records created outside of the scope of the table do not appear and are not selectable

With the preference disabled

• On a DataEntry Form containing the PickList, ensure records created outside of the scope of the table do appear and are selectable

---

Looks good! I tested with both PrepType and COGType, and they both behaved as expected.