Gripes with Google Groups
latacora.singles
latacora.singles
It is a little bit crazy that the authorization construct in Google Groups has an "allow the Internet to join" option. I don't think you'll find that particular button anywhere in Okta or OneLogin.
(I’m a PM @ Google working on some of these efforts)
I think some of the updates we're working on will help.
Happy to answer questions related to this post or other gripes you may have with Google Groups.
So I have inbox@mydomain which Google knows is affiliated with my Google account, google@mydomain which had to be subscribed to the list for me to get mail at my actual email address, and my Gmail address, which Groups uses when I post from the web UI.
Help.
Sidebar: I don't say a ton of nice things about Google, but absolute kudos for you just dropping in here and asking for feedback. Gold star, I'd really like to see more of this.
I haven’t heard of this but I can see how it could happen depending on the exact state of your @yourdomain.com Google account. Sounds messy though and maybe we can sort it out.
Using another alias at my domain was a method to bypass that, as it isn't connected to the Google account at all. (But of course, it also means my real email and my Gmail each get a copy of list emails.)
(Currently we have a support@ service account that sometimes sends automated emails and which forwards incoming things to a group where everyone in the group has been granted "send as support@," since the group side is basically acting as a collab support inbox. I think the whole thing could possibly be a "shared inbox" type group were there just a way to have a service account matching the group email. And of course there may some benefit to it being set up how it is that I'm missing, or a way to do so currently that got overlooked somehow.)
https://cloud.google.com/iam/docs/understanding-service-acco...
(My understanding is that it's a kind of psuedo-user account, and that it's being used because there's no "virtual user" to "act as the group" when it comes to automated emails and tasks or something along those lines. I wouldn't be surprised if it's more complicated and they created an actual domain user that belongs to no-one and then give the service account permission to act as it or something along those lines.)
Whatever is actually happening isn't supper important though - I think somebody over here just did whatever they thought the minimum effort thing to do was without thinking or looking into it much.
I'm fairly certain each group having an admin panel having a page that allows "app passwords" or Oauth2-integrations to be set up for its address/account by the group owner/admins would cover at least 90% whatever we've got going.
(And once again, it is completely possible that something like that can already happen and just isn't obvious to anybody over here.)
Stray dog is an accurate description. Groups has not received the updates needed for use in enterprises but it's a current focus area for us (for reasons you mentioned).
You can add an alias to a group today but perhaps you’re talking about something else?
When looking at enterprise usage, groups aren’t always a mailing list or forum. We are working to decouple a lot of what is baked into a Google Group today.
Do you primarily use groups.google.com, admin.google.com or the AdminSDK APIs?
For example...
service_requests@ (group)
-> operations@ (group)
-> user1@
-> eng-support@ (group)
-> user2@
So right now what we have looks like ``` customerservice_for_client1@ (user account with shared credentials) -> user1@ -> user2@ -> user3@ -> user4@ ```
That groups isn't hipaa compliant, feels inane, especially since email is hipaa-compliant. There's obviously something that prevents it (probably the ease of making records public).
If you'd prefer to get on a call or meet in NYC let me know.
We're working on ways to ensure that a group contains the people you expect it to have. Sounds like a no-brainer but this is one of the most common pain points we hear from customers.
Secondly, there's a slew of group settings exposed through groups.google.com which are not exposed elsewhere (Admin console, APIs). We're working on improving that which will help users know what a group's settings are across all the groups surfaces (groups.google.com, Admin console, APIs).
I think you (google) should drop them all, bring back "Google Chat" as one named umbrella, get all of it working in one place/system, and do an "update" that points them all to the new app. Having 147 disconnected apps to communicate outright sucks horribly.
Here's roughly what that looks like to get all the mentioned info out:
function getGroups(domain) {
var groups = [], pageToken, page;
do {
page = AdminDirectory.Groups.list({
domain: domain,
maxResults: 100,
pageToken: pageToken
});
if (page.groups && page.groups.length > 0) {
groups = groups.concat(page.groups);
}
pageToken = page.nextPageToken;
} while (pageToken);
return groups;
}
function getGroupPerms(groups) {
var perms = [];
for (var i = 0; i < groups.length; i++) {
perms.push(AdminGroupsSettings.Groups.get(groups[i].email));
}
return perms;
}
The huge benefit to GAS IMO is that creds never hit my disk.
I'm guessing this is a feature? As in Google wants it to be easy to just create local sheets/docs/... without them being shared with your org by default and would rather worry about giving admins better features to manage and audit sharing than give admins access to every document under the sun :)