Skip to content
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

LTD: Imrove validation during submission #2337

Open
wants to merge 19 commits into
base: dev
Choose a base branch
from

Conversation

saruniitr
Copy link
Contributor

@saruniitr saruniitr commented Dec 9, 2024

Change description

We validate several things when a draft application is submitted. The current code assumes only one end-user which is not going to be the case for SIEL Temporary applications.

Before changing the code the idea is to simplify the current validation code. This is also not updated with the new fields that we added to the model. This PR doesn't add any new changes except that it simplifies validation.

Once this is merged then further changes will be done to allow for multiple end-users.

@saruniitr saruniitr marked this pull request as draft December 9, 2024 13:04
@@ -42,3 +42,20 @@ class Trackable:

def get_history(self, field):
raise NotImplementedError()


class BaseApplicationValidator:
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I assume this is general enough that it could be used for other licence types than just SIELs (e.g. OIELs)?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

yes

@saruniitr saruniitr marked this pull request as ready for review December 9, 2024 17:33
Current code sorting the results based on first key in the results but for
one of the test this is same for all rows so randomly it sorts by different
order and causing the test to fail. Update the test to sort by all keys
so we have a consistent order.
from api.parties.models import PartyDocument


def siel_locations_validator(application):
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

there are a couple of differences in the checks between this function and the original _validate_siel_locations, is that because they are not needed and so they can be removed?

Copy link
Contributor Author

@saruniitr saruniitr Dec 10, 2024

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

yes, there was a check related to GoodsTypeCategory.CRYPTOGRAPHIC which is for OIELs and we don't support yet. When we support it will be in a different method as this is only for SIELs

@@ -268,12 +268,17 @@ def set_appealed(self, appeal, exporter_user):
self.set_sub_status(CaseSubStatusIdEnum.UNDER_APPEAL__APPEAL_RECEIVED)
self.add_to_queue(Queue.objects.get(id=QueuesEnum.LU_APPEALS))

def validate(self):
raise NotImplementedError("Validator to validate application attributes is not implemented")
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

nice

Copy link
Contributor

@hnryjmes hnryjmes left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I'm wondering if we can get this branch deployed to an env and have someone from UCD click around and do a few submissions as a regression test. Just because there's a lot changing here

@saruniitr
Copy link
Contributor Author

I'm wondering if we can get this branch deployed to an env and have someone from UCD click around and do a few submissions as a regression test. Just because there's a lot changing here

@hnryjmes Verified these changes on devdata and compared with uat at the same time. In both cases the errors messages shown for the items in application task list is same. As the sections are filled then the errors are no longer shown.

Comment on lines +33 to +34
if not application.end_user:
return "To submit the application, add an end user"
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

it seems like this should be at the top, before the check for export type being temporary?

Comment on lines +91 to +104
def siel_ultimate_end_users_validator(application):
"""If ultimate end users are required and they added any documents check if they are all valid"""
error = None
if not application.end_user:
return "To submit the application, add an end user"

ultimate_end_user_required = application.goods.filter(
Q(is_good_incorporated=True) | Q(is_onward_incorporated=True)
).exists()

if ultimate_end_user_required and application.ultimate_end_users.count() == 0:
error = "To submit the application, add an ultimate end-user"

return error
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

should there be a check for ultimate end user documents here?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Copy link
Contributor

@hnryjmes hnryjmes left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

have checked all the validators and they look right to me by eye. if we can get product review from UCD on this later that would give us extra confidence but it looks to me like everything has been copied over correctly.

def create_amendment(self, user):
raise NotImplementedError()


# Licence Applications
class StandardApplication(BaseApplication, Clonable):
from api.applications.validators import StandardApplicationValidator
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Does this import need to be here?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

actually added this to avoid circular dependencies but they are not there atm, I will move this outside of this.

and application.goods_recipients not in recipient_choices
and application.is_shipped_waybill_or_lading is None
):
return "To submit the application, add a product location"
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

It would be good to discuss; should the API validation errors be returned as end-user readable strings or as lite-frontend consumable error keys?

class StandardApplicationValidationErrors:
    MISSING_PRODUCT_LOCATION = "MISSING_PRODUCT_LOCATION"
...

return StandardApplicationValidationErrors.MISSING_PRODUCT_LOCATION

I feel a bit like this is a similar muddying of the API that we currently have for audit trail text formatting; the API does some text formatting rather than just responding with pure data. That means when changing the format of audit trail messages, we always have to do work on the API rather than just adjusting the frontend.

Similarly for this, the API is getting unnecessarily tied to frontend structures/wording. Instead, the frontend could translate the error key in to the user readable string. Or have the freedom to do bullet points instead e.g.


To submit the application:
- Add a product location <a href="/place_to_fix_it">Here</a>
- Add an end user

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Definitely worth considering, initially I only want to get parity with the current functionality. Once this is merged the add further improvements.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants