Making the Point Feature (GPS Lat Long) Mandatory/Compulsory in Event Program

Not finding the ability to make the Point Feature of an event program mandatory. I recognize that I could create a GPS enabled Data Element and make that compulsory/mandatory through a program rule, but I’d much rather make the GPS Point Feature itself mandatory. Anyone dealt with this previously?

1 Like

Hi @Matthew_Boddie,

I have a question please are you using this on Android or the web? I believe if it is possible to only allow the point feature then it should be on both sides so this is why I’m asking.

We can make Data Elements compulsory when we assign them to the program so there is no need to create a program rule for that; however, have you tried to create a program rule that only allows the Point Feature format?

Let’s see if we could get more info about this. Please update us about your experience on this too! Also, I’d like to ask if the reason behind this decision is due to technical issues for example?

Thanks! :+1:

Hi @Gassim sincere apologies for not responding sooner.

This is relevant for both Android and through Capture (Browser) entry. I’m attempting to mandate the filling of lat/long in the point feature section. I am trying to avoid needing to use a Data Element at all for this. I can affect Data Elements through program rules, but can’t make the gps sections for the point feature mandatory or do anything to them with a program rule.

The ask is simply because we have examples where we know lat/long can be filled, and it isn’t being done. If we can make sure that this data gets put in, it would save time/effort vs. having to go back and fill it in later.

1 Like

Hey @Matthew_Boddie - unfortunately its not possible to designate the event feature type as mandatory. We where once looking at a generic feature for accessing the feature types in program rules, to serve another use case. I think that if we had access to the event feature type in a rule variable, you would be able to build a validation?

Perhaps you can describe the use case in a jira user story, and then we can try to solve more than one story with the same generic solution.


@Markus thanks for the context—and yes, I think that would be sufficient; another alternative for this specific use case would be to have the settings available within the program itself (i.e. compulsory settings of individual DEs). We could also (separately) verrrrrrrry happily take use of accessing category Option/category Option Combinations in rule variables, as well.

I’ll look up exactly what a Jira user story is and then build something out!! Thanks again.