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
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
hereās another possibility, similar to how tags are displayed: http://demos.telerik.com/kendo-ui/multiselect/index
@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
But I want it not to close directly 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?
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!
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
Also adding a way to easily remove options, like we already have for tags, would be nice.
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.
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?
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.
Thatās what Iāve been pondering as well. What would be use cases that would require lots of fields for different roles?