Multiple user roles

:wink:

also just cleaned up the code a bit more, much slimmer - getting to code that starts to look okayish: https://gist.github.com/distantnative/8700d5836c29134ef6e4/revisions

Well, checkboxes are obvious candidates. At the moment the user page is tidy, a roles list may not look that nice, but weā€™ll find a way.
In Drupal, even in the upcoming version 8, we use checkboxes for roles. Old and boring, but just works :wink:

Or we can use a fancier widget.

But not sure itā€™s more practical or intuitive. Itā€™s only useful in case the list becomes very long imho.

I have updated user.php and it works fine for the simple cases Iā€™ve tested.

I just came across this and will have a look at implementing it (ofc with kirby design): http://codepen.io/ElmahdiMahmoud/pen/hlmri

Cause I agree, a list of checkboxes doesnā€™t sound that sexy and/or ideal :smiley:

@Malvese I quite like that widget ā€¦

hereā€™s another possibility, similar to how tags are displayed: http://demos.telerik.com/kendo-ui/multiselect/index

1 Like

@texnixe Well, I think its main benefit is that only the roles the user has are listed. Easy to scan. But the widget is a new type of field that needs to be coded and maintained, checking/unchecking roles takes longer, it is a new piece of interface to learnā€¦

A simpler way could be to build on the checkboxes, and just sort them with checked ones at the top when the page is displayed. It would be scannable, fast to use, and everybody already knows how to use it.

@distantnative There is also the good olā€™ Multiple Select, but using a select means we donā€™t see the roles unless with open it.

I tried something. I wanted it to be very close to the current select field. Itā€™s certainly not complete and would need some refinement. But what do you think about the general direction?

http://www.distantnative.com/multiselect.gif

What really bugs me that I canā€™t get it to not close after checking an option so far :angry:

Chosen closes when an option is selected.

But I want it not to close directly :wink: Also just found the JS bug. Only problem (besides design aspects) left is that while on the user edit form the multiple values can be saved perfectly as array in the style

role:
  - admin
  - editor
  - client

But when I try to use that field on a normal page, I get an endless progress spinner on saving. Page content doesnā€™t seems to like arrays and doesnt know how to deal with it? :confused:

That problem could be solved eventually as well. If anyone feels like testing it: https://github.com/distantnative/panel/commit/7bdd9eb01e23ddfe2ec0ed5c39a538c4006d5f43
Feedback is always highly appreciated! :smiley:

It mostly works, but I found a weird little bug. After I check an option, if I click on the label above the multiple select my choice is not saved.

Edit: when I click on the label multiple time it does weird things. Also it seems I canā€™t save my content when I use this field.

Apart from that, it works as advertised. Iā€™m not sure I like the max-height on the select. One of the main benefits of using plain old checkboxes is that you can see all options at a glance. On the other hand, if the list is very long we will ultimately have to scroll anyway. I tried removing the max-height, I think it works okay: if you ever have a very long list youā€™ll be able to use the usual browserā€™s scroll. Maybe itā€™s just me, I donā€™t like to scroll in tiny boxes :smile:
Also adding a way to easily remove options, like we already have for tags, would be nice.

1 Like

Yes, I can confirm that the behaviour is a little weird although the content is saved without any problem.

One thing is that before saving, the value instead of the label is shown in the field. The second thing as @Malvese mentioned, when you click on the label, strange things happen.

1 Like

One last thought. I know Iā€™m getting annoying with my ā€œplain old checkboxesā€, but I think such a widget only helps for long lists.
Up to around 6 items Iā€™d rather use checkboxes: everything at a glance, no need to open a widget, no scrollā€¦
Right now with as few as 5 items we need to scroll. Hereā€™s a comparison:

Multiple selects are basically enhanced checkboxes, so instead of a new field type, could we add options to the existing checkboxes? We could then choose to change the way it displays when/if we add more choices.
To display them as a multiple select we would use something like:

type: checkboxes
    default: architecture
    display: select
    options:
      design: Design
      architecture: Architecture

While weā€™re at it, different values for the same option to fit more checkboxes on one line?

display: 1/3
display: 1/4


I fixed already locally that the values and not the keys are entered on checking an option. And I will fix the weird label issue now.

Could you explain this a lil more, @Malvese? For me it works and it seems for texnixe as well.

Also, @texnixe, whatā€™s your opinion of the question of design: max-height yes or no? Iā€™ll also think about that tag-like remove option

Iā€™m a bit indifferent as regards the max-height, it all depends on the number of options, letā€™s say if I had five options and only four visible within the max-height, that would be annoying, and Iā€™d probably change that setting via a custom style sheet. However, I prefer the select variant over the checkbox one, although if the number of choices is very limited (like 4 to 6 items), checkboxes are sort of OK ā€¦

Ok, I might set the max-height a lil higher in the next version in that case.
On the question of checkboxes - I opted to create this field separately from the checkboxes field, tho it inherits everything from the checkboxes field. I just feel much more comfortable with have all the css, js, php changes separate, if just for easier understanding when reading the code.

And since I am looking for a solution mainly for the user roles field, I want something that also works with quite a few user roles options and, ideally, doesnā€™t change the layout of the existing user add/edit form, when not focussed.

Updated a few things and removed the label issue - also moved it to an plugin so that more people might test it: Multiselect field (plus, this thread can go back to actually focus on multiple roles per user) - thanks already for your feedback and help!

Looking at this issue/idea

how would you think user blueprints (that are based on the user role) should work? Fields from which role would be displayed?

2 Likes

Just read the issue on Github.
@distantnative you wrote:

It also work with multiple roles, but fields with the same name will replace each other - so the last loaded role/blueprint can overwrite earlier ones.

Thatā€™s with a user blueprint per role, right?
Another way is a single blueprint for all users, with a role setting for fields.
Just like we can do:

pages:
  permissions:
    create: 
      - editor
    sort:
      - seo

We could do:

language:
  label: users.form.language.label
  type: select
  required: true
bio:
  label: Biography
  type: textarea
  role:   // or 'permissions'?
    - editor
    - team

Pro: a field is never overridden. No confusion when you add/remove a role to a user.
Con: can be messy if you have lots of fields that are unique to roles.

1 Like

Thatā€™s what Iā€™ve been pondering as well. What would be use cases that would require lots of fields for different roles?