* 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
* test: update no. of pages
* feat: remove text input for Other option
* feat: update schema
It's possible that this method returns true despite not having an `inferred_check_answers_value` set. This is an obvious smell that we will return to fix.
* feat: core functionality
* feat: update schema.rb
* feat: add link for privacy notice, refactor to separate tenant/buyer
* feat: make privacy notices open in new tab
* test: make previous tests pass
* test: add new tests
* 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 shared ownership type question and page
* Add type column to the sales logs table
* Add ownership scheme field to db
Isolating this into a separate commit so it can be cherry picked for any
other sales logs work that's necessary.
* Fix tests
* fix a test
* Fix typo
* Set default time for form handler
Co-authored-by: Dushan Despotovic <dushan@madetech.com>
* Add previous, current and next forms to form handler
* Add current, previous and next sales forms to form handler
* Implement current_lettings_form, current_sales_form and store year and form type in form
* refactor lettings_forms
* Use current, previous and next forms in lettings log model
* Use current, previous and next forms in sales log model
* use current, previous and next forms in csv service
* Remove "startyear_endyear" forms from form handler
* Remove name from form initializer and add an optional start year
* refactor get_form
* update csv test, fix form initialize
* rebase fix
* Refactor form_name_from_start_year method out
* remove unused variable
* fix typo, add date tests
* rebase, fix tests
* add comment to before test block
* Change the FormHandler back to only contain the form objects
* extract name
* 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>
Jack S
natdeanlewissoftwire
Sam
James Rose
kosiakkatrina
Dushan
Ted-U
baarkerlounger
natdeanlewissoftwire