Attachments: REST end point for file upload should allow to specify encounter (ATT-27)

Development
, ,
1

Hi @mksd ,

Thank You for giving me some time. It was really helpful and i am really grateful .I looked what you are mentioned in last call . So as my first task i will modify upload method to which can upload the attachments based on the encounter.:slight_smile:

2

Hi @mksd ,

I looked at the code of upload method which and i am able to add a new parameter for catch the encounter and save the attachment. But i am little bit confuse about how can i pass the encounter from front end of the application. ( Can i get get encounter using $scope.config ?)

3

Let’s not worry about that now, the current UI might not even leverage this new possibility of the REST API.

I would expect your first commit to

  • Extend the REST API so that it handles the encounter parameter.
  • Provide unit test(s) that demonstrate that this new feature of the REST endpoint works as expected.

This is typically where those tests should live.

1 Like
4

i send the PR for changes in upload method . :slight_smile:

5

@ridmal this is a new ticket and piece of work so please start off the master branch again. I would suggest to create an ad-hoc ATT-27 locally to push commits about this ticket:

git checkout master
git pull --rebase upstream master
git checkout -b ATT-27 master
# do some work, commit some code
git push origin ATT-27

I’m assuming here that upstream is /openmrs and origin is /ridmal on GitHub. Then open a PR based on this new ATT-27 branch.

In the headline of your PR, please always reference the ticket that you are working on.

6

I Sent a new PR for ATT-27 :slight_smile:

7

“I am unable to generate Exception you mentioned in the issue”: you mean you don’t know how to bring a ‘mismatch’ between the visit and the encounter?

If so, it looks like any of the encounters ID’d 3, 4, 5 and 6 would do the trick as they seem to be visit-less, see here. So you could for instance use visit (id=1) and encounter (id=3) to bring a test case with the mismatch scenario.

Remember that you should also have a case that shows that if the visit and encounter are provided and match (= the visit is indeed the one of the encounter), then all should be fine.

So basically:

  • If mismatch between visit and encounter ⇒ IllegalRequestException.
  • If only encounter ⇒ verify that the underlying obs is saved and points to that encounter.
  • If visit and encounter match ⇒ verify that the underlying obs is saved and points to that encounter, and the encounter points to that visit.
1 Like
8

@ridmal great work! I merged your PR on ATT-27. Thank you.

1 Like
9

Thank you . . :slight_smile: :slight_smile: