feature: yes/no site_name (hidden)

[fakhrihawari]

No description provided.

[drfaustusfade]

that will make a request on each location, on the same admin1 that will return 304,
what will happen if locationAdmin1pcodeTag changes from A to B and then to A ( on refactor-location-handling locationAdmin1pcodeTag that is handled with array )
what if having a function on form widget that handles for locations unique admin sites requests if missing ( or whatever admin1,2,3 or site type by config, if taking into consideration configurable admin fetch service )

[fakhrihawari]

yes i will change it like on refactor-location-handling,

[drfaustusfade]

please check comment for setLocationAdminSelect
for hidden feature description please add more details and issue # for future reference

[fakhrihawari]

updated

[drfaustusfade]

updated

please try to handle adminSites requests in a separate function before setLocationAdminSelect, what happens if admin sites for admin1 already exist?

[fakhrihawari]

updated

please try to handle adminSites requests in a separate function before setLocationAdminSelect, what happens if admin sites for admin1 already exist?

So you want fetch all the adminsite first then running the setLocationAdminSelect?

[drfaustusfade]

So you want fetch all the adminsite first then running the setLocationAdminSelect?

the idea is like that:
separately from setLocationAdminSelect there should be a function that checks if adminSites list contains the location admin ( if site_type and admin1 ( advanced based on config if admin2,3,4,5/site_type/cluster ), and requests if not

[fakhrihawari]

I put new function on separate function, so for now its just check if admin1 is on adminSites list or not , if not it will make request

[drfaustusfade]

I put new function on separate function, so for now its just check if admin1 is on adminSites list or not , if not it will make request

1. I think setLocationAdminSelect should be used on the form widget and not hidden inside fetchInitialAdminSites, so that not to wait for admin site requests
2. on fetchInitialAdminSites for each location check if site_type is present then proceed ( also maybe site_list_select_id )
3. make requests when req_adminsites.length
4. run setLocationAdminSelect if any/concat of the results have .length ( that will make request twice )
5. consider adding stub function to handle configuration to handle different site requirements, for example in AF only Education schools would need to be fetched on admin2

with those notes let's comment/remove from this pull request and deal with that in a separate issue, we need to consider the details and test this functionality thoroughly as that will impact various operations,
additionally, the question of interest how that will behave with over 100 target locations

[fakhrihawari]

I put new function on separate function, so for now its just check if admin1 is on adminSites list or not , if not it will make request

1. I think setLocationAdminSelect should be used on the form widget and not hidden inside fetchInitialAdminSites, so that not to wait for admin site requests
2. on fetchInitialAdminSites for each location check if site_type is present then proceed ( also maybe site_list_select_id )
3. make requests when req_adminsites.length
4. run setLocationAdminSelect if any/concat of the results have .length ( that will make request twice )
5. consider adding stub function to handle configuration to handle different site requirements, for example in AF only Education schools would need to be fetched on admin2

with those notes let's comment/remove from this pull request and deal with that in a separate issue, we need to consider the details and test this functionality thoroughly as that will impact various operations,
additionally, the question of interest how that will behave with over 100 target locations

but if setLocationAdminSelect not wait for adminsite request done the list adminsite foreach location is empty

[drfaustusfade]

yes, so that when complete, if adminsites updated setLocationAdminSelect will run once again ( better would be to update per location ), like that it is also not perfect, so that I propose to deal in a separate issue

[fakhrihawari]

yes, so that when complete, if adminsites updated setLocationAdminSelect will run once again ( better would be to update per location ), like that it is also not perfect, so that I propose to deal in a separate issue

so you mean run setLocationAdminSelect itself and run again after fetchInitialAdminSites ?
and
no 5 right now the API adminsite only use admin1 not admin2

[drfaustusfade]

yes, so that when complete, if adminsites updated setLocationAdminSelect will run once again ( better would be to update per location ), like that it is also not perfect, so that I propose to deal in a separate issue

so you mean run setLocationAdminSelect itself and run again after fetchInitialAdminSites ?

yes, the idea to have fetchInitialAdminSites not dependant with setLocationAdminSelect, so that we need to elaborate on it

[fakhrihawari]

And no 5 on example you mean by fetched on admin2 ? is from API or just filter the list ?

[drfaustusfade]

that is to the idea of configuration for target locations
that is because of various requirements and list sized some operations need to request adminsites on login, some on admin1 change, some on admin2...

[fakhrihawari]

that is to the idea of configuration for target locations
that is because of various requirements and list sized some operations need to request adminsites on login, some on admin1 change, some on admin2...

okay i will procced this on other branch (refactor location handling)

[fakhrihawari]

yes, so that when complete, if adminsites updated setLocationAdminSelect will run once again ( better would be to update per location ), like that it is also not perfect, so that I propose to deal in a separate issue

so you mean run setLocationAdminSelect itself and run again after fetchInitialAdminSites ?

yes, the idea to have fetchInitialAdminSites not dependant with setLocationAdminSelect, so that we need to elaborate on it

And for this i already updated

[drfaustusfade]

on last pull's commit
when saving from list location, the location name disappears
i am not sure on this pull if yes/no should appear with empty list

[fakhrihawari]

on last pull's commit
when saving from list location, the location name disappears
i am not sure on this pull if yes/no should appear with empty list

from adminSites List

from target locations

type site_id from adminSites list is number but in the target location it saves as a string, and then when trying to match with site_id in adminsiteLists it doesn't match so that make location name disappear or not show

demononamesiteid.mp4

and for this "i am not sure on this pull if yes/no should appear with empty list " , can we just make it like this? if its empty list

[drfaustusfade]

1. should be text
2. if empty list there should not be selection

[fakhrihawari]

1. should be text
2. if empty list there should not be selection

updated

[drfaustusfade]

• on no selection, if site type were selected before
  

• on admin3 change, from list displaying yes, after opening no

[fakhrihawari]

updated