Hi,
Today I noticed a very interesting thing in the ancestor_location expression. Maybe this is intentional, if yes, so sorry for spam :).
Cutting to the chase. I investigated how is implemented this expression and I noticed that in the configuration we must add location type name, not a slug. I did not meet in the project that we comparing something with the name property, so this is not obvious that we should pass the location type name.
LINK TO THE CODE: commcare-hq/corehq/apps/locations/ucr_expressions.py at master · dimagi/commcare-hq · GitHub
Regards,
Łukasz
Hi Lukasz
By slug, do you mean the location type code? commcare-hq/corehq/apps/locations/models.py at master · dimagi/commcare-hq · GitHub
This may have not been an intentional decision, but it should work well as the type name is is guaranteed to be unique to the domain: commcare-hq/corehq/apps/locations/models.py at master · dimagi/commcare-hq · GitHub
I agree that referencing location types by code would be preferable. Unfortunately it's really difficult to change this sort of thing now, since that would have the potential to break existing reports. I'd be in favor of a workaround if that would help the project you're working on, though.
For instance, you could add another parameter to the expression definition called "location_type_code", and require that only one of the two is provided. This way existing reports could continue working, and going forward this could use code instead of name.
Hi,
Yes, I mean location type code.
We used location tyme name in our reports (so we don't have a big problem for now) but we had an issue that reports work correctly on test domain but on the production nothing worked correctly. This issue occurred because on the test domain location type name is 'Region' but on production domain 'Région'.
I will extend this expression according to Ethan suggestion when I will find some extra time. I think support both properties will be helpful in future.
Regards,
Łukasz