One of my users created a data when they are logged in and it doesn’t reflected for them.
When checked the data shows created by as "deleted thing " any thoughts on why this might happened.
Hi there, @gokulmuniappan007… if you want the community to try to help with this one, you are going to need to share details (screenshots) that give us a lot more insight into what might have happened. The simple answer (thought) is that the account associated with the user who created the data has been deleted, but there is no way of knowing what actually happened without more details.
If you don’t want to share those details in the forum, file a bug report so Bubble can look into the issue for you. Oh, and there is no need to tag Emmanuel and Josh in a post like this one… I promise they are a bit too busy to dig into each person’s potential issues. 
Best…
Mike
1 Like
@gokulmuniappan007 this is because Bubble doesn’t map the created by field to a user who after creating data while logged out, subsequently logs in during the same session. So, Bubble leaves the created by field blank and after some time they label it as ‘deleted thing’.
Bubble only maps the created by field to a user when the data is created by a user who is logged out and subsequently creates a user account in the same session.
It makes no sense to me why they don’t.
@mikeloc do you have an idea of any technical reason why Bubble would not be able to easily implement the same exact feature they use for tracking users in a session who subsequently create a new user account versus log in to an existing user account?
Below is the response from support
They’ve shared that this is a hard feature request for a few reasons because it entails:
- tracking all the things that are being created by the anonymous user (easy-ish)
- modify them all at once, rewriting the created by field after a log in, but technically not perhaps not changing the modification date (because technically they didn’t change — this is more of a product/design choice)
- handle the case where things are created right after a log out, or a session switch - while “shopping cart” example works out, a lot of other examples may not adapt as well to this concept of “assignment of created by after creation”
Isn’t this all what they already do using cookies for a 72 hour period to map any data created by a user who is logged out and subsequently creates a user account?
I ran into this issue and submitted a bug report because when a user in the app creates a booking while logged out, and then they log in to their existing account the created by field is empty and turns to ‘deleted thing’ whereas a user who creates the booking and subsequently creates a new user account the created by field is mapped properly to that newly created user. Same exact steps, only difference is signing into an account versus creating an account.
You sure your “user” wasn’t a cookie? Bubble uses cookies by default, which will get deleted eventually. If a user signs up for your app before the cookie gets deleted, that user gets attached to those records he created.
Yes, and that is working fine.
The issue is that if a user doesn’t create a new account, but instead logs into an existing account, they are not getting attached to the records they created, even though they are logging into the account 1 minute after creating the record, so well before the 72 hours of cookies would expire.
Ahhhh. This is a problem.
I know this one is really bugging you, @boston85719, because you bumped this thread, posted two other topics about it, submitted at least one bug report, and also put the idea on the idea board. If it is really getting in your way, you should consider going the local storage route, as Keith suggested in your other topic.
As Keith also mentioned in his reply, the answer to your question is simple. The reason Bubble doesn’t implement this feature isn’t technical in nature. The system simply doesn’t currently do it, Bubble is unlikely to implement it in the near (and probably not-even-close-to near) future, and here is almost certainly why.
I can all but guarantee the feature is not as easy to implement as you might be thinking, and Bubble said the same thing in their reply to you. Combine the fact that it is not a slam-dunk/no-brainer feature (from an implementation perspective) with the fact that in almost five years out here in the forum, I don’t remember seeing too many other people mention that the lack of this feature is getting in their way, and I’m afraid you are on a pretty remote island, my friend, and help isn’t coming any time soon.
Sorry, Boston, but it really (probably) is as simple as that. So, before you go nuts and start talking to a volleyball, I think you are going to have to let this one go and consider going the local storage route.
1 Like
Thanks for the reply. It does seem like the simple answer is that Bubble doesn’t do it because Bubble doesn’t do it.
I’ve never been one to not try to understand things that don’t make sense to me, which is the reason for my persistence in trying to get a more technical understanding of what is the difference between a newly created user and a login to existing account. Since Bubble does the mapping of created by for a newly created user, but not a login to existing account, I am very curious as to any technical differences between the two types of users (newly created versus login to existing account).
I’m also never bashful about trying to help push Bubble as a platform to be better, and in my mind it would be better if Bubble were to make it so a login to existing account is treated the same as a newly created account in regards to mapping the created by field.
I’ve also been running into a bunch of headaches with the Bubble API Replace not working properly as per the documentation ( https://manual.bubble.io/core-resources/api/data-api ). In my case I am getting very confusing results with it.
Having a call setup like below results in a confirmation popup indicating the call was sent through properly, but in the database of the other Bubble application, the fields for ‘created-by-api’ and ‘ssn’ are empty and the built in fields are not changed.
If I instead change the setup to not use the query string checkbox, I get an error.
But as per the documentation the Created By field, and the other built in fields which also produce this same error, are all entered as would be in a Get call just like the documentation indicates.
What is more troubling here for me is that when I do not include the built in fields and I have the setup without the query string checked as below, the values of ‘created-by-api’ and ‘ssn’ come through properly.
However, the documentation states any built in fields not sent via a Put call would be deleted, but that is not the case in this situation.
So, I’m having trouble using built in Bubble functions to achieve a simple task of replacing the created by field as workaround to Bubble not treating a login to existing account the same as a newly created account for mapping the created by field.
I know there are other solutions out there that are built by very reliable and trustworthy 3rd party developers, or other workarounds like not using the built in field of ‘created by’ and have a different field related to user, but I try as much as possible to optimize my applications with using only Bubble default features. At this moment it seems like the Bubble default features are not working properly (Put calls for Bubble API) or are not performing as I might expect (use of cookies to map created by to a login of existing account).
When I searched the forum for other suggestions or solutions I found threads dating back to 2015 about the created by field not getting mapped, and a couple from this past month as well. I suppose the original poster of this thread had a similar issue to mine and might not have explained it in as much detail or provided enough screenshots to be clearly understood as the same issue I am facing.
In the end, I will never hold my breath for Bubble to add new features, but I’ll continue to raise my voice to express my ideas of how certain new features could be very beneficial not just for me, but the community at large.
One of the major use cases for the need to have the created by field mapped to a login to existing account is a shopping cart in which users can select products without being logged in. What brought me here is my work for a client who wants to iterate over the point in the sales process that a user is forced into logging in or creating an account. I’m sure there are a lot of other users who are building e-commerce platforms that would benefit from the same mapping of created by that is done for a newly created account to be done for a login to existing account.
Hopefully the API issue would be fixed, or at least Bubble support would point out what I’m doing wrong there.
Amen to that, man, because I do exactly the same thing, and that approach has served me well from day one on this platform.
Now that I read my reply again, I can see it is based in the cynicism/skepticism that has come from two and a half decades in the software industry, with one of those decades having been spent in product management fighting the never-ending prioritization battle that always leaves a subset of your customers unhappy. It’s a tough gig for sure, and I don’t miss those days at all.
Like you, I have run into plenty of limitations during my builds, and I always go straight for a workaround as opposed to trying to make my voice heard to Bubble. I’m sure lots of folks would argue I am doing the platform a disservice by going that route, but again, that decade in product management did a number on me, and I always figure, eh, why bother? Case in point… I have been one of the most active members of this forum/community over the past five years, and I have been quite vocal with members of the Bubble team (not unsolicited, of course) about the ways in which this place is going downhill. Despite all of the feedback/examples I have provided, nothing has changed, and my cynicism/skepticism continues to grow… but I digress.
Anyway, keep fighting the good fight, Boston, because I’m sure trying to push the platform to be better is actually the right thing to do.
1 Like
As you are very active and invested to help Bubble via the forum, you should definitely communicate via support about issues you may face. One thing that I have noticed is that I routinely submit bug reports for issues that I’m told is not going to be fixed and is a known limitation. Often, support provides a work around solution that had been shared with them or they came up with. I regularly provide support with the work arounds I come up with when a bug is known limitation to hope they share that with others as well.
Is that ‘place’ a reference to the forum? I’ve heard similar views from other long timers as well.
In regards to feedback about Bubble as a platform, I’ve been actually pretty happy with the way Bubble listens. It is like my four year old. Tell them once, count to five in your head, tell them again, count to five, tell them a third time and their attention snaps to and they follow the directions provided. Basically, they are focusing on so many things that it is hard/takes some time before they can focus on just one thing and get it done. I’ve seen some long standing issues fixed in the last several months and I’m confident they will be cleaning up a lot of things as the engineering team expands in numbers as they plan.
Yup, definitely the forum, not the platform. I can’t get enough of the platform, and I talk about it with anyone who will listen. I apparently can’t get enough of the forum, either, but as I have said a number of times, that’s a sickness, and I’m getting help. 
2 Likes