...
| Excerpt |
|---|
There are a number of advanced options for organization levels. These are shown when you click on the Advanced checkbox on the Organization Levels page. |
| Table of Contents | ||||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|
|
Organizations Advanced Options
Type Code
This is a code that you can use to refer to the type when accessing locations in lookup tables or logic. For example, if your level is called District Warehouse, the type code might be district_warehouse
...
Multiple choice or checkbox lookup table questions typically operate on a fixture instance, but you don't have very much control. The technique described here instead creates a "nodeset" using a repeat group with a model iteration query, and then uses that for the lookup table question. This way, you can define whatever properties you need in the nodeset for reference in the lookup table question.
Storing Location Translations
The first thing you need for this to work is stored translations. You can define custom location fields for the name in each supported language, for example:
...
Then edit your locations to populate these fields. This information will now be available to access in your application.
Referencing the current language
This process is described in the page on at https://dimagi.atlassian.net/wiki/x/7CTKfw/spaces/commcarepublic/pages/2143955074/Lookup+Tables#Using-Lookup-Tables-with-Multiple-Languages. If you set up the lang-code question as described there, you should be able to use jr:itext('lang-code-label') to refer to the current language.
Setting up a nodeset
Add a new repeat group, and under the "Advanced" section, set the Model Iteration ID Query to "instance('locations')/locations/location/@id". This will make one iteration of the repeat group for each location in your project. You can add a filter here if you like, or you can filter the expression later, in your lookup table question. Set the Instance ID to "locations", and the Instance URI to "jr://fixture/locations" to make sure the instance is available in the form.
...
Note that you could do whatever you wanted here to decide how to display the location - you could reference the location's state, or a calculated property elsewhere in the form, for instance.
Setting up the Lookup Table question
Now that you have a suitable nodeset, you can set up a lookup table to reference it. Add a new lookup table question and edit the lookup table. Drag the repeat group used to make your nodeset into the "Query Expression" field. It should look something like "/data/locations/item" (*Note: it must start with "/data/". The #form/ syntax will throw an error.) Leave the Instance ID and Instance URI fields blank. Then set the Value Field to "@id", and the Display Text Field to "name", or whatever field in your nodeset you want to display. That's it! Your lookup table question should now use the nodeset described above, with translated names.
...
This page discusses how to reference the location hierarchy in various parts of apps.
...
Enabling Access to Location Hierarchy
...
Some older projects may be setup to only receive the Old Hierarchical Fixture. To transition to the flat fixture, go to project settings, then choose chose Pre-Release Features -> Location Fixture. You can use this to turn on the new location format (flat fixture). Once you have done this, new versions of the app will start to use the new location format. Once all your existing users have transitioned to a new version of the application that uses the new location format, turn off the hierachical fixture. This process is described in depth at https://dimagi.atlassian.net/wiki/x/cinKfwdescribed in depth in this section.
The User's location
To pull the current user's location ID you can use the "commcare_location_id" session variable. To reference this in a form, use the following expression:
...
In some situations, you may want to get a list of locations outside of the ancestors and descendants. In the example above, if a user is assigned to a block, they may want to see all districts in that state anyway. This is controlled using the "Expand From" options outlined on https://dimagi.atlassian.net/wiki/x/GW-Kfwin this section.
Migrating your project from the hierarchical location fixture to the flat location fixture
...
Why might you want to do this? The flat fixture is much simpler to use and understand, and it's faster!
...
Starting off, you may have an existing app which references the old fixture, and this app may have active users. The idea is to be able to migrate your app without disrupting active users.
Go to the aforementioned "Location Fixture" page and check "Sync the flat location fixture". Do not uncheck the other box yet.
Begin converting your app to use the flat fixture as described on https://dimagi.atlassian.net/wiki/x/DArKfw.in this section. You can make new app versions to a phone and test them out, and your existing users won't be affected (As usual, don't release any new builds until it's working so your users don't accidentally update).
Once you're confident that it's working, star the new app version and get your users to update.
Once none of your users are using the old app version, you can uncheck "Sync the hierarchical location fixture" to reduce the size of the restore payload that must be synced to the phones.
...
Go to "Project Settings" then on the left, under "Pre-Release Features" click "Location Fixture".
Ensure that the option "Sync the hierarchicial location fixture (legacy format)." is already selected. If it is not selected, then you are already on the flat fixture format.
On the application that you want to upgrade, go to the applications settings page by selecting the gear in the app builder.
Go to the "Advanced Settings" tab. Under the "Advanced" section select "Both Hierarchical and Flat Fixture" from the "App Aware Location Fixture Format" dropdown. This will allow you to reference both the hierarchical fixture and flat fixture in this app.
To reference both fixtures you need to add the instance references in your form appropriately. In your form that references them both you must add:
<instance src="jr://fixture/locations" id="locations" />
<instance src="jr://commtrack:locations" id="locations_old" />
When writing your xpath references, to refer to the new flat file you use "instance('locations')" to refer to the old format you can use "instance('locations_old')"
Note: you can put anything you want in the id= section above. That is how you'll refer to it in your app.
Begin converting your app to use the flat fixture as described on https://dimagi.atlassian.net/wiki/x/DArKfwin this section. You can make new app versions and publish them to a phone and test them out, and your existing users won't be affected (As usual, don't release any new builds until it's working so your users don't accidentally update).
Once you're confident that it's working and all location references have been converted to the flat fixture, select the "Only Flat Fixture" from the "App Aware Location Fixture Format" dropdown. This will disallow any references to the hierarchical fixture in this app.
Test your application again with this option selected.
Once you're confident that it's working, release a new app version and get your users to update to the new version.