CategoryRemoval.h header
#include <ew/app/entity/CategoryRemoval.h>
Namespace ew::app::entity
Functions
std::unique_ptr< ew::core::undo::Command > ew::app::entity::buildRemoveCategoryCommand(ew::core::project::Project &project, ew::core::foundation::CategoryId categoryId)
Builds an undoable command that removes category categoryId from project and moves the entities filed under it up to its parent, as one step.
Taxonomy::remove reparents child CATEGORIES only, and it cannot do more: a taxonomy has no access to entities, which live on the project. Both callers nevertheless told the user their entities would be promoted – the desktop's confirmation says "Its entities move up to the
parent" and the MCP tool reported "its subcategories and entities moved up to its parent" – while every entity was left pointing at a category that no longer existed (F-0059).
An orphaned entity is not merely mis-filed. Taxonomy::effectiveFields walks from the category it can no longer find, so the entity's whole field SCHEMA disappears: it stops being listed under any category, reads as "(uncategorized)", and – because the relationship graph finds Reference fields through that same schema – its links vanish from the graph as well. Nothing is deleted, so undo restores it all, but until then the entity is effectively lost.
Reparenting is done here rather than in Taxonomy::remove because it needs the project, and once for both callers because the promise was made twice and kept neither time.
An ADDITIONAL membership naming the category moves the same way its primary would. Left alone it would point at a category this command deletes: the entity would silently stop being whatever that category made it, and carry a dead id in the project file. A category with no parent drops the membership instead of promoting it, since a null id is not a membership.
Returns null when categoryId does not identify a category in project.