forked from solidusio/solidus
-
Notifications
You must be signed in to change notification settings - Fork 3
[pull] main from solidusio:main #413
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Merged
Merged
Conversation
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Since we now have a dedicated UI component for Alerts, we should be able to distinguish which flash type goes where (toast or alert). This helper adds two methods: #toasts will collect any flash key other than `:alert`, ideally we use "notice" and "error" but it's not forced; #alerts will return everything in `flash[:alert]`; `:alert` flash key should be used to construct flashes that are displayed by Alert component.
`flash[:notice]` is what is commonly used in other controllers to display a regular success/notice toast, so to be consistent let's use it everywhere. `:success` would also work, but to avoid confusion with Alerts of "success" type (see "ui/alert" component) it's better to use correct naming everywhere.
This should allow to target them with turbo stream responses when needed
Passing strings as messages to `flash[]` is more common than using other primitives, and users deciding to set flash[:alert] might not be aware of the Hash structure that is required to correctly construct and display a UI alert from flash[:alert]. So instead of letting it fail because of the type mismatch (when calling #slice on a string instead of a hash), we can add a fallback option to treat given string as a body of the alert message and construct a `danger` type alert with default title.
We should not delete adjustment reasons if there are adjustments created with them.
This migration will fail if there are any adjustments with invalid adjustment reason IDs. The suggested path of action for store owners is to change those adjustment reason IDs to NULL, because we don't want to accidentally lose adjustments.
[Admin] Flashes helper and reorganization
Restrict deletion of adjustment reasons if adjustments present
fix admin component generator namespace
Sign up for free
to subscribe to this conversation on GitHub.
Already have an account?
Sign in.
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
See Commits and Changes for more details.
Created by
pull[bot] (v2.0.0-alpha.3)
Can you help keep this open source service alive? 💖 Please sponsor : )