I'm trying to share a document in OneDrive by providing access to specific people across orgs. While I'm able to use the /invite endpoint to provide access, sometimes I am not aware whether a given email address is entitled to receive access. For instance, let's say:
A user from org-1 is sharing a file with three email IDs
Two email IDs belong to same org-1
But the third email ID belongs to org-2, which is not entitled to receive access as per org-1's policy
When I dispatch a request to /invite with the three email IDs, the whole request fails i.e. none receive access to the file.
Is it possible to have partial fulfilment? i.e. the entitled users of org-1 are given access but the user from org-2 is denied access, while the response returned is 200?
Also is this possible in Sharepoint as well?
No, you cannot make it partially success on the server side but you can validate if the given accounts are from your organization on your side(writing code) and then remove that and send the request. If you want to send it to other organizations as well you need to configure it on the tenant or site where you want to share data with.
Related
We are using the EnvelopeView: CreateSender endpoint on the server side and are authenticated under a service account we have dedicated for this process. Ultimately, we send a URL such as https://demo.docusign.net/Member/StartInSession.aspx?StartConsole=1&t=<GUID>&DocuEnvelope=<ENVELOPEID>&send=1 back to the end user to pick the signers, and populate tags.
All works fantastically, however, we were hoping to make it so the user can only see and populate the information for this single document. Currently, once the user clicks the link they are essentially authenticated as our backend service account and if they open another tab in their browser and go to (https://demo.docusign.net) they can see all documents and even change the password of the account if they wanted.
Is there a way to restrict this in any way? Would the experience be different if purchased an “API” account not tried to use an actual user account on the backend? Yes, we know about OAuth, but we don’t really want to impersonate the sender and prefer to keep a dedicated service account.
An "API" account would give you the same issues as dedicating one of your current users as a "Services Account," so I don't think that's a solution.
Instead, I suggest that you move all of the functionality that's needed upstream into your app. That way you will not need to present the Sender view to your users.
Your app can enable your users to:
choose who the envelope will be sent to
choose/edit the email messages, etc
choose the documents that will be sent
etc
If you have preset templates that include the document tabs/fields for the signers then there is no reason for the sender to deal with the sending screen for picking the tab/field locations on the documents.
This type of app will also give a smoother user experience to your users since they'll stay in your app rather than bouncing over to DocuSign for part of the task.
I have a private extension in the chrome web store. This extension is for users and devices who are managed via the Google Admin / GSuit system.
When in use, the extension contacts the GSuit / big data servers to log data. To tell my customers appart, I get them to type in a unique customer ID into each of their chromebooks, one ID per customer.
This was ok, but I would like to automate the system. Can I send down the customer ID instead of getting them to type it in ?
I thought of using the Asset-ID to identify the chromebook - but I cant find any way to extract the asset-id in my extension to allow the device to send it back to the server !
I thought of using one of the free text policy settings - but I can't get access to those in the app either !
I don't want to use email address as some of my smaller customers use gmail, so they would all get clumped together.
As an account administrator, you can first try retrieving a user using a userKey which can be the user's primary email address, the unique user id, or one of the user's alias email addresses. A successful Users:get request will return users resource including customerID.
Then, with the customerID, you may now get the assetID by retrieving all chrome devices for an account. Use GET request and include the authorization described in Authorize requests.
Here's the sample request:
GET https://www.googleapis.com/admin/directory/v1/customer/my_customer or customerId/
devices/chromeos?projection=basic or full&query=query
&orderBy=orderBy category&sortOrder=ascending or descending order
&pageToken=token for next results page
&maxResults=max number of results per page
Response for this request will include annotatedAssetId.
Also, View Chrome device information might also help.
I'm currently using the docusign api to make a request that searches the user's folders in order to bring back all the envelopes that are out for signature. This works but it doesn't seem to bring back envelopes from shared folders.
Having executed the 'list' api action I can see that my user has access to another user's folders and having logged in as that user I can see that some signing requests have been sent. I'm just wondering if this is a limitation of the API search function or whether I'll have to perform a list then iterate through each folder requesting envelopes, the search API function has been quite useful as it allows me to return recipient information as a part of the request whereas it seems that listitems doesn't allow that.
Edit: I'm looking to perform a lookup that will bring back all of the envelopes that have been sent by user A and user B that are out for signature.
The situation is that we have multiple company accounts that can send docusign documents to customers. What we need to be able to do is to view all documents that are out for signature across all accounts in one single list.
Any help would be much appreciated.
Per, https://docs.docusign.com/esign/restapi/Folders/Folders/list/
call GET /v2/accounts/{accountId}/folders this will return list of folders which userA has access to, this will also include the list of userB folders. Once you get folderId from previous call then use below call to get the list of envelopes in the folder
GET /v2/accounts/{accountId}/folders/{folderId}
For a DocuSign integration, I'm working on allowing users to send on behalf of others. Using DocuSign's REST API, I am able to send on behalf of another DocuSign user by using the <SendOnBehalfOf> node inside the X-DocuSign-Authentication header of the request, as described here.
I've also found that to find any DocuSign users capable of sending on behalf of, I just need to check their apiAccountWideAccess and allowSendOnBehalfOf permissions.
This alone seems like a security concern for me. Is there a way for me to, first in DocuSign, restrict users for designated sending? For example, can I make it so John can send on behalf of Bob, but Jane cannot? If possible, can I then use the DocuSign REST API to check who a particular user can send on behalf of?
Or, does DocuSign allow any designated sender to send on behalf of any other user, so long as they have the aforementioned permissions? I can't find any documentation about this.
There is a Group called "DocuSign Viewer" that will restrict users from sending envelopes. You can assign the a new user to that group by using the group ID when making the call to create the user (or do it in the member console easily as well).
As far as sending on behalf of, the initiating sender will need Account Wide Rights (apiAccountWideAccess in the API). The only restriction for the user they are sending for is they must be able to send envelopes.
A 3rd party website is offering our service to their members. When they sign up, members have to agree to our contract. Currently this is handled manually, with envelopes being sent through email. We want to streamline this process allowing members to enter their information into the web site, and then immediately be presented with a contract to review and sign.
The 3rd party web site will collect the member information, then use the REST API to create a draft envelope based on a Template and information the the member enters on the website. The application will then display the contract in the web page so that the user can review and sign it. The document workflow will ensure that signed copies are routed to appropriate parties within our company via email for completion.
We want the 3rd party web site to have access to an account to which we can share templates. We want the 3rd party application to have very limited capabilities trhough the API:
Submit requests using a User ID and Integrator Key that we provide. These credentials need be different from other User Ids and Integrator Keys under our account
Create a draft envelope based on the templates we provide
Post a Recipient View allowing the application to display the document for review and siganture (in an IFrame)
Receive the signing status via the return URL provided in the Recipient View post
Possibly request status for an envelope
The external application should not have access to other templates, documents, or unnecessry API calls.
We want to be able to cancel the application's access at any time.
Question: Permissions and API Limitations
Is the above scenario feasible with respect to establishing limited access to the DocuSign REST API? How would we set this up?
Do account user permissions limit API use, if the API is enabled for the user? I found these settings in the user permissions section of the documentation. I can make guesses as to how to set them, but I need guidance on the actual implications of some settings.
Submit DocuSign API Requests: true
Manage Account: false
Send Envelope: true
Manage Templates: Use
DocuSign Desktop Client: false
Transfer Envelopes to User: false
Allow sender to set email language for recipients: false
I assume "Account-Wide Rights" should be false, but under that option in the documentation, it lists RequestStatus as one of calls covered. Will an application embedding the signing process still have sufficient permissions to complete the tasks listed above if "Account-Wide Rights" is false?
Are there other settings or issues I need to consider?
Firstly, thanks for using DocuSign. The answer to your question is in a few different parts. To clarify, I am answering assuming:
1.) You are a current customer (or about to be one) of DocuSign.
2.) You have a plan that is set up to allow integration (IE you aren't trying to do all of this with a personal plan, or something like that).
There are a couple of terms I will use... Sender and Recipient. In this scenario, the THird Party Website is "the sender" and they are Sending the documents through YOUR DocuSign account, using the API. The people who are signing up for your service are going to be Envelope Recipients.
Just like with the post office, someone has to send, and someone gets the envelope.
So far so good.
So what will happen is that the third party website will write some code that knows how to talk to the DocuSign API, and you will need to know:
-DocuSIgn Account ID (this is your DocuSign account)
-The Integrator Key (this is the key that you will need to certify before going live, which identifies all those API calls as coming from them)
-Credentials to access your account (this can be either the actual creds, or a token, etc).
Now, there are two ways to do it. You can either have the third party website make the and send all of the envelopes as if they all came from a single "user" in DocuSign (likely) or if you know that a particular user should send out things, you can do that too.
I am going to assume that all of the sign up packets will be sent as if they came from something like Signup#company.com.
So you will make sure you have a user in your DocuSIgn account with that Email address and name, and make sure that user has the ability to send via the API (there's a setting in DocuSign admin), and all envelopes will be sent as if that "person" sent them.
You will need the settings for that user (the one that will "send" all the envelopes), set as you showed above. You would need the Account Wide access if you wanted to send "on behalf of" a different user. But you aren't doing that, so you should be cool.
The last thing is that you will need to make sure you have an envelope based plan (as opposed to a seat based plan) because otherwise, that one mega-user will look suspicious (sending hundreds of envelopes in an automated fashion).
I hope this answers the question?
-Dan