Saving image to Bubble Storage from URL: stored under different user ID

DanielH · 2024-10-23T19:23:59.014Z

I’m building a user signup flow. The flow uses “Create account for someone else,” so the person (technically a logged-out “user”) creating the new ‘user’ account has a different uniqueID from the account that is being created.

Person creating the account is User A, the account being created (‘for someone else’) is User B.

User A creates a Thing (image) via a workflow for the new user B.
Workflow first stores a dynamically generated URL (to a 3rd party image generation service) into the Image Thing:

Screenshot 2024-10-23 at 3.17.46 PM676×640 39.8 KB

Next WF step modifies that Thing to save the image to Bubble Storage:

Screenshot 2024-10-23 at 3.17.02 PM676×448 32 KB

Problem is, the image is saved to Bubble Storage (“File manager”) under the UserID of A, not B. How do I correct this so the image in the file manager is properly associated with the actual user of the image (user B) and not the creator of the image (user A)?

This is a problem because ‘user A’ is/are anonymous web visitors and I have no need to relate any files to them.

Thanks.

net-tt · 2024-10-24T08:49:08.659Z

Create a User field to Image data type and assign User B. When a data type can be created by another user, you need a User field to contain that user.

DanielH · 2024-10-24T15:39:14.908Z

Hi and thanks for the response.

Thats what I thought would do it, but it does not seem to work. If you look in the 1st screenshot of the original post you can see I have a “Owner” field that is assigned to the B user, which is created in the prior step.

Is this what you meant, or am I missing something?

DanielH · 2024-10-24T15:56:03.643Z

I thought I had figured out a solution, but it was a false positive.

I created a second field on my Image Thing and made it an explicit ‘image’ type field instead of a text field (which is what the external image URL field is).

Still, in either case, when the image is saved to Bubble it get assigned the userID of the logged-out user A.

The initial question remains: how do you control file ownership in cases where Bubble saves files directly to the file manager?

tylerboodman · 2024-10-24T17:40:38.655Z

Maybe you could do some gymastics like URL:saved to Bubble Storage:formatted as base64 and use the Base64 to reupload it to your app with a different owner. Then delete the original :saved to Bubble Storage file since its the old owner

This is a screenshot from a plugin so some of the boxes will look different in API connector

image1473×1698 195 KB

DanielH · 2024-10-24T20:15:35.593Z

Hi, thanks for your suggestion.

I have not played with converting into/out of base64. I may give that a try at a later date, however it seems that would add many extra steps/workload.

Plus, you still have the basic issue of how to find the original file since its saved to a random user ID (for anonymous visitor/user A).

More generally, is duplicating then removing a file really the ‘best practice’ on changing a file’s ownership/user ID? Conceptually, if you knew the user ID of the original file, I guess you would have to use a backend workflow to actually do this, otherwise you’d run into privacy rule issues (one user should not be able to delete the file of another user!).

Jici · 2024-10-24T20:19:05.579Z

Similar to what @tylerboodman suggested (this is doing almost the same thing) is to use this plugin:
File Uploader Bubble API Plugin | Bubble

DanielH · 2024-10-24T20:34:23.627Z

Hi Jici, thanks for referencing a plugin for this.

But won’t we be in the same place as now when it comes to removing the original image? The original image is saved to a UserID of a random web visitor (user A), not the userID of the registered user (user B). So we don’t know the original userID.

Maybe I need to step back a moment and think more carefully about this: I feel like I’m going in circles and it (file management) shouldn’t be this difficult.

Jici · 2024-10-24T20:52:42.823Z

If you want to manage privacy for 1 file but 2 different user, it will be better to link the file pivacy to a things and set, for example, a user field (list) that will contain both user and use this field to allow access to the file. The privacy will be attached to this item instead of a file. But your case is user A doesn’t really exist, so not sure what is the issue with the original file.

The plugin will leave the original file (attached to user A) and create a new file that you can attach to user B (but it will be two files)

DanielH · 2024-10-24T21:00:19.785Z

Jici:

But your case is user A doesn’t really exist, so not sure what is the issue with the original file.

This is what I’m stuck on. Since A doesn’t exist, I do not have their userID. So how do I find the file that was originally uploaded under this ID in order to remove it?

I guess I could add another field to a user Thing along the lines of “pre-registered user ID” and, when I create the actual account (user B), I can save the “current user ID” into that field. Then my ‘delete original image’ workflow would reference that ‘pre-registered’ userID. But man, that is not very elegant!

DanielH · 2024-10-24T23:25:15.467Z

As it turns out, deleting a file from the Bubble storage is more limited than I thought. The ‘delete an uploaded file’ action requires searching the db for the the “File URL”. So I guess you can’t remove a file directly–even if you knew the User ID or exact filename–you have to ‘find’ the file via its relation to some other Thing.

(I’m not sure what the User ID field in the File Manager is actually useful for, as it does not appear you can search by it in the FM or a WF action)

So I’m going to forget about the ‘UserID’ in the file manager entirely and just focus on finding the image based on the relation between the new user (B) and Image Thing.

Its a little annoying, as now we have to remember the User ID in the file manager is meaningless if we ever have a situation where we need to audit a certain file.

Anyway, I’m marking this as solved since we will just focus on the database Things for any file references.