Closed thirdpolice closed 2 months ago
The current behavior (always has been) is that a variant is linked only to the latest job that generated it, forgetting what happened before
Why would you want some different behavior?
It’s not that important, the niche downside scenario is:1. Editor 1 makes some changes to steps in a group of combos, generates variants2. Editor 2 makes some prereq tweaks, generates variants, there’s some overlap in affected variants3. Editor 1 uses the link from their job to view all the variants they need to process. Some altered variants are not visible here.4. Editor 2 reviews their variants and only checks for the prereq tweaks they made, failing to vet the step changes that were introduced by editor 1.This is very unlikely to happen with our current staff but if we ever get to 5+ editors again it could be worth thinking about.On 3 Jul 2024, at 22.45, ldeluigi @.***> wrote: Why would you want some different behavior?
—Reply to this email directly, view it on GitHub, or unsubscribe.You are receiving this because you authored the thread.Message ID: @.***>
Why not using the variants link under the single combo page instead of the links under the job page? That way you won't have problems. In the meantime I'll add a "Included in" section under the combo page to help.
Jobs 18979 and 18981 were single-combo generations from the same combo. When the first one was run it generated 29 variants and linked to them. But when 18981 was run, those variants were overwritten and disappeared from the 18979 log.
Is this intentional? Losing the history could disrupt an editor's workflow if a later job removes info they were using, although it's not too likely to happen with our current workforce.