Skip to content

feat: make previous fixes visible#162

Draft
Lars Kemper (larskemper) wants to merge 4 commits intotrunkfrom
feat/make-previous-fixes-visible
Draft

feat: make previous fixes visible#162
Lars Kemper (larskemper) wants to merge 4 commits intotrunkfrom
feat/make-previous-fixes-visible

Conversation

@larskemper
Copy link
Copy Markdown
Member

@larskemper
Copy link
Copy Markdown
Member Author

@shopware/product-cc-after-sales I need some opinion before moving forward with this.

Right now, with the current UI implementation, its quite tricky to handle and display new logs and already fixed logs together in the same interface, especially in the “fix modal”, since they require pretty different handling.

The approach I have implemented for now is to separate new and old log groups (marking new ones as “new”) and then merge them once they reach the same “fixed” state.

That said, I see three possible directions:

  1. Handle everything in a single list => highest effort, but probably the cleanest UX
  2. Keep one log group and one modal, but split the content into different lists (e.g. via tabs)
  3. Use two separate modals (what we currently have)
Screenshot 2026-03-30 at 08 17 36

@jozsefdamokos
Copy link
Copy Markdown
Member

IMO if the user saved already lets say 100 fixes and 10 new show up on a rerun, the checkmark should be gone from the listing on the rerun and it should say 100/110. Then when he clicks on the modal he can easily filter for the new ones, so maybe tabs make sense. So option 2

@MalteJanz
Copy link
Copy Markdown
Contributor

I would prefer option 1. It would be the proper UX someone would expect. Also imagine edge cases like this:

  1. I am in the fix modal, select some entries and apply a fix for all of them
  2. Suddenly I noticed that one of the entries needs a different fix
  3. Right now I think there is no way to modify a fix again, right (not sure)?

And if we allow proper editing of existing fixes, we don't need much additional UI, you can just display the same stuff on further migrations and its up to them to fix new issues or adjust existing ones. A way to filter / sort the listing for unfixed stuff would be great though

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.

Users should be able to edit / view previously fixed errors when they re-run the migration

3 participants