Browse Source

Merge a2e4481350 into e079455f65

pull/3151/merge
Katherine Langford 6 days ago committed by GitHub
parent
commit
cfdec4ffa2
No known key found for this signature in database
GPG Key ID: B5690EEEBB952194
  1. 5
      docs/Gemfile
  2. 4
      docs/Gemfile.lock
  3. 2
      docs/adr/index.md
  4. 8
      docs/dev_tasks/index.md
  5. 179
      docs/dev_tasks/new_question.md
  6. 2
      docs/documentation_website.md
  7. 48
      docs/form/page.md
  8. 156
      docs/form/question.md
  9. 20
      docs/setup.md

5
docs/Gemfile

@ -7,3 +7,8 @@ end
group :development do group :development do
gem "webrick" gem "webrick"
end end
# used to be in standard library
gem "base64"
gem "bigdecimal"
gem "csv"

4
docs/Gemfile.lock

@ -26,6 +26,7 @@ GEM
commonmarker (0.23.10) commonmarker (0.23.10)
concurrent-ruby (1.3.6) concurrent-ruby (1.3.6)
connection_pool (3.0.2) connection_pool (3.0.2)
csv (3.3.5)
dnsruby (1.61.9) dnsruby (1.61.9)
simpleidn (~> 0.1) simpleidn (~> 0.1)
drb (2.2.3) drb (2.2.3)
@ -279,6 +280,9 @@ PLATFORMS
x86_64-linux x86_64-linux
DEPENDENCIES DEPENDENCIES
base64
bigdecimal
csv
github-pages github-pages
webrick webrick

2
docs/adr/index.md

@ -1,6 +1,6 @@
--- ---
has_children: true has_children: true
nav_order: 14 nav_order: 15
--- ---
# Architecture decisions # Architecture decisions

8
docs/dev_tasks/index.md

@ -0,0 +1,8 @@
---
has_children: true
nav_order: 14
---
# Common dev tasks
A collection of guides for tasks that may have to be carried out repeatedly.

179
docs/dev_tasks/new_question.md

