Skip to content

Commit

Permalink
Update ObsByConceptSearchHandler to support Core 2.2.*
Browse files Browse the repository at this point in the history
  • Loading branch information
@mogoodrich
mogoodrich committed Aug 7, 2018
1 parent e3e2d47 commit 8f31b76
Showing 1 changed file with 7 additions and 7 deletions.
14 changes: 7 additions & 7 deletions .../src/main/java/org/openmrs/module/attachments/rest/ObsByConceptListSearchHandler1_10.java
View file
@@ -1,11 +1,5 @@
package org.openmrs.module.attachments.rest;

import java.util.ArrayList;
import java.util.Arrays;
import java.util.Collections;
import java.util.Comparator;
import java.util.List;

import org.apache.commons.logging.Log;
import org.apache.commons.logging.LogFactory;
import org.openmrs.Concept;
Expand All @@ -28,6 +22,12 @@
import org.springframework.beans.factory.annotation.Qualifier;
import org.springframework.stereotype.Component;

import java.util.ArrayList;
import java.util.Arrays;
import java.util.Collections;
import java.util.Comparator;
import java.util.List;

/**
* The contents of this file are subject to the OpenMRS Public License Version 1.0 (the "License");
* you may not use this file except in compliance with the License. You may obtain a copy of the
Expand All @@ -46,7 +46,7 @@ public class ObsByConceptListSearchHandler1_10 implements SearchHandler {
protected AttachmentsContext context;

private final SearchConfig searchConfig = new SearchConfig("obsByConceptList", RestConstants.VERSION_1 + "/obs",
Arrays.asList("1.10.*", "1.11.*", "1.12.*", "2.0.*", "2.1.*"),
Arrays.asList("1.10.*", "1.11.*", "1.12.*", "2.0.*", "2.1.*", "2.2.*"),
Arrays.asList(
new SearchQuery.Builder("Allows you to retrieve Observations for a patient and a for list of concepts")
.withRequiredParameters("patient", "conceptList").build()));
Expand Down

5 comments on commit 8f31b76

@mks-d
Copy link
Member

@mks-d mks-d commented on 8f31b76 Aug 8, 2018

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Thanks @mogoodrich . I'm thinking that we should probably be consistent here and ensure that all beans that supported up to 2.1.x until this commit should now support up to 2.2.x, what do you think? Unless this creates unexpected additional work of course.

@mks-d
Copy link
Member

@mks-d mks-d commented on 8f31b76 Aug 8, 2018

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Unless this creates unexpected additional work of course.

In which case this should be reported in an ATT ticket.

@mogoodrich
Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@mks-d agreed, I think, what steps do you think need to be taken? We just discovered this because some outside consultants we were working with were running against 2.2.x and all of a sudden all obs for a patient began appearing in the Attachments window. We are currently still running 2.1.x so I'm not in a position to test other functionality on 2.2.x right now, I just fixed this one once I realized it was a quick fix.

@mks-d
Copy link
Member

@mks-d mks-d commented on 8f31b76 Aug 8, 2018

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Just for the sake of consistency I would do a text search for 2.1.* to find all beans that have been limited to that upper bound. And I would add the 2.2.* as you just did. This doesn't mean that everything will necessary work against 2.2.x, but at least on the principle the code base would be consistent.

@mogoodrich
Copy link
Member Author

@mogoodrich mogoodrich commented on 8f31b76 Aug 8, 2018 •
edited

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Oh, right, yes I did do that and it was the only 2.1.* I found... some others already support "2.". We probably should change this one to be "2." but the standard pattern on the other REST handlers is to have each point release separate (though I'd wouldn't be opposed to changing this convention).

Please sign in to comment.