Dynamic Buttons on Form with preset value in URL

[JoelR]

My app is launched using the results of a LINKTOFORM expression that specifies a Location ID in the URL. The form displays a list of valid Issue Types for that location. The problem is that the Issue Type selection is not visible when the form loads for the first time. To make it visible, you can simply reload (think F5 or refresh) or you can change the location. However, the filtered list must be visible on initial load to function properly. Is this possible? 

The Issue Types are filtered using this valid_if expression:

SELECT(
   Issue Types[ID],
   AND(
      [Building] = [_THISROW].[Building],
      [Location Type] = [_THISROW].[Location Type]
   )
)

The Issue Types table contains values Location ID, Building, Location Type, etc. I also tried specifying the Building and Location Type in the URL thinking it will "speed up" the logic, but that didn't help. Those values are calculated anyway based on the unique Location ID. 

Is it possible to load a form with a default value and display a filtered dropdown or button list based on the default value?

[Marc_Dillon]

Yah that should definitely be possible. Can you give more details on your implementation? You mentioned how the location id is in the URL. Are you coming into the app from somewhere external? Why do you mention the Location ID, but you're not using the Location ID in your posted valid_if expression? Screenshots are always helpful.

[JoelR]

The app is launched from a URL, actually a QR code. Location is determined by the QR code, not geolocation. Think of a location as a location in the building, not a map. The Location ID must be specified in the URL to look up the Location Type (Restroom, Elevator, etc.) from the Locations table so a filtered list of Issue Types appropriate to the location can be presented to the user. This is the Issues form that should load:

This works beautifully in all cases except one: on initial page load. The Issue Type is not displayed until the page is refreshed or until you select a different location (which won’t be allowed in the app since the report will be tied to your current location). The initial load looks like this:

The Issue Types are specified as multiple rows in the Issue Types table, so elevators will have types like bumpy ride, noisy, but restrooms will have soap, toilet paper. The joke is you don't want a bumpy ride in the restroom. 😉 This table allows the property manager to configure a list of issue types and service providers per location type per building, allowing the app to scale to hundreds of properties.

The link to the Issues form is actually calculated in a second app, using a LinkToForm expression that specifies a default value for the Location ID. I have also tested specifying the Location Type and Building in the URL since those can also be calculated in the second app. The odd behavior is not affected by specifying more fields that are looked up anyway. The form that is opened from the QR code or URL is tied to the Issues table:

When the form is loaded, the Location ID [and optionally for testing purposes the Building and Location Type] is specified and will display in the form. The valid_if expression for the Issue Type is on the Issues table. 

Here is the Locations table:

Every location has a location type in the Locations table. The Issue Types are determined by the Location Type. Thank you community for any assistance!

[Marc_Dillon]

Understood. I suspect maybe there's an issue with the URL. Can you share how the URL is created, and an example of an actual full URL that's embedded in one of the QRs?

[JoelR]

@Marc_Dillon here is a test URL: https://www.appsheet.com/start/922582bb-7f00-45c7-b096-c2a266e4e6d3#control=Report&defaults=%7B%22Lo... You should see an ACCEPT screen followed by the broken form. If you refresh or change the location the buttons will appear. Thank you!

[Marc_Dillon]

I see that you're pushing values for Building and Location Type through in the URL. But those columns have App Formulas. Maybe try to remove those and just have the Location_ID?

[JoelR]

@Marc_Dillon You are right. I should have mentioned that Location ID is the only required field and I added the others for testing only with the thought that maybe there would be fewer calculations on that initial load. The behavior is the same without those preset values. The issue still occurs when truncating the URL to Location ID only: https://www.appsheet.com/start/922582bb-7f00-45c7-b096-c2a266e4e6d3#control=Report&defaults=%7B%22Lo...

You also picked up on the unnecessary _ in Location_ID. Also a test because I read somewhere along the way not to use spaces, so I changed that one column name. 

[Marc_Dillon]

Both of your URLs appear to work fine for me at this time (I did see the described issue earlier). Did you change something?

[JoelR]

It will always work on subsequent attempts or on location value change. Try pasting the link into a private or incognito window. This will simulate a first-time user, replay the app consent screen, then you will see the issue. 

[Marc_Dillon]

Ahh, gotcha. So it's probably not an issue with the URL then, but has to do with the interplay with the consent screen. What if you turn the consent screen off?

[JoelR]

I can turn it off?!? How?

[Marc_Dillon · Accepted solution]

.

[JoelR]

+1 = 687

@Marc_Dillon you are awesome! So, maybe a bug?

I don't think we need the user consent since this will not be deployed in California or Europe, but maybe something the support team will want to look at. Thanks so much!

[Marc_Dillon]

Yah, you might report that to support.

[JoelR]

Yes, I have and thanks again for your expertise!