The CSV can be located anywhere as long as you reference the correct path to it when reading from it. In the example above, it was just in the root of the KPI directory.
There is no right or wrong way to do it — my code above is merely a suggested approach to it. If you do want to follow that approach then you can just have multiple lines with the same username and project_uid but different permissions in the permissions.csv file:
@Josh
Is there a way to add users and assign permissions from an external system using a similar method? I mean other than a clunky set of SSH commands?
@ks_1, yes for assigning permissions, no for creating users — you can just integrate the external system with the appropriate API endpoints. I would suggest looking at the network tab when in the KPI UI and see what endpoints are called and then just emulate that behaviour.
For creating users, you could potentially have a script that fills in the HTML sign-up form, but I haven’t tested that.
@Josh,
Is there any development plan to implement APIs to add/remove users? If not, I’m planning to get it developed from our end and will create a pull request once done.
@ks_1, there’s nothing in the pipeline at the moment, but I would suggest we consult with @jnm about the approach to implementing this. It’s best to develop features that can be merged into master to serve the rest of the community rather than creating a fork that you need to maintain.
It works perfectly. So adding users in bulk is now a piece of cake. Thanks @Josh and @jnm.
I also have some groups set up for different types of users, and would like to change these from APIs as well. Is there existing functionality for this using Authorized Application?
Hi @ks_1, that’s great! I’m not aware of an endpoint that’s exposed to do that, but I’ll leave that open to @jnm to comment. It looks like you can manage this sort of thing just through the existing permissions endpoints as a work-around? You could have a spreadsheet or whatever that links permissions to groups and then assign those to users. Team management is something that’s in the pipeline, so hopefully you can manage this without a work-around soon.
We always faced some credential issues when using this method, only now did we realize the problem…
When creating users through this method, the credentials work on KPI, but they don’t work on KC (although the users are created there as well). Users can log into kf.url, but if they try to sign in on ODK Collect using the KC endpoint, the credentials don’t work.
The only way to get it to work is to go to kf.url/admin and reset the passwords for these users.
After that, the KoBoCAT OpenRosa endpoints, which use digest authentication, should work for the new user. I’ve filed a bug; please check the reproduction steps and add comments if your experience differs.
@jnm
We’ve edited the v2 KPI endpoints to create users and edit permissions (also all other parameters) using superuser credentials… Can I directly submit a pull request?
Thanks for the pull request. Did you intend to expose the usernames, names, email addresses, etc. to anyone who accessed the endpoint, including anonymous users and non-superusers? You also seem to remove an entire method, migrate(), for no apparent reason.
I would request that you please review the checklist in the PR template (none of the boxes are checked). Unit tests are absolutely mandatory for a change like this, and the unit tests should illustrate what you expect the API to do. For example, I would be able to tell if you intentionally wanted to give the general public that level of access to your user list if there were a unit test—and if you didn’t, the unit test would’ve caught the mistake.
So adding users in bulk is now a piece of cake. Thanks 
