A key challenge with the way KoBo currently works is that each data collector needs to create their own account in order to get permission to submit data. This is a critical problem for large deployments of dozens or hundreds of data collectors, making it extremely time-consuming to deploy KoBo.
User story
As a survey administrator for a large project with hundreds of enumerators I want to be able to quickly create and assign individual user accounts to know who submitted what data and without spending hours creating them the regular way in order to save time.
For self-hosted KoBo, users can be created and managed in Django, but this is confusing for admins who then need to manage users on two completely different interfaces.
I suggest we add, in the KoBo web app [kpi], an easy way to:
create users: a regular user should be able to create other user accounts directly within KoBo. This wouldnât require an email address for each account created: it would only require a username, a password, and what permissions are granted.
They could be an option to add an email address and require the new user to confirm that email address. For those accounts that donât have an email address, password reset is donât by the super admin.
import large numbers of users: by uploading a spreadsheet with username, password, email address (if applicable), and permissions, the super admin could create dozens or hundreds of users.
export the list of users, including usernames and passwords: in order to facilitate the onboarding of new users and communicate their credentials (for example during training workshops).
edit users: the super admin should be able to reset usersâ passwords, manually changing it or generating a new one (thanks to an integrated password generator), or change their permissions
delete users: after a deployment is over or when some groups of users are done working, the super admin could delete users
Iâll be happy to help with the UI/UX part of this development. I can see how a table would easily achieve all the tasks above.
I agree. I need teachers to use Kobo in a rural setting. Why not provide an easy way for the superuser to add new users - instead of forcing them to open their own accounts. As it is these new users will need access to the internet and face a steep learning curve. The current situation defeats the purpose.
@raph Do you have time to create some wireframes for how this would look in reality? Especially steps 1, 4, and 5 would be really useful to visualize. Seeing the different fields you think would be necessary and the suggested user flow would help clarify some of the assumptions behind this suggestion.
@tinok I would be happy to work on wireframes, though for the next few weeks I donât have much bandwidth. I will try to get on it soon. In the meantime, I can describe how I would implement it:
A simple table, similar to the one currently used to share a form (see below)
Just three buttons to âCreate userâ, âImport bulk usersâ, and âExport usersâ
Clicking on âCreate userâ would open a dialog with three required fields: username, password, and permissions; and optional fields like first name, last name, email address (these optional fields will be for the user to keep track of who is who)
Saving the new user information would create a user account that is immediately ready to collect data (if they have the permission for it)
When clicking on a user in the table, a dialog would open with all the information about the user (the password would be obfuscated, with a button to make it visible). And in the dialog, there would be an âeditâ and a âdeleteâ button
Clicking the âeditâ button would make the fields editable, and would allow for changing the password.
We added a âgroupâ column. We didnât that fully, but the idea is rather than Kobo offering a fixed set of groups (e.g. moderators) with a fixed set of permissions (e.g. view submissions, validate submissions), users would be able to create the groups they want with the permissions they want. So they may do something like admins/moderators/enumerators, or instead group enumerators by geographic areas, etc
As you can see, the User Management system is currently within each formâs settings. But it may be wiser to have it separate, for example as a third tab below Projects and Library on the left. So that a user can create/manage users and groups for their entire account, and then they can just share (using the current âsharingâ feature) forms with specific users or groups.
@raph@designer_horizontal Thanks for this! Could you please add a step by step UX flow? Iâm not understanding where people click to get to these new screens and what the <5 button means.
The need for adding users this way was to quickly create several users who can be data collectors (ie who have the âadd submissionsâ permission. Is there a need to create users this way for the other permissions?
The idea with the other permissions is just to give more flexibility to those âsuper adminsâ. Being able to create âmoderatorsâ (who can validate submissions) or other âadminsâ (who can do everything) makes deployment a lot easier: no need for each of those users to go to Kobo and create their own account, which takes time and have proved to complicate the process. The âsuper adminâ can create all accounts directly there, pick the right permissions, and send credentials to everyone. It is less of a priority than creating/managing data collectors, but would create a more comprehensive and simpler system to manage a deployment.
@tinok after consulting with partners, we went for something a bit different. We created a new âUsersâ tab to manage users and group for the whole account. Once the users/groups are created, we would just need to go to the Sharing menu of the relevant form and share the permission(s) we want with the user(s) or group(s).
Thanks for the update, @raph and for the design @designer_horizontal! I may have missed it, but how would users create groups?
And how exactly are groups used? I get you can add/remove people from groups but not what effect this has. I suspect you imply adding groups in the current permissions screen?
Clicking on the âGroupsâ button on the left, and then on âNew groupâ on the right
And how exactly are groups used? I get you can add/remove people from groups but not what effect this has. I suspect you imply adding groups in the current permissions screen?
Yes that is correct. The point of groups is to prevent having to give/edit/remove permissions to dozens, or sometimes hundreds of users. By putting all users in different groups, we would just have to go to the current permission screen, enter the group name, and select the permissions.
Hi @davidwales Iâm not part of the Kobo team, I was just pitching in with ideas and designs. But I believe there is not timeline yet for this feature
