Change handling of legacy occurrence point data

[gigxz]

Merging this PR

• use the squash-merge strategy

Description

Issue: https://github.com/open-path/Green-River/issues/7236

This is walking back a previous assumption which said "you would only have one Occurrence Point form per field you're collecting". So only ONE move-in form, ONE unit assignment form, etc. If you want to customize it it can be done with custom_rule values.

Proposed approach is to only show the enabled forms, PLUS special logic to show Move-in Date, DOE, and PATH status if there is data that would otherwise be hidden.

"Bug" Reproduction:

• Add and publish second form that collects Move-in Date. Don't add any rules to enable it.
• Previous Behavior Move-in date is duplicated on all Enrollment Dashboards. It shows up once per form.
• New Behavior the new move-in date form doesn't appear unless specified

Scenarios requiring this change:

• Multiple move-in forms (hypothetical)
  • Project type X collects Move-in Date using form A which has a required move-in address on it
  • Project type Y collects Move-in Date using form B which does not have move-in address on it
• Multiple occurrence point forms that collect/display current_unit (https://github.com/open-path/Green-River/issues/7093)
  • One form is read-only, used for most projects
  • One form allows anyone to edit, used for certain projects

Type of change

Bug fix

Checklist before requesting review

• I have performed a self-review of my code
• I have run the code that is being changed under ideal conditions, and it doesn't fail
• If adding a new endpoint / exposing data in a new way, I have:
• Any major architectural changes are supported by an approved ADR (Architectural Decision Record)
• I have updated the documentation (or not applicable)
• I have added spec tests (or not applicable)
• I have provided testing instructions in this PR or the related issue (or not applicable)

[ttoomey]

looks reasonable to me, thanks!

[ttoomey]

This is fine; it's consistent with how the other models. But the Enrollment class is getting kind of big (550 lines). I wonder if this might be an opportunity to extract this into some kind of single-purpose service class

class Enrollment 
  #...
  def occurrence_point_forms
    OccurrencePointFormCollection.new(self).all
  end
end

class OccurrencePointFormCollection
  def initialize(enrollment)
    @enrollment = enrollment
  end

  def all =  active_forms + legacy_forms

  def active_forms
    definitions = Hmis::Form::Definition
      .with_role(:OCCURRENCE_POINT)
      .published_or_retired
      .latest_versions
    # definitions.map ...
  end

  def legacy_forms
    #...
  end
end

[gigxz]

Thanks for the suggestion and snippet @ttoomey, I updated this to use a class. Both the Enrollment and Project occurrence point form function logic are moved into it

[ttoomey]

This looks great, thanks for the restructure!