WorkflowStatus.h header
#include <ew/core/workflow/WorkflowStatus.h>
Namespace ew::core::workflow
WorkflowStatus struct
struct ew::core::workflow::WorkflowStatus
One state a piece of work can be in on its way to being finished – "Drafted", "Approved", "Needs rewrite".
The project declares its own, and there is exactly one vocabulary. A team's states are its own: a studio with a legal pass and a publisher sign-off has states nobody else has, and a novelist has three. A fixed enum would be wrong for everybody, and a second vocabulary per content type would make "what is still unapproved" one question per type – which is how a lead ends up maintaining the answer in a spreadsheet.
Members
QString ew::core::workflow::WorkflowStatus::name
What the team calls this state, in their own words. Compared case-insensitively; stored as the person who declared it typed it.
QString ew::core::workflow::WorkflowStatus::colour
The colour the graph paints work in this state, as "#rrggbb"; empty leaves it uncoloured.
On the status rather than chosen by the view, because a lead scanning a scene is reading a convention their team already has – red for rewrite, green for approved – and a colour the view assigned by position would change the moment somebody inserted a state.
bool ew::core::workflow::WorkflowStatus::approved = false
Whether reaching this state means the work is signed off.
A flag rather than "the last one in the list is approved": most pipelines have more than one finished state (approved, and locked against further edits) and at least one state after them that is emphatically not finished – the rewrite a reviewer sent back. Ordering cannot express that, and "everything of mine that is not yet approved" is the question this exists to answer.
bool operator==(const WorkflowStatus &, const WorkflowStatus &)=default
Statuses compare equal when every field matches.
WorkflowStatuses struct
struct ew::core::workflow::WorkflowStatuses
The project's vocabulary of review states, in pipeline order.
Ordered because a lead reads it as a pipeline – drafted, reviewed, approved – and a count per state means nothing shuffled. Empty until a project declares one, which turns the checking off rather than making every line's status unrecognised.
Members
std::vector<WorkflowStatus> ew::core::workflow::WorkflowStatuses::statuses
The states, in the order work moves through them.
bool operator==(const WorkflowStatuses &, const WorkflowStatuses &)=default
Vocabularies compare equal when every status matches, in order.
Functions
const WorkflowStatus * ew::core::workflow::findWorkflowStatus(const WorkflowStatuses &vocabulary, const QString &name)
The status in vocabulary called name, or null when it declares none.
Null is the interesting case: it means a piece of work carries a state the project has since renamed or removed, which is reported rather than silently counted as unset.
bool ew::core::workflow::isApprovedStatus(const WorkflowStatuses &vocabulary, const QString &name)
Whether name is a state vocabulary considers signed off.
False for an empty name and for one the vocabulary does not know: neither is evidence that anybody approved anything, and defaulting the other way would report unreviewed work as done.
bool ew::core::workflow::sameWorkflowStatus(const QString &left, const QString &right)
Whether left and right name the same status.
Case-insensitive, and the ONE place that decides: "approved" typed into a filter and "Approved" declared in the vocabulary are the same state, and two comparisons disagreeing about that would show a lead a count that did not match the graph beside it.
WorkflowStatuses ew::core::workflow::standardWorkflowStatuses()
The vocabulary offered to a project that has not declared one: drafted, reviewed, approved, locked, needs rewrite.
A seed a project ADOPTS by an explicit action, never a default it silently starts with. A project that has never used review state must keep validating and saving exactly as it did, and a vocabulary that appeared on its own would put five states nobody chose in front of a novelist who has no reviewers.
Deliberately untranslated: these are stored in the project file as data, and a name that changed with the UI language would make a project written in Spanish unreadable to the English build.