Since the merge of user roles management between the appstoreconnect and apple developer accounts, i haven't been able to give access to my team on appstoreconnect to the certificats and identifiers.
It's always disabled and I can't check it.
Simple answer: You can't invite people to resources over at https://developer.apple.com/account with a personal account. Therefore the checkbox is greyed out and not clickable.
Simply go over to https://developer.apple.com/account to check your enrollment. There you can find your "Entity Type" (> Membership)
Related
Recently we have purchased a production account. I have logged into the account as Account Administrator but I am unable to see Docusign Admin. This was not the case for the developer account where it was already present from beforehand.
I need it as I have to add an organisation.
Below I have added a picture of how it looks in dev account.
So, most likely you have someone else in your company who is the admin. You will to find out who that is.
Every account has to have one admin at all times. You don't see to have administrative rights, but someone else may have.
If not, or if you don't know who that is - you will need to contact customer support to get this restored and take over as admin.
Another option is that you have multiple accounts in production. Meaning, when you log in, your user is a member of more than one account. You need to switch accounts. That switcher is an option on the right-top menu.
If you had "Admin" in Demo, then someone had to add that as it is not provided by default. Admin tools (Org Management and Access Management w/ SSO) are only included in the Enterprise Pro plan. For Business Pro or Standard plans, it is a paid add-on. Check to see if your account is an Enterprise Pro plan.
Also, if your company already has Org Mgmt, a "DocuSign Admin" (org, not account admin) needs to link this new account to the Org.
I am a developer using the Docusign API. When my users are tagging signature spots for their signers, I have disabled as many "tag types" as I can except for just SIGNATURE, INITIAL, FIRST/LAST NAME. However the users appear to have this "Formula" tag they can add which is of no use to us. I don't want it because it can confuse our users, but when I log into my account under Preferences/Features the "Enable Calculated Fields" checkbox is checked but greyed out so i cannot uncheck it.
I've looked at the Documentation and haven't figured out why this would be greyed out. There is no mention of this feature being tied to another feature. Is there any way to the formula/calculated-field tags?
Please ask either DocuSign Customer Service or your Account Manager for help to get this resolved. This is an account setting issue that probably needs to be updated on the platform for your account.
Is there a way to create a group admin using the API?
Someone who is able to add and delete users from the group but not from the general administrator account?
I can see there are only 3 permissions profile that can be assigned to a group, Administrator
Thanks.
Currently DocuSign does not use a tiered administrator structure with either the API or their standard console.
Several DocuSign employee's that I've talked with have suggested that a tiered structure is in the works but they don't have a release date for that as yet.
As a temporary fix to this, if you have an account administrator at DocuSign (and depending upon your account set up) you can request that they create sub-accounts to which you can assign groups of users and limit administrators from reaching other accounts. This is the solution we used for multiple business units that didn't need access to each others documents.
You can create more permissions profiles, but the degree to which your users can access settings remains largely the same.
Hope this helps.
I have a navigation menu that will be using audiences to control visibility of the links on the menu. For simplicity (and to allow help desk to manage the access), we will be using Active Directory security groups to control access to the links.
When trying to add Active Directory security groups to the link's audience, I am unable to find the new security groups. I can add other security groups that are in the same Active directory OU, just not the new ones.
If I create a new page or site, and go to site permissions, I can add the new groups there, just not under audience.
How do I force SharePoint to rebuild its list of AD Security groups that it displays for audiences?
To be clear we are not using custom defined audiences within SharePoint at all. Under central administration, there is only the All site users audience. The groups I see being populated in the audience field include those that came from AD orginally. I just do not know how to get the new groups to show up.
As a work-around, I could create new pages with redirects for each of the links, and set permissions on the pages themselves, but that seems like a overly complicated and annoying solution for something that should have an easy fix.
Thanks
Looks like an old post but I thought I'd still reply. It might help someone.
Just make sure that in AD the security group is marked as "Global" under Group scope. If the group is marked as "Domain local" or "Universal", it will not show in the audience rule.
Hope this helps.
:)
Have you preconfigured audiences in User Profile Service Application?
Try looking this: http://technet.microsoft.com/en-us/library/cc262169.aspx
Exactly the same challenge I'm facing. Have manually prompted a profile synchronization (incremental and full) in the hope that this would trigger an update, but it doesn't.
New AD groups aren't showing up, and some old ones (it appears, at this point in my studies) aren't being removed. There seems to be a fundamental audience field update failure, while the rest of SharePoint picks up the profile changes just fine.
Found this: http://blog.arjanfraaij.com/2011/05/adding-active-directory-ad-group-to.html
Hope it's useful.
Last edit: It worked. Still had to define audiences to get them applied (couldn't directly apply AD groups), but a simple Audience composed of a single AD group now properly controls audiences. Just make sure you then compile audiences too...
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.