Using content generated with #14, pydocusign provides utilities to make HTTP requests that mimic DocuSign notification callbacks.

https://github.com/novafloss

Currently, pydocusign format all errors field into message. https://github.com/novapost/pydocusign/blob/master/pydocusign/client.py#L86

That's a pain to provide meaningful errors to user and administrators.

Would be nice to have specific fields in exeption :

• docusign_code
• docusign_message
• http_code
• http_message

Envelope.STATUS_SENT was removed in 0.7. Should be restored, as it is the simplest way to access envelope's pseudo constants and some third-parties may rely on it.

Would be easier to debug issues by devops if we log at debug level:

• client instanciation
• request and response (brief or verbose)
• maybe request and response contents if we consider that debugging is not secure.

Reference of tab here: https://www.docusign.com/p/RESTAPIGuide/RESTAPIGuide.htm#REST API References/Tabs/Title%20Tab.htm

(PR on the way)

https://www.docusign.com/p/RESTAPIGuide/RESTAPIGuide.htm#REST%20API%20References/Void%20Envelope.htm

Essentially, this is a PUT on envelope, so supporting this feature could support some others as well. i couldn't find a succint list, and didn't see PUT for envelope at http://iodocs.docusign.com/. Here's what i found so far for other uses of that method in the REST docs:

• send a draft envelope: https://www.docusign.com/p/RESTAPIGuide/RESTAPIGuide.htm#REST%20API%20References/Send%20Draft%20Envelope.htm
• modify draft envelope subject and message: https://www.docusign.com/p/RESTAPIGuide/RESTAPIGuide.htm#REST%20API%20References/Modify%20Draft%20Envelope%20Email%20Subject%20and%20Message.htm

Such as sent... Should be pydocusign.Envelope.STATUS_SENT or pydocusign.Recipient.STATUS_SENT (they are Sent, not sent).
Same for other statuses.

At the moment, the file object returned by DocuSignClient.get_envelope_document() returns file object that has no close() method: https://github.com/novapost/pydocusign/blob/467e4e17bb01879068bcf8f50f3118940ad82c57/pydocusign/client.py#L246
The close() method is implemented in the response object. Not in response.raw.

Without close() method, it is quite hard to explicitely close the connection!

As of version 0.12, routingOrder is not required by pydocusign to post envelope. But it looks like it is required by DocuSign API.
=> Always pass a routingOrder, with a default to 0 if necessary.

https://github.com/novafloss/pydocusign/blob/master/pydocusign/client.py#L483

response.raw is an urllib3 response object. response.close is a method on a Requests Response object. I'm not sure why this was added in the first place, but this should not work.

It's possible that older versions of Requests and urllib3 had a bug around this, but using 2.9.0 and up, this line doesn't do anything useful and could be harmful.

At the moment, DocuSignClient.login_information() fails badly when there is either a request error (connection error, network error, timeout...) or a DocuSign error (such as wrong login/pass).
=> Log the errors.
=> Raise DocuSignException with an adequate message.

Add timeout argument to DocuSignClient.__init__() => sets a default timeout used when performing HTTP requests.

For this feature, do not add a timeout argument to every method of the client: let's wait and see if the global timeout option is enough.

If neither root_url or account_url are defined, account_url will not be set, even if account_id is present. https://github.com/novafloss/pydocusign/blob/0.13.2/pydocusign/client.py#L85 i believe this renders the client inoperable, so perhaps an exception should be raised at that point.

This is a requirement for #65

At the moment, as of pydocusign version 0.10, demo/accounts.py creates an user account then deletes it.

As seen in Travis-CI.org, it used to work: see https://travis-ci.org/novapost/pydocusign/jobs/42855139#L244-L256

But now it is broken: see https://travis-ci.org/novapost/pydocusign/jobs/46837725#L287-L306
Looks like the created user account now requires activation. This step has not been automated yet.

Find a solution to pass the tests!

Here are some options:

• automate account activation. Implies fetching and parsing email, then performing HTTP requests. Quite complicated and greedy, but should be possible.
• create account using options so that activation is not necessary. If such options are available, should be the simplest option.
• other ideas? Feel free to propose fixes in comments below ;)

Note: as pydocusign's maintainer I'd like to avoid mocking DocuSign, because I like the idea of having integration tests. This ticket is a typical example where integration reveals issues.