@ -0,0 +1,179 @@
---
parent: Common dev tasks
nav_order: 1
---
# New Questions
Concerns adding a brand-new question to Lettings Logs or Sales Logs. This question will appear on the website as part of the form and should be handled in Bulk Uploads. It will be exported as either a CSV download for users or XML export for automated ingestion by downstream users.
Guide is up-to-date as of 2026.
## Basic checklist of tasks
### 1. Create a migration to add the new field to the database
This allows the answer to the new question to be saved.
You can create a new empty migration file from the terminal if you are in the root of the project:
```
bin/rails generate migration NameOfMigration
```
The new migration file will be saved in `db/migrate`.
Whilst the specifics will vary, the new migration file should look something like this:
```ruby
class AddSexRegisteredAtBirthToSalesLogs < ActiveRecord::Migration[7.2]
def change
# Add a new column called "name" of type string to the sales_logs table
change_table :sales_logs, bulk: true do |t|
t.column :name, :string
end
end
end
```
See also: [Active record migrations](https://guides.rubyonrails.org/active_record_migrations.html)
### 2. Run the new migration
`bundle exec rake db:migrate`
This will update `schema.rb`. You should not edit `schema.rb` directly.
### 3. Create a new question class
This will define the question that gets rendered on the online form.
Existing question classes can be found in `app/models/form/<log type>/questions/`. Depending on the type of question (checkboxes, radio groups, free-text fields), there will almost certainly be an existing question class that you can refer to as a guide.
For example, if you need to create a new radio form, then you may want to copy `armed_forces.rb`.
Sometimes a question will appear in multiple places in the form, or have multiple similar forms. Historically on CORE we'd make a different question class for each, but now we think it's more maintainable to add a small amount of logic to the question to make it dynamic.
See also: [Question]({% link form/question.md %})
### 4. Create a new page class
This creates the page that your new question will be rendered on.
Existing page classes can be found in `app/models/form/<log type>/pages`.
Usually there is only one question per page, but in some cases there may be multiple. It may not be necessary to create a new page if the new question is being added to an existing one.
See also: [Page]({% link form/page.md %})
### 5. Add new page to an existing subsection
Without this step, your new page will not be inserted into the form!
Subsections can be found in `app/models/form/<log type>/subsections`.
You will want to add your new page to the appropriate place in the list returned by `def pages`.
To make your new page only appear in the forms for the upcoming year, you wrap the page class in parentheses and add a conditional expression to the end, like so:
```ruby
(Form::Sales::Pages::SexRegisteredAtBirth1.new(nil, nil, self) if form.start_year_2026_or_later?),
```
Note: the `@id` attribute of a page is what will be displayed in the url when visiting it. It must be unique within a collection year (i.e. two pages in 25/26 cannot share an ID, but two pages in different collection years can share an ID).
Do not use a `depends_on` block for showing a page on a specific year.
### 6. Update the locale file
The locale files define some of the text for the new question, including hints and the question itself.
Locale files can be found in `config/locales/forms/<year>/<log type>/` and there is one locale file for each form subsection.
Copy the entry for an existing question and substitute in the text for your new one.
The locale config for a question by default is laid out like `en.forms.\<year>.\<form type>.\<subsection>.\<page id>`. We assume 1 question per page. If there is more than one question per page you will need to add these as subsections in the page locale and set up a custom <code>@copy_key</code> property in the constructor.
### 7. Add validations
Add validation methods to the appropriate file. For example `app/models/validations/<subsection>_validations.rb` or `app/models/validations/sales/<subsection>_validations.rb` for sales. Any method in these files with a name starting `validate` will be automatically called. Adding an error to the record (log) will show an error on the frontend and the BU.
An error is added by calling `record.errors.add :<question id>, I18n.t("validations.<validation key>")`. You'll need to add the key where appropriate to the relevant locale file inside `config/locales/validations/...`.
Make sure to add errors to all relevant question IDs that can trigger the error. Note that questions on CORE can be answered in any order and amended at will so you cannot make assumptions on order of questions answered. CORE uses the question ID to show the error to the user on the page. If you don't add errors to all relevant question IDs, the user will not see an error but not be able to submit.
### 8. Include the new field in exports
The fields that get exported in CSVs and XMLs are defined in `app/services/exports/\<log type>_log_export_constants.rb`.
If there is not a set for `YEAR_<year>_EXPORT_FIELDS`, create one. Add your new field to the current year's set.
You may also have to update the `<log type>_log_export_service.rb` to correctly filter the year-specific fields.
### 9. Update the bulk upload parser
This will allow bulk upload files to save the new field to the database.
You can find the relevant file at `app/services/bulk_upload/<log type>/year<year>/row_parser.rb`.
If doing this work during yearly rebuild, add this new field as the last field in the file. It's much easier to have a single task at the end to correct all the field numbers.
You will need to add a new `field_XXX` for the new field. In total, update the following places:
- Add the new field to `QUESTIONS` with the text of the question.
- Add a new attribute alongside the existing ones neat the top of the file:
```ruby
attribute :field_XXX, :type
```
- Add the new field to `field_mapping_for_errors` with the name of the field in the database.
- Add the new field to `attributes_for_log` with the name of the field in the database.
- If the field needs to be case-insensitive, add to `CASE_INSENSITIVE_FIELDS`.
You may also have to add some additional validation rules in this file.
We should try and keep validations in the BU few, and leave to validations on the log which you set up earlier. Only add validation specific to the csv format. For instance, validating the input format where we allow "R".
Validation for ensuring that the value uploaded is one of the permitted options is handled automatically, using the question class as the original source of truth.
Make sure that if a value fails a BU validation, then a valid value is not written to the log in the `attributes_for_log` method. If a BU produces a log that is 'complete', all errors will be ignored. Errors on fields the log considers 'valid' are ignored. So, you must make sure the log is incomplete for the user to see the error report. Normally you'll do this intuitively as invalid fields will mean you won't have a valid value.
You'll also need to update the field count in `app/services/bulk_upload/<log type>/year<year>/csv_parser.rb`, as well as the `cols` method.
### 10. Update unit tests
- Create new test files for any new classes you have created. Update any test files for files that you have edited.
- Update `spec/fixtures/variable_definitions/sales_download_25_26.csv` (for sales/lettings and for the relevant collection year) with the new question's field name and definition.
### 11. Update factory file
In `spec/factories` there are a series of factory files. These generate populated objects for use in tests. We also use them on CORE for the buttons that generate completed logs.
You will need to update the factory file for the relevant log type to include the new field. Don't worry about gating it to be year specific, old year questions will be ignored.
### 12. Update reference example BU file
In `spec/fixtures/files` we keep a sample BU file for a range of years and both log types. This gives us a fixed reference for a valid BU file. Make sure to update this and test that you can upload it locally.
### 13. Update auto generated example BU file
In the `app/helpers_bulk_upload/<log type>_log_to_csv.rb` file we maintain functions that convert a log into a BU file. This is used by tests and by the button on CORE to download an example BU file.
Make sure that this file is updated to include the new field in the relevant `to_<year>_row` method. You don't need to update the field numbers.
If you're adding a new method for this year, copy paste the previous year's row method. This'll avoid some nasty merge conflicts down the line.
Make sure you can download this test file and then upload it again.
### 14. Check the CSV download service
Users are able to download CSV exports of logs. This is handled by `app/services/csv/<log type>_log_csv_service.rb`. It should automatically include the new field, but worth checking locally that you're happy with both the codes and labels download.
### 15. Add test CSV export definitions
In `spec/fixtures/variable_definitions` there are a series of CSV files that define the names of fields. These are normally set in the UI by CORE but to make our tests more authentic we maintain labels for use in the tests.
If making one for the new year, just add a new file in that folder. The CSV export tests will pick it up automatically.
### 16. Check log export service
We export an XML representation of all logs made that day nightly. This is handled by `app/services/exports/<log type>_log_export_service.rb`. It should automatically include the new field, though make sure the spec file for this service passes. You will need to update `apply_cds_transformation` if the column name requested in the export doesn't match the database.

2
docs/documentation_website.md

@ -1,5 +1,5 @@
--- ---
nav_order: 15 nav_order: 16
--- ---
# This documentation website # This documentation website

48
docs/form/page.md

@ -11,32 +11,11 @@ Pages sit below the [`Subsection`](subsection) level of a form definition.
An example page might look something like this: An example page might look something like this:
``` ```
class Form::Sales::Pages::PropertyPostcode < ::Form::Page class Form::Sales::Pages::SomePage < ::Form::Page
def initialize(id, hsh, subsection) def initialize(id, hsh, subsection)
super super
@id = property_postcode @id = "some_page"
@depends_on = [{ "needstype" => 1 }] @depends_on = [{ "needstype" => 1 }, { "age#{@person_index}" => { "operator" => "<", "operand" => 16 } }]
@title_text = {
"translation": "translation1",
"arguments": [
{
"key": "some_general_field",
"label": true,
"i18n_template": "template1"
}
]
}
@informative_text": {
"translation": "translation2",
"arguments": [
{
"key": "some_currency_method",
"label": false,
"i18n_template": "template2",
"currency": true,
}
]
}
end end
def questions def questions
@ -56,3 +35,24 @@ The description is optional but if provided is used for a paragraph displayed un
It’s worth noting that like subsections a page can also have a `depends_on` which contains the set of conditions that must be met for the section to be accessible to a data provider. If the conditions are not met then the page is not routed to as part of the form flow. The `depends_on` for a page will usually depend on answers given to questions, most likely to be questions in the setup section. In the above example the page is dependent on the answer to the `needstype` question being `1`, which corresponds to picking `General needs` on that question as displayed to the data provider. It’s worth noting that like subsections a page can also have a `depends_on` which contains the set of conditions that must be met for the section to be accessible to a data provider. If the conditions are not met then the page is not routed to as part of the form flow. The `depends_on` for a page will usually depend on answers given to questions, most likely to be questions in the setup section. In the above example the page is dependent on the answer to the `needstype` question being `1`, which corresponds to picking `General needs` on that question as displayed to the data provider.
Pages can contain one or more [questions](question). Pages can contain one or more [questions](question).
## Useful Properties
<dl>
<dt>id</dt>
<dd>
The name of the field. This should correspond to a column in the database. In the example, the id is 'ppcodenk'.
<br>
Note page IDs must be unique. If not unique, you may run into issues where the next page function will have a stack overflow exception. This is true if using `depends_on` blocks to hide/show pages. You can however reuse page names if using ternary or if conditions to dynamically add pages to a subsection. We only do this for year specific pages on CORE, so page IDs don't have to be unique across all years.
<br>
A potential issue you may see is if you accidentally set the page ID to null, the code to register all the page routes will try to register a nil route, which will set it to the root path for a log. This means you'll get a strange error on the log summary page.</dd>
<dt>depends_on</dt>
<dd>
Pages can have a `depends_on` which contains the set of conditions that must be met for the page to be accessible. It is specified as a hash from properties of a log to conditions.
<br>
A condition can be a single value that must equal the property or a hash of comparisons. Multiple conditions in a single hash work as 'AND' conditions. Multiple hashes work as 'OR' conditions.
<br>
If the conditions are not met then the page is not routed to as part of the form flow. In the above example the page is dependent on picking `General needs` on the `needstype` question, or age being 16+.</dd>
<dt>questions</dt>
<dd>Array of questions to show on the page.</dd>
</dl>

