We have a self-hosted gitlab solution and are trying to integrate a third-party application. For that we created a new account and wanted to set up a new application. But we were greeted by the following screen:
'Adding new applications is disabled in your GitLab instance. Please
contact your Gitlab administrator to get the permission'
I have an admin account and have looked everywhere to set this permission but can't find it. In my own account it is also impossible to add application, but in the admin area the possibility is there.
In the pricing table there does not seem to be any option that adds this feature so I don't think it is a blocked feature.
Any help would be much appreciated.
Go to https://gitlab.example.com/admin/application_settings
On the general tab beneath "Account and limit", there is a checkbox called "User OAuth applications".
Once you toggle this every user gets the ability to define her or his own OAuth2 Applications.
Related
I have a Chrome extension. I'm the developer, and I have a Google group for users than can use the extension. I want to add a collaborator to help develop it. From what I've seen on the Google Developer site, I'm apparently supposed to make a google group to add additional developers. But I see no option to create a new group on my Developer Dashboard.
I'm not sure why, but I have a guess: According to this SO response, you can only have one publishing group associated with your account. So my user group may be preventing me from creating a developer group. But I need a user group — the extension is in testing, and I only want these approved users to be able to use it.
So what do I do? Do I have to create a new Google and developer account and simply give my collaborator the username and password? Or is there a way to do this without creating a new account (as I think that would mean my existing users would have to delete the old extension and re-add the new one, which could get messy as many of them aren't tech-savvy).
In Azure API Management you can enable integration with AAD, by following the guidelines in this article:
https://learn.microsoft.com/en-us/azure/api-management/api-management-howto-aad
This part describes the sign in after setting up AAD integration:
https://learn.microsoft.com/en-us/azure/api-management/api-management-howto-aad#a-idlogintodevportalsign-in-to-the-developer-portal-by-using-an-azure-ad-account
In step 3 of of this part, the following is mentioned:
"You might be prompted with a registration form if any additional information is required."
I don't want to bother my consumers with this dialog, but I can't find what 'additional information' is meant here.
The sign up dialog only shows email, first name and last name.
Anyone knows what information the registration process is missing, which leads to this dialog to show up?
I don't want to bother my consumers with this dialog, but I can't find what 'additional information' is meant here. The sign up dialog only shows email, first name and last name.
If you don't want to enable the registration process, you could delete Username and password
provider from azure portal.
It will just use the Azure AD provider. then it will not prompted with a registration form.
Updated:
If I click sign up, I get the registation is disabled.
After consulting the Azure API Management product group, it became clear you cannot disable this dialog at the moment.
The documentation is mentioning the dialog is only prompted in a certain case, but that's is not accurate. The dialog will always be shown when you sign in on the developer portal, when the Azure API Management is integrated with AAD.
We are using DocuSign REST API (DocuSign C# Client) to create a DocuSign account for our clients. An account is created successfully, but when the user login that account on DocuSign Web (New UI) then they do not get "Go to Admin" menu in admin preferences. Is there any settings that we need to apply while creating DocuSign account. We are using DocuSign C# Client to create an account and applying only email and user name.
Also, we want to update some DocuSign account settings using REST API. But some parameters are not getting updated. When I checked the API log and found that parameter which we want to modify its read only. Below what i found from API log.
"allowEnvelopeCorrect":"false","allowEnvelopeCorrectMetadata":{"rights":"read_only","uiHint":"available"}
See my answer below on another thread, I would try to explicitly call canManageAccount and see if the permission gets set. It may still need to be done in SOAP.
Fail to update user's "Manage Account" permission through "Modify User Account Settings" API
Are you creating new accounts through the API or just adding new users to an account?
There's actually a bug in the platform currently that will be fixed soon - the bug is that for single user accounts the Go To Admin link in the menu drop menu is not available. I believe this might be causing your issue. Starting tomorrow you should be able to access the Admin menu directly through - admin.docusign.com/auth - and I think next week the actual menu item should be enabled and bug fixed.
-- By Ergin
It has been fixed Now.. Thanks.
I have successfully set up a Team Foundation Service account and have been using it with Visual Studio 2012 for source code control, no problems. Note this is the online service, not the old TFS product. I now want to add another Live ID account so they can write and track bugs. Using the Manage Members link I have tried two different Live ID accounts as well as their name but it always says they are not a known user. I know the Live ID accounts are correct. Do I have to invite them or add them some other way first? All of the examples show it "just working".
Are you adding them via the web interface? You should be able to do this by clicking the cog icon in the yourproject.visualstudio.com site. This launches the admin site, you can go into a collection, or add from the Security tab. It really depends on where you want to add them (if they only need access to specific projects/collections it's done at that level), you can add a new user from the Overview or Security tabs by entering their Live ID/email address.
In Moss 2007 you have the ability to set the target audience for each individual web part within a page. Is there a way to preview how the page will look to another user without logging in as that user? What I am looking for is a way for someone with full control/design permissions on a site to be able to preview how the site will be displayed to another user. Any suggestions?
I have a few test accounts that our IS department uses to preview pages, however we do not allow non-IS departamental staff to use those accounts. Those staff members only have access to their one account. So, if a user makes changes the target audience on a web part on one of their pages, right now they have no way to preview how the page will look to someone else other than asking someone else to login & watching over their shoulder. I can't give out the account information for the test accounts, nor can I create new test accounts.
Thanks!
Edit: I have the ability to preview. The problem is that other users with full control of a site can't preview the page. Here's a scenarios: In my school division each school has a site. The principal has full control of his school's site. On the landing page, he wants all the school announcements to be visible. However, some should only be visible to teaching staff, while others need to be visible to the students. He uses audience targetting but cannot preview to see at a glance that the targetting is correct. A lot of the users are not computer savy so things need to be as simple as possible. Also, that was just one scenario, there are other scenarios that are not divided by school. There are many users with full control of a site with different requirements - so it's not feasible to create test accounts for all scenarios.
First I don't think it is possible to have a preview feature if you are using NT security. Maybe it is something you can do with forms authentication but I never used it.
On that subject. I think when you are developing new features or integrating stuff on a MOSS/WSS server you need a little flexibility.
With what I see you have to following things you can do. It is surely more cost effective than developing a custom solution. I assume you are using NT Security.
User accounts : Ask your domain administrator to have dedicated user accounts to play with.
Virtual Machines : Ask to have some virual machines to be able to play with that server combined with tests accounts
Sandboxed environment : Ask your IT dept to create a sandboxed MOSS environment to have to possibility to replicate your actual MOSS environment and create custom user scenarios.
Edit: After re-reading the question I released that you want the users to be able to preview a page. I think you will need to look into writing a preview control that uses Impersonation to load the page. Not sure how feasible this is, but surely someone has created a preview feature. Sounds like a pretty common scenario to me.
Old Answer:
Could you not fire up a non MS browser such as Firefox, which will prompt for the username and password.
You can then just clear the session cookies to be prompted to log in as someone else.
This is the technique I used for an ASP.Net site that used authentication against the domain in a similar manner to SharePoint.
Alternatively, you can create a control/webpart that hooks into the audiences for the site and displays the audience membership to the user (maybe from the GetMembership call). This does not preview the site, but it will give your editors a heads up on who is in each audience. Something that will help them get the audiences correct.
We have made a similar webpart for security group membership.
I think there are two approaches you can take:
Do make use of test accounts to preview the pages. You can ease the "pain" to log in as another user by making use of the RUNAS command (http://technet.microsoft.com/en-us/library/bb490994.aspx). So it's possible to just create a shortcut on the desktop that opens a browser making use of another account's credentials. Only that browser instance will work with the test account.
Make a copy (or more copies) of the page that you want to preview, store it in a secured site (so it's only accessible for the principal for example), and tweak the Audience Targetting properties of the web parts on that page/pages.
For previewing target audiences only, the only way to do it is to create a target audience that runs based on a properties in the SSP User Profile Properties.
You can then have a control that allows the editor to change the value stored thier profile, re-compile the profiles and voila (for some description of voila) the user will have change thier audience targetting values to something else.
This would need quite a bit of coding and some thought put into the rules for the audience targetting.
At the end of the day, the most cost effective way is to push back to your infrastructure guys for an account solution that will allow you to have an "reader" account people can use for this function.