I have encountered a strange behavior in the web-client (SAO) while working on a custom module for loading additional subdivisions for a specific country. I will try my best to explain the behavior as follows hoping someone could tell me if this is a bug or an expected behavior.
1- I have created a list of close to 2000+ subdivisions for Costa Rica that are organized according to the country’s normal geo division that goes from provinces, cantons, districts, to finally neighborhoods. All of them are loaded into the country.subdivision table.
2- So upon creating a new party and I try to select Costa Rica from the country list, I notice that the subdivision list will take some time to finish populating all the 2000+ subdivisions. This is expected because the list is long. So in order to reduce the loading time, I decided to create an entry in the “address subdivision types” for that country (CR) to filter only “province” type and limit the subdivisions to be loaded.
3- The expected behavior would be that after limiting the type to only “province”, the subdivision list will populate faster, as there is only 7 provinces. This behavior is carry out correctly for the first time I create the party. But if I load an existing party, move to change the country to any other country, and without saving select back Costa Rica again, the subdivision list will load all the 2000+ entries as if the address subdivision type filter wasn’t set.
4- I traced the web client XHR communication with the server using Firefox’s Developer Tools kit and found out, when the strange behavior happens, it makes the following sequence of calls:
As you can see, the call (line 2) to read the subdivisions is called with the domain clause (“type”, “in”, [“province”]) missing, hence it fetches all the subdivisions. I believe this is because (line 3) the on_change_with_subdivision_types is called afterwards when it should come before line 2. Line 3 is needed to provide the missing domain clause from above. So, the question is if there is a way to ensure that line 3 is called before line 2 at all times?
Ok, digging a bit further in the sequence of XHR calls from the client, I noticed another thing that may be source of the problem.
When I load an existing party that has Costa Rica as it’s country, and try to change the country to say “Colombia”, I noticed that in the XHR call, the subdivision type clause from Costa Rica is used. In other words, it appears as if the call to fetch subdivisions (i.e. model.country.subdivision.search_read) is using the subdivision type filter ([“type”, “in”, [“province”]]) of the country from the current record (Costa Rica), and not from the country that was just selected (Colombia). This explains why when selecting back Costa Rica, the subdivision type filter clause is missing, as my previously selected country was “Colombia” and it has no address subdivision type defined.
Could this be a bug? I will try this in the desktop client and report my findings later.
I can confirm that this strange behavior does not happen in the desktop client, only on the web-client. I am using SAO from source distribution release 5.4
I am not relying or doing anything special regarding the order of the on_change calls. I am just reporting what I found. It may not be important at the moment, but I think there is something wrong in SAO.
What I mean is that we have we can not rely on on_change_with being called before of after the population of the selection. But at the end, the proper call to fill the selection will be done. The fact that desktop client call order is different from the one of the web client is is random (probably order of dict iteration). So there is no problem as long as at the end the data and form are correct (even if in some case it is reducing the performance).
At the beginning I thought the problem was caused by the call order of the on_change functions, but later on my second post, I found out that it may be related to incorrectly applying the address subdivision type domain clause from previous country selection to the current newly selected one. So they produce different populated subdivisions. One shows 2000+ entries which is not designed to, while the other just show a subset as desired, and not just a matter of performance reduction. I mean this behavior is currently popping up on this particular instance, but I am worry that it may happen in other similar situations where we have a field that updates its information “on the fly” with a domain clause that is dependent on other field that at the same time is dependent on other fields. I am not very good at working with javascript, but I will try to look at SAO and see what I can find.