When accessed using JSONAPI, the output for the fields in a webform is simply a text string. To be more easily machine parseable, this should be rendered as JSON instead.

    "elements": "first_name:\n  '#type': textfield\n  '#title': 'First Name'\n  '#required': true\nlast_name:\n  '#type': textfield\n  '#title': 'Last name'\n  '#required': true\nemail:\n  '#type': email\n  '#title': Email\n  '#required': true\nrequest_description:\n  '#type': textarea\n  '#title': 'Describe the information you''re requesting'\n  '#required': true\n"

On the assumption that representatives from individual FOIA Offices will be logging in to Drupal and creating the content for their Office and defining its request form, we need a means to a) affiliate users with a given Office*, and b) prevent users from editing content not "owned" by their office.

• A potential edge case we may need to cover is the possibility of an Agency representative who should have edit access to multiple Offices in their Agency.

Now that we have shifted plans and are going to work in a headed/coupled manner, we should remove modules (like, OpenAPI/ReDoc, SimpleOAuth, JSONAPI, etc) which are unnecessary given current known site needs.

If it turns out we need some of the functionality these modules provide, we can add that back in later when the use case for them is more clear.

See the fields defined in https://github.com/18F/foia-recommendations/blob/master/schemas.md#foia-metadata-json-file

See release instructions at https://github.com/acquia/blt/releases/tag/8.9.0

In testing the authentication ticket, @DarkCody and I found that user editing is failing on the site. It looks like it stems from a bug in the simple_oauth module reported here: https://www.drupal.org/node/2883862

Per comment from Wim in that ticket, it appears the simple_oauth_extras module repairs that bug. Add it to our code base and confirm you are able to edit and save users without error.

Currently the drush aliases for dev and test are in, but not prod.

Since we spun up the code base, both Lightning and Drupal core have had new releases. We should update to keep in sync.

https://github.com/acquia/lightning/releases/tag/2.1.6

We have the form emitting successfully in JSONAPI. Now we need to work out to POST back to the endpoint in order to create the form submission.

A security update was released for D8 today. Details at https://www.drupal.org/SA-CORE-2017-003

Depending on timing, we may be able to wait for Lightning to update as a distro if we don't want to try to update core independently.

Two unrelated tweaks needed:

• The salt.txt file is not being generated locally in the DOJ-specific local build
• Some documentation would be helpful of how to set up the DB after the code is installed

In order to secure the API endpoints we provide, we'll need to implement some form of API identity verification. That could be a simple API key, OAuth, or something else.

There are two specific cases that will need to be addressed.

1. The front-end connecting to the API to read data and submit Requests
2. Individual FOIA Offices making API calls directly to the backend to update the status of a Request.

We should apply the patch that Malik posted in this issue: https://www.drupal.org/project/jsonapi_extras/issues/2948512

Begin creating system documentation for the features created thus far, including content types, taxonomies, API endpoints, and implemented user stories.

For an initial starting point, work from the Architectural Review documents (as we'll want to start that process also). For consistency store docs in the repo with the codebase.

Setup Travis so that it does all the magic.

Issue 41 from 18F issue queue

The custom 'foia' theme is not being used, and can be removed.

@jenter @malikkotob @ba66e77 Just pinging you to let you know that the repository name changed, so your Git remotes will need to be updated. Please pass along as needed.

The Reservoir distribution builds in an automatic API documentation section that's pretty awesome. Steal it and make it ours.

As discussed with 18f on July 18, we will be moving forward with the Cog theme.
As part of this discussion, we will be need to abstract the 'Susy' grid out of the new theme.
This is so we can layer in the "U.S. Web Design Standards" framework and use their grid.

To allow front ends to access the API (assuming they're not on the same domain) we'll need to add the CORS module to set those headers.

Issue 40 from 18F issue queue

As discussed with 18f on July 18, we will be moving forward with the Cog theme.

The following steps are required to layer in the "U.S. Web Design Standards" framework:
[ ] Using the npm method of inclusion, add in the framework
[ ] Once the files have been generated, confirm both sass imports and js dependencies are included in gulp task framework

By switching to PHP7, we'll get better performance out of Drupal 8. Update the BLT configuration so that the local VM uses PHP7 and file a support request to have our ACE environment updated to use it also.

It's been discussed that there are common field elements which the Request forms for all FOIA Offices share. Determine a means to define these elements in one setting so that when forms are created for individual Offices they are not forgotten.

This could, minimally, be a validation on form creation that checks to ensure fields with the required machine names are included. A better UX for the form creators would be a means by which the fields are automatically created when they start a new form. Webform module provides a templates feature which might be able to provide that capability.