Group-specific permissions in Aggregate


I would like to have in aggregate the possibility of having groups of users with the same rights so as to be able to answer all the requirements when working with different teams on common forms or not
You can register a login / password on behalf of a group, but it requires managing the group outside of aggregate, which makes this system unsecure.
A good example is the REDCap program, which in the same domain offers you more secure "access" to data.


The feature you are describing is pretty similar to this, but I think it differs in that you want different permissions on the server side (e.g., for data managers not for data collectors). Is that correct?

Sorry but currently I do not do too much in the short

If you allow it Yam I will dream a little (I anticipate that very little your constant advances :grin: )
And I will take the example of the link:

  • secretary: input of patient data (data seen by all but not able to see the data of the doctor or nurses)
  • doctor = diagnosis (hide from all except doctors) and treatment decision (can only be seen by doctor and nurse)
  • nurse = application of care
  • accountant (yet another case)
    (Nota Bene: I do not think ODK and our android are sufficiently powerful and secure to answer this topic, but this is an exercise)

We can have several scenarios:

  1. Access to different categories in a form depending on the category of the person (secretary, nurse, doctor, ...)
  2. Access to different forms on devices used by several categories of people (secretary form, nurse form, doctor's form, ...)
    But in this case it will be necessary to find the means to "connect" the form "data of secretary" with the 2 other forms!

I understand the access to the forms by identification:

  • Name First name (+ code / password?) (List of speakers registered in the form => updated list or encrypted csv file?)
  • Fingerprint (ah yes ODK has not yet developed this part but it will come, I do not doubt you)

For the Aggregate server:

The groups remain the only solution with registration of the access codes in the database

  • secretarial group: all can modify, supplement patient information
  • doctor group: all can see the diagnosis (one can dream)
    Divided into subgroups because none will accept that other doctors look at their data :sunglasses:
  • group chief doctor (no longer entering data but relis, validates files)
  • group nurses: ....
  • data management group: extraction, construction of patient history and data analysis

The groups exist in ODK with name and label, it would be enough (it is always easy to say) to use them for the creation of the groups associated with the form and its data.

For this example, it would also be necessary to envisage a daily update of the complete files of the patients (identity, treatment, care) with update of the devices
This may also involve in a 2nd step the possibility of encrypting the xml form

(Nota bene: it is a model that I participated in for TabletPC in 2004-2010 in Visual Basice which is operational in Niakhar in Senegal. Observatory and monitoring of demographic population)