Uploaded image for project: 'OpenMRS Core'
  1. OpenMRS Core
  2. TRUNK-5331

CohortMembership should not require a startDate

    XMLWordPrintable

    Details

    • Type: Bug
    • Status: Code Review (Initial)
    • Priority: Should
    • Resolution: Unresolved
    • Affects Version/s: Core 2.1.0
    • Fix Version/s: None
    • Component/s: None
    • Complexity:
      Medium

      Description

      Original Bug Report

      I am running openmrs Version: 2.1.2 and i am attempting to create a new cohort of patients with a certain encounter type - which is successful but returns 0 results yet the database has the information.

      Dev Notes:

      The cohort builder's CachingPatientFilter fetches a cohort of patients that match the selected criteria. And then calls Cohort.intersect() with another cohort containing all patients. This lead to allPatientsCohort.getMemberships().retainAll(selectedPatientsCohort.getMemberships()) which eventually calls CohortMembership.compareTo()
      

      Proposed Solution

      Change the new CohortMembership design to allow null start dates, and use this as the default. See: https://talk.openmrs.org/t/more-changes-to-the-new-cohort-membership-model/15818

      Acceptance Criteria:

      • drop the not-null constraint on CohortMembership.startDate
      • remove any Java logic that defaults CohortMembership.startDate to new Date(), and instead default it to null.
      • Cohort.intersect should behave in a way that makes sense if you give it {Patient 123, startDate Jan 1} and {Patient 123, startDate Feb 15}.
        I would be satisfied if the output is either a cohort with {Patient 123, startDate Feb 15}, or else a cohort with {Patient 123, startDate null}
        but the dev who works on this can propose anything else that makes sense.

        Gliffy Diagrams

          Attachments

            Issue Links

              Activity

                People

                Assignee:
                gcliff CLIFF GITA
                Reporter:
                dkayiwa Daniel Kayiwa
                Designated Committer:
                Daniel Kayiwa
                Votes:
                3 Vote for this issue
                Watchers:
                15 Start watching this issue

                  Dates

                  Created:
                  Updated:

                    Time Tracking

                    Estimated:
                    Original Estimate - Not Specified
                    Not Specified
                    Remaining:
                    Time Spent - 1 day, 2 hours Remaining Estimate - 1 week
                    1w
                    Logged:
                    Time Spent - 1 day, 2 hours Remaining Estimate - 1 week
                    1d 2h