Getting this warning If the app uses the US...

[Himanshu_Gupta]

Getting this warning

If the app uses the USEREMAIL() function, it must require users to sign in. As currently configured, the behavior of this function is unpredictable and will stop working entirely on Jan 20, 2018. Please fix your app before that date.MORE INFO.

What could be the alternate of useremail() as i want to capture the email while using same premium version ?

Thanks in advance…

[pravse]

Your app must enable user signin. You can do that on the Premium plan — just go to the Security pane and turn on the option.

[RezaRaoofi]

Security > Require Sign-In pane and setting the “Require user authentication” option.

[RezaRaoofi]

@Lauro_de_Freitas what I dislike about being moderator is that sometimes it is hard to tell my personal idea without looking biased, but I am saying it anyways!

I disagree with you in AppSheet sucking people into using freemium; especially in this case of USEREMAIL(); they have been always clearly mentioning not to use Per App or Publisher plans if you need to recognize users in your app, or have anything to do with customization for users. Here are 2 questions I just copied from pricing page that refer to scenarios you need Per User plans: . . - Do you need to restrict app access to particular people? - Do you need to customize the behavior of the app based on the specific user? . . If you are so relying on USEREMAIL() function that now losing it is a big impact on your app; I would assume you are most likely doing one of the above on a Publisher plan, just because the USEREMAIL() function happened to work on per app plans.

[RezaRaoofi]

@Himanshu_Gupta Yes, the best approach is to switch to a Per User plan. Standard, Premium, or Pro.

[Himanshu_Gupta]

@RezaRaoofi i am not customizing app based on specific user but I just need to capture who filled what and so far it was working awesome. This app is used by 40 people on ground thats why i am worried

[Himanshu_Gupta]

What could be best replacement of publisher plus ? standard premium or pro?

[pravse]

@Himanshu_Gupta, if you have the same set of 40 people (eg: your team in your company), then a Secure plan is definitely what you need. Whether Standard or Premium depends on the feature set being used. The system will tell you (go to the Manage -> Author pane)

[pravse]

+Simon Langelier, if you use USEREMAIL() inside a conditional expression, your app is currently not reliable in its behavior — because a user isn’t required to sign in but you are trying to change behavior based on their useremail() – and this value isn’t available unless they sign in

[Lauro_de_Freita]

@praveen

You state the USEREMAIL doesnt return a meaningful value if a user is signed in, true. But I think the app maker should check the value returned in his designing of the app (like a checking to see if an object has a NULL value in OOP)

You also implied app makers dont check / test their app when they signed in as app creator, and hence they dont notice this function doesnt work. 1) They should. 2) I do check my app as an ordinary user.

You said: “UserEmail happened to accidentally work some of the time.” No, not accidentally, not some of the time. I know what UserEmail returns, how my app behaves when someone is not signed, it behaves consistently all the time, and Ive designed the app to handle the case scenario of someone not signed in.

Just my opinion.

[pravse]

I just added a new top-level thread. plus.google.com - Clarifying user sign-in requirement when using USEREMAIL() As some of you kn…

At the end is a request for any app creator affected by this to send us information.

We will need you to move to a Secure plan, but we can help you figure out the lowest cost transition. Clarifying user sign-in requirement when using USEREMAIL() As some of you kn… plus.google.com

[Lauro_de_Freita]

@praveen

I saw the same message while editing the app and posted a query (now deleted).

Your reply doesnt explain the message. We are on a per app plan (Publisher Plus). We are fine with not requiring user sign-in.

Will the function be retired/made obsolete on Jan 20th? Why? Our app uses the function.

It seems to me that you suck people in to using AppSheet to make apps on freemium or low cost plans, but then change functionality/features to force them on to higher paying plans (STANDARD or PREMIUM).

Another example of this is the ability of the app-maker to copy textually the app definition to see the difference between versions of the app. I posted in the community about this (15 weeks ago) and the response I got was that this type of functionality is on more expensive plans, but you would think about similar functionality for other plans (see your reply below):

"Hi @Lauro_de_Freitas, I understand the ask. It would be at the “definition” level since there isn’t actually any “code” generated per app.

It sounds like the app update functionality is what you want, but you aren’t using it because of the plan you are on.

We provide some kind of diff in the version history but it isn’t very readable. Also when there are very large differences between versions, they are not captured.

Internally, yes we can do a diff. We need to find a meaningful way to expose this to users."

I recommended AppSheet to two other units outside our charity unit, but this, along with other things is making me rethink this.

[pravse]

Lauro also sent me direct email, so copying my response as explanation.

Thanks for contacting me.

The problem with USEREMAIL() is that it depends on users signing in. Otherwise, the function doesn’t provide a meaningful value. So for this to make sense, the app requires signin.

Now what has been happening is that app creators do not set up the app to require signin. They leave it as a public app. When they try the app, they themselves are signed in, so it appears to work. But when they distribute it to their users, it works for some users (who happen to signin) and not for others (who do not happen to sign in). They report it as a bug, their users are not happy, etc.

Further, in apps that do not require user signin, we assume we can be more aggressive about things like caching/sharing data across user accesses, because we know that the data is not different per user. This assumption is flawed if you are using USEREMAIL() inside various expressions. So there are correctness implications as well.

All of this is because we didn’t check for this, as we do for so many other app consistency issues. So that’’s why we’re starting to check for it — if your app uses USEREMAIL(), it’s got to require signin. This isn’'t about “removing” functionality that is working. It is about fixing functionality that was never supposed to work but happened to accidentally work some of the time.

[Simon_Langelier]

I use this fonction for one year now. I have 10 day to change 4 applicaitons use by lot of people. it a short time for me… do you have a quick solution?

[pravse]

Will discuss internally if we can extend the timeframe to the end of the month.

However, if your app is using this currently, it is currently executing in an unpredictable/buggy fashion. Where is the USEREMAIL() function being used? Is it in an AppFormula by itself, or is it being used inside condition expressions?

[Simon_Langelier]

It is use inside a condition expressions and I have no issu with this feature.

Ex:

Or(useremail()=xxxxxxxxx,useremail()=xxxxxxxxx,…

[Himanshu_Gupta]

Hey all i have a small doubt I only use useremail() for capturing who filled the response and that too from app formula so do i still have to upgrade it to user sign in?

[Himanshu_Gupta]

And where to switch if that is mandatory clause? currently

am using publisher plus, do i need to upgrade to

upgrade to secure plan->>Standard ?or secure app ->>premium ?

[Himanshu_Gupta]

I am more worried about the complications in this transition