Anyone else has this problem with sending emails?

when I apply a condition to send a warning email only when the other user is not logged in I should send, but the user is not logged in and does not send the email, but if I do not put any condition or put the condition only when the user is logged in if he sends the email even though the user is not logged in, it is strange.

user logged in is probably referencing the current user (not the other user) so that could be the problem.

If that’s not it, perhaps try adding the same logic as a text field on your page so you can see what value it’s showing for other user is logged in.

Hi,
the logic is correct, a notification is sent to the email of the user of the parent group, but adding this condition does not send the email, it is something rare and I wanted to know if someone else has the same problem.

I also tried to see if the parent group user is logged in, but is not logged in, so I do not see what the problem is, I do not know whether to make a bug report about this.

Does the logic work when you put the same logic on the user interface, perhaps as a text field? If so, then I’d file a bug report because the behavior is inconsistent which is a bug.

If it doesn’t work on the UI either, then I’d use debug mode to see what what’s going on (debug_mode=true). That may clarify it, one way or the other.

in debugging mode it does not show irregular information, everything works fine, but it is obvious that it is not, I suppose I will make a report to analyze in depth, I will follow up on this to see if this issue would be helpful to other users who have the same problem.

Yeah, sounds like it’s worth a bug report then.

I was followed up on the case, the engineering team supported me and detected the problem, I asked for help in the forum recently about this.

http://forum.bubble.io/t/how-to-change-the-permanent-registered-user-as-not-connected/35298

Do not misunderstand the difference between “Current User” and the “User” data type.

Data about your registered users is stored in your app database as fields in the User datatype. (“Duh. I know,” you say.)

But “LOGGED IN” is NOT one of these properties. Why is that?

And, what is “Logged In”, anyway? Logged In is a TRANSIENT (not stored) property of something callled “Current User”. It is not a field in User. Nor is it intended to be.

What (or who) is “Current User”?

“Current User” is an abstraction — it’s a metaphor that we need to be able to program things that happen on a page in our site or app. “Current User” at its core, just means — there is a connection open to this page.

A human being using a browser might be “Current User”. A bot like Googlebot might be “Current User”. If my app attempts to make an API call to your page, that connection is “Current User”.

“Current User” is just a convenient term for “something has this page open”, as it were. It’s a metaphor for “session”.

It is also a way to distinguish THIS User (the user we imagine is using the app right now in a unique session) from many OTHER User’s in our database.

Question: What can we know about “Current User” in general? Answer: Precious little. We can only know what the browser (or User Agent, as in the case if my hypothetical API hitting your page) will tell us.

That is, UNLESS, the “Current User” logs in.

Once “Current User” logs in, we can be sure that the browser/agent session represents a person (or at least, an authorized agent of said person) and we can make a connection between a USER (data object) in the database and the current session.

So, “is Logged In” is just the difference between an unauthenticated session and an authenticated session. IT IS NOT SOMETHING WE CAN EVALUATE to know if registered user joe@blow.com is currently authenticated to and using our app.

See?

We need to have a “Current User” concept and need to be able to differentiate between “is Logged In” and “is not Logged In” users for pages to know what to do with open sessions.

For example:

  • We imagine what happens when a user with no account randomly hits an admin page: Do we let them see it? Do we give them permission to click buttons and change data? HELL NO. So, PRIVACY RULES must be able to differentiate between (first) whether “Current User” is Logged In or not. For “Current User” NOT Logged In, we can either challenge them (“Hey, log in to see this page”) or just bounce them (“When Current User is not Logged In, navigate to index page”), etc.

  • Once Logged In, we might make different decisions about “Current User”’s access to things. Now that we have established a connection between a session and a User object in the database, we can get more granular.

But here is what you must understand: Logged In is essentially a property of the SESSION. It is not a property of the User object.

Here is (one of the reasons) why folks get confused on this point:

If I visit a page in your app, but I’ve never been there before and have never signed-up (registered) or logged in, the app can still treat me AS IF I have an entry in the database.

How is this possible? How is it that I have no User object associated with me, but you might drop data on my “User” object?

The answer is cookies (local browser-based storage) and temporary database objects… both of which expire at some point unless I establish a definite link between my temporary stuff and a permanent User object. (Which Bubble does when I “sign-up” for your site/app.) Also, I DO have a User object and a unique ID for that object, if you do some data dropping operation on me. It’s just a temporary (transient) one.

So you may still have this question: “Well, if there’s an authenticated state to the session, why doesn’t the User data object know this?”

The problem is this: Logging out. Practically speaking, your users do not manually log out. They CAN, but they don’t. So you can know when a user logs in (during your log-in workflow you could set a property like “Current User’s Last Login” to Current Time/Date and we might also set a Boolean like User’s Online to “yes”.

But what about when that user logs out? IF they log out manually (click a log out button), you could know for certain that that user is no longer logged in and so is now logged out. (Before logging them out, we could store the time of logout and set User’s Online field to “no”. )

But what if the Current User never manually logs out? (And again, Users hardly ever manually log out.). What if they just go AFK (“away from keyboard”)? What if they close the browser tab? What if they close the browser? What if they shut down their device? What if there’s a power outage? An internet outage?

Answer: We cannot know these things. And so, our handy User’s Online is “yes” is of little to no value as it goes true (“yes”) on log-in, but rarely goes false (gets set to “no”), except in the case of an explicit manual log-out.

So, if you desire to know this, you have to make assumptions and inferences about at what point you decide a user is no longer “active”.

How much time must elapse since the last user action that we can detect and track before we decide the user is assumed to have gone away?

Only YOU as the app designer can determine that. There is no good default for that. Different apps might judge user inactivity in vastly different ways. Is the gap hours, minutes, seconds, milliseconds? Only YOU can judge this. Every app will be different.

So there’s not a built in property for that.

Long story short: You can know when a session is opened (or when a user logs in) but you cannot know for sure when the session closed (or the user “logged out” unless they explicitly choose to do so). Potential workarounds and some of their limitations are described above.

Also, “Current User” does not have any automatic connection to a User database object. The property “is Logged In” is not a database property, but a transient property associated with a session, NOT a specific user in one’s database. That is, it IS NOT a field on User, nor should it be.

“Current User” is an abstraction that should not be confused with any object of User datatype in your app’s database. However, if “Current User” is Logged In, we can understand that there is a User object in the database that represents the person or system that has opened a connection to our app.

3 Likes

I think it’s an interesting topic, it’s a topic that I have not seen that was discussed in the forum.

This topic was automatically closed after 70 days. New replies are no longer allowed.