-
-
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] New admin user edit page #5856
[Admin] New admin user edit page #5856
Conversation
0dda58d
to
9276214
Compare
Looks like the promotions spec failures are consistent across all branches and unrelated to this PR
|
f107c75
to
451003c
Compare
Codecov ReportAttention: Patch coverage is
Additional details and impacted files@@ Coverage Diff @@
## main #5856 +/- ##
=======================================
Coverage 89.23% 89.24%
=======================================
Files 752 754 +2
Lines 17510 17533 +23
=======================================
+ Hits 15625 15647 +22
- Misses 1885 1886 +1
Flags with carried forward coverage won't be shown. Click here to find out more. ☔ View full report in Codecov by Sentry. |
451003c
to
777a06d
Compare
I have fixed the (unrelated) failing API promotions specs in this PR: #5859 |
admin/app/components/solidus_admin/users/edit/component.html.erb
Outdated
Show resolved
Hide resolved
25a87fc
to
bdfe150
Compare
bdfe150
to
f7ea6b8
Compare
This migrates the `users/:id/edit` page to the new admin. It still relies on the old backend admin controller for the `#update` action as well as the other top level user tabs such as address, order history, and so on. Co-authored-by: benjamin wil <[email protected]>
f7ea6b8
to
ac8ee59
Compare
Summary
This PR is for issue: #5824
This migrates the
users/:id/edit
page to the new admin. It still relies on the old backend admin controller for the#update
action as well as the other top level user tabs such as address, order history, and so on.In the next couple PRs I will migrate the remaining tabs to the new interface, but for now I thought it best to keep the old interface for actions such as creating a new user, which we definitely want to still have working.
This PR does not handle the issue of permission dependent interface elements. In the old admin, some buttons would not be visible if the user lacked the permissions to action them. However it looks like that is currently standard for the entirety of the new admin as I don't see any permissions checks or anything like this anywhere in the new admin:
If we are using a new helper or gem to manage this and I am just missing something definitely let me know which implementation I can reference! Otherwise for now I will put this up as is because handling
if can?
permissions checks across the whole of the admin is a bit out of scope for this PR.In the next PRs I will migrate the other tabs of the user admin (address, order history etc) and will add the modal for user creation (although I may leave the user creation backend logic as is for now as it looks like the issue specifically states that the user invitation flow should be considered a separate task.
Again there weren't really designs for this so I just went for it and tried to keep to our existing components as much as possible. Hopefully it looks decent!
The attached video shows the functionality visually:
Screen.Recording.2024-09-18.at.9.29.12.PM.mov
Checklist
Check out our PR guidelines for more details.
The following are mandatory for all PRs:
The following are not always needed: