Repository navigation
Add form components for preference fields - #6713
benjaminwil wants to merge 1 commit into
Conversation
github-actions
Bot
added
changelog:solidus_core
Codecov Report❌ Patch coverage is
Additional details and impacted files@@ Coverage Diff @@
## main #6713 +/- ##
==========================================
+ Coverage 92.47% 92.49% +0.01%
==========================================
Files 1065 1073 +8
Lines 21541 21592 +51
==========================================
+ Hits 19921 19971 +50
- Misses 1620 1621 +1 ☔ View full report in Codecov by Harness. 🚀 New features to boost your workflow:
|
| end | ||
|
|
||
| def label | ||
| @type.constantize.human_attribute_name("preferred_#{@preference_name}") |
There was a problem hiding this comment.
This is a change from backend's t(name, scope: "spree", default: name.humanize). While probably more correct, also kind of a regression because we're missing so many of the translations for doing it your way. Something for your to-do list?
There was a problem hiding this comment.
Added to my to-do list. 👍
b015cd1 to
cb672fd
Compare
jarednorman
left a comment
jarednorman
left a comment
There was a problem hiding this comment.
I don't think the error stuff is right yet.
| # Forwards the error so that input component templates have access to | ||
| # error context. | ||
| @args[:error] = @error if @error.blank? |
There was a problem hiding this comment.
We want to pass the error to the input when there is no error? Wat.
There was a problem hiding this comment.
Meant nil. Thanks!
Preference-enabled models (like `Spree::PaymentMethod` subclasses and `Spree::Calculator` subclasses) allow admin users to configure preferences on records from the admin interface. To support this in the new admin, we can add preference field components for each form-enabled preference type that has been historically supported in `solidus_core` and `solidus_backend`. The component previews are rendering in tests and via Lookbook right now. In a subsequent commit I will wire up these components to work dynamically with payment method admin forms.
cb672fd to
4b2ad0b
Compare
|
#6706 has been approved by one core team member. It includes this commit. So I will just wait on additional approvals there and not muck around with this extracted commit anymore. |
Summary
I have extracted this commit from #6706 to propose it be merged independently. The existence of these preference field components is required to do further admin work on payment method, calculator, and promotions UIs.
From the commit message:
Preference-enabled models (like
Spree::PaymentMethodsubclasses andSpree::Calculatorsubclasses) allow admin users to configure preferences on records from the admin interface. To support this in the new admin, we can add preference field components for each form-enabled preference type that has been historically supported insolidus_coreandsolidus_backend.The component previews are rendering in tests and via Lookbook right now. In a subsequent commit I will wire up these components to work dynamically with payment method admin forms.
Checklist
Check out our PR guidelines for more details.
The following are mandatory for all PRs:
The following are not always needed: