Skip to content

Core - Fix profile service, storage and device bugs found by the tests - #912

Merged
RobertBeekman merged 3 commits into
masterfrom
fix/profile-services
Oct 24, 2026
Merged

RobertBeekman merged 3 commits into
masterfrom
fix/profile-services

Conversation

@RobertBeekman

@RobertBeekman RobertBeekman commented Oct 20, 2026 •

Copy link
Copy Markdown
Member

Fixes the profile service, storage and device bugs found by the test suite (#907). Each fix flips the test that pinned the old behaviour.

Fixed

  • New profiles are stored at the current migration version. Creating a profile only saved its category, which didn't set the version. Until the profile was saved in the editor, every start of Artemis ran migration M0001 on it and logged an error. Duplicating it (export + import) failed. CreateProfileConfiguration now also saves the profile, which sets the version.
  • Headsets with 2 or 4 LEDs get their default layout. The code looked for Artemis 2 LED headset.xml, but the files are named ... LEDs headset.xml.
  • A category created "at the top" is listed first right away, so its profiles render on top instead of underneath the others.
  • CloneProfileConfiguration makes a real copy. The clone used the same stored data as the original. Saving a clone with SaveProfile now stores its profile through the original. The workshop submission wizard relies on this.
  • A profile configuration that isn't valid JSON no longer stops all migrations. It is logged and skipped like a broken profile.
  • A stored profile without a version is migrated from version 0, the same way imports already were. A profile in the current format without a version still can't be imported, because there's no way to tell it apart from an old one.
  • A stored setting that can't be read falls back to the default value passed to GetSetting, instead of default(T).
  • Importing a profile raises ProfileAdded.
  • Devices placed by the auto-arrange fallback get the z-index of their type.
  • ProfileCategoryRepository.IsUnique returns true when the name is free. Nothing calls it yet.
  • Migrations M0001 and M0004 leave a missing node type or storage out instead of writing null.
  • Migration M0003 also unwraps a list that is an item of another list.

Not changed

  • ActivationBehaviour on profile configurations is stored, but nothing in Core reads it. That needs a decision on what it should do, so it's left out.

Testing

  • Artemis.Core.Tests: 1385 passed
  • Artemis.UI.Shared.Tests: 176 passed

…by the auto-arrange fallback

- Headsets with 2 or 4 LEDs get their default layout, the files are named "... LEDs headset.xml"
- Devices placed by the auto-arrange fallback get the z-index of their type
- New profiles are stored at the current migration version, so they're no longer migrated on every start and can be duplicated right away
- A category created at the top is listed first right away, so its profiles render on top
- CloneProfileConfiguration makes a copy of the stored data, saving a clone stores its profile through the original
- Importing a profile raises ProfileAdded
- A profile configuration that isn't valid JSON is logged and skipped instead of stopping all migrations
- A stored profile without a version is migrated from version 0, like an imported one
- ProfileCategoryRepository.IsUnique returns true when the name is free
- M0001 and M0004 leave a missing node type or storage out instead of writing null
- M0003 also unwraps a list that is an item of another list
@RobertBeekman
RobertBeekman marked this pull request as ready for review October 24, 2026 14:19
@RobertBeekman
RobertBeekman merged commit 83cf6da into master Oct 24, 2026
2 checks passed
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.

1 participant