Central betas are an opportunity to get community feedback on ongoing work, so check out the introduction and follow the instructions to try it out on our sandbox or your own machine!
Role-based Permissions
Following up on our last release which introduced Projects to Central, for v0.5 we are adding role-based permissioning. In short, there are now three tiers of web users in the Central administration panel:
Newly created Web Users are no longer privileged, and they can't really do much apart from log in and update their profile and password.
But, web users may now be assigned as Project Managers on particular projects, which grants them the right to create forms, change form and project settings, create and manage app users, and all other project-related work, but only for the projects they are assigned to.
All existing web users are Administrators, who may perform any action on the server, including all Projects. New in v0.5 is the ability to decide who should and should not be an Administrator.
We hope that between the ability to partition your forms by project and tighter control over per-project permissions and roles, you'll be able to better manage your ODK-related staff and installations.
For more information about roles, please read this doc.
We plan to continue expanding both Projects and Roles in future releases; you can continue to find details about our plans for Projects in this issue and we plan on adding more types of roles and possibly some kind of role customization in the future. We know, for instance, that it would be useful to have some kind of read-only role for allowing analysts and third parties access to submission data. If you have thoughts and feedback about either of these work areas, please leave a comment below!
Other Highlights
Thanks in part to feedback from our users and contributions from community developers, we have made the following improvements:
Administrators are now able to update any user profile. Only the user may directly set their own password.
Project names may now be edited by Administrators and Project Managers.
Users may now be retired, which logs them out and removes them from the server, but leaves some of their information intact so that old auditing information (ex: "who created this form?") is still kept.
Projects may now be archived, which cleans the out to the bottom of the Projects list and makes them mostly read-only.
Non-integer IDs in API requests now yield a reasonable error message rather than a crash (#182; contribution by @Akshay_Patel).
Conflicting IDs upon resource creation (eg xmlFormId) now yields a 409 rather than a 400 error (#191).
As always, we have updated our User Documentation and Developer/API Documentation for the latest changes. New to the API docs is the Changelog, which notes additions, breaking changes, and other things of note for each major release.
Especially the "configure via QR code" is neat! Would be super useful if we could set ODK Collect user/admin parameters from ODK Central as well (auto-submit comes to mind).
I couldn't persuade the R package OData to get to the data, LibreOffice (at least my version 6.0) has no OData option (contrary to docs), so here's a quick example using HTTP and basicauth (no OData) in R: http://rpubs.com/florian_mayer/spotlighting
@Florian_May We do want to add some sort of Central to Collect sync that would include forms, submissions, and settings. See What's coming in Central for more.
It's a bummer that the R-package and LibreOffice don't work. I've filed an issue at https://github.com/opendatakit/central/issues/72 so we don't forget to look into it. If you know why R/LibreOffice are failing, please comment on the issue!
I am trying to setup ODKCentral v0.5 on AWS EC2, trying to replicate the steps of digital ocean setup. Everything goes smooth, until I try to start docker-compose@central service, which gives me an error:
[root@ip-172-31-8-82 central]# systemctl status docker-compose@central
● docker-compose@central.service - central via docker-compose
Loaded: loaded (/etc/systemd/system/docker-compose@.service; disabled; vendor preset: disabled)
Active: failed (Result: start-limit) since Fri 2019-05-17 21:14:05 UTC; 52s ago
Main PID: 7918 (code=exited, status=200/CHDIR)
May 17 21:14:05 ip-172-31-8-82.ap-southeast-1.compute.internal systemd[1]: Unit docker-compose@central.service entered failed state.
May 17 21:14:05 ip-172-31-8-82.ap-southeast-1.compute.internal systemd[1]: docker-compose@central.service failed.
May 17 21:14:05 ip-172-31-8-82.ap-southeast-1.compute.internal systemd[1]: docker-compose@central.service holdoff time over, scheduling restart.
May 17 21:14:05 ip-172-31-8-82.ap-southeast-1.compute.internal systemd[1]: start request repeated too quickly for docker-compose@central.service
May 17 21:14:05 ip-172-31-8-82.ap-southeast-1.compute.internal systemd[1]: Failed to start central via docker-compose.
May 17 21:14:05 ip-172-31-8-82.ap-southeast-1.compute.internal systemd[1]: Unit docker-compose@central.service entered failed state.
May 17 21:14:05 ip-172-31-8-82.ap-southeast-1.compute.internal systemd[1]: docker-compose@central.service failed.
Please note that the docker service itself is working fine, and is active.
so, by "the docker service itself is working fine," do you mean that you ran something similar to docker-compose up and the website is running?
if so, then you need to docker-compose stop and then do systemctl start docker-compose@central (or possibly restart) and then it should work correctly.
By docker service, i meant the original docker service, not docker-compose. However, now I think that it is irrelevant perhaps.
I successfully ran docker-compose by going into the folder and executing 'docker-compose up'... The server and ODK is working fine. However, I am still missing the autorun with server startup script, since original docker-compose@central service is not working even now.
so, i am confused. have you copied the autorun script to the appropriate location, and are you using a linux distribution for which the script is actually valid (theoretically any debian but we've only tested on ubuntu)?
yes, sort of. if you go to /version.txt you should see a few version indicators. if they don't make sense to you, paste them here and we can help you decode them.
We are particularly interested in answers to the following questions.