Move re-stamps createdBy/createdDate/lastModifiedBy on the moved node and its whole subtree — a relocation is recorded as a creation, destroying authorship #3263

Activity

1. rbuergi commented on Sep 3, 2026

   

   rbuergi

   on Sep 3, 2026

   ContributorAuthor

   More actions

   Cross-reference: #3264 — no version history is retained on this portal, so the stamps this bug overwrites cannot be recovered afterwards. Independent root causes; together they turn a Move into permanent loss of authorship.
2. rbuergi commented on Sep 4, 2026

   

   rbuergi

   on Sep 4, 2026

   ContributorAuthor

   More actions

   Fixed on main by #3273 (merged 2026-09-04). Closing by hand — core's merge queue does not fire Closes links; six issues behaved that way today.

   🚨 Verified by reading the merged source, and existence-checked first — earlier today I closed three issues on a git show <ref>:<path> | grep … || echo clean that printed "clean" because the path did not exist. So: git cat-file -e origin/main:src/MeshWeaver.Mesh.Contract/MeshExtensions.cs → exists, then read it.

   The mechanism was TWO halves, and the issue's "Expected" only named the symptom

   Half 1 — the copy leg re-stamped unconditionally. Move is copy-to-target + delete-the-source, and RetargetNode stamped LastModified = UtcNow on every copied node — so the moved node and every descendant got it.

   Half 2 — and this is the one nobody could have guessed from the issue. The copy leg re-created its nodes from meshService.Query<MeshNode>("path:{source} scope:subtree") — a projection, not the stored node. PostgreSqlSqlGenerator.GenerateSelectQuery selects id, namespace, name, node_type, description, category, icon, display_order, last_modified, version, state, content, desired_id, main_node, sync_behavior, exclude_from_context — and not created_by, created_date, last_modified_by. Those are real columns the point read and the INSERT both use, but no query projects them, and PgMeshNodeReader returns null for an absent column by design. So on Postgres every node arrived with blank stamps and HandleCreateNodeRequest filled them with "now, by the caller".

   That is why version: 47 survived while the four stamps did not — it confirms the row is the same row, and it also explains why this could never be reproduced on the in-memory provider, which returns the stored node verbatim. Filed separately as Systemorph/MeshWeaver.Plugins#1310.

   What landed

   RetargetNode now takes preserveAuthorship, and a move passes true:

   return preserveAuthorship
       ? relocated                       // Id / Namespace / MainNode change; the four stamps ride along
       : relocated with { CreatedDate = default, CreatedBy = null,
                          LastModified = default, LastModifiedBy = null };

   and the copy leg reads each node from IStorageAdapter rather than trusting the query projection — the query stays the RLS-filtered decision of which nodes, storage answers what they are. No values are written back after the fact.

   Copy deliberately does the opposite, and that distinction is the reason this is a flag rather than a blanket rule: AccessContextScope impersonates MeshNode.CreatedBy, so a copy that inherited the original creator would run owner-scoped work as someone who never touched the node.

   A privilege-escalation hole found and closed while gating this

   Measured, not theorised: with the flag ungated, an Editor (Read | Create | Update, no Delete) could copy an admin's node with authorship intact — minting a node in their own space that the platform then impersonates the admin for. RLS does not close it, because reading the source is exactly what an Editor may do. PreserveAuthorship now requires Delete on the source namespace — the same entitlement MoveNodePermissionAttribute requires of a mover — with UNDETERMINED refusing as unavailability rather than denial.

   Test

   test/MeshWeaver.Hosting.Test/MoveNodePreservesAuthorshipTest.cs, over the real MonolithMeshTestBase, asserting the moved node and a descendant. Without the fix it failed on the timestamps (lastModified …39.3262830Z → …39.4102920Z on the root, …39.3278600Z → …39.4127360Z on the descendant); with it, 2/2. The copy control arm fails on main without the change too.

   Honest limit recorded in the PR: the projection half is not falsifiable by a core test, because the in-memory provider returns the stored node verbatim. Its evidence is the Postgres SELECT list.

   #3264 (no version history retained) remains the reason this was unrecoverable rather than merely wrong — the reporting half of that is #3278; the store itself is still open.
3. rbuergi

   closed this as completedon Sep 4, 2026
4. rbuergi

   added a commit that references this issue on Sep 4, 2026

   Merge origin/main (#3273's authorship fix) into the satellite fix

   ...

   76f4941
5. rbuergi

   added a commit that references this issue on Oct 1, 2026

   fix(access): a move carries authorship by naming its stored source, g…

   ...

   885a57c