Skip to content
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

feat: more discrete commit-on-save instead of commit-on-change w/ confirm modals #8541

Merged
merged 13 commits into from Aug 4, 2020

Conversation

julianlam
Copy link
Member

@julianlam julianlam commented Aug 1, 2020

Small UI hints when privileges changes are staged (but not committed/saved)
image

New save/discard buttons
image

- new language strings for confirmation and success modals/toasts
- indeterminate privilege handling (/cc @psychobunny)
- added new discard button
- both discard and save buttons now have confirmation dialogs
@julianlam julianlam added this to the 1.15.0 milestone Aug 1, 2020
@julianlam julianlam self-assigned this Aug 1, 2020
@julianlam
Copy link
Member Author

image

A better view of the new privilege setting hints... green check for staged addition, red outline for staged removal, and red dash for staged removal (but indeterminate privilege still applies)

@pitaj
Copy link
Contributor

pitaj commented Aug 2, 2020

So what's the difference between the types of staged removal?

@julianlam
Copy link
Member Author

Nothing, it simply denotes the privilege that will be set or removed, once you hit save.

@pitaj
Copy link
Contributor

pitaj commented Aug 2, 2020

Wait now I'm more confused. Why are there two types of staged removal?

@julianlam
Copy link
Member Author

julianlam commented Aug 2, 2020 via email

@julianlam
Copy link
Member Author

julianlam commented Aug 3, 2020

Was out when you commented... basically, there are two kinds of privileges, same as before. Either it's applied, or not. However, we added the inherited privilege just as a way to explain to admins that because registered-users has a certain privilege, then basically all users have that privilege, since all users are members of registered-users.

e.g. registered-users has posts:edit privilege. Since all users are in this group, any additional groups added to the privilege table will also have posts:edit (since privileges are additive), so we signify this by using the implicit privilege.

So that's why we use the indeterminate checkbox state; the dashed input.

The new colouring simply signals to the admin that the changes have not been applied yet, that is all 😄

Also, ability to add user to a privilege table without needing
to refresh the privilege table.
breaking: helpers.getUserPrivileges and helpers.getGroupPrivileges
no longer make socket calls to the following hooks:

- filter:privileges.list, filter:privileges.admin.list,
  filter:privileges.global.list, filter:privileges.groups.list,
  filter:privileges.admin.groups.list,
  filter:privileges.gloval.groups.list

The filters are still called, but done before the helper method
is called, and the results are passed in instead. This change
should only affect you if you directly call the helper methods,
otherwise the change is transparent.
@julianlam julianlam merged commit a716a55 into master Aug 4, 2020
@julianlam julianlam deleted the privileges-discrete-save branch August 4, 2020 00:42
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

2 participants