GET /v2/accounts/{accountId}/connect/failures will return a list of DocuSign Connect failures (when a callback isn't adequately handled). i think i'll work up a PR shortly.

DocuSign notifications (see also #14) is XML format.
As a user of pydocusign library, I do not want to care about the XML manipulation (using beautifulsoup, lxml or whatever). I want to focus on the data.

As an example, in order to get envelope status, at the moment I must code my own solution to load and parse XML input.
The proposal is that pydocusign provides a parser/reader which has some envelope_status property.

Support the following API methods:

• Create Account
• [Delete Account](https://www.docusign.com/p/RESTAPIGuide/RESTAPIGuide.htm#REST API References/Delete Account.htm)
• [Get account information](https://www.docusign.com/p/RESTAPIGuide/RESTAPIGuide.htm#REST API References/Get Account Information.htm)

Have a demo script to illustrate usage.

As of version 0.13, Envelope.post_recipient_view() takes routingOrder as argument, whereas DocuSignClient.post_recipient_view() uses attributes like clientUserId, userId or email/userName. Moreover, in DocuSign, routingOrder is not unique. So routing_order is definitely not the most explicit attribute to select a recipient.

See also https://www.docusign.com/p/RESTAPIGuide/RESTAPIGuide.htm#REST%20API%20References/Post%20Recipient%20View.htm

it is spelled incorrectly as requireAcknowledgment when it should be requireAcknowledgment. PR incoming.

i was going to leave a ticket about adding support for Signer.excludedDocuments, but realized that there are actually several attributes not supported by that object. It may be cumbersome to explicitly include all sorts of untested attributes, so perhaps a compromise would be to allow the passage of additional keyword arguments into the objects on instantiation. Whatever solution would have to also be implemented in the to_dict method.

Currently, there isn't support for GET /v2/accounts/{accountId}/envelopes/{envelopeId}. GET in an envelope context only works for returning documents and recipients specifically.

https://docs.docusign.com/esign/restapi/Envelopes/Envelopes/get/

PR forthcoming.

https://diecutter.alwaysdata.com has wrong certificate.
It makes pydocusign.tests.generate_notification_callback_body() fail.

Unsecure http may be enough at the moment, since we don't expect to use real private information in tests.

At the moment, demo scripts are not really readable and poorly usable:

• they read environment variables, because that is something we can setup on travisci.org
• they prompt the user for missing arguments, but the prompt is quite raw

As commands, demo scripts will get an help. Users will be able to provide arguments with options such as demo/accounts.py --integrator-key="some-key".

Lacking support for excludedDocuments in the Signer object.

See also #64

In templates/callback.xml, there is a if..else on DeclineReason, but the produced output has empty DeclineReason if data was provided. The two cases should be swapped.

At the moment, test suite uses PYDOCUSIGN_TEST_* as configuration.
As pydocusign user, in order to simplify configuration process, I want DocuSignClient to use environment variables (if they are available) as default values.

In order:

1. arguments explicitely passed to DocuSignClient() obviously have priority
2. then if DOCUSIGN_* is available, use it
3. else fallback to defaults

Issues I've run into when adding support for more DocuSign features and functionality:

• Defining the attributes multiple times (in the attribute list and in the constructor) is overly verbose
• Doctests for testing object serialization clutters up the code (this is more of a stylistic preference, but I tend to reserve doctests for cases where the the tests would be useful as documentation)
• Had to create my own duplicate hierarchy of Tab objects when adding support for anchor strings

Given a well-configured DocuSignClient (i.e. with username, password, root URL and integrator key), when I call methods such as get_envelope_recipients(), I get an error because account_url attribute has not been initialized. This account_url attribute can be initialized via login_information() method.

Proposal: as a developer, I do not want to add explicit login_information() call everywhere I use other methods. I'd rather call methods such as get_envelope_recipients() which automatically call login_information() if account_url attribute has not been initialized yet.

Starting from version 0.13.1 (2015-03-16) Envelope.post_recipient_view() takes ‘recipient’ argument instead of ambiguous ‘routingOrder’. However, demo at https://pydocusign.readthedocs.io/en/0.13.2/demo.html still uses routingOrder and crashes.

When releasing, the following message appears:

warning: check: missing required meta-data: url

Update Python packaging accordingly.

Apparently, an add_envelope_recipients request returns a 201 response [edit: in v2 of the API] , yet the client is expecting a 200. An exception is raised:

DocuSignException: DocuSign request failed: POST https://demo.docusign.net/restapi/v2/accounts/<account>/envelopes/<envelope>/recipients returned code 201 while expecting code 200; Message: {...}

Should we be setting expected_status_code=201 in just the post for that method, or should we set that in the post method itself?

See the documentation at: [OAuth2 Authentication Support](https://www.docusign.com/p/RESTAPIGuide/RESTAPIGuide.htm#OAuth2/OAuth2 Authentication Support in DocuSign REST API.htm) and [Acting As Other Account Users](https://www.docusign.com/p/RESTAPIGuide/RESTAPIGuide.htm#OAuth2/Acting As Other Account Users.htm)

(I am working on a PR for this.)

Should we gitignore it?

The emailNotification option for signers makes it possible to configure per-recipient email body, subject and language.
See reference at https://www.docusign.com/p/RESTAPIGuide/Content/REST%20API%20References/Recipients/Signers%20Recipient.htm

Important: even if in embedded signing mode (i.e. DocuSign does not send emails to recipients) language is used as the default to display DocuSign's user interface.
See http://stackoverflow.com/questions/26785088/embedded-docusign-signing-using-recipients-language

At the moment, pydocusign supports only notifications on envelope events. But DocuSign has recipient events too. Let's support them!

We have the Envelope model class which has methods that call underlying APIs. Adding a void() helper method would be nice.

Release the 1.0 version.

PR to include:

• #89
• #93
• #95

As of version 0.12, DocuSignCallbackParser.recipients_events returns recipient key, which is in fact mapped to clientUserId. Moreover, there is a recipientId field in callback response which is not returned by recipient_events property.
Both clientUserId and recipientId should be explicitely returned.
For backward compatibility, recipient can be kept.

AttributeError: 'NoneType' object has no attribute 'string' at https://github.com/novafloss/pydocusign/blob/0.13.2/pydocusign/parser.py#L48

A DocusSign Connect configuration may or may not have "Time Zone Information" checked as "Included", which means this method should handle a case where timezone information is not present.

Recipients can be added until the envelope is complete, although auto emails will only be sent if the new recipient's routing order hasn't already been reached: https://www.docusign.com/p/RESTAPIGuide/RESTAPIGuide.htm#REST%20API%20References/Add%20Recipients%20to%20an%20Envelope.htm

Recipients whose process has not been completed can be removed: https://www.docusign.com/p/RESTAPIGuide/RESTAPIGuide.htm#REST%20API%20References/Delete%20Recipients%20from%20an%20Envelope.htm

i intend to make a PR for this soon.

As docusign client software (typically the user interface that uses pydocusign), I want to receive notifications when signatures are updated (typically when document has been signed). At the moment, pydocusign has a "signer return URL", where the signer gets redirected after he accepted or refused a signature. But signers may not proceed the redirection. So a callback from DocuSign service itself would be appreciated. There is DocuSign Connect and "eventNotification" argument in create envelope function.

See https://www.docusign.com/p/RESTAPIGuide/RESTAPIGuide.htm#REST%20API%20References/Send%20an%20Envelope.htm

Implement methods to retrieve (download) documents in envelope.
Typical use case: an envelope has been completed, let's download the signed documents.

See https://www.docusign.com/p/RESTAPIGuide/RESTAPIGuide.htm#REST%20API%20References/Get%20List%20of%20Envelope%20Documents.htm%3FTocPath%3DREST%2520API%2520References|_____52
and perhaps https://www.docusign.com/p/RESTAPIGuide/RESTAPIGuide.htm#REST%20API%20References/Get%20Document%20from%20Envelope.htm%3FTocPath%3DREST%2520API%2520References|_____54

See http://iodocs.docusign.com/APIWalkthrough/requestSignatureFromTemplate
Templates have documents and roles.
When creating an envelope using a template, we need template ID and mapping recipients to roles.

Calling login_information() is not required to use DocuSign API. There is no concept of session.
At the moment, pydocusign's login_information() does completes the setup of the client: API URL and username.
Such setup could be done in initial client's constructor (__init__).
It would avoid HTTP calls.

As a developer of software that uses DocuSign API via pydocusign,
in order to test the behaviour of an HTTP service that receive DocuSign's notification callbacks,
I want to fake these DocuSign's notification requests.

I do not want to follow a complete DocuSign workflow, mostly because:

• it is quite long to create an envelope and sign it (several remote API calls)
• it is quite hard to automatically sign a document (at the moment, I do not know howto)
• while I'm developing a web service, it is usually unreachable from the internet, i.e. DocuSign servers won't be able to send notifications to the service...

So, I'd like the following things:

• tools to generate requests that fake/mock/stub/whatever DocuSign's notification requests. For the body contents, templates may be a good option.
• if possible, tests to validate that pydocusign's templates are up to date and actually look like the ones sent by DocuSign itself... At the moment, I do not know how to achieve this feature.

See https://travis-ci.org/novapost/django-docusign/jobs/48910306#L376-L378
Sometimes there is no clientUserId attached to envelope recipient. Exception should not be raised.

            pydocusign.SignHereTab(
                documentId=1,
                pageNumber=settings.DOCUSING_SIGN_PAGE,
                xPosition=settings.DOCUSIGN_SIGN_XPOS,
                yPosition=settings.DOCUSIGN_SIGN_YPOS,

            ),

works

            pydocusign.fullNameTabs(
                name="Name",
                tabLabel="Name 1",
                pageNumber=settings.DOCUSING_SIGN_PAGE,
                xPosition=375,
                yPosition=574,
            ),

fullNameTabs, companyTabs etc is not recognized. What is the best bet to have these tabs added.

I googled and tinkered and could not find a solution. I apologize in advance if this is answered somewhere or an easy solution that I am missing

See https://www.docusign.com/p/RESTAPIGuide/RESTAPIGuide.htm#REST%20API%20References/Tab%20Parameters.htm%3FTocPath%3DREST%2520API%2520References|Send%2520an%2520Envelope%2520or%2520Create%2520a%2520Draft%2520Envelope|Tab%2520Parameters|_____0

At the moment, we have SignHereTab only.