Skip to content

fix(multiuser): make preexisting workflows visible after migration#9049

Merged
lstein merged 8 commits intomainfrom
lstein/fix/multiuser-model-migration
Apr 14, 2026
Merged

fix(multiuser): make preexisting workflows visible after migration#9049
lstein merged 8 commits intomainfrom
lstein/fix/multiuser-model-migration

Conversation

@lstein
Copy link
Copy Markdown
Collaborator

@lstein lstein commented Apr 14, 2026

Summary

  • PR Feature: Shared/private workflows and image boards in multiuser mode #9018 assigned preexisting workflows user_id='system' with is_public=FALSE, causing them to disappear from all users' libraries
  • Migration 30: Sets is_public=TRUE for all system-owned workflows so they appear under "Shared Workflows"
  • Router fix: Admins skip the user_id filter in workflow listing endpoints, giving them visibility into all workflows including system-owned ones
  • Frontend fix: The "Shared" toggle in the workflow list is now visible to admins on system-owned workflows (uses canEditOrDelete instead of isOwner)
  • Docs: Updated multiuser user guide to document private/shared workflows, private/shared/public image boards, and added a warning about preexisting workflows appearing in the shared section

Test plan

  • Verify migration 30 runs cleanly on a database that already ran migration 28 (system workflows become public)
  • Log in as a non-admin user and confirm "Your Workflows" shows only your own workflows (no system/shared leakage)
  • Log in as a non-admin user and confirm "Shared Workflows" shows system-owned public workflows
  • Log in as admin and confirm all workflows (including system-owned) appear in listings
  • As admin, verify the "Shared" toggle appears on system-owned workflows in the list
  • As admin, verify you can edit and delete system-owned workflows
  • As a regular user, verify you cannot edit or delete system-owned workflows (403)
  • Run pytest tests/app/routers/test_workflows_multiuser.py — 21 tests pass
  • Run pytest tests/test_sqlite_migrator.py — 23 tests pass

🤖 Generated with Claude Code

@lstein @claude
fix(multiuser): make preexisting workflows visible after migration
d2227be 
PR #9018 assigned preexisting workflows user_id='system' with
is_public=FALSE, causing them to disappear from all users' libraries.

- Add migration 30: sets is_public=TRUE for all system-owned workflows
  so they appear under "Shared Workflows"
- Skip user_id filtering for admins in workflow listing endpoints so
  they can see and manage all workflows including system-owned ones
- Show the Shared toggle to admins on system-owned workflows in the
  workflow list UI
- Update multiuser user guide to document private/shared workflows,
  private/shared/public image boards, and warn about preexisting
  workflows appearing in shared section
- Add regression tests for system workflow visibility, admin CRUD
  access, and regular user access denial

Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>
@github-actions github-actions bot added api python PRs that change python files services PRs that change app services frontend PRs that change frontend files python-tests PRs that change python tests docs PRs that change docs labels Apr 14, 2026
@lstein lstein added the v6.13.x label Apr 14, 2026
@lstein lstein moved this to 6.13.x Theme: MODELS in Invoke - Community Roadmap Apr 14, 2026
JPPhoto
JPPhoto approved these changes Apr 14, 2026
View reviewed changes
Copy link
Copy Markdown
Collaborator

@JPPhoto JPPhoto left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Looks good, works well. My only question is if the changes to the database should be made as a change to migration_28.py as this hasn't really been out in the wild and admins will still be able to fix visibility on workflows now even if migration 28 ran before.

@lstein
Copy link
Copy Markdown
Collaborator Author

lstein commented Apr 14, 2026

Looks good, works well. My only question is if the changes to the database should be made as a change to migration_28.py as this hasn't really been out in the wild and admins will still be able to fix visibility on workflows now even if migration 28 ran before.

It won't hurt to do that. I'll make the change now.

@JPPhoto
Copy link
Copy Markdown
Collaborator

JPPhoto commented Apr 14, 2026

Are you planning to remove migration_30.py and alter tests for migration 28 accordingly?

@lstein
Copy link
Copy Markdown
Collaborator Author

lstein commented Apr 14, 2026

Are you planning to remove migration_30.py and alter tests for migration 28 accordingly?

I've altered the tests for migration_28. I wasn't going to remove migration_30 because I don't know how many people will have deployed in the interval. Is it more than N=1 do you think?

@JPPhoto
Copy link
Copy Markdown
Collaborator

JPPhoto commented Apr 14, 2026 •
edited
Loading

I've altered the tests for migration_28. I wasn't going to remove migration_30 because I don't know how many people will have deployed in the interval. Is it more than N=1 do you think?

