Hello everyone--up a creek with filtering without security filters

[nimble777]

Hey App World,

I am up a creek, again, with trying to accomplish the work of a security filter without using a security filter. My end goal is to automate the process of the system reading the driver’s email address and assigning him/her ONLY the loads that belong to the individual. I have tried, [Driver Name]=USERSETTINGS(“Driver”), I have tried, Usermail(), Username(), and several other options to no avail.

I am resolute to figure this out, but it has taken me many, many, many hours and feels almost like a hopeless cause. Can someone please help me out with an expression that might work? I am open to using slices, but have not found a way to correlate slices with behaviour yet.

Thank you so much!

P.S. I know this question has been asked at least a few times already, I simply could not find the other posts. My apologies.

[MultiTech]

Essentially you’re trying to circumvent AppSheet’s licencing policy - I would advise against this.

I get it, you don’t want to have to pay $5 per user (so things are secure, personalized, and all that), it can add up; but ultimately that IS what needs to happen.

---

If you’re resolute, I’ll give you my experience building out things like this (in the early days of the platform this type of build wasn’t against the TOS, but all of the old apps setup this way were eventually caught and needed to right the licencing… I’m just saying).

There’s no way for you to make use of the USERSETTINGS() or anything like that that would differentiate users from others. The only thing you can do is create a UserSetting that allows people to enter in who they are.

You can try and create a way to ensure they are who they say they are - with workflows, SMS/push notifications, custom security codes, etc. - but all of this is a violation of AppSheet’s TOS.

Now you CAN create a UserSetting where people can enter in their email or other info (for pre-population in forms) but you can’t use that for security filters, slices, things like that. (Well… … I mean you can… technically the system would allow it… but like I said before… TOS.)

---

You can make use of this switch, located in Date>Tables, to filter out all the rows in a table - this way the app functions as a data collection portal.

[nimble777]

Hi Matt, Ahhh, I hear what you are saying and I would never want to do anything against the AppSheet code. I was under the impression that security filters were for making data more safe, and that personalizing an app user’s experience (with information that was directed only for him/her) without using security filters was acceptable. :-0

The only reason I am asking this question is because I was told by my boss that apparently an AppSheet representative guaranteed him that the type of app he was trying to have built would be doable with the Premium option of the service. We are more than happy to pay the $5 per user, etc.

Does this clarify what I was asking for, or did my conversation with my boss get some wires crossed in translation?

[Bahbus]

It sounds like your boss was advised that to build what he wanted would come at a cost of a Premium plan. Which, of course, if that is the case, you might need to scrap what you have and start over with those premium features in mind. But I would also double clarify with your boss that he is willing to pay per user.

[nimble777]

Yes, to my knowledge he is willing to pay the Premium cost–matter of fact, we are already paying for Premium for one user.

[MultiTech]

nimble777:

an AppSheet representative

I would also reach out to this person for clarity.

[MultiTech]

nimble777:

personalizing an app user’s experience!

I’m not sure if personalizing the user experience would fall within the realm of this use of a public app.

Screenshot_20200218-071944|281x500

[Bahbus]

Because you have things “assigned” to people or types of people, you should scratch this and start over as a full-blown planned usage of user login. That way you’ll have a waaaaay easier time doing what you are trying to do since you’ll have the option of directly grabbing the logged in user’s email address.

Your attempt to keep this under a Public app is clearly the wrong route, and would potentially be against the TOS.

[nimble777]

Thank you gentlemen, I appreciate your feedback. @Bahbus @MultiTech_Visions