Difficulty adding a list of texts to a list of texts field

I’m stuck attempting to add to a list of Things. I’ve run out of alternatives, can anyone help?

Here is the workflow (there is no condition on the search):

and here is the API workflow it calls:

and the condition set on each is the same:

The Vehicle History and Job History are lists of Things and they work perfectly. However, the fields with CONCAT in the name are lists of texts. They work at random. sometimes I get no values added, sometimes I get one, and sometimes I get one plus a number of commas (empty texts) yet I know for a fact that these fields should be lists of four or five texts.

I’ve tried anything from 2 seconds to 6 between calls and I get identical results. At this rate I will be cross-referencing until next year :slight_smile: Can anyone dig me out of this hole?

This question seems pretty complicated and it leads me to some questions. Why are you keeping lists of things and then ALSO lists of things that are apparently concatenated from somewhere.

Are you confused about the differences between “set list” and “add”/“add list”?

I guess my question is: Do the values for the “CONCAT” lists coming from an external API or something?

The reason I ask is that LISTS in Bubble are, more of less, just like JavaScript arrays. EXCEPT for some differences in the various list operations you can perform.

When you do list operations like “add item” (add a single thing of the list’s type to the list) and “add list” (add an array of items of the list’s type to the list), these ARE NOT equivalent to “push” in JavaScript.

The way those things are different from a “push” operation is that – any of the items that are ALREADY in the list are NOT added.

This seems weird, but it’s actually handy. Lists are generally useful in the same way that arrays are, but the intent of them inside of Bubble is for doing things like, for example, managing user data types such as “Roles”.

By keeping duplicate items from appearing in lists, Bubble removes a lot of the complexity in that. (Consider: If a User takes some action that is supposed to add or delete a Role (maybe now they are not just a normal user but a super-user), I do NOT have to do a bunch of stupid error checking. I can just shove the Role onto their list of Roles. (If they already have the super-user role, they don’t wind up with two entries for that role in their list.) <— hope I’m making sense.

ANYWAY, my point behind this is:

Sometimes it will look like Bubble is not adding something to a list. All THAT means is that the item must already have existed in the list. (It in fact WAS NOT added. However, an identical value of that type is ALREADY in the list.)

If you have list in Bubble that DOES have duplicate items, that list must have been created in a non-standard way (that is, it was not created with the built-in add, remove, etc. list operations).

So you seem to be reporting that sometimes you are seeing lists with multiple null values. Those must be coming from something like some JavaScript you are running on a page, an external API, or something like that.

It is hard (if not impossible) to create a list via Bubble workflow actions that contains duplicate values.

If you DO somehow get an array of values with duplicates in it, the SET LIST operation WILL preserve those duplicates. (SET LIST tells Bubble “here are the list items - do not mess with them - just blow away anything that was here and replace it with this list”.)

However, if you have an existing list and you ADD LIST that has duplicate values in it (or the existing list already has some of the values in it), the duplicate items will be dropped.

Here’s an example. Let’s say I have a thing in my database that is a list of integers. It looks like this:

thing is [1, 2, 3, 4, 5]

Let us now say that I constructed or received some other list of integers that is like this:

otherList is [4, 5, 6, 7, 7, 7]

The result of “thing ADD LIST otherList” is this:

thing is now [1, 2, 3, 4, 5, 6, 7]

If I were to instead do “thing SET LIST otherList” I will get:

thing is now [4, 5, 6, 7, 7, 7]

Perhaps this helps you in your debugging.

1 Like

@keith at first I felt so bad you took all that time to type up an answer because I did not make clear why I needed the CONCAT fields and where they come from.

I do understand the set list and add list, experimented with both in my desperation for a solution, and I love the way bubble handles lists. So let me try to explain what I am doing and where things are coming from.

Firs the lists of Things will be used exactly as you describe. However, the CONCATS are another story. I need some very wide-ranging searches. For example, when a user is on the Customer List they can of course search for a customer in the customer’s fields but they also need to search for the customer by many other things e.g. vehicle registration plate, VIN number, color, year… or by invoice number or job date … and on and on it goes.

So after much testing, I’ve found the most appropriate route for my searching requirements is to create a CONCAT field for each Thing. That CONCAT contains the text values of fields that need to be searchable. Then I use the S&A plugin and point it to the various CONCAT fields in the single table it is searching (e.g. Customers).

Once I had all that testing completed and my data table structures right, I set about creating volumes of meaningful test data. The data in the tables was therefore created by bubble workflows but not your typical add/edit/delete style workflows. It was done in bulk API Workflows.

Then comes the time to build those cross-references (list of Things) which went well and the list of CONCAT for searching (list of texts) and that is not going so well. I’m getting anything from blanks to a string of commas, a single entry and a few commas, to two entries, and right up to the five I expected. I thought it might be something to do with the delays between APIs or some syntax I have wrong. That’s what I was hoping.

Welllll… the extent of getting the CONCAT values is just to do these “set list” operations?:

If so, that’s easy enough to debug in a page, right? Just make a page of type customer, put some repeating groups on it that will show you the results of these searches (like the last one Search for Job Card’s Vehicle CONCAT would be the source for one of those RGs).

Visit that page with a customer ID and see what happens.

Could it be privacy rules keeping some of this from populating correctly? [EDIT: Yep, that seems to have been the issue for the OP] Perhaps your xref_customer_build workflow needs to be run with “ignore privacy rules”? (I’m sure you’ve thought of that, but if not… If you’re triggering or scheduling an API workflow at runtime, that workflow gets kicked off with the privacy restrictions of Current User. If Current User is not the admin/superuser, this can lead to weird results if the workflow you’re kicking off is kind of a system/backend event.)

I guess the question is: Does this work for SOME "customer"s, but not others?

Anyway, I can’t think of simple reasons why your stuff wouldn’t be working beyond what I’ve described above. Of course, we can’t see your “Search for…” criteria. Those are easy to get wrong as well! (As I’m sure you know.)

This is one of those things I would work on IN A PAGE. Once you have it working right there, fix your api workflow…

Search on all four is as shown above in post one. a simple Customer Field = API’s Customer.

But I think you might have hit the nail on the head with the privacy suggestion. I have not set them up yet but did experiment with a few. One was referring to a field in a now deleted table, other’s rely on the user being logged in and I had changed browser today and had not run the index page so was not logged in. I’m going to dive into this tomorrow (it’s after 9om here now) because I think you nailed it. I had not even thought of privacy rules. Nor, incidentally had I noticed the ‘ignore privacy riles’ checkbox - there are just so many of them. I let you know how I get on.

1 Like

Ha, sorry missed the picture of your simple search criteria.

Yeah, run that workflow with “ignore privacy rules” turned on.

(Just about the ONLY place you’ll see comma separated lists of nulls in Bubble is when a privacy rule keeps some parts of a thing from being “visible” but other parts of it are… You can sometimes observe this in the “view source” of a page, for example.)


Another thing learnt today … shame some of them have to be so hard won :tired_face:

1 Like

I did a quick test on a small batch of records and it’s working. It was a combination of privacy rules looking for a role in a table that had been deleted, another privacy rule requiring me to be logged in which I was not and surprisingly in an earlier API workflow, I had failed to pass a parameter but it was not showing as an issue until I closed and reopened my browser. So problem solved - thanks @keith

1 Like

:+1: glad that worked out!

This topic was automatically closed after 70 days. New replies are no longer allowed.