I think it's maybe N=4, probably all devs, and I don't think it's worth having another migration in place since the admin user will be able to see and modify all workflows per the rest of the PR.

@JPPhoto
Copy link
Copy Markdown
Collaborator

JPPhoto commented Apr 14, 2026 •
edited
Loading

@lstein docs/multiuser/user_guide.md:202 mentions workflow visibility. Double-check that with tests/app/routers/test_workflows_multiuser.py:323 and resolve the correct behavior you want.

The core issue now:

  • invokeai/app/services/shared/sqlite_migrator/migrations/migration_28.py:29 now sets is_public default to TRUE,
  • invokeai/app/services/workflow_records/workflow_records_sqlite.py:55 does not set is_public on insert,
  • so every newly created user workflow becomes shared by default.

@JPPhoto JPPhoto self-requested a review April 14, 2026 13:30
@lstein
Copy link
Copy Markdown
Collaborator Author

lstein commented Apr 14, 2026 •
edited
Loading

@lstein docs/multiuser/user_guide.md:202 mentions workflow visibility. Double-check that with tests/app/routers/test_workflows_multiuser.py:323 and resolve the correct behavior you want.

The core issue now:

  • invokeai/app/services/shared/sqlite_migrator/migrations/migration_28.py:29 now sets is_public default to TRUE,
  • invokeai/app/services/workflow_records/workflow_records_sqlite.py:55 does not set is_public on insert,
  • so every newly created user workflow becomes shared by default.

True. The fix is to keep the default is_public=FALSE and to just set it to true for legacy workflows existing in the database at the time of migration_28. Implementing and testing now, updating docs.

Just working through an issue that occurs when going from multiuser mode back to single-user.

@lstein
Copy link
Copy Markdown
Collaborator Author

lstein commented Apr 14, 2026 •
edited
Loading

Migration is now fixed to make existing workflows shared and owned by 'system'. New workflows created by users will be private by default. I also took the opportunity to suppress all the UI having to do with workflow sharing when running in single-user mode. The only thing that may be off in the UI is that workflows created and shared in multiuser mode still have the "shared" tag when viewed in single-user mode. To me this is a useful feature because it maintains some history about the workflow.

Docs and tests have been updated to be consistent with the desired behavior.

I think it is good to go, but please test both in single-user and multi-user mode:

  • When migrating from an earlier version of the database, legacy workflows become owned by system and is_public=TRUE

When running in multiuser mode:

  • New workflows created by admin or unprivileged users are private by default.
  • Private workflows are not visible to other unprivileged users.
  • All user's private workflows are visible to the admin, and can be edited or deleted.
  • Private workflows can be made shared by checking the "Shared" checkbox in the Save dialogue.
  • Private workflows can be made shared by toggling the "Shared" slider in the workflow browser tile.
  • Shared workflows can be edited by the owner or admin, read-only by other unprivileged users.

When running in single user mode:

  • All workflows appear under "Your workflows" and are read/write.
  • The "Shared Workflows" section isn't visible
  • None of the "shared" badges, sliders or checkboxes appear
  • New workflows created in single-user mode are owned by "system" and will be shared when shifting to multiuser mode.

JPPhoto
JPPhoto approved these changes Apr 14, 2026
View reviewed changes
Copy link
Copy Markdown
Collaborator

@JPPhoto JPPhoto left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Good in my basic testing, switching from multi-user to single and back, etc. Would love more community testing of this.

@lstein lstein enabled auto-merge (squash) April 14, 2026 16:09
@lstein lstein disabled auto-merge April 14, 2026 16:26
@lstein lstein merged commit e252a5b into main Apr 14, 2026
13 checks passed
@lstein lstein deleted the lstein/fix/multiuser-model-migration branch April 14, 2026 16:27
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Reviewers

@JPPhoto JPPhoto JPPhoto approved these changes

@blessedcoolant blessedcoolant Awaiting requested review from blessedcoolant blessedcoolant is a code owner

@dunkeroni dunkeroni Awaiting requested review from dunkeroni dunkeroni is a code owner

@Pfannkuchensack Pfannkuchensack Awaiting requested review from Pfannkuchensack Pfannkuchensack is a code owner

Assignees

@JPPhoto JPPhoto

Labels

api docs PRs that change docs frontend PRs that change frontend files python PRs that change python files python-tests PRs that change python tests services PRs that change app services v6.13.x

Projects

Invoke - Community Roadmap
Status: 6.13.x Theme: MODELS

Milestone

No milestone

Development

Successfully merging this pull request may close these issues.

2 participants

@lstein @JPPhoto