Multiple user roles

I just came across this and will have a look at implementing it (ofc with kirby design):

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:

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?

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

  - 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:
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
      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?


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:

      - editor
      - seo

We could do:

  label: users.form.language.label
  type: select
  required: true
  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?

I could see a default blueprint - but what would be the use case to have those fields be not based on roles? And I somehow really don’t like the idea of having a suboption of a field defining if the field is added or not (it’s quite a difference with things like sort).

It’s just that this

so the last loaded role/blueprint can overwrite earlier ones

seemed weird. Do I even know the loading order? But the value is written only once in the text file, so maybe it doesn’t matter if the field is defined in multiple role blueprints?
Also, it sounds like we have to be very careful: what if in one of several blueprints sharing the same field, one of them has different settings?

A default blueprint would be useful when we want a field to be available to every user. Then no need to even assign roles, everybody has it by default.