Scope all front-end requests where needed

[maxpatiiuk]

Fixes #2292

To test:

• Attachment counts are scoped to the current collection (can be checked by making sure the attachment count matches the number of displayed attachments in the attachment viewer) (they were not scoped before)
• Pick lists of type "Entire table" or "Single Field" have their pick list items scoped (they were not scoped before, @grantfitzsimmons do you see a problem with this change?)

[grantfitzsimmons]

Pick lists of type "Entire table" or "Single Field" have their pick list items scoped (they were not scoped before, @grantfitzsimmons do you see a problem with this change?)

I do see potential problems with that change, as items that were once visible will no longer be (and previously valid pick list values would be invalid as well).

I'm not sure if this has a large scope, however, as it is not common to use pick-list items based on an entire table or field, but it might be worth asking Andy or Theresa.

[carlosmbe]

Attachment Counts are still not scoped to current collection

Screen shots
Two different collections, same counts

[maxpatiiuk]

@melton-jason could you please pick up this PR?

Remaining things:

• Fix the issue discovered by Carlos
• Add a collection pref for making pick lists based on a table not scoped (like they were before this change) - the default should be scoped. Relevant place in code: https://github.com/specify/specify7/pull/3304/files#diff-d1cc9c7e699ae9b07df06cd17a5127059d55991ac2f6a3d0ebc92c557bee15d7

[melton-jason]

Fix the issue discovered by Carlos

The problem here is that fetchCollection would always set the domainFilter property of the query to undefined (and thus default to false). This is because Specify could not resolve the scoping relationship of Attachment as it doesn't have a field titled collection, collectionobject, discipline, division, or institution. When the scoping relationship can not be resolved, the fetchCollection would always 'remove' the domainfilter.
Instead of being defined in a relationship, the 'scope' of an Attachment is defined in two columns on the Attachment table: scopetype (which is a number which represents/maps to the correct scoping level) and scopeid (the id of the scopetype).

The backend already has handling for scoping Attachments when domainfilter=true is provided:

specify7/specifyweb/specify/filter_by_col.py

Lines 18 to 25 in 05ffff3

	if queryset.model is Attachment:
	return queryset.filter(
	Q(scopetype=None) |
	Q(scopetype=scoping.GLOBAL_SCOPE) |
	Q(scopetype=scoping.COLLECTION_SCOPE, scopeid=collection.id) |
	Q(scopetype=scoping.DISCIPLINE_SCOPE, scopeid=collection.discipline.id) |
	Q(scopetype=scoping.DIVISION_SCOPE, scopeid=collection.discipline.division.id) |
	Q(scopetype=scoping.INSTITUTION_SCOPE, scopeid=collection.discipline.division.institution.id))

While the changes in 05ffff3 are 'hacky', I think any generic solution on the frontend would be quite messy (if not impossible without hardcoding around the attachment case).

---

Add a collection pref for making pick lists based on a table not scoped (like they were before this change) - the default should be scoped.

The collection preference can be added to the Remote Properties App Resource with the pattern: sp7_scope_table_picklists_<COLLECTION_ID>. (similar to the other Collection Preferences defined in this App Resource: CO_CREATE_COA, CO_CREATE_PREP, CO_CREATE_DET).
The default value is true, which means Specify will try and scope the picklist items by default.

Judging by the previous code and that in production, the picklistitems would only be unscoped (domainfilter set to false) when the table that the picklist is based off of is one of:

• Collection
• Discipline
• Division
• Institution

See

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

Lines 115 to 117 in 52176a4

	domainFilter: !f.includes(
	Object.keys(schema.domainLevelIds),
	toLowerCase(tableName)

This behavior has been preserved.

[emenslin]

Looks good, attachments and picklists seem to be scoped properly

[pashiav]

Looks good! Could not reproduce the collection issue from earlier.