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:
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.
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?
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?
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
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!).
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.
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)
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!
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.
