Sidecar documents should be able to inherit parent's collections

[eaolson]

Sidecar documents created when splitting documents default to having no collections. I'd like to be able to have those sidecar documents inherit their parent's collections. Collections can be specified with the --splitter-sidecar-collections option, but those can vary per document, so that rules out batch processing. This could also probably be done afterward in a reprocess action, but now it's a two-step process.

I was thinking something like a --splitter-sidecar-inherit-permissions option that caused Flux to add the parent's collections as well.

[rjrudin]

I like the idea of an "inherit" option here. The decision to not inherit collections was due to our experience with chunks typically having a different set of collections - specifically, a collection that is the context for a TDE. And so it was considered common practice to explicitly define the collections.

A boolean --splitter-sidecar-inherit-collections would address the use case you mention, which isn't uncommon - i.e. the documents being copied may have different collections, and some of those collections should be inherited by chunks - but it's not possible to define an explicit set of collections for all chunks.

Related to #634 - I am wondering if --splitter-sidecar-inherit-permissions would be useful as well. Because once we start using the source document as a source of metadata (as opposed to using --collections and --permissions as the default source of metadata), it should be trivial to support any metadata.

[eaolson]

I agree, I like the idea of --splitter-sidecar-inherit-permissions as well. In cases where the output database does not have the same set of roles as the input database, I'm not sure if an error should be raised or if that role should just silently not be included.

[rjrudin]

When the target role doesn't exist in the output database - I don't think that's a problem that a tool would want to interject itself into. In that situation, I would typically create the missing roles in the output database to prevent the error. My thought being that those permissions are meaningful and thus the only acceptable solution is to create the necessary roles so that the permissions can be copied. In the event that the permissions aren't meaningful, I normally would just omit all of them and use an admin user to copy the documents and figure what to do about permissions later.