156
docs/form/question.md

@ -6,81 +6,145 @@ nav_order: 4
# Question # Question
_Updated for 2026._
Questions are under the page level of the form definition. Questions are under the page level of the form definition.
An example question might look something like this: An example question might look something like this:
``` ```ruby
class Form::Sales::Questions::PostcodeKnown < ::Form::Question class Form::Sales::Questions::PreviousPostcodeKnown < ::Form::Question
def initialize(id, hsh, page) def initialize(id, hsh, page)
super super
@id = postcode_known @id = "ppcodenk"
@hint_text = "" @copy_key = "sales.household_situation.last_accommodation.ppcodenk"
@header = "Do you know the property postcode?"
@check_answer_label = "Do you know the property postcode?"
@type = "radio" @type = "radio"
@answer_options = { @answer_options = ANSWER_OPTIONS
"1" => { "value" => "Yes" },
"0" => { "value" => "No" }
},
@conditional_for = { @conditional_for = {
"postcode_full" => [1] "ppostcode_full" => [0],
}, }
@hidden_in_check_answers = true @hidden_in_check_answers = {
"depends_on" => [
{
"ppcodenk" => 0,
},
{
"ppcodenk" => 1,
},
],
}
@question_number = QUESTION_NUMBER_FROM_YEAR[form.start_date.year] || QUESTION_NUMBER_FROM_YEAR[QUESTION_NUMBER_FROM_YEAR.keys.max]
@disable_clearing_if_not_routed_or_dynamic_answer_options = true
end end
ANSWER_OPTIONS = {
"0" => { "value" => "Yes" },
"1" => { "value" => "No" },
}.freeze
QUESTION_NUMBER_FROM_YEAR = { 2023 => 57, 2024 => 59, 2025 => 57 }.freeze
end end
``` ```
In the above example the the question has the id `postcode_known`. ## Useful Properties
The `check_answer_label` contains the text that will be displayed in the label of the table on the check answers page. <dl>
<dt>id</dt>
<dd>The name of the field. This should correspond to a column in the database. In the example, the id is 'ppcodenk'.</dd>
The header is text that is displayed for the question. <dt>copy_key</dt>
<dd>This specifies copy from <code>config/locales/forms/...</code> that should be associated with the question. Not normally needed, will be inferred as <code>#{form.type}.#{subsection.copy_key}.#{id}</code>.</dd>
Hint text is optional, but if provided it sits under the header and is normally given to provide the data inputters with guidance when answering the question, for example it might inform them about terms used in the question. <dt>type</dt>
<dd>Determines what type of question is rendered on the page. In the example, the question is a Radio Form so the <code>app/views/form/_radio_question.html.erb</code> partial will be rendered on the page when this question is displayed to the user</dd>
The type is question type, which is used to determine the view rendered for the question. In the above example the question is a radio type so the `app/views/form/_radio_question.html.erb` partial will be rendered on the page when this question is displayed to the user. <dt>answer_options</dt>
<dd>Some types of question offer multiple options to pick from, which can be defined here. In the example, there are two options. The option that will be rendered with the label 'Yes' has the underlying value 0. The option with the label 'No' has the underlying value 1.</dd>
The `conditional_for` contains the value needed to be selected by the data inputter in order to display another question that appears on the same page. In the example above the `postcode_full` question depends on the answer to `postcode_known` being selected as `1` or `Yes`, this would then display the `postcode_full` underneath the `Yes` option on the page, allowing the provide the provide the postcode if they have indicated they know it. If the user has JavaScript enabled then this realtime conditional display is handled by the `app/frontend/controllers/conditional_question_controller.js` file. <dt>conditional_for</dt>
<dd>Allows for additional questions to be rendered on the page if a certain value is chosen for the current question. In the example, if the value of this question is 0 (the 'Yes' option is selected), then the question with id 'ppostcode_full' will be rendered beneath the selected option.<br/>If the user has JavaScript enabled then this realtime conditional display is handled by the <code>app/frontend/controllers/conditional_question_controller.js</code> file.</dd>
the `hidden_in_check_answers` is used to hide a value from displaying on the check answers page. You only need to provide this if you want to set it to true in order to hide the value for some reason e.g. it's one of two questions appearing on a page and the other question is displayed on the check answers page. It's also worth noting that you can declare this as a with a `depends_on` which can be useful for conditionally displaying values on the check answers page. For example: <dt>hidden_in_check_answers</dt>
<dd>
Allows us to hide the question on the 'check your answers' page. You only need to provide this if you want to set it to true in order to hide the value for some reason e.g. it's one of two questions appearing on a page and the other question is displayed on the check answers page.
<br/>
If <code>depends_on</code> is supplied, then whether this question is hidden can be made conditional on the answers provided to any question. In the example, the question is hidden if 'ppcodenk' (this question) has value 0 or 1. (As these are the only two possible answers, the question will always be hidden.)
</dd>
``` <dt>question_number</dt>
@hidden_in_check_answers = { <dd>
"depends_on" => [ Determines which number gets rendered next to the question text on the question page and in the 'check your answers' page.
{ "age6_known" => 0 }, <br/>
{ "age6_known" => 1 } The convention that we use for the question number is that the hash should contain all years explicitly, even if it doesn't change between years. When building a new year's forms we should add the question number for the new year to all questions. See the `add_new_year_to_questions` rake.
] </dd>
}
```
Would mean the question the above is attached to would be hidden in the check answers page if the value of age6_known is either `0` or `1`. <dt>disable_clearing_if_not_routed_or_dynamic_answer_options</dt>
<dd>
Questions that are not routed to will be cleared. Setting this to true will prevent this from happening. Normally can be replaced with implementing <code>derived?</code>.
</dd>
The answer the data inputter provides to some questions allows us to infer the values of other questions we might have asked in the form, allowing us to save the data inputters some time. An example of how this might look is as follows: <dt>check_answers_card_number</dt>
<dd>
Is used only for the household characteristics section as each person gets their own card on the CYA page. If you're looking to add a custom CYA card somewhere else in the form, see <code>check_answers_card_title</code>
</dd>
``` <dt>check_answers_card_title</dt>
class Form::Sales::Questions::PostcodeFull < ::Form::Question <dd>
If set to non nil, on the CYA this question will be put in a box with this title. If multiple questions set the same <code>check_answers_card_title</code>, they will be grouped.
</dd>
</dl>
Another example shows us some fields that are used when we want to infer the answers to one question based on a user's answers to another question. This can allow the user to have to answer fewer questions, lowering their total number of clicks.
```ruby
class Form::Sales::Questions::PostcodeForFullAddress < ::Form::Question
def initialize(id, hsh, page) def initialize(id, hsh, page)
super super
@id = postcode_full @id = "postcode_full"
@hint_text = "" @inferred_check_answers_value = [{
@header = "What is the property’s postcode?"" "condition" => {
@check_answer_label = "Postcode"" "pcodenk" => 1,
@type = "text" },
@width = 5 "value" => "Not known",
}]
@inferred_answers = { @inferred_answers = {
"la" => { "is_la_inferred" => true } "la" => {
"is_la_inferred" => true,
},
} }
@inferred_check_answers_value => [{ # Other fields omitted for brevity
"condition" => { "postcode_known" => 0 },
"value": "Not known"
}]
end end
end end
``` ```
In the above example the width is an optional attribute and can be provided for text type questions to determine the width of the text box on the page when when the question is displayed to a user (this allows you to match the width of the text box on the page to that of the design for a question). <dl>
<dt>inferred_check_answers_value</dt>
<dd>Determines what gets shown on the 'check your answers' page if we infer the answer to this question. In the example, if the question 'pcodenk' has value 1 (indicating that the postcode is not known), then the answer shown for this question will be 'Not known'.</dd>
<dt>inferred_answers</dt>
<dd>Determines any questions whose answers can be inferred based on the answer to this question. In the example, the 'la' question (Local Authority) can be inferred from the Postcode. We set a property 'is_la_inferred' on the log to record this inferrance.</dd>
</dl>
## Useful methods
<dl>
<dt>derived?</dt>
<dd>This is function that should return true if the question is to be derived, such as where it's answer can be inferred based on another question. Setting this to true will cause the question to not be shown in CYA. The user will still be shown the question. This method is very similar to a depends_on method, but a depends_on block is used to always infer an answer of "". derived? is reliant on other code setting the answer, such as <code>set_derived_fields!</code></dd>
<dt>get_extra_check_answer_value</dt>
<dd>Used for putting extra lines below the main answer in the CYA page. Used on the address search to show the full address below the UPRN</dd>
<dt>label_from_value</dt>
<dd>Used for custom labels that differ from the main site. Normally will use the labels on the page, Useful for instance changing "No, enter xyz" to just "No".</dd>
<dt>skip_question_in_form_flow?</dt>
<dd>Similar to derived, but the user is still able to go back and edit the question later. Will not cause question to be hidden from CYA.</dd>
</dl>
## Question visibility
The above example links to the first example as both of these questions would be on the same page. The `inferred_check_answers_value` is what should be displayed on the check answers page for this question if we infer it. If the value of `postcode_known` was given as `0` (which is a no), as seen in the condition part of `inferred_check_answers_value` then we can infer that the data inputter does not know the postcode and so we would display the value of `Not known` on the check answers page for the postcode. There are broadly 3 reasons to hide a question. Here's how to handle them.
In the above example the `inferred_answers` refers to a question where we can infer the answer based on the answer of this question. In this case the `la` question can be inferred from the postcode value given by the data inputter as we are able to lookup the local authority based on the postcode given. We then set a property on the lettings log `is_la_inferred` to true to indicate that this is an answer we've inferred. 1. The question should not be asked, answer should be derived as nil and user should not be able to change this. If so, set up a `depends_on` on the page.
2. The question should not be asked, answer should be derived as some value and user should not be able to change this. If so, set up a `depends_on` on the page and set up a `derived?`. Use a method like `set_derived_fields!` to set the answer.
3. The question should not be asked, answer should be derived as some value and user should be able to change this. If so, set up a `skip_question_in_form_flow?` method.

