No error is displayed when a reusable item's Type of content is empty

I have a reusable element which is a popup. To work well, it needs a City to be passed.
Why isn’t it possible to raise an issue if the popup is displayed without passing it a City, as it happens for the “Go to page” action?
Popup definition:
image
Showing the popup (no required element):
image
Compared to navigating to a page which requires data:
image

Well, because just like a page with a type CAN in fact be loaded with a null object (a unique ID that resolves to empty), forgetting to pass a value that you consider “required” IS NOT an error condition.

It is up to YOU (by which I mean your app) to decide what should be done if the thing is empty/null/undefined.

In the case of a popup like this, which seems to be generated by a user action, your app should be checking that the supplied city is not empty and doing something if that’s a problem. (The text in the popup could say “hey try again, dude” OR (for example) the input where the user is supposed to have entered a City can be highlighted (as it is not valid). There’s a lot of ways to do this of course.

So it’s simply not an error. The Issue Checker is not an AI app design helper, it’s there to report app-breaking issues that should not be allowed to be pushed to Live.

Aside: The following is a closely related topic:

NOW, another thing you should consider: You compare this situation to navigating to a page with a type. When you do that, the “Go to page” dialog does require “Data to send”. But note that Data to send is a dynamic value. Whatever expression you put there MAY and CAN resolve to empty.

Note also that a smart-ass user can either just construct a URL to a page (e.g., let’s say you have an invoice page mysite.com/show_invoice/[unique ID of some invoice object]) and just omit the unique ID (e.g., mysite.com/show_invoice).

So you can have workflows for when current page’s thing is empty, do something like redirect (don’t show any interface elements and navigate to some other page).

Or, they may try to guess or modify a uid in an effort to try and expose data that they should not be able to access. Hence, we have privacy rules and additionally, it’s common to do workflows on typed pages such that “if Current User is not this page’s thing’s Creator” or “Current User is not this page’s thing’s Recipient”, we again do not show anything on the page and redirect them.

The point is: A null argument for a typed page or for a typed popup is not an error, but is a common situation that one’s app must handle (as appropriate).

2 Likes

I do that a lot, although I have the impression that the data gets to the client even if it’s not supposed to. I’ve been able in some occasions to see a brief flash of a page that the user was not supposed to view, followed by a redirect.

Hey @furnys, Yes, that can happen. What one wants to do is ensure that all page elements are hidden (not visible) by default. They should only be shown via Element > Show workflow in the “Current user is this page’s thing’s Creator” workflow, for example.

This is easiest to do if all of the page’s elements are in a group that serves as a master container for the page. (You have the page object, a group on it that’s basically the size of the page, and all of the things inside are what you’d think of as “everything on the page”.) In this way, you can just make that master object hidden by default and then show it when appropriate via a workflow action.)

The other thing to keep in mind: Of course, one should have privacy rules set up as well so that, even if the wrong user saw the page and the elements on it, any data objects that are restricted to them would not be downloaded due to privacy rules – if that is possible.

For some types of things, this isn’t possible. Consider that a “listing” type site would have various “owner” users who are creating Listings about their properties. Many aspects of the Listing datatype must be viewable to anyone (things like description, photos, etc, etc).

But the privacy rule would keep fields that are private, private. Certain publicly viewable fields could be downloaded to the browser.

Point being: Techniques like only show the page data after we’ve determined that the User should be able to see them should not be confused with privacy rules. They work hand-in-hand and should be used together.

Setting everything not visible is a tactic I have tried, but then editing the application is a PITA because every page is empty in the editor.

About privacy rules, I have to fully understand them yet, but from what I’ve seen, they don’t seem particularly fine-grained.