Skip to content

feat(#10038): add PlaceQualifier and related methods #10057

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

Open
wants to merge 5 commits into
base: 9835-add-cht-datasource-apis-for-creation-and-update-of-contacts-and-reports
Choose a base branch
from

Conversation

apoorvapendse
Copy link
Contributor

@apoorvapendse apoorvapendse commented Jun 15, 2025

Description

WIP Pull request to add PlaceQualifier and related validations.

Related: #10038

Code review checklist

  • UI/UX backwards compatible: Test it works for the new design (enabled by default). And test it works in the old design, enable can_view_old_navigation permission to see the old design. Test it has appropriate design for RTL languages.
  • Readable: Concise, well named, follows the style guide, documented if necessary.
  • Documented: Configuration and user documentation on cht-docs
  • Tested: Unit and/or e2e where appropriate
  • Internationalised: All user facing text
  • Backwards compatible: Works with existing data and configuration or includes a migration. Any breaking changes documented in the release notes.

License

The software is provided under AGPL-3.0. Contributions to this project are accepted under the same license.

Comment on lines +362 to +364
if (!parent.parent) {
return Object.keys(parent).length > 1;
}
Copy link
Contributor Author

Choose a reason for hiding this comment

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

This was a case I missed addressing in #10043

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Basically for the final parent.

Copy link
Member

Choose a reason for hiding this comment

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

nice. can you add a comment above this as well for future selves.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

done

@apoorvapendse apoorvapendse marked this pull request as draft June 15, 2025 11:40
@apoorvapendse apoorvapendse force-pushed the place-qualifier branch 2 times, most recently from fd06592 to 4e197c4 Compare June 15, 2025 13:49
@sugat009 sugat009 self-requested a review June 16, 2025 04:55
Comment on lines +362 to +364
if (!parent.parent) {
return Object.keys(parent).length > 1;
}
Copy link
Member

Choose a reason for hiding this comment

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

nice. can you add a comment above this as well for future selves.

*/
export type PlaceQualifier = ContactQualifier & Readonly<{
parent?: NormalizedParent;
contact?: NormalizedParent;
Copy link
Member

Choose a reason for hiding this comment

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

question: Isn't contact supposed to be either a string containing a UUID string or a object that contains the key _id which has the value of a UUID string. Using Identifiable interface would be more appropriate 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.

Yes, I was a bit unclear about this.
But I ended up seeing and following:

readonly contact?: NormalizedParent;

Copy link
Member

Choose a reason for hiding this comment

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

I re-read and re-ran the code for this. I have an explanation for this. It's true that the contact will have a value of string or an object with _id with value string. However, when requesting a place along with it's lineage, the contact object is expected to be a person typed object with parent as a field and so on. In which NormalizedParent is a nice fit-in. Example.
This can be left as it is.

Comment on lines 403 to 420
if ('parent' in qualifier) {
if (!isNormalizedParent(qualifier.parent)) {
throw new InvalidArgumentError(`Missing required fields in the parent hierarchy [${JSON.stringify(qualifier)}].`);
}
if (hasBloatedLineage(qualifier)) {
throw new InvalidArgumentError(`Additional fields found in the parent lineage [${JSON.stringify(qualifier)}].`);
}
}

if (hasField(qualifier, {name: 'contact', type: 'object'})) {
if (!isNormalizedParent(qualifier.contact)) {
// eslint-disable-next-line max-len
throw new InvalidArgumentError(`Missing required fields in the contact hierarchy [${JSON.stringify(qualifier)}].`);
}
if (hasBloatedLineage(qualifier.contact)){
throw new InvalidArgumentError(`Additional fields found in the contact lineage [${JSON.stringify(qualifier)}].`);
}
}
Copy link
Member

Choose a reason for hiding this comment

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

suggestion: there's probably a way to refactor this

Copy link
Contributor Author

@apoorvapendse apoorvapendse left a comment

Choose a reason for hiding this comment

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

I've added missing coverage for qualifer.ts in the other PR(#10056), so skipping that here.

@apoorvapendse apoorvapendse marked this pull request as ready for review June 16, 2025 18:52
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.

2 participants