20
docs/setup.md

@ -18,6 +18,14 @@ We recommend using [RBenv](https://github.com/rbenv/rbenv) to manage Ruby versio
We recommend using [nvm](https://github.com/nvm-sh/nvm) to manage NodeJS versions. We recommend using [nvm](https://github.com/nvm-sh/nvm) to manage NodeJS versions.
## Instructions for Windows users
If you are working on a windows machine, you will want to install the tools on [WSL](https://learn.microsoft.com/en-us/windows/wsl/install) as some of them are not native to windows. The instructions in these docs assume a Debian-based distribution, such as Ubuntu.
_You will see a significant performance degradation if you are running the server on WSL whilst the files are on windows._ Thus, make sure to clone the repository into your WSL instance.
Some windows IDEs, such as [VSCode](https://code.visualstudio.com/docs/remote/wsl) and [RubyMine](jetbrains.com/help/ruby/remote-development-starting-page.html#run_in_wsl_ij) can connect you to WSL, which will allow you to develop as though the files were on the local windows filesystem. Ignore any reccommendations that you might see suggesting you keep the files on windows - our experience is that both tests and page loads are much slower when the files are on windows.
## Pre-setup installation ## Pre-setup installation
1. Install PostgreSQL 1. Install PostgreSQL
@ -106,9 +114,17 @@ We recommend using [nvm](https://github.com/nvm-sh/nvm) to manage NodeJS version
sudo mv geckodriver /usr/local/bin/ sudo mv geckodriver /usr/local/bin/
``` ```
Also ensure you have firefox installed Also ensure you have firefox installed
7. Install libyaml-dev if on Linux
Linux (Debian):
```bash
sudo apt install -y libyaml-dev
```
7. Clone the repo 8. Clone the repo
```bash ```bash
git clone https://github.com/communitiesuk/submit-social-housing-lettings-and-sales-data.git git clone https://github.com/communitiesuk/submit-social-housing-lettings-and-sales-data.git

Loading…
Cancel
Save