We’ve been using your API for a while now, and if the experience has been mostly pleasant, there are some aspects which are making our work more difficult, so I wanted to let you know what would make our life easier:
Return IDs of created items: when we create a meta data (org unit, data element, etc), the API should return the newly created object id (or ids if multiple ones). Failed to do so require us to make a second call using a field to fetch the object back, this being a risky thing when fields are not always unique. Same thing when a batch process occurs, having something such “2 updated, 2 ignored” does not help me - I need to know which have been updated and which not so that my app can react accordingly.
Respect user rights management: if I can only access some object using the app with a given user/password, I should have exactly the same rights throught the API - the way I access the app should not impact what I can see/do
Cf my previous mail, the additionnal point is to have a lot of thought before altering the API in a backward incompatible change - this can break a lot of software, and at minimum to document those closely.
I’ll be happy to discuss more on those topics, and to contribute any help that can be useful.
- *Return IDs of created items:* when we create a meta data (org unit,
data element, etc), the API should return the newly created object id (or
ids if multiple ones). Failed to do so require us to make a second call
using a field to fetch the object back, this being a risky thing when
fields are not always unique. Same thing when a batch process occurs,
having something such "2 updated, 2 ignored" does not help me - I need to
know which have been updated and which not so that my app can react
accordingly.
Yes, this can be done using the new `importReportMode` in 225 (you probably
want to set it to full)
- *Respect user rights management:* if I can only access some object
using the app with a given user/password, I should have exactly the same
rights throught the API - the way I access the app should not impact what I
can see/do
Not exactly sure what you mean here. Where do you see these issues?
···
-
Cf my previous mail, the additionnal point is to have a lot of thought
before altering the API in a backward incompatible change - this can break
a lot of software, and at minimum to document those closely.
I'll be happy to discuss more on those topics, and to contribute any help
that can be useful.
Regarding my question re: user rights through the API, maybe I was mistaken. Just to be sure: if I connect with a specific user using the API, I should get exactly the same access as I get through the UI with the same user, correct?
Martin
···
On Mon, Oct 24, 2016 at 4:44 AM, Morten Olav Hansen morten@dhis2.org wrote:
–
Return IDs of created items: when we create a meta data (org unit, data element, etc), the API should return the newly created object id (or ids if multiple ones). Failed to do so require us to make a second call using a field to fetch the object back, this being a risky thing when fields are not always unique. Same thing when a batch process occurs, having something such “2 updated, 2 ignored” does not help me - I need to know which have been updated and which not so that my app can react accordingly.
Yes, this can be done using the new importReportMode in 225 (you probably want to set it to full)
Respect user rights management: if I can only access some object using the app with a given user/password, I should have exactly the same rights throught the API - the way I access the app should not impact what I can see/do
Not exactly sure what you mean here. Where do you see these issues?
Cf my previous mail, the additionnal point is to have a lot of thought before altering the API in a backward incompatible change - this can break a lot of software, and at minimum to document those closely.
I’ll be happy to discuss more on those topics, and to contribute any help that can be useful.
Yes, today almost all our apps are using the web-api directly.. so if
anything is blocked there, it will be blocked by the UI also (we still have
some old UI which is not using the web-api, but they should be secured also)
···
On Mon, Oct 24, 2016 at 3:21 PM, Martin Van Aken <martin@joyouscoding.com> wrote:
Regarding my question re: user rights through the API, maybe I was
mistaken. Just to be sure: if I connect with a specific user using the API,
I should get exactly the same access as I get through the UI with the same
user, correct?
--
Morten Olav Hansen
Senior Engineer, DHIS 2
University of Oslo