What field type for selecting a larger amount of items?

Kirby 3 Solved ✅
#1

I’ve got the situation where i need to select a number of items out of a large list.

In this specific case, the recipients for an email newsletter are to be selected from a list of 900 users.

I first tried with the checkboxes-field which lists the ~900 users in a checkbox group:

image
image1052×390 50.3 KB

That technically works, but i ran into some trouble with a bug in Kirby’s UI.
See https://github.com/getkirby/kirby/issues/2866
I can not use this as long as this bug exists. That means currently it’s a no-go for my project.

Then i tried a multiselect-field. That doesn’t work at all, it is much too slow. Except of that, it’s not user-friendly because of optical and haptical reasons.

Next i thought about the pagetable-section from Sylvain:


but that doesn’t give me a possibility to select the checked users, meaning no solution for my problem.

Finally i found the wunderful relationship-Plugin from Ola:


I like it very much, and this works best from a user experience point of view.
But i noticed it get’s terrible slow as soon as more then 50 or 100 items are select. In the end it needs several seconds to notice that an item has been clicked, so it’s not a solution, too. I like this one most, but i can’t use it.

image

Unfortunately I no longer have any idea how to solve this problem. :thinking:
Is there really no way to select entries from a longer list?

If the checkboxes-plugin wouldn’t have that UI bug, it’s probably a solution which at least works technically.

I am very happy about every hint, because currently i don’t see any solution to complete that task.

#2

Wouldn’t it make sense to store this information in the user file instead of in another page? Of course, it would be more cumbersome to edit… But then long lists of options are not great either.

#3

The situation is that there are several lists for newsletters, and it should be possible to add or remove users from one central point.

I think it’s not possible to enter into some hundred user account pages one after another to select which lists each user is subscribed to.

#4

Why does this have to be handled manually anyway instead of letting users subscribe via a form and then update their user information programmatically accordingly?

#5

That’s the use case: The organisation decides who is a recipient on a list. There is not a user login area at all. It is managed centrally by the organization’s employees.

#6

Then a last suggestion before I run out of ideas: A custom view with just the users where you can tick them off and store this information in the user files. Maybe with a column for each newsletter type. Needs a Panel plugin, of course.

#7

That sounds good to me.

Thats a field with the list of all items and i can check the ones i want.

But, what is the difference to the checkboxes field?

Storing the information in every users file is a bit tricky, too? Because i need to loop over all users when sending the newsletter, to find out if the user is subscribed on the list. I think its better to store the information in the list, because then i only need to loop over the list items.

#8

I would create a custom section in this view, similar to the Pagetable thingy but with inputs to check options that are then stored. Not a field.

#9

Yes, you would have to filter them.

Of course, instead of storing this information in the user files, you could also just store it somewhere else, in a page or even in an SQLite file.

#10

If I’m not mistaken, I actually have no problem with saving the information, but with the UI? For example, the only problem with the checkboxes field from my point of view is that the entries are not displayed. Or with the relationship field that the UI no longer reacts when a certain number is selected.

I’m afraid to run into the same problems when trying to build a plugin.

#11

Yes, I understand that. Just wondering how user-friendly multiple checkbox lists would be, even if the bug was fixed. As far as I remember, checkboxes don’t even have a search function.

And the users field doesn’t work either? Because that would be my first choice for users. Or did I miss that option in your enumeration above?

#12

What is the difference between your suggestion and the checkboxes field? Was your plan not to have checkboxes but instead only to select the row? That could work…

The users field could work, but there are two small problems with it: you can not see who is selected and who is selected not in one list. You then have the selected users in the panel page, and the other ones in the add-dialog - if i’m not wrong. The other problem i have with the users field, that i can not show the company name of the user as additionally information because the text field is not working (in 3.4.3, soon to be fixed i guess, see https://github.com/getkirby/kirby/issues/2832).

I will try again the users field right now. It was my first choice, too. But then i switched to checkboxes because it is less clicking when adding or removing users.

#13

Have you checked if this is already implemented in 3.4.4-rc1?

The first point: yes, true, but if it is overall more usable…

#14

You mean the suggestion of a custom view? You could add search, it would be more a table with rows for users and columns for different types of newsletters. Each table cell would have an input field.

I envision something like the Pagetable, but editable. It wouldn’t even have to go into a separate view, could live in a page as well.

#15

I just checked the users-field again.
I have persons with the same name, that means i need to show more information like the company name or email-address. I tried:

        fields:
          recipients:
            label: Empfänger
            type: users
            text: "{{ user.content.company }} {{ user.name }} - {{ user.email }}"

But it only shows the user name. I tried with info attribute, too.

#16

Yes, i’d prefer that, too. Unfortunately, my Vue.js capabilities are not sufficient. However, I would immediately award it as a paid job if someone had the capacity. The solution would be a pagetable-like field with the ability to toggle the rows. That would be enough for me in the first step.
Perhaps the second step is the input field (a tags field? - to select several newsletters per person).

#17

I just tested with 3.4.4-rc1 and worked (the text option, I mean)

#18

What attribute did you test?
I tried text and info right now. Now it works in the add dialog, but in the normal page view it’s not shown.

#19 
 recipients:
            label: Empfänger
            type: users
            text: "{{ user.content.street }} {{ user.name }} - {{ user.email }}"

(Used street for the field because I don’t have a company field…

Bildschirmfoto von 2020-10-03 15-10-28

#20

Strange…

image
image930×90 23.1 KB

But only shows me the name in the page. I need to sort by company.
++ update: i needed to clear the list and create a new, now it’s displayed correctly

The problem with the users-field still is that you can not see which persons from one company are subscribed and which not, because the one information is in the page (not subscribed) the other one you have to open the add-dialog for. Thats why i still believe the Pagetable-like field would be a better solution for my use case, because then you can see the for example 7 persons from one company, and who is selected and who not.

I think i will go with the users-field for the moment. That at least works technically as expected. My favorite would be the pagetable-like field.