Different data in a group...or two different pages?

To enable our app to have a “test” mode for sales demos etc, I have a set up test data in different collections.

Having too many conditional elements on one page seems to throw out the display, with lists getting pushed all over the place.

Should I have two groups with all the live/test elements in them, and show those conditionally.

Or maybe have two entirely different pages.

PWA for reference, Thanks.

Hmm, the page I need to display different data on is the Home page, so that doesn’t make it particularly easy to do the test/live page.

Will a page load action redirect ok I wonder?

Could you just make a copy of the app and use that for demos?

Yes. But then I either have to make app changes twice. Or create a new app (and therefore link) every time I make a change. Which is not very efficient.

To answer my own question … No, it does not. If you put a “if this is test mode go to another page” action on the home page load it doesn’t fire.

So I think there are a few issues with the whole “Page load action” function as it currently stands.

  1. It doesn’t work consistently and won’t redirect
  2. You can’t “send to page” in the way you can when logging-on or signing up
  3. It does not allow for removed users to be redirected if they return

It would be very handy to be able to have the “Current xxxxxxx” always available on a page. And to have this preserved through refreshes etc.

A possible solution is to create a single button “Welcome” back page which is set to the “Home” page. This button then can perform all the actions (including returning to signup if they are not logged on).

Has anyone done this?

Hi @NigelG,

Based my experience, I came to the concept of separate “routing page” - a blank page after the log-in, where all logic is done and user is sent to a specific section of the app after the login.

You might find this video useful:

Also, few notes in addition:

  • for log-in / sign-up actions, I would avoid adding anything else. I don’t know why, but sometimes this could result in unexpected behaviour (especially when conditional actions are used). So that’s why I came with this “routing page” concept;
  • this “routing” page should be set as a “home” page, to be sure, that user rights are checked in any time;
  • it might be a good idea to put additional “user role” checks for each page (on screen enter), so that user couldn’t get to some restricted pages (this is more relevant to webapps; potential scenario requires logging in from 2 user accounts and going back several times);
  • “on screen enter” actions should be used with a good knowledge about their limitations (they’re sometimes not consistent). I would advice:
    – avoid using custom action responses;
    – avoid using “one-time variable reset” actions. On-screen-enter is done every time when the user presses a button on a screen, so if you want to reset the counter once - reset it on previous screen (or you’ll have a result of resetting it every time :slight_smile: )
    – there was a bug, when on-screen-enter action was not executed when user presses “back” button in the browser (and I think on Android as well). Not sure if this is fixed or not.

I know this doesn’t directly answer your question, but still hope this information could be useful.

Thanks.

The “blank page” doesn’t always work. Or at least doesn’t always work in the way we think it works.

My guess is that it sometimes adds just enough delay for the user side to catch up with the page.

But not always, so I have had to put a welcome button on the page that waits for the user data to be available. It’s a worrying race condition.

The other wrinkle is that the user data in the database is not the data that is loaded onto the home screen. Maybe it is cookie based or something. Delete a user record and see what happens when you display that data on a home page. It’s still there.

Anyway, we had to launch so there are ‘welcome back’ buttons. A bit of a cludge but nobody has complained so far :slight_smile: