We're running Sentry on-premise in a cloud hosted Kubernetes environment.
One thing we noticed was that members without a team are still able to view all project names, something we would like to hide.
Any idea if it's possible to hide all projects from a member? What we would like to achieve is users only being able to see projects to which their assigned teams have access.
Right now, all the user has to do is to browse Settings > Projects in order to see all active projects.
Related
We are developing a multitenant application with shared schema for a web application. I would like to know the best practices for designing UI strategies.
We will have different roles for saas owners like Adminsitrators, Helpdesk, Account Manager so The SAAS owner may need to have multiple users who will acess the application and do their job.
HelpDesk: If a tenant put up a ticket, helpdesk team shall be able to view and solve.
Account management: Account Managers may need to access the payment information of the tenants for following up the tenants.
ServiceManagers: To perform maintenance and upgrades etc.
In this case
Do we need to have different UI for "Saas owner" and "Tenants" or is it better to manage it with permissions and roles?
Any best practices?
There are many facets to decide on the mode of delivery
In case you prefer to use Micro FrontEnds, admin and tenant functions can be separate. However, the individual functions like help desk,Accounts management can be a separate micro frontend
There should be options for a tenant to white label the UI (custom logo, custom theme, custom layout (more development effort)) etc.
With or without micro frontends, your UI layer should be working based on the permissions that comes as an aggregation of the user's roles (even across tenants).
The UI always has probes to the API to get the permissions and render the various UI components based on the granted permissions to the user.
We used to build custom UI components like custom grid, custom forms etc so that the permissions could be used to show or hide the various UI elements based on the permissions that a user might posses.
Ex: In the context of a Administrator, I will be able to see all the team members, but in the context of a Service Administrator, I will be able to assign members to various tenant functions like help desk, accounting etc which the Administrator will not be able to perform, but can view the mappings.
Similarly, your business requirements will drive the UI, hence if you follow using the permissions for the UI, it is always very fine-grained and easy to manage than depending upon higher levels of abstraction like Roles.
HTH
We've had a DevOps member leave recently and have had complaints that all of the integrations (incoming webhooks) that they had set up have stopped working... (once the user was disabled).
One suggestion for dealing with this was to notify the affected channels when we deactivate the user, but I can't find in the API methods a way to look up which channels a user might have configured these webhooks for...
Anyone had to do something like this?
To get the apps and internal integrations that have been installed by a specific user use the API method called team.integrationLogs.
This method lists the integration activity logs for a team, including
when integrations are added, modified and removed. This method can
only be called by Admins.
For a programmatic solution you will need to go through all log entries for one user / app to find out its latest status.
However, it might still become difficult to reinstall all that apps / setup all that webhooks again properly after a DevOps member has left depending on how good your documentation is. We have therefore started using a generic admin user (e.g. "slackadmin") as main installer for all important apps / integrations for our workspace.
We have several API's, one for each of our customers, and I want to be able to create apps for all of these (different AppResources). These apps will have their own logo's, titles, app IDs etc. Also, if possible, I want to be able to swap these post build, so that we can set up a build-once, deploy-many automation tool. The necessary files would ideally be fetched from the API itself. How would I go about and do this?
We have a google-marketplace-app which is already published and actively used by consumers. But there is a new requirement, where we need to block any new installations of the app without impacting the existing consumers.
Is there a straight forward option to achieve this? Or do we have to unpublish existing app and republish with some specific options (i.e: "visibility-options")?
The ideal expectation from our perspective is not to let existing app consumers/domain-admins to perform anything on this regard. But only that existing domains needs to whitelisted from our end (by app developers) to allow installation of the app to admins of those domains, where as any other domains shouldn't have install access (even with direct app installation link).
Appreciate any recommendations on this.
In the Chrome Developer Dashboard there is an option to add trusted testers to the app. The accounts that are in that list will have the visibility to the application.
You can also create a group and add that group to the list, and the people inside that group will also have visibility to the app.
Here you can find the documentation related to this. Hope this helps.
I have basically two URL's http://xyzwebsite.com (for Development Testing) and http://abcwebsite.com (For Production). I have a simple Login mechanism where a user can click on Google Plus icon to log in rather than using their Username and Password. I created one Project for Development with obviously different Client ID and different for Production with a separate client ID.
But I tested both the URL's above with the client ID of Development project and it worked fine. I am wondering why there is a need ot having multiple projects in Google API console?
There is no particular need. A single project can have several URLs and client IDs for use.
Some reasons you might use multiple projects include:
Changing project settings in dev without worrying about breaking production
If you have a development script that gets into an endless loop or something it might use up all of the quota and the production app might start throwing errors
You might want clear branding on the dev app that explicitly identifies as not production.
Some unknown reason I can't think of.