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.
Related
I'm looking at using the Bot Framework (https://docs.botframework.com) is it possible to register a bot programmatically e.g via service? I see there are Azure bots but still don't see a way to register via service?
At the moment you have to manually log into the portal to register the bot and obtain your keys. There has not been any indication from Microsoft that this will change in future.
from what I know about the goals of the dev team, since this is a highly requested feature, we will probably see this in action in future version of the bot framework.
But no kind of timeline yet for this feature.
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 am trying to recruit some beta testers for an app of mine using Test Flight. None of the testers will be in house employees or anything like that- just some folks I know who would like to help test my app (I'm a hobbyist and don't have any employees anyways).
When I went to add somme users in ITC for test flight it made me assign them a role. The only role that made sense to me was "Technical". However, I am worried that assigning somebody I don't know well the technical role will allow them to make changes to my app descriptions, reject or submit binaries, and things like that.
Is that something I need to worry about? Is there a way to assign a user the role of JUST tester without giving them access to my apps via ITC?
Apple's documentation does not seem to explicitly state what users with various roles can do.
No, this isn't really safe, and it's not a good idea to give the 'Technical' role in iTunesConnect to someone you don't fully trust.
The iOS 8 TestFlight system has a way to setup external testers, see the "External testers" section on https://developer.apple.com/app-store/Testflight/
The downside is that your app has to go through the review team each time you make any major changes before it goes to external testers (hence if the tester is really a close part of your team it is still advantageous to add them as an internal tester by giving them the technical role). The reviews don't take as long as a normal App Store review.
Alternatives (that don't involve a review) are Crashlytics Beta Distribution (owned by Twitter) or HockeyApp (owned by Microsoft). There are other services too, or you can host IPAs on your own website (using the mechanism designed for enterprise apps) but generally doing this means you miss out on other features you get when using the more integrated solutions.
Short answer: no. It is not safe to add testers with technical role.
Long answer:
According to iTunes Connect, the user must have Admin or Tech.
After reading the comments, I will complete my answer with this.
There are Internal Testers and External Testers.
External Testers are not available as of yet (see https://developer.apple.com/app-store/Testflight/).
Only Internal Testers are allowed by now (which means, your testers WILL be able to change your apps).
Since you need the user to have minimum rights, you should add the user as Technical (the less risky, but still dangerous).
I see that there is a checkbox in iTC that lets you enable the Internal Tester role:
What permissions will the users have? Theoretically, they will only have access to the beta versions (but that is a guess, since I have not tried it yet). You could create an account for a fake internal tester and check that you can't modify apps with that role.
A technical users will have access to the 'My Apps' section of iTunes Connect. This means that they can change the description of an app in the app store, update prices and even remove an app from sale.
There is no way to have a user with just an 'internal tester' role. That's what external testers are for.
It is possible to grant someone access to test as an internal tester, but not have them be able to log into iTunes Connect.
Create an iTunes Connect User with the "Technical" role with an email address that they can receive. Then have them accept it with a different Apple ID.
As long as they cannot log into iTunes Connect with the email address you added as the "Technical" user, they cannot misbehave.
I'll try to explain my goal as good as I can;
I want to trigger a script whenever there is a new computer added to a Organizational Unit.
To do this i need to activate the logging of this event under the local security policy/audit policy. I guess my question is, do I need to do this on all the domain controllers, or is it enough to do it one just one?
Also, is it possible to see the event from a member server with the Management Tools pack installed? As I don't want to put too much work on the Domain Controllers.
Here is the Microsoft article that gives 4 ways of tracking changes in Microsoft Active-Directory. You will find everything you need from configuring the eventlog to receiving notifications by way of different kind of polling.
I can't find much about this online so I was wondering if someone knew here.
Is SSRS 2005 if a user creates a subscription, will other users be able to view and edit those subsciptions? If not, is it possible to make subsciriptions visible to everyone?
Thanks
Quick answer is no.
Long answer is:
AFAIK, there is no site-wide subscription management functionality. The best you can do within Report Manager is site-wide schedule management, which allows admins to set up schedules at preferred times and let users choose those schedules when creating their subscriptions.
Our solution for controlling/centralising subscriptions was to set up a generic Windows user, log in to Report Manager and use that user to create all subscriptions. This means that all requests for subscriptions go through the IT department (+ or - depends on your situation. We didn't want users creating subscriptions themselves). All users who know the generic username/password can manage subscriptions in one place. Not ideal but it works for us.
Another option is that all the data for subscriptions is held on the Server, either in the Reporting Services database or in the Jobs themselves. If you are brave you can delve in and set up some sort of interface to access this.
This is definitely an area in which I find SSRS lacking.
Update:
You live and learn. I've just found that (provided you have sufficient privileges) if you open a report, then go to the subscriptions tab, you can view and edit any subscriptions that are set up on this report by any user. Still not ideal as you don't get an overview of the subscriptions across the system but better than the bleak picture I painted previously!