Checking the database for a User data type, if there is a result would basically mean they have an account and therefore are ‘signed up’…however, I couldn’t imagine a situation in which a search of the User datatype would return a result that would be indicative of ‘user is not signed up’ because from the simple fact that a result was returned on the user data type search verifies that the user ‘is signed up’.
If this were to address the issue of a allowing a workflow to run workflows and create something in the database when the user who performs that action is not a registered user of the platform and therefore ‘is not signed up’ then this would make more sense as I could search for a datatype of ‘Restaurant’ and determine if the ‘Creator’ of that ‘Restaurant’ ‘is signed up’ and if the value of the ‘is signed up’ returns as false, I would know that the ‘Restaurant’ was created by a user who was not a registered user.
Searching the database for User data type though to me is not a potential use for the ‘is signed up’ evaluation as mentioned, no matter what it is already clear that a User data type entry that returns a result is returning a User in the database who ‘is signed up’.
That seems to be what I have said above about searching for Users and results indicating the user ‘is signed up’ and there is no need to use an evaluator to glean that information.
However, having an operator for ‘user is logged in’ can be helpful for various reasons, such as indicating in a Chat feature if the User who is part of the conversation is currently logged in, indicating they have an active session. I believe that is an evaluator that is actually going to be more helpful and valuable in more situations.
I think that it could be something that is a feature and an available function and the security/privacy concerns be left up to the developer themselves. We already have access to privacy rules, and in my mind Bubble should not be held responsible in any way for privacy issues related to an app that a developer put together with poor privacy controls.
Giving us in the privacy controls a field to check to decide if we the developer want to restrict the exposure of the ‘is logged in’ evaluation, just like we can do with the User data type social media login, slug and all other data fields on that User data type.
I can think of plenty of examples of when we might want that complete control, and thinking along the lines of an application with companies who have employees who communicate with each other, the privacy rule can be constructed to say when the ‘current user’s company is this users company’.
I was live in a Bootcamp session looking at a student’s app who is from Italy and I thought it was some kind of difference in the way the translation was working, but later saw it in my own app and was taken back by the change.
My first reaction to it was that it would function differently than the existing ‘is logged in’ and instead would help us to evaluate if a User who is on the app has actually ‘signed up’ or not…something that lead me to believe evaluating that would be related to the cookies tracking users and determining if they are a registered user or not as it relates to them creating data in the database when not ‘signed up’ or ‘logged in’ and the data field of creator would be the ‘ghost’ or ‘anonymous’ type of user.
Absolutely and this crops up in various areas, such as the ‘parent groups width’ versus the ‘container width’ when setting the collapse width or hiding rules in the responsive editor…no reason for using two different terms that mean the same thing because it leads to confusion.
Also crops up in things like API stuff as mentioned in this post
http://forum.bubble.io/t/proper-syntax-for-created-date-creation-date/174643?u=boston85719
The wording of ‘user is signed up’ is very confusing and I do not think does a decent job of conveying the actual functionality of the operator. ‘Is logged in’ was much more self explanatory and I personally think does a much better job of conveying the functionality behind the operator.