RequiredValues.h header

bool ew::app::entity::isRequiredValueMissing(const ew::core::taxonomy::FieldDefinition &field, const ew::core::entity::Entity &entity)

Whether field is a required property that entity has not filled in.

The single rule, so the Inspector's mark on a card and the report's list can never disagree about what "outstanding" means. Everything below is this applied to a set of fields.

"No value" means absent or blank: a property whose value is a run of spaces has not been filled in, and treating it as filled would let the one thing this exists to catch through.

A Boolean property is never missing, whatever its stored value. A checkbox always shows an answer – unticked reads as "no", and it is a legitimate one – so a required Boolean would nag forever until the writer ticked and unticked it to no effect. Marking a yes/no required asks for nothing the form does not already say.

There is deliberately no special case for a FIXED property. A fixed value is supplied by the category and an entity cannot fill it in, so "fixed and required" would render a form that can never be completed – which is why ew::core::taxonomy::FieldDefinition::setRequired and ew::core::taxonomy::FieldDefinition::setFixed each clear the other. The exclusion is the model's invariant, not a rule restated here; restating it would be a second copy to keep in step, and an unreachable branch nothing can test.

std::vector< QString > ew::app::entity::missingRequiredKeys(const ew::core::project::Project &project, const ew::core::entity::Entity &entity)

The keys of the required properties entity has no value for, in the order the Inspector shows them. isRequiredValueMissing decides each one.

Reads entity's effective properties through ew::core::project::Project::effectiveFieldsFor, so inherited requirements count exactly as own ones do – which is the point of marking a property required on a category.

std::vector< MissingRequiredValue > ew::app::entity::missingRequiredValues(const ew::core::project::Project &project)

Every required property with no value, across every entity in project.

Ordered by the project's own entity order, then by each entity's property display order, so two runs over an unchanged project produce an identical list – a report that reshuffles between runs cannot be diffed.

This is what makes "required" mean something. Nothing refuses a save over it and nothing should: a half-filled world is the normal state of a project in progress, and a word processor that blocked you from closing a character sheet would be answering a question nobody asked. What the writer needs is to be able to FIND them, which is what this gives the health report and the Inspector.