* feat: update max and add new spec
* feat: update previous years
* feat: combine identical offered questions
* feat: update tests
* feat: add test for property_number_of_times_relet
* Remove bulk_upload_lettings_logs flag
* Add spacing above actions in data sharing agreement
* Add banner
* Add model validation
* fix log component
* Fix factory
* Put validation behind feature flag
* start adapting to data protection confirmation
* Make tests more generic
* Add tests for display_organisation_attributes
* Use data_protection_confirmed? method
* Address code review
* rubocop
* Prevent access to bulk upload pages when DPC not signed
* Address PO review
- As we migrate more organisations onto the service we need to be more conservative.
- This PR removes tracing on healthchecks entirely, whilst lowering everything else from 0.02 to 0.01.
* Add data sharing agreement
* Add data sharing agreement view
* Add controller actions
* Update details page
* Rubocop fix
* Fill in placeholders and persist data in table
* Update agreement template
* Validate that correct template for the year is used for sales (with headers)
* Check the correct template is being used without headers
* Check correct template for lettings
* Update csv parser on sales
* Remove redundant methods
* Extract form years
* Reverse year check mathod
* Remove soft validations from sales setup and make them mandatory
* Remove soft validations from lettings setup and make them mandatory
* Fix remaining tests
* Add card numbers to pregnancy checks
# Context
- https://digital.dclg.gov.uk/jira/browse/CLDC-1732
- data providers are given read-only able access to schemes and locations
# Changes
- introduce `pundit` policies to schemes and locations. the old scope mechanism has been removed
- apply policies at view level so hide write access based functionality from data providers
# Context
- https://digital.dclg.gov.uk/jira/browse/CLDC-2305
- This is rework to add missing validations for sales setup fields for bulk upload
# Changes
- There is code that clears log fields if they are not a valid option. in order to generate errors for these we check certain fields for content prior to `log.valid?` being called. Unfortunately there does not appear to be an easy way to access to valid options therefore these values have been hard coded
- Privacy notice must be accepted other considered a setup error
- The `type` question can actually be one of three questions with the same identifier. these are excluded as part of `validate_valid_radio_option` and instead validated with a different mechanism. The rationale being that `log.valid?` will clear data before we get there
- Remove tests associated to upload threshold which are no longer required
* Do not allow 32 as an option for 22/23 sale type
* Correctly block log creation
* refactor test
* lint
* Add error to the correct field
* Add error as part of validating radio options
* Update row parser null check
* Update permissions and scheme/location views
* Display parent organisation's schemes in the list
* Hide toggle scheme button from child organisation
* Update show location to use user_can_edit_scheme?
* Refactor user_allowed_action?
* remove redundant return
* Clear period if the organisation doesn't charge for that rent period
* Clear layear if it's invalid for renewal
* remove void and mrcdates
* Remove shortfall if larger than rent
* Confirm location after creating
# Context
- We're currently using a custom fork of devise
# Changes
- Switch back to original devise gem
- This gives us the benefit of being able to more easily upgrade when the time comes
- Minor fixes to validation copy during password reset process which were not correct
* add a bespoke validation to the row parser
when buyer 1 is uploaded with working situation child, this should be validated with a custom message.
a test for this case was also created
* replicate the work from the last commit for the 2023 row parser and associated test file
* lint correction remove blank lines
- Previously, when attempting to import a log that already exists in the service, the importers would update its attributes.
- In most situations we don't want this as it could override changes that the user has made to the logs.
- This change adds an option to the log import services to allow this functionality to be toggled.
* call form to reset invalid values when saving a sales log
* fix tests failing after updating sales log functionality to reset invalid answers
* add a test to cover the new functionality added
* a further test