[BUG] "Linked data missing from ..." : please HELP / FIX IT!

Hey,

Today, I’am again getting this boring error message where linked data are missing from screens :

I have a welcome page, a home page and I applied the “blank screen” workaround to get the data loaded and available in the home page. After the home page, I have 2 sections, aka 2 screens linked to the home page. Until yesterday, the second section/screen didn’t exist, and all was working fine with the first section / data (even if I already add to delete et rebuild lots of links to get this result, but …). Today, I add my second secton/screen : it is exactely the same kind of screen and link from the home page. And what happened ? ==> All linked data missing, for both the FIRST and the new section. ARGH !

So again, I will have to spend long minutes and even more to remove all links from screens to screens and to rebuild them, because I dont’ know why and how but it’s the only way I’ve found to get the linked data back. I don’t even know which links or screens are causing this bug.

Adalo, come on ! Can you please have a look at this BUG ? We can’t build complex & multi screen apps, with internal and external data, if we can’t rely on what is available to build these apps, and furthermore, I can’t rely on something that works one day, and does not work the day after. Without talking about the time lost to try to repair this bug by ourselves, and to succeed in “by chance”. But tomorrow, I will have to do the same and I’m pissed ahead.

Please :pray:t2:, get rid of the f***king bug and ensure the basics are reliable!
And if it’s not a bug but an “expected or normal behavior when manipulating several screens and several internal or external collections”, so please let us know and take time to provide documentation on how to avoid such disappointing situation.

I am really sorry for this post but I am so angry. I stop working with Adalo for today, I spend too much time to do and redo, neither productive nor efficient, wasted time.

:pray:t2::pray:t2::pray:t2::pray:t2::pray:t2::pray:t2::pray:t2::pray:t2::pray:t2::pray:t2::pray:t2::pray:t2::pray:t2::pray:t2:

1 Like

Ok guys, I think I have pointed out the root cause - or one of the root cause / scenario, for missing data.

Hereafter my app configuration :

1 - Welcome page (including login form, linked to home page, and the “blank screen” to work around the user data retrieval)
2 - Home page (containing a custom list of “items” data).
3 - Item page : user select an item in the previous screen, and comes in this screen.
From this selected item page, user have access to 2 “services”, so 2 screens : screen A and screen B.
Let’s consider only screen A :
4 - Screen A : contains another list and inherit the “items” data. Ok. From this screen, I start a workflow, so several subsequent screens till completion of the workflow.

Here is the root cause of the bug :

All these subsequents screens (no matter how many sub screens you have, from 1 to N) contain a nav bar with a left icon associated to the “back” link. Ok, if this navigation list was the only one, no datalost.

But these screen also contains a direct link button (same bug with icon and text) to screen A or a previous sub screen, aka something like “return to the begining” or “return to step X” :

BOOM ! “items” data lost.

Remove these “nominative screen” link, and your data are back.

Ok, so my assumption and contribution to get this bug definitively solved is the following : “enable data inheritance for any screen-to-screen link within the app”.

This way, any data “collected” during any workflow or during any enabled navigation within the app will not trigger loss of data for the makers - and will avoid lot of complications in case of a live app needing an update.

Thanks in advance ! :smiley:

2 Likes

@Ben @jeremy @KatelynCampbell @ashley : can you provide any help in getting this bug fixed ?

It prevents building apps with segmented or switchable workflows.

:pray:t2:

1 Like

@ChristopheHK

The way that linking data works is that for a target screen to have access to a current “item”, all the incoming links need to be sending a current item (the only exception to this is a back link, like you pointed out).

Hi @Ben, thanks for your feedback.

The problem is that data linking works the same the screen linking. So as of today, switchable workflow can’t be implemented / built.

Moreover, let’s consider the following :

  • screen A : generating the current item, linked to target screen B.
  • Screen B : correctly contains the current item, and is linked to target screen C
  • Screen C : correctly contains the current item, and is linked to target screen D.

Any “back” link between screens A, B, C and D works, the current item is there in any screen.

Any link from any screen to any other screen, A B C or D does not work for data, linked data are lost in the target screen. That’s surprising because any screen from A to D contains the current item. So two ways data linking does not work.

Coming back from screen D to C should work, as there’s only two incoming links for screen C, the one from screen B and the one from screen D - and both screen B and screen D contain the current item.

Because screen C is “upstream” from screen D, it would need to use the back link action in order to not cause any missing data.

OK, hum… So how can I implement my switchable workflow…

… Thinking…

… Thinking…

… Maybe by generating the same current item from screen D? Hum… May work… Have to try!

@ChristopheHK Did you figure it out?

No, unfortunately, so I had to left Adalo to build my app with another No-code tool.

1 Like

@ChristopheHK oh ok. shoot. I was hoping you figured it out. Hopefully they can get this rectified. I’d love to have my screens link so that my users can move around in the order they want without having to update data to get there.

1 Like

There is definitely something odd in the way that data is linked from screen to screen.

Even if you have not errors it seems to lose connection.

1 Like

@ChristopheHK, would like your input please, what is the ‘blank screen’ workaround you mention.

It’s just an intermediate screen your user will cross when connecting your app. First screen go to intermediate screen (blank screen) then your second app screen. This way, user data have enough time to load.

That workaround is also broken. The only way I have found to do it is to have a Button on the page for a “Welcome - click here to continue”.

User logs in > Goes to Page > User Data is STILL not loaded > Data eventually loads > Click button

1 Like

It is also a big problem using the workaround for restricting signup to a list of emails. So making the signup button a “list” filtered on email input.

Because the data is so slow to load, you get a spinning icon > a HUGE list of buttons > no button.

It looks very poor.

1 Like

Hi @NigelG,

It’s Friday and time for crazy experiments. You’ve motivated me to create an alternative way of user check upon signup (so that user exists).

Here it is:

It’s not blazingly fast, but for an existing user it should works faster than classic way.
Also, comments are welcome - I’m in unchartered waters here :slight_smile:

Best,
Victor

1 Like

Very interesting. As I said on the other thread I want to check if an email is on an external whitelist. (It is in Airtable).

Maybe I should sync Airtable with a my Adalo collection to make it faster ?

1 Like

Hi @NigelG,

I’m not familiar with Airtable… if there is a way to have “unique” column there, and if there is an API access, may be you could try the same approach - make this email an “unique” column, make API request to create record with this “unique” value and work from there based on the error returned…
Just as an idea :slight_smile:

Best,
Victor.

Or … I could just look it up ?

Not sure why adding a new one and waiting for a response is better ?

Hi @NigelG,

The problem is how to look it up :slight_smile:

My logic is based on what’s done in Adalo’s API. They have: GET ALL (returns all records), GET ONE (returns one record based on ID), POST (creates new one), PUT (modifies based on ID) and DEL (deletes based on ID).

The main thing here that (a) for an operations with a single record its ID is needed, and (b) with GET ALL there is no way (at least which I know) to extend the result with something like “SELECT * from USERS where EMAIL=…”. So no lookup by field is possible.

After having a quick glance at Airtable API, their API offers a bit more options, including “filterByFormula” option. If this could be used as a lookup filter, then your suggestion should work.

My suggestion is more like a “workaround” :slight_smile:

Best,
Victor.