AttachmentsService ahead of REST API work (ATT-24)

Software Add-on Modules
, , ,
81

The API that you use also allows to filter on the concepts/questions, see here the 3rd argument.

82

@mksd Thanks. So what I should be doing is that getting complexObs from the API and passing that list as the third argument.

83

Concepts (complex) not complex obs. But yes.

You need to restrain which obs are returned by asking only for those that are coded by certain concepts.

84

@mksd thanks. i am sorry for the misspellings. The configured concepts(complex) are fetched as a list of strings from here. But a list of concepts is required as the third parameter. How should I handle that?

85

Are you asking me how to go from a list of concept UUIDs to a list of Concept objects? :wink:

If yes then Iā€™m sure that you can figure that one outā€¦

1 Like
86

@mksd Thank you very much for answering my question paper with such humbleness.

87

I would start by doing the conversion list of UUIDs ā†’ list of Concept somewhere around the service impl. class, so where you need it basically. Eventually it could be useful to have this logic moved to AttachmentsContext, but letā€™s look into that at a later point.

1 Like
88

Then also I want to clear out one thing if this wasnā€™t obvious.

Every entity of the OpenMRS data model is saved with a UUID as unique identifier (see here why). And each service or DAO layer should provide a simply way to fetch its supported entities through their UUID.

So concepts should lead you to search for a ā€˜concept serviceā€™. Concepts are basic building blocks of the OpenMRS data model meaning that their ad-hoc service is most likely to be found in OpenMRS Core. A quick search will lead you to this.

1 Like
89

@mksd Thank you very much for your tips and guidance. I will read them and get familiarized.

90

@mksd I placed the code block to save non-complex obs. I am sorry to have erased it.

91

Yes, and I saw that you added it again which is good.

Now the point is that we need to cover all sort of a scenarios and ensure that the main attachments fetching API does what is expected of it. Knowing that it can essentially do three things:

  1. Fetch all attachments for a patient.
  2. Fetch all attachments for a patientā€™s visit.
  3. Fetch all attachments for a patientā€™s encounter.

Where by ā€˜attachmentsā€™ we mean wrapping complex obs that have been configured to be recognized as such, so those coded by a configured list of concepts complex.

It would be great if you could outline further tests to be made (before jumping in the code and making them.) What scenarios would you test?

1 Like
92

Yeah Test driven approach! datā€™s great. I am thinking of (in addition to what you have mentioned above)

1.Fetch all attachmentā€™s for a particular patientā€™s visit for a given encounter.

93

It would make sense to distinguish this from point 3 if it was possible to not attach encounter to a visit. Could you check this and report back?

Btw what I would like you to do is to outline (here) possible atomic test cases for each of the 3 broad scenarios. What situations would you test? What tests setups would you put together?

94

@mksd Ok I will search about it and report back. I think I have already written a test case to search for patientā€™s encounter. In the same way I would write a test method using the patient as the only argument.

What I was mentioning before was to write a test method using all the three parameters ( patient, visit and encounter)

95

Well basically it doesnā€™t make any sense to specify both the visit and the encounter (I think), so we should introduce two separate methods in AttachmentsService:

List<Attachment> getAttachments(Patient patient, Encounter encounter, boolean includeRetired);
List<Attachment> getAttachments(Patient patient, Visit visit, boolean includeRetired);
96

@mksd Thanks. The current AttachmentsService takes in three parms (patient, encounter, visit). I guess that has to be removed then and modified as mentioned above.

97

@mksd Shouldnā€™t I include

List <Attachment> getAttachments(Patient patient, boolean includeRetired) in AttachmentService in addition to the above two methods you have mentioned ?

98

Yes absolutely. But I would like you to focus on the the ā€˜encounterā€™ one for now as thatā€™s the easiest to test. Or at least thatā€™s the one for which the tests setups are easier to put together.

1 Like
99

@mksd I modified the AttachmentsTest. Looking forward for your feedback.

100

@mksd I guess the test for the encounter is ok. Shall I go on and do the same for other two tests as well. Is it alright to use the same TestHelper method in preparing test data?