Android capture 2.1.2, and dhis 2.33: issue (value does not match the attribute pattern) during second sync, although it synced the first time and the pattern is the same and not changed

I have a Tracker capture program that has two events, the entity and the first event is created by the first user and the second event is created by another user.

I used the following pattern to generate tracked entity attribute id:

ORG_UNIT_CODE(…) + “-” +CURRENT_DATE(dd-MM-yyyy) +"-"+ RANDOM(*******)

when the first user creates the entity and the first event and try to sync so it appears at the second user to create the second event the data gets synced without any error, but when the second user try to create the second event and try to sync it doesn’t get synced showing up the following error:

value does not match the attribute pattern

as in the following screenshot:

why? is it an issue? do I need to shorten the pattern? or is using a lot of characters in the pattern not a good idea?

Hello @hamza.

I have been trying to reproduce the issue in a similar environment but I cannot. Both users can synchronize properly on my set-up.

A couple of things:

  • Are you sure the user has the rights to edit that generated attribute? I agree that if that is the case the error shown should be different (so this might be a bug that we will report if it is the case)
  • Is your pattern properly generated? I mean, when you check the value populated if follows the pattern?

Another important thing is that your pattern might not behave as expected because of the way Android works. You can read a bit more here: Home - DHIS2 Documentation but basically, because Android is precaching 100 values at the moment of the initialization, whenever you enter new TEI tomorrow, the day will be the one from today. This will also happen if you change from one month to another or even a year (less likely). Maybe this is fine with you, but just wanted to flag it.

Please try/verify what I mentioned and let me know otherwise. I might ask for specific credentials to verify on your server.


I checked everything and still having the same issue in my implementation, I had to shorten the ORG_UNIT_CODE(…) length in order for it to work, and it worked, also there is another issue with the pattern when I change the pattern and try to go to the App to manual sync the new configuration so the new pattern gets applied the new pattern does not get applied the app still uses the old pattern configuration whenever I create a new TEI.
I found that I had to do a full reset for the app and login again in order for the new pattern to take effect, could you also try this with the same pattern configuration I shared later and try to change the length of the ORG_UNIT_CODE(…) and try to sync the new changed pattern using normal manual sync of configuration and see if the new changes gets synced. If you want the credentials I will share them with you.

Hi @hamza

Regarding the length; this is somehow the expected behavior as the API is giving an error. I will try to explain with a quick example:
Pattern (note there are 10 characters): ORG_UNIT_CODE(..........)

When generating the value this will happen:

  1. An ORG_UNIT with code: OU_mysuperlongcode will get a pattern as OU_mysuper
  2. An ORG_UNIT with code: OU_short will fail!

Then reason 1 will work and 2 will fails is because underneath the following API call is executed:

If the name is shorted than the requested pattern an error 500 is returned:
{"httpStatus":"Internal Server Error","httpStatusCode":500,"status":"ERROR","message":"Could not generate value: Value is invalid: ORG_UNIT_CODE -> OU_"}

So I would recommend that you never use a pattern which might be shorter than the shortest of your OU_CODES.

Regarding the second issue; this is normal although we might consider a bug. Will report to the dev team and will try to come with a solution.

1 Like