Current Assumed Behavior: When project teams configure a workflow for sequential subjects (see this StackOverflow entry), they include the #priority keyword in subject metadata as part of subject upload/creation & linking to subject set.
Current Failure Mode: If a team forgets to include the #priority metadata, they could add the key-value pair to existing subjects via the Python Client, but the priority values don't automatically propagate to the Designator-facing priority column in the SetMemberSubjects table. Propagation from Subjects to the SetMemberSubjects table is executed via the SubjectMetadataWorker, which is triggered when the Subject is linked to a SubjectSet.
Current workarounds: a) link subjects to new subject set and delete old subject set (or unlink+relink subjects to existing subject set); b) Zoo dev manually runs SubjectMetadataWorker via Rails console.
Proposed Enhancement Ideas:
- Detect subject metadata update (via Subjects controller) and run a SubjectMetadataWorker for each update (or when
#priority specifically is updated). Downside: this might trigger heavy API load to accomplish a relatively rare use case.
- Create admin-accessible button that would run the SubjectMetadataWorker over all subjects linked to the relevant workflow -- i.e., as part of activating
prioritized setting on that workflow, also create accessible button to sync current state. Upside: no need for Rails console intervention, making task accessible to any Zoo team member via admin page.
Thoughts? @yuenmichelle1 -- as dev who implemented sequential subject selection in Designator, any comments or backstory on why Designator-facing priority values are stored in the SetMemberSubject table (as opposed to being pulled fresh from the subject metadata)?
Priority: not high, given rare need for sequential selection configuration and acceptable workarounds (that are now documented in StackOverflow).
Current Assumed Behavior: When project teams configure a workflow for sequential subjects (see this StackOverflow entry), they include the
#prioritykeyword in subject metadata as part of subject upload/creation & linking to subject set.Current Failure Mode: If a team forgets to include the
#prioritymetadata, they could add the key-value pair to existing subjects via the Python Client, but the priority values don't automatically propagate to the Designator-facing priority column in the SetMemberSubjects table. Propagation from Subjects to the SetMemberSubjects table is executed via the SubjectMetadataWorker, which is triggered when the Subject is linked to a SubjectSet.Current workarounds: a) link subjects to new subject set and delete old subject set (or unlink+relink subjects to existing subject set); b) Zoo dev manually runs SubjectMetadataWorker via Rails console.
Proposed Enhancement Ideas:
#priorityspecifically is updated). Downside: this might trigger heavy API load to accomplish a relatively rare use case.prioritizedsetting on that workflow, also create accessible button to sync current state. Upside: no need for Rails console intervention, making task accessible to any Zoo team member via admin page.Thoughts? @yuenmichelle1 -- as dev who implemented sequential subject selection in Designator, any comments or backstory on why Designator-facing priority values are stored in the SetMemberSubject table (as opposed to being pulled fresh from the subject metadata)?
Priority: not high, given rare need for sequential selection configuration and acceptable workarounds (that are now documented in StackOverflow).