I’m continuing to learn Bubble through hands-on practice and I’ve come back to you for help with a new question.
I’ve set up API payments. The backend workflow listens for HTTP notifications and logs the information in the database. However, unfortunately, this data is not associated with any user.
1 - created with workflow
2 - created with backend workflow
The ‘Created by’ field is empty, and I can’t figure out how to display information about a successful payment to the user on the frontend.
Could you also advise how to change the payment status from ‘pending’ to ‘succeeded’ using backend workflow?
PS: I’m able to catch the ‘pending’ status when a payment request is made, but I struggle to track when the status turns ‘successful,’ and I’m unable to link the payment data to a specific user.
Ditch Bubble’s created by field and create your own field to track the user. Presumably you can extract some identifier from the request body, use that to search for a user, then update record accordingly.
Why, what’s the issue? Do you know which event triggers this status and are you listening for this event?
Alex, thank you so much for your response. The event is being tracked correctly. Ultimately, a new line is created through the backend workflow, but it isn’t associated with any user.
This will be the last resort if we can’t manage a more elegant solution.
+1 - it’s really straight forward, and particularly important when heavily using the backend (for instance, what if a webhook is received and you want to assign the created by field to a specific user?). It’s fairly elegant, and you can set up a DB trigger with the following condition:
Only when Thing before change is empty and Thing now’s createdBy is empty:
Make changes to Thing now → createdBy = Thing now’s Creator.
createdBy should be a field of type User. This database trigger will mean that everywhere in your app that a Thing is created, the manual createdBy field is automatically assigned, unless you specify it whilst creating it, in which case the condition won’t run
That means that you can:
Override Creator field when you need to by referencing createdBy
Don’t need to backtrack over all Create a new Thing actions, as the trigger will automatically set the createdBy field to be equal to the Creator field when a thing is created.
@georgecollier would you be able to break this down for me?
Currently struggling with the same issue. I have repeating groups that use ‘search for’ and then ‘created by: current user’. But I have just added a backend workflow and when I run the frontend workflow, which triggers the backend workflow, as OP stated, the ‘created by’ is blank.
So I stumbled upon your response, which sounds like it’s the fix, but if I’m honest I don’t fully understand it.
A few questions…
Would I create this as a new data type, or just add as a field to ‘User’?
Do I set this to the ‘create a new thing’ in the backend workflow or front-end?
I think I’m getting confused with the naming conventions in your example.
Thanks @georgecollier that makes sense regarding that, but the issue I have is there doesn’t appear to be any user identifier from the request body in the backend workflow and so I fail to see how or where I can attribute any change to the new ‘Created By’ field.
Well the contents of your backend workflow must be attributed to a user somewhere, right? For example, Stripe doesn’t return a User ID to Bubble, but it does return a customer ID, and then I can search for the Billing Account with that customer ID and then find the Billing Account’s User.
Well how do you know who’s request the image is for? Clearly you already have some way of doing it.
When you make the API call, the ‘id’ field will be returned. You should save that to an AI Image. When the webhook comes in, Do a search for AI Image where id = Request Data’s ID and that will find the corresponding image.
If I understood correctly what you need, then here’s the simplest option.
From the workflow, you create a Thing and write the task ID in the field (you will have the user association). You pass the task ID to the backend workflow. You modify the thing with the constraint = task ID and add the necessary values you need.
