I have published a deployment that runs with the developer account. In the deployment settings I have a role called "Supervisors". I have assigned a google group to that role, directorssupervisors#domain.com.
When the deployment runs with the developer account, everythings works fine. But when the deployment is ran by any other user, I get the following error:
appmaker.application.permission.GroupsPermission: Error reading group directorssupervisors#domain.com. Note: The deployer developeraccount#domain.com must have access to this group.
Exception:
Exception: You do not have permission to view the member list for the group: directorssupervisors#domain.com
The group settings are configured so that everyone in the domain can view the membership; moreover, the developer account is a member of the group.
I have checked the information provided in this post and also in this post but none of them seem to help. The developer account was added to the group more than 72 hours ago and the deployment was published more than 48 hours ago.
So far, everything is leading me to believe this is a bug. Before I open a support ticket with the G Suite AppMaker team, I would like to know if anyone has had the same issue and if there was a solution to it.
Thanks in advance for your help!
UPDATE:
Now it is also showing the error when the app is ran by the developer account!
It so happens that the AppMaker team corrected a buggy behavior that allowed the reading of email addresses from groups without having the permission properly set up in the group settings. To make the app work again I had to make sure the group permission had the proper access for viewing email addresses; Group Settings -> Permissions -> Access permissions -> View Email Addresses.
Once I changed the permission to All members of the group, I proceeded to republish the app and then it worked again.
Update 12/31/2019
On top of the already mentioned above, you also need to make sure that the group is visible to all members in the organization:
Group Settings -> Permissions -> Basic permissions -> Group Visibility.
Related
My organization set up Cloud SQL as the default for Google App Maker about one month ago. In the last week, we have been unable to preview or publish apps that use Cloud SQL data sources, including the sample applications which worked perfectly before. The failure occurs during the authorization process. When previewing or publishing an app, Google App Maker displays a dialog stating "Deploying this app requires authorization". Next it prompts the user for their Google account and then requests approval for the necessary authorizations (e.g., "Manage the data in your Google SQL Service instances"). After approving the authorization, the prompts to authorize begin over with the dialog stating "Deploying this app requires authorization".
Observations:
We have repeated this problem on multiple different computers, networks, and four different user accounts.
In the SQL cloud console, our Cloud SQL instance shows new databases being created for each app along with new database-specific user accounts
All of the databases appear as expected when I log directly into the Cloud SQL database using phpMyAdmin
Other apps which don't use a Cloud SQL datasource work fine, including an app that uses a calculated data source which is hosted in the same Cloud SQL instance
The only errors in the Stack driver logs for the Cloud SQL database showed "INFO" level communication errors with the database (aborted connection...Got an error reading communication packets)
I'm unable to find Stack driver logs for the apps because I cannot preview or publish them (either option would provide a link to the Stack driver logs)
There are now approximately 20 databases in our SQL instance (mostly associated with simple app tests) and we have only used 1 GB of 10 GB of space in our SQL instance
I haven't seen any related problems on the Google Issue Tracker for Google App Maker
I'd appreciate any help or suggestions on what to check in order to resolve this issue.
I posted an issue to Google Issue Tracker and Google corrected the problem. They also provided a workaround if this problem happens again.
Here is the response from the Google development team posted on Google Issue Tracker: https://issuetracker.google.com/issues/145345198
It's great to hear your up and working again! We are aware of this issue and are working through a longer term fix. The specific bug appears to be related to some changes made in the Google Cloud session policy control that may have rolled out to your domain recently interacting with AppMaker in a way that was not expected. We've spent time diagnosing the underlying issue and we beleive we know the root cause. I suspect your domain admin did a version of the workaround below.
Without getting too far into the details, the specific bug is that for a Deployer of an AppMaker application, if the Google Cloud Session policy is set with any expiration time, the returned token AppMaker sees is invalid, triggering a loop in AppMaker trying to generate a valid security token. Historically, these session tokens never expired but recently there was beta feature launch that allowed domain admins to set them to expire. We strongly suspect your domain recently set this expiration policy explicitly and that's what is causing the bug.
The good news is that these policies are overridable per Organizational Unit and we have tested that OUs which have the original classic Never Expire setting do, in fact, allow AppMaker to work.
My suspicion is that your domain admin has reverted recent, local changes to your organizational policy under the admin.google.com console, specifically under Security > Google Cloud session control (Beta).
If this happens again, here the workaround we would recommend. Note you don't need to do this if you're currently up and working. You will need the help of someone with admin.gogole.com powers, specifically User and Organizational Unit powers at your organization. It is a slight increase in security risk but it restores some classic behavior that was standard until recently.
The summary of the workaround is to override the Google Cloud session control expiration setting such that individuals who need access to AppMaker deployments can have it. To mitigate systemic security risk, this is best done by creating a limited purpose Organizational Unit with just that setting different than the parent OU settings.
The workaround is to:
Contact someone in your domain with Admin powers for your Google for Business license.
Have your admin proceed to https://admin.google.com. The actions below need to be performed by a domain admin.
Under the Users section, identify the specific user account that needs the ability to deploy AppMaker Apps.
Identify the Organizational Unit of that Appmaker dev user and make a note of it.
Under the Organization Units settings, locate the Organization Unit you identified above.
Create a new Organization Unit underneath that user's current Organizational Unit with some descriptive identifying it as special w.r.t AppMaker. So for Developers, make something like DevelopersWhoAreAlsoAppMakerDevs.
Back under the Users tab, locate the user from step 3. Move this user into the new Organizational Unit you've just created. This change can take a while to propagate.
-Interlude- At this point, you've made a new Organizational Unit for just that individual and added them to it. You can certainly add multiple people to that OU, especially if they're already in the same parent OU. Use your discretion as to what amount of Organizational rework you wish to pursue. You may not be using OUs at all or you may decide to just turn off this control for the whole domain. It's up to you.
Under admin.google.com's Security settings, locate the Google Cloud session control (beta) settings.
Under this panel, from the dropdown menu on the left, locate the Organization Unit you just created.
Be sure to select ONLY the OU you intend to change.
Change the "Google Cloud Console and Google Cloud SDK session control" from expiring to "Session Never Expires".
Save your changes.
The account you selected in step 3 should now be able to deploy AppMaker apps.
It appears this OU change is only necessary for the deployer of an AppMaker app, not an individual user. Note also that if you have multiple AppMaker developers who all have different current OU settings, you may need to create multiple daughter OUs to avoid a sudden radical shift in OU settings for an individual account.
I have linked GA360 to Big Query. I do have a service account added to GCP as per documentation. The account I used has Project Owner permissions as required to link to said project.
Can I remove the Project Owner permissions from the GCP account once the link has been established in GA360? I do not want that account to have such a high access level to the project.
I did run a test on a small scale and it worked but I am not willing to risk a transfer failure on all of the data in production.
Yes, you can remove the permissions from the account you used to link GA360 to BQ.
The permission is only required for the time of setting this up.
It is not being checked whether the account which set up a connection is still active or has the same rights.
We have had multiple views linked by different accounts, of which most are not in the team anymore and therefore do not have "owner" rights anymore. The exports still work though (which makes sense, given that a company might keep using GA and the exports but part ways with the internal/external employee who sat it up).
We just set up elasticsearch, logstash and kibana on our swisscom application cloud instance. Now when I log in into kibana with the full_access_username and full_access_password I can do almost everything except adding new users and manage existing ones under settings - user management.
There I always get a message saying:
You do not have permission to manage users. Please contact your administrator.
Does anyone of you has an idea on how to fix that?
We d like to have different users and give them permissions on some indices and attributes only.
Thanks in advance for your help.
As Swisscom provides their Elasticsearch Service as managed, you have some limitations in terms of administrative functions. At the time of writing this includes cluster and user management as well as watches.
You can provide new users by creating service-keys cf create-service-key <service-instance-name> <service-key-name>.
When I go to App Insights -> Activity Log I get:
No permissions to run the selected query.
Is that because there are no queries to run? Or is it really a permissions problem?
I have defined two queries but they don't show up in the dropdown. Should they?
Where can I read more about this? The docs page didn't help me very much.
Please ensure that the user has access to the following azure provider in addition to the obvious ones.
"microsoft.insights/eventtypes/*"
you could also try "microsoft.insights/*/read", in case you want the role to view all monitoring data from Azure Monitor.
more on custom roles & RBAC is documented here:
https://learn.microsoft.com/en-us/azure/role-based-access-control/custom-roles
To configure custom roles in Azure - https://learn.microsoft.com/en-us/azure/role-based-access-control/custom-roles-powershell
Activity Log interaction is here:
https://learn.microsoft.com/en-us/rest/api/monitor/activitylogs/activitylogs_list
Why do i get this error message when i try to launch conversation service tool:
Unable to retrieve the list of workspaces. Error: Insufficient privileges
You need delete cookies of your browser. I faced with the same problem but after to delete cookies I could see my workspaces.
I'm one of the developers of the Watson Conversation service and you seem to have uncovered a small bug in the way that the tooling currently operates. We've been able to successfully reproduce this.
In short, when you open up the tooling to train an instance of the Watson Conversation service a call is made to Bluemix for all instances of the Watson Conversation service that you can see. However, due to the way that Bluemix space permissions work, you may be able to see instances that you don't have permission to edit. You should be able to find your service in the dropdown in the upper right corner of the screen.
In order to have permission to edit and make changes to an instance of the Watson Conversation service, you'll need to have dev permissions in the space that contains the instance of the Watson Conversation service. If you'd like to work on that service instance, you'll need to ask the person who owns the service instance to grant you dev permissions in the space. You can find out more about how to do this in the managing team members and roles section of the IBM Bluemix documentation.
I met the same issue
"Unable to retrieve the list of workspaces. Error: Insufficient privileges".
I double checked my permissions and validated that I have the admin access to all services in my space.
Then, I switched to a different browser and was able to navigate to the watson tool login page.So for my case, it looks more like a cookie issue. Thanks #Richard L. 's comment.