12578 - Support posting multiple tiles with file-list datatypes

[bferguso]

Types of changes

• Bugfix (non-breaking change which fixes an issue)
• New feature (non-breaking change which adds functionality)
• Breaking change (fix or feature that would cause existing functionality to not work as expected)

Description of Change

Initial cut of this is for discussion only. This brings knowledge of arches-querysets aliased_data into core, which shouldn't be done. Will tidy up or close when a strategy has been developed.

Issues Solved

Closes #12578

Checklist

• I targeted one of these branches:
  • dev/8.1.x (under development): features, bugfixes not covered below
  • dev/8.0.x (main support): regressions, crashing bugs, security issues, major bugs in new features
  • dev/7.6.x (extended support): major security issues, data loss issues
• I added a changelog in arches/releases
• I submitted a PR to arches-docs (if appropriate)
• Unit tests pass locally with my changes
• I added tests that prove my fix is effective or that my feature works
• My test fails on the target branch

Accessibility Checklist

Developer Guide

Topic	Changed	Retested
Color contrast
Form fields
Headings
Links
Keyboard
Responsive Design
HTML validation
Screen reader

Ticket Background

• Sponsored by:
• Found by: @
• Tested by: @
• Designed by: @

Further comments

[apeters]

@bferguso arches-querysets already overrides some of the built-in arches datatype methods. There's already one for files here
I think we should just copy that updated method there and that way keep arches clean.

[bferguso]

@apeters - I guess my concern with this is if we start just overriding larger amounts of arches core functionality in the ancillary apps then then we're setting ourselves more more brittleness as both of them mature. With a new frontend being developed in v9 some of the existing assumptions may no longer be valid (in this case that only one tile will be updated / added at a time) and the earlier we get in front of those the better off we'll be.

[apeters]

@apeters - I guess my concern with this is if we start just overriding larger amounts of arches core functionality in the ancillary apps then then we're setting ourselves more more brittleness as both of them mature. With a new frontend being developed in v9 some of the existing assumptions may no longer be valid (in this case that only one tile will be updated / added at a time) and the earlier we get in front of those the better off we'll be.

I get that, but I feel like that ship has already sailed. In fact I think it's probably the other way around. I think that the querysets/component lab/modular reports apps will eventually become the new standard and that we'll be selectively porting code/developing new patterns in these new apps such that they ultimately represent "core" Arches. However it happens these things will conceptually "merge" at some point.

I think that having references to TileTree attributes within core Arches when querysets is still very much in it's infancy and not required by core is potentially confusing. Conversely, these overridden methods in querysets are already pretty well established and simply adding to that doesn't "break" from that.

These, of course, are just my suggestions. Happy to hear from others out there on this.

[bferguso]

@apeters - This is a more generic approach for supporting multiple file-list tiles to be sent in a single POST. It defaults to the original nodeid-scoped naming convention, but falls back to the tileid / nodeid scoped if that fails.

[apeters]

what happens when new tiles are submitted and don't have a tileid?

[bferguso]

It's already caught above. I chose to use the existing implementation first so it would be a no-op when used by the existing the code base. Lines 1324-1330 implement the existing logic of nodeid-only namespacing.

[apeters]

So if submitting more than one new tile (w/o tileids) via querysets, then this will just revert back to the original logic which sill won't solve the issue of not being able to associate a tile with a file, correct?

[bferguso]

Although I haven't done any mods to querysets, the solution for this I think would be to pre-populate the tileid in querysets, and then the file-save logic would work in arches core. We have this working here, using querysets and pre-populating the the tileid even before it hits querysets. I think the approach in my mind is to have the apps (in this case querysets) prepare the data so it can be handled by the base datatype. This would eliminate having to override the whole save function and just focus on preparing the data so it can be consumed properly by the datatype.

Other option would be to pull the functionality to get the files from the request out into its own function so that could be overridden. I've checked that in as an option to consider:

https://github.com/archesproject/arches/pull/12579/changes#diff-8f09e23698f4ac99abe8e670f189a7682e39895b5caaa4908b42b0737ff18b22R1362-R1383

[apeters]

Yeah, I think breaking that out has no downside. We should be mindful of populating tileids on the client as the backend logic might rely on the absence of tileids to inform its diffing logic.

[apeters]

I"m not able to produce a PUT request that can exercise this code. Can you provide some instructions on how to repro this?

[apeters]

looks good to me