Skip to content

feat: Introduce preferred search operators on TEA [DHIS2-12183] #21376

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

Merged
merged 10 commits into from
Jul 18, 2025

Conversation

muilpp
Copy link
Contributor

@muilpp muilpp commented Jul 9, 2025

This PR introduces the preferred search operator field on a TEA.
It's an optional field that's added to the TEA to define the recommended operator for search or comparison.
This is merely a suggestion for the end user and will not be enforced.

Ticket: https://dhis2.atlassian.net/browse/DHIS2-12183

@muilpp muilpp marked this pull request as ready for review July 15, 2025 08:26
@muilpp muilpp requested a review from a team as a code owner July 15, 2025 08:26
@@ -71,6 +71,11 @@ public void validate(
"Not a valid TextPattern 'TEXT' segment."));
}
}

if (attr.getPreferredSearchOperator() != null) {
Copy link
Contributor

Choose a reason for hiding this comment

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

I dont think we should support "accepting" the I variant as the preferredSearchOperator. Let us validate and block that.

Copy link
Contributor Author

@muilpp muilpp Jul 15, 2025

Choose a reason for hiding this comment

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

On the other hand, I variants will be accepted as allowed operators, mostly to avoid breaking the API, right?
As I understand it, I variant operators should not be used in Tracker, but we don’t (or can’t) enforce this rule.
Wouldn’t it be more consistent to accept these operators in both the preferred and allowed fields until we find a better solution?

Copy link
Contributor

Choose a reason for hiding this comment

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

We should not accept I-variants to be accepted in preferred or allowed/blockedOperators.

Let us block it as part of TEA metadata saving validation. Either we block it, or we "map it" to the Tracker Operator variant before persistence. I am in favour of blocking it.

In the UI, only the Tracker Operators (non-i variants) will be used anyway.

In the actual Export API, we do the "Mapping of I-variant to Tracker Variant" before the preferred/allowed operator validation kicks in.

@@ -0,0 +1,3 @@
-- Migration script to add the field preferred operator in the trackedentityattribute table
alter table trackedentityattribute
Copy link
Contributor

@ameenhere ameenhere Jul 15, 2025

Choose a reason for hiding this comment

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

Can you migrate from a 2.41 instance directly into this branch build and see if any issue show up?
The reason I am asking is, if we have separate migration files dealing with the same alter table , there might be issues with keeping all of it in a single transaction. So just try it out. The test should cover running both this migration, and the minsearchcharacters migration in a single migration attempt.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

During development I tried a few times and it worked.
I imported a 2.41 database (no minsearchcharacters no preferredsearchoperator present), and after the migration, both fields are present in the database.

@@ -90,6 +91,7 @@
"translations": [],
"attributeValues": [],
"legendSets": [],
"preferredSearchOperator": "IEQ",
Copy link
Contributor

Choose a reason for hiding this comment

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

The I variant operators should not be allowed to be preferredSearchOperator. Since this is a new feature, we will not be breaking anything. So let us block this in this PR.

@muilpp muilpp requested a review from ameenhere July 15, 2025 13:24
@muilpp muilpp enabled auto-merge (squash) July 15, 2025 13:38
Copy link
Contributor

@ameenhere ameenhere left a comment

Choose a reason for hiding this comment

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

Overall LGTM. Only comment is to block preferredSearchOperator having any I-variant operator. (And for the other issue for allowedOperators as wel the same blocking of I-variant should happen)

@muilpp muilpp requested a review from ameenhere July 18, 2025 09:50
Copy link

Quality Gate Failed Quality Gate failed

Failed conditions
1 New issue
1 New Code Smells (required ≤ 0)

See analysis details on SonarQube Cloud

Catch issues before they fail your Quality Gate with our IDE extension SonarQube for IDE

Copy link
Contributor

@ameenhere ameenhere left a comment

Choose a reason for hiding this comment

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

Minnor nitpicky comments. Feel free to decide if you want to include it or not.

@@ -331,6 +331,7 @@ public enum ErrorCode {
E4079(
"Program `{0}` category mapping `{1}` has multiple option mappings for Category Option `{2}`"),
E4080("Program `{0}` category mapping `{1}` has an invalid option mapping `{1}`"),
E4081("The provided preferred TEA operator `{0}` is not part of the tracker operators `{1}`"),
Copy link
Contributor

Choose a reason for hiding this comment

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

Suggested change
E4081("The provided preferred TEA operator `{0}` is not part of the tracker operators `{1}`"),
E4081("The provided preferred TEA operator `{0}` is not part of supported tracker operators `{1}`"),

@@ -208,8 +208,8 @@ private void mapAttributeFilters(
|| queryFilter.getFilter().length() < tea.getMinCharactersToSearch())) {
throw new IllegalQueryException(
String.format(
"At least %d character(s) should be present in the filter to start a search, but the filter for operator %s doesn't contain enough.",
tea.getMinCharactersToSearch(), queryFilter.getOperator()));
"At least %d character(s) should be present in the filter to start a search, but the filter for the TEA %s doesn't contain enough.",
Copy link
Contributor

Choose a reason for hiding this comment

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

Nitpicky: Do we actually use TEA and TET in error messages? Or do we want to use the full "Tracked Entity Attribute" ?

Copy link
Contributor Author

Choose a reason for hiding this comment

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

I'll change the message in the coming PR

@muilpp muilpp merged commit 8cf2e13 into master Jul 18, 2025
15 of 16 checks passed
@muilpp muilpp deleted the DHIS-12183-tea-preferred-operator branch July 18, 2025 12:34
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