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.

        Attachments

          Issue Links

            Activity

              People

              Assignee:
              gcliff CLIFF GITA
              Reporter:
              dkayiwa Daniel Kayiwa
              Designated Committer:
              Daniel Kayiwa
              Votes:
              3 Vote for this issue
              Watchers:
              14 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