Skip to content

Conversation

@Akol125
Copy link
Contributor

@Akol125 Akol125 commented Nov 11, 2025

Summary

  • Routine Change
  • ❗ Breaking Change
  • 🤖 Operational or Infrastructure Change
  • ✨ New Feature
  • ⚠️ Potential issues that might be caused by this change

Add any other relevant notes or explanations here. Remove this line if you have nothing to add.

Reviews Required

  • Dev
  • Test
  • Tech Author
  • Product Owner

Review Checklist

ℹ️ This section is to be filled in by the reviewer.

  • I have reviewed the changes in this PR and they fill all of the acceptance criteria of the ticket.
  • If there were infrastructure, operational, or build changes, I have made sure there is sufficient evidence that the changes will work.
  • If there were changes that are outside of the regular release processes e.g. account infrastructure to setup, manual setup for external API integrations, secrets to set, then I have checked that the developer has flagged this to the Tech Lead as release steps.
  • I have checked that no Personal Identifiable Data (PID) is logged as part of the changes.

@github-actions
Copy link
Contributor

This branch is working on a ticket in the NHS England VED JIRA Project. Here's a handy link to the ticket:

VED-909

@Akol125 Akol125 changed the title start uplift schema ticket2 VED-909-Uplift-Schema-Expression-Rule Nov 12, 2025
@Akol125 Akol125 changed the title VED-909-Uplift-Schema-Expression-Rule VED-909: Uplift Schema Expression Rule Nov 12, 2025
@sonarqubecloud
Copy link

Copy link
Contributor

@JamesW1-NHS JamesW1-NHS left a comment

Choose a reason for hiding this comment

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

just a few issues.

NB: though the operation of the validator is dependent on fields in the schema, we're not testing explicitly for an error when checking a field that we know is not present in the schema. test_postcode_string_rule_valid_and_invalid() sort of does it (with field_path = POST_CODE) but it's by accident rather than on purpose.

I assume that we expect the FHIR validator to deal with those?

Copy link
Contributor

Choose a reason for hiding this comment

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

Where are these schema files used?

Copy link
Contributor Author

Choose a reason for hiding this comment

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

these files would be used as schema files per environment, not populated yet as it is meant to be used when we have a fully functional schema that we can use per environment,

Copy link
Contributor

Choose a reason for hiding this comment

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

Where is this file used?

Copy link
Contributor Author

Choose a reason for hiding this comment

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

same

expression_values = data_parser.extract_field_values(expression_fieldname)
print(f"Validating Expression ID {expression_fieldname} with values: {expression_values}")
except Exception as e:
message = f"Data get values Unexpected exception [{e.__class__.__name__}]: {e}"
Copy link
Contributor

Choose a reason for hiding this comment

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

I'd make the message "Extract Field Values: Unexpected exception ..." - it's better English and more consistent with the function naming

Copy link
Contributor Author

Choose a reason for hiding this comment

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

for testing but would ultimatelty remove it eventually

row += 1
return row
except Exception as e:
message = f"Expression Validation Unexpected exception [{e.__class__.__name__}]: {e}"
Copy link
Contributor

Choose a reason for hiding this comment

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

I'd make the message "Validate Expression: Unexpected exception ..." (see above)

except Exception as e:
message = f"Expression Validation Unexpected exception [{e.__class__.__name__}]: {e}"
error_record = ErrorReport(code=ExceptionLevels.UNEXPECTED_EXCEPTION, message=message)
error_record = ErrorReport(code=ExceptionLevels.PARSING_ERROR, message=message)
Copy link
Contributor

Choose a reason for hiding this comment

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

We're overwriting the error_record written in the previous line.
Do we want to add both of these in add_error_record()?

Copy link
Contributor

Choose a reason for hiding this comment

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

Question: should backend (and later recordprocessor) unit tests also use this schema when creating a Validator?

"9876543210",
)
)
self.assertIsNone(
Copy link
Contributor

Choose a reason for hiding this comment

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

This is a duplicate of lines 28-35

# With empty rule, generic string constraints apply: non-empty and no spaces
self.assertIsNone(checker.validate_expression("STRING", "", field_path, "SW1A 1AA"))
# Real-world postcode with a space should fail as spaces are not allowed without a rule override
field_path = "POST_CODE"
Copy link
Contributor

Choose a reason for hiding this comment

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

I can't see POST_CODE in the test schema anywhere, did you mean PERSON_POSTCODE?

field_path = "contained|#:Patient|address|#:postalCode|postalCode"
# With empty rule, generic string constraints apply: non-empty and no spaces
self.assertIsNone(checker.validate_expression("STRING", "", field_path, "SW1A 1AA"))
# Real-world postcode with a space should fail as spaces are not allowed without a rule override
Copy link
Contributor

Choose a reason for hiding this comment

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

should we then add a test for that e.g.
self.assertIsInstance(
checker.validate_expression("STRING", "PERSON_POSTCODE", field_path, "SW1A 1AA"),
ErrorReport,
)

@dlzhry2nhs
Copy link
Contributor

Work has been paused on this approach. Worth considering closing the PR. Especially if we get a clear outcome from VED-947 which results in us redesigning the approach.

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