Important change in the new 4.0.x branch

The document version (entity_legal_document_version entity type) ID field has been converted from string to a serial. See #3163562 to find why. Even a minimal update path from 3.0.x has been provided, site builders should be aware of the following aspects:

  • New serial IDs are still keeping the reference to the old string IDs. Old IDs were converted by retaining the numeric part (former timestamp) as new integer ID. For instance, legal_notice_1683794048 (string) was converted into 1683794048 (int).
  • The update path was tested only with MySQL and PostgreSQL. With other database drivers tests should be performed before running updates in production. Feel free to open new issues in order to improve the update path, in entity_legal_update_9002() & entity_legal_post_update_9002().
  • The update path covers also views using the changed fields. We acknowledge that it might not cover the whole situations out in the wild. At least, it covers the view provided by the module but also other views. For sure not all views that can be imagined based on the entities from this module. But such views are quite easy to be fixed from the UI by site builders, if case.
  • We're doing this change in 4.0.x, which is a module's new major version. That means any disruption is acceptable, including not having a 100% update path. Projects are responsible to adapt, even to provide additional update paths if they need.

Getting started

There's a 5 minute webcast available at https://www.youtube.com/watch?v=Syuqy_23L3M that details how to set the module up and how it works. You can also read a tutorial on how to get started at http://www.codesidekick.com/blog/entity-legal-legal-document-management-drupal.

Introduction

The Entity Legal module provides a solid, versionable, exportable and flexible method of storing legal documents such as Terms and Conditions and Privacy Policies. Users can be forced or soft-suggested to re-read and re-accept legal documents when they change and a full audit trail of which user has accepted when is available.

Why it was made

This module aims to minimise assumptions made about how user acceptable legal documents are managed on a site. Sites can have more than just a terms and conditions or terms of use page, and getting different users to accept different agreements is often a necessary component of complex, member oriented sites.

Alternatives

Differences from legal and terms of use module.

  1. Support for more than one type of document on the site (eg Terms of Use as well as Privacy Policy and Terms and Conditions). You decide what types of documents are, their names, the users roles they correspond to and when users need to accept them.
  2. Entity API based and fully exportable using Features.
  3. Each document has custom settings as to whether users accept during sign-up and need to re-accept when a new version is created. Alternatively documents can live as static pages with no user interaction required.
  4. Provides an audit trail of which user accepted which version and what time.
  5. Comes loaded with different methods of notifying users of a document update including popup, drupal status message and full page redirection.
  6. Comes complete with a very high level of automated test coverage for each acceptance method and Entity type.
  7. Extensible, site administrators can create their own delivery methods using the modules API and because the entire module is written using Entity there are also many hooks provided by the Entity API that are provided.

Project information

Releases