I have a data model where there is a Survey Thing, and the Survey has a field which is a list of Question Things, where each Question has various fields.
I have a serverside workflow triggered by a change in the Survey’s Phase field - if Phase was A and is now B, fire a custom event passing in Survey Now (ie. the object after the change to phase B).
The custom event then does a series of actions with this Survey, including one where I have a custom server-side Action plugin which builds some JSON to send to a third party service - it’s a bit beyond what Bubble could build natively, but easy to do with Javascript. All of the Survey’s non-list fields are populated and can be used as you’d expect. The Question list is populated with objects, it lists all the correct field keys, but every field is null except the unique ID field (which is correct). That means I can’t build the JSON.
I’ve tried changing the Survey passed in to the custom event to be the first item returned by a Search for a Survey where unique ID = Survey Now’s unique ID - ie. trying to force a proper reload of the object from the DB - but this has no effect, and it also fails if I try it within the custom event workflow. I’m not really sure what else I can do… is this a known problem? Is there an obvious workaround?
PS I have confirmed that in earlier steps, before my plugin is called, I can query the value of any field in any of the Survey’s Questions and they are populated - so this is likely something to do with the way Bubble wraps up the Things to pass them to a server-side plugin.
If I pass the same Survey into a client-side plugin, I can see all of the values are correctly populated.
FWIW the deeply inelegant workaround is to create an additional field for the Question list and pass that in directly, at which point they’re all magically populated. At that point I care less about this, but it’s hard to see it as anything other than a bug…?
Is the plugin purely there just to run Javascript? If you install the Toolbox plugin you can put a Javascript action right in your workflow and feed the unique IDs to that
You should set your SSA up to accept a Thing (I guess that’s a Survey in this case). When you do that, you’ll get the Bubble object that represents that thing (you might also pass a list of Things).
That thing has the .listProperties() and .get() methods on it. You use .listProperties() to know the names of the fields on your Thing and then .get() to return the value of whatever field(s) you’re interested in.
Fields that are themselves Things will again be Bubble thing objects with .listProperties() and .get() on them. If they are like that, you get whatever fields you need.
Field that are lists will be Bubble List objects (with .length() and .get()) methods on them. After being .get()'ed, you may have an array of JS versions of Bubble native datatypes OR you may have a list of Bubble thing objects, or you may even have a array of Lists, depending upon what the fields on your Thing are.
Thanks, that is indeed exactly how I established that I am getting the right number of Questions in for each Survey and that they each have the full set of keys defined with listProperties(), but the values retrieved by get(key) are null for everything except the IDs - unlike in a client side plugin, where the same code shows the real values. When run on the Survey itself, listProperties and get work as you described.
My guess is that Bubble is not passing in the in-memory Survey representation it was using earlier in the workflow, it is instead re-reading from the DB to ensure it is fully synchronized, and when doing so only retrieves the info available in the Survey thing (ie. the list of Question IDs is stored within the underlying Survey table, or at least is presented that way in the Bubble UI, while the other data would require further reads from the Questions table). Perhaps there’s a way to force it to do a lazy load of the Questions, but I couldn’t find it (calling get() without a key didn’t make it happen) - and you’d expect that to be triggered by get for keys it knows it hasn’t retrieved… so maybe an underlying ORM system bug
