This app handles user feedback related things.
To run unit tests, execute the following:
bundle exec rake
Testing with a mock
bowl from the
development> bowl feedback
Testing with real authorisation
In order to raise tickets in Zendesk, the
feedback app submits data to the
support app. As the relevant
support app endpoints are behind
feedback needs a bearer token for authorisation. To get this working after an import of signon data from preview:
Copy the token from the support app initializer.
Start a rails console session within
signonotron2> bundle exec rails c
Execute the following (to update the token):
u = User.find_by_email('email@example.com') a = u.authorisations.first a.token = "<PLACE TOKEN HERE>" a.save
To start with real authentication using
development> GDS_SSO_STRATEGY=real bowl signon support feedback
Assisted Digital Help With Fees Feedback
This feedback is not stored in the support-api like the other tickets. This data is stored in a google spreadsheet. The ID of the spreadsheet to store the data in is set via the following environment:
To find the ID of a spreadsheet you wish to use, the following documentation from google is useful.
Authorisation for writing to the spreadsheet must be granted to the app.
- Generate a service account (see Google's documentation) and store the JSON key somewhere safe.
- Extract the
client_emailvalue from the JSON key and make it available to the app in the
- Extract the
private_keyvalue from the JSON key and make it avaiable to the app via the
- Share the spreadsheet that you want to write data to with the email address
stored in the
GOOGLE_CLIENT_EMAIL. It should have at least "can edit" permissions so the application can write data to the sheet.
Email Survey Signups
This type of feedback is not actually feedback, it's a response from a banner displayed by static asking users to provide an email address where we can send them a link to a survey. You can find out more about surveys in static by reading the documentation.
The request will contain an
email_address (the users email address), a
survey_source (the path on GOV.UK where the sign up form was displayed), and
survey_id (the survey they were invited to take part in). The
should match with an instance of
EmailSurvey defined in
These instances, like their counterparts in static, have start and endtimes so
that we don't send emails when the survey has closed. Unlike their counterparts
in static they do not have match rules on the path - response that gets past an
survey_id check and is in the
active? time period will be sent an email.
The email is sent using GOV.UK Notify using the "GOV.UK Surveys" service and a
hardcoded email template (name:
that belongs to that service. This means that all running instances must use
API keys for the same service or the template won't exist. The API key is
provided with the env var:
Deployed environments have this filled in via puppet and our standard mechanism for handling keys. On the GOV.UK dev vm you'll want to join the service on GOV.UK Notify and create your own API key. When creating a key for yourself choosese either:
- "test" - which won't send any emails at all, but will give you valid responses from the API
- "team" - which will only send emails to people on the team or the whitelisted email addresses.
Note that future versions may allow for different surveys to use different templates, but they'll still all have to belong to the same Notify service.
A note on Notify template parameters
Notify templates can be parameterised, and when we talk to the notify API we
personalisation key that contains values for all the parameters in the
template. Notify will error if there are missing keys, but it will also error
if there are extra keys. This means we have to take care when editing the
template in the Notify UI and take care not to introduce, nor remove parameters
without updating the code.
Currently the template takes a single parameter:
survey_url- the url that the survey lives at and will be sent in the email to invite the user to take part in that survey - this is constructed by taking the
EmailSurveyinstance and adding the
cparam to the query string.
Adding new parameters will require a deploy, so it might be best to add a new template with new parameters and have the deploy change the template id and the parameters.