April 16, 2021

Deployment Time: 11:05 AM PST

Features & Enhancements

None.

Bug Fixes

None.

Rollout changes

Item Rollout status
Authentication Groups do not require a domain. New: 100% of free users and 75% of paid users.

Previous: 100% of free users and 50% of paid users.

Preview announcements

The AppSheet Preview program lets app creators try out new app features that are not yet fully supported. Learn how to participate in the AppSheet preview program for app client features.

  • No new preview features were released today.

What's currently available in the Preview program?

Item Description
Feature Chart Editor

App Creators can now make use of our new chart editor and the new and improved charts it can create. Learn more.

Feature Filters in AppSheet applications

App users can now filter items from a collection of records based on column values.

The feature is available both on mobile devices and desktop computers. Learn more.

Feature Resizing column width in table views

App users can now resize the width of columns in any table view. Simply click and drag the separator between column headers.

1 Like

hi @praveen

Sorry for pinning you for this, it would be appreciate if I could borrow your time to understand this new feature.

I simply suppose this feature should be in conjection with Google Group/Domain stuffs, it that correct?

What this new feature is indicating what we can do more?

Appreicate for your clarifications.

@Gabe_Moothart and @kamila FYI

@tsuji_koichi … Koichi-san, this is meant to use in apps that already supported authentication via domains (instead of explicit lists of user emails).

We have already supported the ability to choose a domain (say mycompany.com) and make the app accessible to anyone in a group (say “admins”) within that domain.

It turns out that for some companies, the group definition does not need to match one-to-one with a domain. You can have groups whose members span multiple domains. So the change described in these release notes allows for that more general use case.

1 Like

Hi @Praveen, Thank you very much for the clarifications.

Just because probably I m missing the starting point to understand “auth groups” in this context, I m not able to catch up with whie I understand now we are able to add different domain mails to the groups.

Is there any new documents or step by step guide so that we fully understand what is now being capable under the platform? Without detailed docs, probably it would be difficult for community to understand this new fetures which should be super useful though.

2 Likes

Thanks for the feedback Koichi. We have two documents that describe this feature - we will be updating the screenshots shortly, but the step-by-step process remains largely the same (linked below). If they are not clear, let me know, I’ll be happy to update.

As Praveen mentioned, previously, this feature required that the domain of each group member matched the domain listed. This was an oversight, because very often organizations have members of groups with different domains. This change makes that validation optional, so it is relatively a small (but powerful) change.

1 Like

Hi @kamila
Thank you for following up and looking after the issues.
I read through the revised documentation, but sorry to say it is till not perfectly clear to me what is the new available feature with this.

My understanding was the Google DomainGroups can make a “group” of selected users, UNDER the same domain, like @example.com, as user for the group we generate, but taking the context of this thread we discuss, i assumed we are able to add group user whose email address is not @example.com
Am I right?

To make a user group with different domain emails, we have been using Amazon cognito, where we can push and list up any email address and wrap them as a single group and push it to auth for our production application.

Does this new feature indicate that we are able to do the same without OKTA, Cognito, but using Google Domain groups ?

Hi Koichi,

Yes, you are correct. Let me add additional explanation using an example.

Let’s say you are an admin of Google Workspace, called abc.com, that has several domains in it: abc.com, xyz.com, and mno.com. In this Google Workspace, you have several groups you created. One of them, called “Sales” has members from all domains in it: anne@abc.com, rob@xyz.com, and sid@mno.com.

Old behavior: this feature was built such that it would only give access to users whose domain matched the main domain - so in this scenario, only anne@abc.com would get access to the app.

New behavior: we fixed this feature so the domain validation is optional. It can still be set to be matched. If set, we would observe the old behavior. If not set, access will be given to all members of the group, regardless of the domain - so anne@abc.com, rob@xyz.com, and sid@mno.com will get access.

Hope this helps.

1 Like

Thanks Kamila,
Our company is small enough, just using few different domains under our g-workspace account.
On that, I assume, abc.com, xyz.com, mno.com is managed by the same google workspace account,and those accounts are managed by Google to host domain, then we are able to create a group , including users with those different domains.

Lets me assume an extream case,

On our business, we use abc.com account and domain which is used for google workspace account (as root) , but we are also using other domains, like abc-def.com which is hosted by other vendor, like GoDaddy or MS 365.

Do you mean regardless of who host the domain the story you mention is going to be applied?

Sorry, i m not fully understand how admin works will work on Google Workspace, so maybe i m just lacking in knowledge about it to understand clearly what you mean.

1 Like

In short, this will not work. The way this feature works is it gets the appropriate access Oauth scope to the group from the admin of that Google Workspace - so the admin has to have the appropriate Oauth scope in the first place.
Any groups that are managed by that Google Workspace can accessed. But groups that are not managed by that Google Workspace can’t, because the appropriate scope is not provisioned.

1 Like

Thanks Kamila
Your answer is perfectly making sense and clear. Appreciate if you revise the official documents so that any other users and community members get it crystal clear to see what is possible and impossible.thanks again

2 Likes

No problem, thanks for all the feedback Koichi! I’ll take a look at the docs this week and make sure to make this clear.

2 Likes

Thanks Kamila
Updating the docs will massively helps us and community. Cheers.

1 Like

@kamila

The one last things.

Last year, during the webiner to explain the roadmaps, I remember there was a plan and schedule the integration with Firebase Auth/GCP IAM - Was scheduled on Q4 last year.

Is it still a plan, just delaying to introduce to us? This new feature we talked about here is the one of GCP IAM connection?

@praveen

@Takuya_Miyai

3 Likes