I’m very much hoping I’m just an idiot, but feel like I’ve read/tried everything and that I’m on the brink of losing my mind regarding a feature I assumed would be table stakes for bubble.
Here’s the quick of it:
I get an API response with embedded JSON from Open AI so bubble is unable to parse directly from the message.
No problem. I’ll just shoot it over (POST) to an internal API endpoint that has to be set to public in order to use the detect data feature for bubble to parse the JSON.
Yay, I can now run database operations on stuff bubble can understand.
EXCEPT… because we’re passing an admin api key everything is “created by” app admin. I need each of these things to be “created by” the user who triggered the request.
Is there not a way to either A) pass the entire parsed (bubble-readable) “request data” back to the original call so I can trigger the db actions under the intended user?
Do i need to send each object in each array back individually as a list?
I just feel like I’m missing something. There’s no way bubble’s intended action is that we have to pass each individual data fields around and jump through these hoops parsing data manually to process it, right?
Someone tell me the thing have I neglected to do that will make me feel dumb for posting this
An alternative would be to create an “Owner” field on the response datatype, of type User, and send in the UID of the user into the internal API post call, and using “Owner” as the search constraint rather than “created by”?
Yep, definitely that is my last resort. Unfortunately I’m pretty deep into a project, so it would require a lot of work to rebuild and retest stuff. Just can’t believe this is the only way?
There’s a way to capture the user token at their next login, and save it then use that in the API call later. try searching for it. I am away from computer right now to find it
@danschlung I have long ago needed to stop relying on the created by field. Although I thought it was great to rely on, and why wouldn’t we since it is a built in field created for every entry, but it has too many issue.
Besides what you are experiencing, which looks like @chris.williamson1996 gave a great solution for, I’ve found other reasons it is not something to bother with and instead I use a custom field of User-Owner.
Bubble cookies to map users. When a user is logged out and creates data, Bubble cookies of 72 hours will correctly map the user to the created data if they register an account and login within those 72 hours. However, if the user has a registered account, is logged out while creating data, then logs into their existing registered account, Bubble doesn’t map the data to the user.
The empty or ‘deleted thing’ values makes it impossible to search for data entries using constraints of ‘created by is empty’ to try and find abandoned data entries.
Other reasons not due to Bubble, but potential features
Employees who leave a company, the data should be transferable to a new employee.
Creating accounts on behalf of somebody else, which also creates other data at same time that needs to be properly mapped to the newly created account
Running backend workflows that create data when the user is not logged in…for me this is usually when working with webhooks that once received will create other data entries.
I’m sure there are other reasons that I have forgotten or not uncovered yet, but for me personally, I no longer utilize ‘created by’ built in field…however, I have bookmarked the solution from Chris as it does make sense to have that field be as accurate as possible even if I’m not utilizing it in any meaningful way.
The default creator field should be avoided for exactly this reason - always have a User field on the relevant data types. Generally, that’ll be the same as Creator, but there are plenty of instances you’ll want to create things on behalf of someone else but still have them belong to that person.
It’s generally a best practice for Privacy Rules and General App Management to have a “_User” field on each data type. This allows you to set good privacy rules and also gives you more flexbility as the native “Creator” Field cannot be edited.
webhooks leading to Create a new Thing (perhaps Stripe payments/Invoices)
backfilling / creating data from BE workflows (let’s say you screwed up and made chat messages a list of texts on a conversation data type and need to create a new Message thing for each of those texts)
any time you use the app connector or API connector for internal API calls (at least in its simplest API token configuration)
Oftentimes you can use the fact that the Current User is passed between scheduled API workflows, but that won’t help every case. If we work on an existing app, one of the first things we do is migrate all use of Creator field to the User field (so we can deal with other optimisations and refactor DB if necessary whilst still keeping the data owned by the right person)
@chris.williamson1996 this is brilliant advice. Security is the #1 reason I didn’t pursue the store & pass API route, as I ran into exactly the issue you described having to expose the data. Obviously a non-starter.
I spent the entire weekend on this (with sooo much reading of the forum, manual, youtube, etc, i promise) & had no idea of the /auth backend wf option. Probably just didn’t realize what I should be searching for, I guess…
Still seems entirely crazy to me that there isn’t a built in method that accepts a passed json and generates the “request data” bubble can read without having to invoke a public API. (@allenyang this would be nice quick win for your next QoL day or whatever y’all call it, since the underlying framework is already built out )
Anyway, thank so much, Chris. I have plans to return to this problem early this week, so I’ll let you know how it goes!
yeppers! This was on the first “real” app I built when I didn’t know better. I now use a “mapped-user” on every single table that needs to be associated with a user.
haha nope. I spent a few years flying in and out of philly when i worked in consulting, but I don’t think that’s where i picked it up. I grew up in a rural area outside of Chicago, near the Wisconsin border, so I think it’s also a midwest thing. While I’ve been in Austin for many years now, old habits die hard!
)
I now use a “mapped-user” on every single table that needs to be associated with a user.