feed-gov-back 0.4

A small framework for API enabled customisable feedback forms

A small API enabled framework for adding user feedback forms to existing applications within GOV.uk (or other apps).

Quick start

• Install the package:

  pip install feed-gov-back

• Add feedback to your INSTALLED_APPS in your settings:

  INSTALLED_APPS = [
      ...
      'feedback',
  ]

• Include the feedback URLconf in your project urls.py like this:

  path('feedback/', include('feedback.services.urls'))
  
  or if not using the Api:
  
  path('feedback/', include('feedback.urls'))

• Run migrations and load fixtures:

  ./manage.py migrate
  ./manage.py loaddata path/to/fedback/fixtures/*.json

Using Make

The Makefile provides some handy commands:

make test  # run all tests
make sdist  # run python setup.py sdist to create a local installable

How it works

A FeedbackForm contains one or more FormElement models of different ElementType. These models represent the form and it’s elements. The data is collected for each submission into FeedbackCollection which contain FeedbackData records for each form element submitted.

As a form can be placed in different parts of a web resource, Placement records can be created to group together form data submitted for different parts of the application. Placements do not have to be created upfront, and can be generated on the fly by providing a unique placement key with the form.

A REST Api is exposed to allow manipulating the models externally, which is useful when this is deployed into a backend service.

In addition, a view to accept form submissions is provided, as well as template tags to render a complete form or part of it.

Forms can be built via the Api, Models or simply created via the Django admin or even fixtures.

Element Types

There are 3 element types defined: scale, large text area and text input. Scale elements can receive options to override defaults. The options and defaults are:

{
    "min": 1,
    "max": 5,
    "min_label": "Poor",
    "max_label": "Excellent",
    "type": int
}

It is also possible to explicitly define the scale labels by providing a list of labels instead of the min/max
combination

``labels: ["great", "indifferent", "poor"]``

In this case the "type" property of the options should be changed to ``str``

Fields can be rendered by the form_element template tag provided or manually in your templates.

Data collection

Data is collected into the FeedbackData model, grouped into FeedbackCollection entries. As feedback forms can be used in different parts of an application, the model expects a Placement to tell it which part of the application or website this form relates to. If a placement is not provided explicitly, a default one will be used. Placement ids can also be provided in runtime by simply providing it as a string. New Placement records will be created.

Settings

The following settings are expected in your Django application

Setting	Description
AUTH_USER_MODEL	A path to the User model. Defaults to auth.User
DEFAULT_PLACEMENT_KEY	A key to use as default placement if one is not provided. Defaults to DEFAULT
ANONYMOUS_COLLECTION	A boolean to determine if to force anonymous collection or retain the user if available. Defaults to True
MANAGED_FEEDBACK_MODELS	Set to False to prevent the creation of database models. Defaults to True

Usage

To include a complete feedback form:

{% load feedback_form %}
{% feedback_form request 'FORM_REFERENCE' %}

or to include a specific placement:

{% feedback_form request 'FORM_REFERENCE' 'PLACEMENT_ID' %}

Note that the feedback_form tag requires the request to pass through it in order toe generate the csrf_token.

One important note regarding FORM_REFERENCE shown in the tag example above: FORM_REFERENCE can be either a Feedback form unique key, it’s unique UUID, the form Model instance itself, or a dict representation of the form. This allows for different usage pattern, depending on where this package is installed. For example, if Feedback forms are to be used across a service which is made of an API and a UI layer as separate applications, the API can install the package allowing for model creation but obviously not using the templatetags as it has no rendering responsibility. The UI however can install the package, disabling model management and only use the tags, by passing the dict returned from the API call. Note that in the case of passing a form model or dict the single quotes should be omitted. The example application demonstrates this concept.

Styling

The implemented template tags wrap the entire form in a div with id feedback-form. Subsequently, each element is div wrapped with a class feedback-form-element. The submit button is classed with feedback-form-button. Within each element the following divs wrap the name, label and description fields: feedback-form-element-name, feedback-form-element-label and feedback-form-element-description

Example App

The example directory contains a simple django project that utilises the feedback lib. It provides a docker contained postgres db which can be built to isolate the example. The make file allows for installation of the library based on a local sdist build.

To run it, create a virtual environment and activate it. Then either provide your own database or docker-compose up to use the docker one. Start with:

./manage.py migrate
./manage.py loaddata ./feed/fixtures/*.json
./manage.py runserver

• You can create your form via http://localhost:8000/admin (create a superuser to access the admin)

• interact with the form via http://localhost:8000

• load the form using a key only: http://localhost:8000/key

• load the form using a dict representation of it: http://localhost:8000/dict