Skip to content

Feat/gh1458 possible to drag and drop usages to re-parent them and bumped devexpress to 23.2.15#1459

Open
rdevoogtatstariongroup wants to merge 2 commits into
developmentfrom
feat/gh1458-PossibleToDragAndDropUsages
Open

Feat/gh1458 possible to drag and drop usages to re-parent them and bumped devexpress to 23.2.15#1459
rdevoogtatstariongroup wants to merge 2 commits into
developmentfrom
feat/gh1458-PossibleToDragAndDropUsages

Conversation

@rdevoogtatstariongroup

Copy link
Copy Markdown
Contributor

Prerequisites

  • I have written a descriptive pull-request title
  • I have verified that there are no overlapping pull-requests open
  • I have verified that I am following the COMET-IME code style guidelines
  • I have provided test coverage for my change (where applicable)

Description

Move an Element Usage to another Element Definition (drag & drop) — closes #1458

Adds drag-and-drop reparenting of an ElementUsage. Drag a usage onto an
ElementDefinition (in the Element Definitions browser or the Product Tree; in the
Product Tree also onto another usage) and it is moved into that definition —
keeping its Iid, name, short-name, owner, excluded options and all
ParameterOverrides (values included). Previously the only workaround was to
re-create the usage manually, losing all of that.

How

  • New IThingCreator.MoveElementUsage(usage, targetDefinition, session) re-parents the
    usage in a single ThingTransaction (same pattern as
    RequirementRowViewModel.ChangeRequirementContainer).
  • New shared CDP4Composition/DragDrop/ElementUsageDropValidator centralizes the drop
    guards so both browsers stay consistent and cannot create invalid models:
    write permission, same-model only, and ElementDefinition.HasUsageOf(...) to block
    self-drop and transitive containment loops.
  • Wired into ElementDefinitionRowViewModel (EngineeringModel + ProductTree) and the
    ProductTree ElementUsageRowViewModel; a tooltip documents the gesture.

Not included

Duplicating a usage is intentionally left out: the data-source only supports a
server-side copy of an ElementDefinition ("Only Element-Definition may be copied"),
and a client-side deep-create could not reliably restore override values. Tracked
separately (see linked web/SDK tickets); move already preserves everything.

Note for reviewers

This branch also bumps DevExpress 23.2.5 → 23.2.15 across all .csproj to fix the
local NU1605 restore conflict. CI/AppVeyor must serve 23.2.15. Happy to split this
into its own commit/PR if preferred.

Align all project references to DevExpress 23.2.15 to resolve the NU1605
package-downgrade conflict: transitive DevExpress.CodeParser/DataAccess resolve
to 23.2.15 and demand DevExpress.Data/Xpo = 23.2.15, which conflicted with the
23.2.5 direct pins. Restore and build now succeed.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

[Feat] As a User I want to move an element usage from one element definition into another while holding all its values and overrides

1 participant