Thank you for your feedback, @dr_michaelmarks! The features you mention are definitely all important, and we're aiming to implement them. We've spent part of this week planning our next couple of releases, which will include more project management functionality. As we roll that out, I think we'll have more functionality around (3) and (4). We're planning to continue releasing new versions regularly, and as we do so, I think we'll be striving to both implement functionality that already exists in Aggregate (such as user deletion) and roll out new functionality (such as project management).
@Felix_Mutua, as part of that new project management functionality, there will be improvements to how app users are organized. Those improvements should help reduce the number of app users you see on a single page. In addition, we may also hide revoked app users in the list by default. Would that be useful?
As part of the next release, we're also planning to add the app user name to the CSV.
For those who is missing publish to Google sheet function from ODK Aggregate. A good script that can read OData feed from ODK Central and bring to your Google sheet can be found in GitHub. Just replace row 111:
var odata_fetch_url = odataurl + table_name_selected + 'S';
with:
var odata_fetch_url = odataurl + table_name_selected;
However, on launching docker-compose build or docker-compose up I only receive errors. There seems to be a problem with package management.
The following packages have unmet dependencies:
postgresql-client-9.6 : Depends: libpq5 (>= 9.6.11) but 9.6.10-0+deb9u1 is to be installed
E: Unable to correct problems, you have held broken packages.
I assume this is a problem within the container, rather than a DigitalOcean problem. Anything I can do about this? Would love to try Central out.
@yanokwa Many thanks for this -- have now got it to work and starting to test. New interface looks great, docker-based set-up on DigitalOcean much more straightforward than google apps, and things seems very robust. (Not that I have put it under any stress testing).
However:- a question I cannot find answered easily in ODK Central docs. How backward compatible is Central?
I ask because we currently rely on a number of ruggedised field GPS devices which can only run ODK Collect 1.4.17 (presumably due to the base Android 4), which makes the QR code scanning / App User system tricky to use.
Manually typing in the long server link (from a non-field device that /can/ run ODK Collect 1.18) to these older devices does not seem to work (a username and password demanded, but I can find no obvious way to find out what that would be).
@tcw Central should be compatible with most versions of Collect as long as you can type the long URL (which I know is annoying, but that system has some nice security properties).
If you give me more information about the device you are using with Collect v1.18, we can try to reproduce the error and fix it. Once we get that working, we can look into v1.4.17.
Apologies that I was not clear. The ODK Collect 1.18 on a device that runs it works just fine.
The problem is with the device (a Garmin Monterra) which can only run 1.4.17. I've typed in the long link by copying from the device which runs 1.18 (this was the only way I could find that long link -- since ODK Central only shows the QR code - perhaps there is a work around if an independent QR reader could be used to copy/paste address).
Collect 1.4.17 demands "Server Requires Authentication", presumably a username and password, but how do I know what those are? (Collect 1.18 has a blank username and password). I've checked the long link several times so I don't think it's because I've typed it wrong.
Thanks @yanokwa -- I agree the link is the most likely issue, but I did check several times. Do I understand correctly that no username or password should be required, if using the long-form URL? Will wait for Central v0.4 and try again as you suggest.
Can you make it easier to get the link from Central into older versions of ODK collect? -- e.g. an option for the url in text form instead of QR code, so that it could be emailed to the device & then cut-n-pasted into the relevant box?
We are particularly interested in answers to the following questions.