-
Notifications
You must be signed in to change notification settings - Fork 14
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Introduce Address answer type #261
Conversation
"autosuggest":{ | ||
"label": { | ||
"text": _("Enter address or postcode and select from results") | ||
}, | ||
}, |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This was added because the DS component requires this at the moment. This bug will be fixed in the DS soon.
tests/app/test_jinja_filters.py
Outdated
@@ -17,6 +17,7 @@ | |||
map_list_collector_config, | |||
RadioConfig, | |||
CheckboxConfig, | |||
get_formatted_address, |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
These imports should be sorted
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Again we need to add a linter for things like this (if possible) if we are to enforce. But I have updated anyway 👍
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thanks - I am in the process of adding a card to integrate isort
to our linting and make it compatible with Black
@JamesGardiner All comments should now be addressed. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Works as expected, a few minor comments
|
||
return validate_with | ||
|
||
def get_field(self) -> AddressField: |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
get_address_field?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
get_field
because it is overriding the abstract base class method.
app/forms/fields/address_field.py
Outdated
|
||
from wtforms import Form, FormField, StringField | ||
|
||
logger = logging.getLogger(__name__) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Couldn't see where this is used
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Not used explicitly but defined to ensure the logger logs errors with the correct module name. This is a common pattern across runner.
@@ -216,13 +216,23 @@ def update_answers(self, form_data, list_item_id=None): | |||
for answer_id, answer_value in form_data.items(): | |||
|
|||
if answer_id in answer_ids_for_question: | |||
if answer_value not in self.EMPTY_ANSWER_VALUES: | |||
answer_value_to_store = ( |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Not 100% sure what this is doing, looks to me if answer_value is a dict make another dict with all the empties removed. Then check it's not completely empty at a later stage?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This is just filtering out any EMPTY_ANSWER_VALUES
when the answer is a dict i.e address since we don't store any answers that match EMPTY_ANSWER_VALUES
.
…onnaire-runner into address-answer-type
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
As discussed, we should be testing the summary output for no address answer (optional address), and I've asked Andy about whether address line 1 should be mandatory for optional addresses (if they fill in at least one address field).
…onnaire-runner into address-answer-type
Have updated schema/tests for optional version. |
What is the context of this PR?
For context see: #241
Introduced a new answer type to support address answers in runner.
This introduces a new data model for storing address answers:
How to review
Note:
Checklist