-
-
Notifications
You must be signed in to change notification settings - Fork 1.3k
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
Admin stock locations form #6160
base: main
Are you sure you want to change the base?
Conversation
2acc0de
to
17d8f3d
Compare
Codecov ReportAll modified and coverable lines are covered by tests ✅
Additional details and impacted files@@ Coverage Diff @@
## main #6160 +/- ##
==========================================
+ Coverage 88.81% 88.91% +0.10%
==========================================
Files 835 839 +4
Lines 18153 18202 +49
==========================================
+ Hits 16122 16184 +62
+ Misses 2031 2018 -13 ☔ View full report in Codecov by Sentry. |
2ee470c
to
8c92d69
Compare
526a065
to
95992db
Compare
As a common resource controller make it inherit from ResourcesController.
Changes description: - introduced `@include_name_field` flag that controls whether to show "Name" field on the form; - renamed keyword `address` to `addressable` to better reflect that the nature of the passed object; - renamed keyword `name` to `fieldset_name` to avoid confusion with "Name" field, whereas `fieldset_name` is a name to be used for the form (e.g. "users[billing_address_attributes]"); Motivation: This change allows to reuse this component in location stock form component, where the only difference between forms is that "Name" field is not there for location stock address. Also, maybe it'll be sensible in the future to migrate stock location to use a `stock_location_address` association and remove all the address related fields from the `stock_location` table, but for now it's quite a big task to be contained in current scope. So for now, just treat `stock_location` as an `addressable` which can be used to render address form component.
This is the first step to refactor checkbox component, so it can be used as a separate element or as a form control.
Motivation: We have a couple of places throughout the admin where checkboxes are used as part of a form, with all the same elements being reused to construct a checkbox field: - label with some caption; - hidden input field to support sending a "0" value in request; - optional toggletip hint; Few places however lacked the hidden input, therefore the form was not submitting the "0" value correctly. This updated component builds a reusable form checkbox, that encapsulates all the needed layout and logic for a form checkbox to be displayed and work properly, with an interface to customise it to each form needs.
95992db
to
c0d25ea
Compare
test failure seems to be one of those intermittent |
@kennyadsl @tvdeyen hey guys, you might have missed this one, can I get some eyes 👀 please? |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Can we extract the address component changes into a separate PR please? This change warrants more visibility in changelogs.
Summary
Adds a page with form for stock locations create/update, as well as updates stock locations table with links to go to edit page.
Updates "ui/forms/checkbox" component to contain common layout and logic reused between all checkboxes in admin forms, separating a "checkbox" component as a single element into its own component "ui/checkbox".
Adds helper methods
.back
,.discard
and.save
for UI button componentsAdds missing tests for refund reasons, tax categories and product forms, where missing hidden input prevented booleans to be saved properly.
Page screenshot:

There are a few differences from the design card which I believe make sense to have:
email
column instock_locations
, and the "Phone" field is included in "ui/forms/address", so "Phone" field is not placed in its own section;Checklist