Perhaps it would be advisable to have a unique constraint on SignatureType.signature_backend_code.

• Transfer ownership on Github
• Update URLs in docs
• Update project's settings on readthedocs

django_anysign.CreateSignatureView deals with signature creation. Typically, it is the view where users put documents and signers together.

django_anysign.SignerReturnView is a view where signer lands back from backend page, right after he proceed/refused a signature.

Typical methods/attributes are:

• signer and get_signer => property to get signer instance from request
• signature and get_signature => property to get signature instance from request
• get_context_data() => signer in context data, signer.signature in context data
• update_signer(status, status_date) => updates signer status (backend's specific status). Not implemented.
• update_signature(status, status_date) => updates signature status (backend's specific status). Not implemented.
• template: signature/signer_return.html

The makemigrations management command will create a new migration for the model inheriting SignatureType whenever the keys in settings.ANYSIGN['BACKENDS'] change. This can happen if the setting has different values in different environments. makemigrations will bake the value derived from the first environment into a migration, and then migrate in the other environment will think the migrations are out of sync with the models.

It would be handy to have a management command which would create a SignatureType for each backend in settings.ANYSIGN['BACKENDS']. i suppose that presumes that the SignatureType model didn't implement any additional required fields.

Requires recent version of Tox to setup a nice test grid: https://testrun.org/tox/latest/config.html#generating-environments-conditional-settings

Make sure django-anysign runs with Django 1.8

At the moment, Signature model has a signature_backend_id attribute, which contains the signature's identifier in vendor's external database.
Signers can have the same kind of identifiers. In order to make it easier to fetch/identify/inspect signer instances in vendor's external database, let's store this signature_backend_id for signers too.
This attribute must be optional (blank=True).

The field signature_backend_id from signer model has not a good name !
Rename it to signer_backend_id

At the moment, Signer instances are unordered. But in a typical signature workflow, signers are ordered => add some signing_order field.

I forked it, removed django version limit, and adjusted django_anysign_demo for testing.
With Django 4.1.4, it works fine.
May you consider to remove django version dependency?

Just like signature_backend_id attribute identifies the signature on backend side, we need an identifier on local (Django) side. Because, just as in Django side we store external backend ID, in external backend we may store Django's id. Default primary key (integer id) is not enough. Something like an uuid would be welcome.

Another use case is URL construction: it is better if "signer return" and "callback" URL contain signature uuid:

• it is quick and easy to get the signature object matching the request. We can use a SingleObjectMixin whatever the backend.
• it is a bit harder for clients to "guess" a valid URL and try various POST/GET requests. They need a valid signature identifier.

UUID should be the default implementation, but of course this must be overridable.

Make sure django-anysign runs with Django 1.7

What about following Django's supported versions? See https://www.djangoproject.com/download/
Django supports 1.7, 1.8 and 1.4 branches. 1.4 is not supported by django-anysign, so only 1.7 and 1.8 remain.
=> Drop support for django 1.5 and django 1.6 in the next release.

It should make it easier to maintain the application and demo project.
Those who want support of legacy Django version will still be able to install legacy versions of django-anysign (versions are not deleted on PyPI).

Django ships with a UUIDField, since 1.8. Perhaps the base model classes can use it when Django 1.8 or higher is installed.

django_anysign.SignatureCallbackView handles callback requests from backend, usually sent by backend when signature was updated (signed, changed, refused, delivered, ...).

Typical methods/attributes are:

• signature and get_signature => property to get signature instance from request
• get_context_data() => signer in context data, signer.signature in context data
• update_signature(status, status_date) => updates signature status (backend's specific status). Not implemented.
• template: signature/signature_callback.html

Not sure about signer property and update_signer method (see also #9), because the callback may be called on events that do not belong to a signer or belong to multiple signers. As examples:

• using DocuSign, callbacks can be sent when document is added. No signer involved
• using DocuSign, when signature is created with "embedded signing", all signers are marked as "sent", i.e. multiple signers involved.

For a given signature, signers must be ordered!

• in docs/settings.txt, add a section "Check your settings" at the end of the document.
• actually write checks, maybe using Django's system check framework. Else using hospital
• assert the checks run within the demo

Like #7, but for signer model.