openlmis-referencedata

Clone Tools
  • last updated a few seconds ago
Constraints
Constraints: committers
 
Constraints: files
Constraints: dates
added

added

changed

changed

changed

changed

changed

changed

changed

changed

changed

changed

changed

changed

changed

changed

changed

changed

I thought that for PUT if a resource does not exist, a new one should be created with the given id

I thought that for PUT if a resource does not exist, a new one should be created with the given id

both fields make sense for me

both fields make sense for me

I think there was a reason why we decided to call this property as entries but I don't remember. I am okay with changing it to subscriptions but I would wait for Chongsun Ahn response

I think there was a reason why we decided to call this property as entries but I don't remember. I am okay with changing it to subscriptions but I would wait for Chongsun Ahn response

I would say if a request has null or it is not set then backend should treat it as an empty list.

I would say if a request has null or it is not set then backend should treat it as an empty list.

Łukasz Lewczyński CC Chongsun Ahn The entries seem pretty generic... I'm having trouble grasping what they are actually representing. The only name for them I found at one of the eLMIS screenshot i...

Łukasz Lewczyński
CC Chongsun Ahn
The entries seem pretty generic... I'm having trouble grasping what they are actually representing. The only name for them I found at one of the eLMIS screenshot is "Subscription", but I'm not sure about that. Perhaps a simple "Assignment"? Anyway, we should definitely rename it to the picked name so the naming is ubiquitous.

In eLMIS the Supply Partner also had Name and Code, should we add them Chongsun Ahn?

In eLMIS the Supply Partner also had Name and Code, should we add them Chongsun Ahn?

Same for the PUT below.

Same for the PUT below.

Or the token might be invalid. Same for others below.

Or the token might be invalid. Same for others below.

Technically a 400 is a bad request, so it might not simply be the query parameters that has an issue. Same for others below.

Technically a 400 is a bad request, so it might not simply be the query parameters that has an issue. Same for others below.

Why not a page?

Why not a page?

I think we should support that there may be a supply partner, but it may at any point not have any entries. All entries might be removed while configuring, or when first created, etc.

I think we should support that there may be a supply partner, but it may at any point not have any entries. All entries might be removed while configuring, or when first created, etc.

how about adding info for 404 error?

how about adding info for 404 error?

I think that this should say that you are not authorized to get this info

I think that this should say that you are not authorized to get this info

I think that this should say that you are not authorized to get this info

I think that this should say that you are not authorized to get this info

I think that this should say that you are not authorized to get this info

I think that this should say that you are not authorized to get this info

I think that this should say that you are not authorized to get this info

I think that this should say that you are not authorized to get this info

I think that this should say that you are not authorized to get this info

I think that this should say that you are not authorized to get this info

OK, great! but where is the info on fisheye that will tell me from which branch are those changes?

OK, great! but where is the info on fisheye that will tell me from which branch are those changes?

with entries as null there are no required fields in this model. Not sure if there is a sense to create a supply partner without entries (cc: Chongsun Ahn)

with entries as null there are no required fields in this model. Not sure if there is a sense to create a supply partner without entries (cc: Chongsun Ahn)