* remove Organisation#relationship_type
* add indexes and fk constraints to org relations
* remove relationship_type from seeds
- as these have now been removed
* seeding is now idempotent
* feat: add scheme reactivation behaviour
* test: add tests
* refactor: linting
* fix: find deactivation periods by scheme/location ids rather than just the first
* feat: add activating_soon status to location (not to schemes as they have no startdate field)
* feat: fix logic and add tests fo activating soon
* fix: check for startdate presence
* route deactivated scheme to reactivation page
* Render correct reactivate question content
* refactor into a helper
* display successful reactivation banner for default date
* Save reactivation date
* Add reactivation errors
* lint and fix url in tests
* make toggle translations generic
* Add reactivation status
* Reuse date validation messages
* Show deactivate this location when location is reactivating soon
* Display correct confirmation banner
* Add validation for reactivation date before deactivation date
* Improve availability label
* Use current collection start date if created at is later than that
* Update paths
* Fix controller and don't display the previous day if location availability start afterwards
* refactor availability label
* Filter out active periods
* lint
* Refactor active_period method into the model
* Allow deactivations and reactivations from available from date instead of start of the collection date
* Prevent deactivations during deactivated periods
* lint
* typo
* Remove active periods that last 1 day (because they get deactivated on the same day)
* Move the active_periods into helper
* extract remove_overlapping_and_empty_periods into a separate method
* Remove nested deactivation periods
* Make deactivate/reactvate location form use location_deactivation_period model
* refactor toggle date methods
* extract shared condition
* update validations
* refactor validations
* Update schemes deactivation form to use dectivation model
* Refactor
* lint
* remove redundant location_id and update scheme controller
* update active_periods
* Remove deactivation date from schemes and add scheme deactivation periods table
* Update affected logs when a scheme gets deactivated
* Update status method
* Display availability timeline
* Update flash notice message
These fields are set using IDs from the previous CORE service. There was an incorrect assumption that these fields were integers so we were casting them as such. We have discovered that these fields are strings (e.g., `027`) so this change adjusts our types.
Previous to this change, the `reservist` field mapped `0` to yes and `1` to no. This change adjusts the mapping from `1` to yes, `2` to no, and `3` to prefer not to say.
* wip
* Rename managing_agents column
* add managing relationship
* f
* feat: add my features branched off managing agents branch
* feat: update nav behaviour
* feat: simplify housing_providers view
* feat: fix pluralise to default to plural rather than singular
* feat: remove managing agent related code so can be merged directly
* tests: update tests and add new ones for housing_providers
* refactor: rubocop conciliation
* tests: fix failing navigation tests
* tests: one more plural test
* refactor: erb linting
* refactor: erb linting
* feat: right-align "Remove" text
* feat: update nokogiri to pass bundler-audit
* feat: grey out search button
* feat: remove section-break
Co-authored-by: Jack S <jacopo.scotti@softwire.com>
* feat: add boyer_company page and question (migration still to be committed)
* feat: add migration and updated schema
* feat: update tests (and add housingneeds_type to schema that was previously missing)
* tests: add tests for question and page
* refactor: spacing
* feat: update schema
* feat: add boyer_company page and question (migration still to be committed)
* feat: add migration and updated schema
* feat: update tests (and add housingneeds_type to schema that was previously missing)
* tests: add tests for question and page
* refactor: spacing
* feat: update test
* feat: add boyer_company page and question (migration still to be committed)
* feat: add migration and updated schema
* feat: update tests (and add housingneeds_type to schema that was previously missing)
* tests: add tests for question and page
* refactor: spacing
* feat: add boyer_company page and question (migration still to be committed)
* feat: add migration and updated schema
* feat: update tests (and add housingneeds_type to schema that was previously missing)
* tests: add tests for question and page
* refactor: spacing
* feat: add migration and updated schema
* feat: update tests (and add housingneeds_type to schema that was previously missing)
* feat: add migration and updated schema
* feat: update tests (and add housingneeds_type to schema that was previously missing)
* feat: add migration and updated schema
* feat: update tests (and add housingneeds_type to schema that was previously missing)
* test: update tests
* feat: add buyer 2-1 relationship question and page (migration and schema to come in next commit)
* feat: add buyer 2-1 migration and schema
* feat: update schema
* feat: add depends_on and tests
* feat: add hint text
* tests: add new tests
* refactor: lint appeasing
* Remove an unused ethnic_other column
* remove sale_completion_date from lettings logs
* Add collection start year
* Remove sale_or_letting column
* Rename rent_type to rent_type_detail in the export
* Format dates
* refactor
* Fix test
While migrating users from the previous service to the new one we discovered that email addresses are not unique in the previous service. This means that one user in the new service might relate to multiple users in the previous service.
This change:
- Adds a new LegacyUser model that can belong to a User. Each LegacyUser model has one old_user_id that corresponds to the user ID in the legacy service.
- Updates the user import service so that we create this association for new users
- Creates a Rake script to backfill the association for existing users
* Add abstract log class and sales log class
Created a parent log class for sales log and lettings log. Any bits common
to both sales and lettings can live in the parent class. As the sales log
functionality is built up any commonalities with lettings log can be extracted
into the parent log class. The sales log model is set up without a json form
and instead the form is defined in code - like the setup section of the lettings
log.
* update sales logs controller
* update lettings controller specs
* update filter method name
* update organisations controller
* use lettings method
* Add deleted tests back
* lint
Co-authored-by: Kat <katrina@madetech.com>
Co-authored-by: Kat <kosiak.katrina@gmail.com>
This renames the case_log to lettings_log as everything we've written so
far has been geared towards lettings of social housing so it makes sense to
have the name describe this. This is also a precursor to adding in stuff for
sales logs (whatever shape that takes)
Co-authored-by: James Rose <james@jbpr.net>
kosiakkatrina
Jack S
Phil Lee
natdeanlewissoftwire
James Rose
David May-Miller
Sam
Dushan
Ted-U
baarkerlounger
natdeanlewissoftwire