Update docs

CONTRIBUTING.md

@@ -139,7 +139,7 @@ information on how to run and edit the documentation page.
 
 #### Style Guides
 
-* For Scala code we use [Scalastyle](https://www.scalastyle.org/). The configs are `scalastyle-config.xml` and
+* For Scala code we use [Scalastyle](http://www.scalastyle.org/). The configs are `scalastyle-config.xml` and
   `scalastyle-test-config.xml` for source code and test code respectively
     * We have it set to fail builds if the styling rules are not followed. For example, one of our rules is that all
       lines must be <= 120 characters, and a build will fail if that is violated.
@@ -210,4 +210,4 @@ A pull request must satisfy our [pull request requirements](#pull-request-requir
 Afterwards, if a Pull Request is approved, a maintainer of the project will merge it. If you are a maintainer, you can
 merge your Pull Request once you have the approval of at least 2 other maintainers.
 
-> Note: The first time you make a Pull Request, add yourself to the authors list [here](AUTHORS.md) as part of the Pull Request
+> Note: The first time you make a Pull Request, add yourself to the authors list [here](https://github.com/vinyldns/vinyldns/blob/master/AUTHORS.md) as part of the Pull Request

modules/docs/src/main/mdoc/api/zone-model.md

@@ -241,12 +241,12 @@ Note that if both a backend ID and specific connection keys are included on a zo
 
 Zone Connection specifies the connection information to the backend DNS server.
 
-field        | type        | description |
+| field         | type   | description                                                                                                                                                                                                                                                  |
------------- | :---------- | :---------- |
+|---------------|:-------|:-------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------|
-primaryServer | string      | The IP address or host that is connected to.  This can take a port as well `127.0.0.1:5300`.  If no port is specified, 53 will be assumed. |
+| primaryServer | string | The IP address or host that is connected to.  This can take a port as well `127.0.0.1:5300`.  If no port is specified, 53 will be assumed.                                                                                                                   |
-keyName       | string      | The name of the DNS key that has access to the DNS server and zone.  **Note:** For the transfer connection, the key must be given *allow-transfer* access to the zone.  For the primary connection, the key must be given *allow-update* access to the zone. |
+| keyName       | string | The name of the DNS key that has access to the DNS server and zone.  **Note:** For the transfer connection, the key must be given *allow-transfer* access to the zone.  For the primary connection, the key must be given *allow-update* access to the zone. |
-name          | string      | A user identifier for the connection.
+| name          | string | A user identifier for the connection.                                                                                                                                                                                                                        |
-key           | string      | The TSIG secret key used to sign requests when communicating with the primary server.  **Note:** After creating the zone, the key value itself is hashed and obfuscated, so it will be unusable from a client perspective. |
+| key           | string | The TSIG secret key used to sign requests when communicating with the primary server.  **Note:** After creating the zone, the key value itself is hashed and obfuscated, so it will be unusable from a client perspective.                                   |
 
 #### ZONE CONNECTION EXAMPLE <a id="zone-conn-example"></a>
 
@@ -261,4 +261,10 @@ key           | string      | The TSIG secret key used to sign requests when com
 
 ### SHARED ZONES <a id="shared-zones"></a>
 
-Shared zones allow for a more open management of records in VinylDNS. Zone administrators can assign ownership of records to groups. Any user in VinylDNS can claim existing unowned records in shared zones, as well as create records in those zones. Once a record is owned, only users in the record owner group, the zone administrators and those with relevant ACL rules can modify or delete the record. The [batch change API endpoint](create-batchchange.html) and [batch change area of the portal](../portal/batch-changes.html) are where users can create new records in shared zones, modify records they own, or claim unowned records. If a zone's shared state changes to false the record ownership access is no longer applicable.
+Shared zones allow for a more open management of records in VinylDNS. Zone administrators can assign ownership of
+records to groups. Any user in VinylDNS can claim existing unowned records in shared zones, as well as create records in
+those zones. Once a record is owned, only users in the record owner group, the zone administrators and those with
+relevant ACL rules can modify or delete the record. The [batch change API endpoint](create-batchchange.html)
+and [DNS change area of the portal](../portal/dns-changes.html) are where users can create new records in shared zones,
+modify records they own, or claim unowned records. If a zone's shared state changes to false the record ownership access
+is no longer applicable.

modules/docs/src/main/mdoc/index.md

@@ -1,6 +1,5 @@
 ---
-layout: home
+layout: home title:  "Home"
-title:  "Home"
 section: "home"
 position: 1
 ---
@@ -9,18 +8,21 @@ position: 1
 
 ![VinylDNS logo](../img/vinyldns-fulllogoDARK-300.png)
 
-VinylDNS is a vendor agnostic front-end for enabling self-service DNS and streamlining DNS operations.  It is designed to integrate with your existing DNS infrastructure, and provides extensibility to fit your installation.
+VinylDNS is a vendor agnostic front-end for enabling self-service DNS and streamlining DNS operations. It is designed to
-VinylDNS manages millions of DNS records supporting thousands of engineers in production at [Comcast](http://www.comcast.com).
+integrate with your existing DNS infrastructure, and provides extensibility to fit your installation. VinylDNS manages
-The platform provides fine-grained access controls, auditing of changes, a self-service user interface,
+millions of DNS records supporting thousands of engineers in production at [Comcast](https://comcast.github.io/). The
-secure RESTful API, and integration with infrastructure automation tools like Ansible and Terraform.
+platform provides fine-grained access controls, auditing of changes, a self-service user interface, secure RESTful API,
+and integration with infrastructure automation tools like Ansible and Terraform.
 
 VinylDNS helps secure DNS management via:
+
 * AWS Sig4 signing of all messages to ensure that the message that was sent was not altered in transit
 * Throttling of DNS updates to rate limit concurrent updates against your DNS systems
 * Encrypting user secrets and TSIG keys at rest and in-transit
 * Recording every change made to DNS records and zones
 
 Integration is simple with first-class language support including:
+
 * Java
 * JavaScript
 * Python

modules/docs/src/main/mdoc/operator/pre.md

@@ -1,6 +1,5 @@
 ---
-layout: docs 
+layout: docs title:  "Pre-requisites"
-title:  "Pre-requisites"
 section: "operator_menu"
 ---
 
@@ -41,44 +40,6 @@ Connections (DDNS and Transfer) can be setup
   can [configure default zone connections](config-api.html#default-zone-connections). When no zone connection is
   specified on a zone, the global defaults will be used.
 
-## Database
-
-[database]: #database
-
-The VinylDNS database has a `NoSQL` / non-relational design to it. Instead of having a heavily normalized set of SQL
-tables that surface in the system, VinylDNS relies on `Repositories` where each `Repository` is independent of each one
-another. This allows implementers to best map each `Repository` into the data-store of choice.
-
-As `Repositories` are independent, there are no "transactions" that span repositories. Each `Repository` implementation
-can choose to use transactions if it maps to multiple tables within itself.
-
-There are **links** across repositories, for example the `RecordSet.id` would be referenced in
-a `RecordSetChangeRepository`.
-
-The following are the repositories presently used by VinylDNS:
-
-* `RecordSetRepository` - Instead of individual DNS records, VinylDNS works at the `RRSet`. The unique key for RecordSet
-  is the `record name` + `record type`
-* `RecordChangeRepository` - The history of all changes to all records in VinylDNS. In general, some kind of pruning
-  strategy should be implemented otherwise this could get quite large
-* `ZoneRepository` - DNS Zones and managing access to zones
-* `ZoneChangeRepository` - The history of all changes made to _zones_ in VinylDNS. Zone changes can including syncs,
-  updating ACL rules, changing zone ownership, etc.
-* `GroupRepository` - VinylDNS Groups
-* `UserRepository` - VinylDNS Users. These users are typically created the first time the user logs into the portal. The
-  user information will be pulled from LDAP, and inserted into the VinylDNS UserRepository
-* `MembershipRepository` - Holds a link from users to groups
-* `GroupChangeRepository` - Holds changes to groups and membership
-* `BatchChangeRepository` - VinylDNS allows users to submit multiple record changes _across_ DNS zones at the same time
-  within a `Batch`
-  The `BatchChangeRepository` holds the batch itself and all individual changes that executed in the batch.
-* `UserChangeRepository` - Holds changes to users. Currently only used in the portal.
-
-## Database Types
-
-### MySQL
-
-Review the [Setup MySQL Guide](setup-mysql.html) for more information.
 
 ## Message Queues
 

modules/docs/src/main/mdoc/portal/batch-changes.md

@@ -1,54 +0,0 @@
----
-layout: docs
-title:  "Batch Changes"
-section: "portal_menu"
----
-
-## Batch Changes
-Batch Changes is an alternative to submitting individual RecordSet changes and provides the following:
-
-* The ability to include records of multiple record types across multiple zones.
-* Input names are entered as fully-qualified domain names (or IP addresses for `PTR` records), so users don't have to think in record/zone context.
-
-#### Access
-* Access permissions will follow existing rules (admin group or ACL access). Note that an update (delete and add of the same record name, zone and record type combination) requires **Write** or **Delete** access.
-* <span class="important">**NEW**</span> **Records in shared zones.** All users are permitted to create new records or update unowned records in shared zones.
-
-#### Supported record types
-* Current supported record types for Batch Change are: `A`, `AAAA`, `CNAME`, `PTR`, `TXT`, and `MX`.
-* Additionally, there are `A+PTR` and `AAAA+PTR` types that will be processed as separate `A` (or `AAAA`) and `PTR` changes in the VinylDNS backend. Deletes for `A+PTR` and `AAAA+PTR` require Input Name and Record Data.
-* Supported record types for records in shared zones may vary.
-Contact your VinylDNS administrators to find the allowed record types.
-This does not apply to zone administrators or users with specific ACL access rules.
-
-#### Requirements
-* DNS change requests must contain at least one change.
-* The maximum number of single changes within a Batch change varies by instance of VinylDNS. Contact your VinylDNS administrators to find the Batch change limit for your instance.
-* To update an existing record, you must delete the record first and add all expected records within the same request; a delete and add of the same record set within a Batch change request will be processed as an update.
-* When creating a new record in a shared zone, or updating an existing unowned record, a record owner group is required. Once the owner group is assigned only users in that group, zone admins, and users with ACL permissions can modify the record.
-
----
-### Create a Batch Change
-1. Go to the Batch Changes section of the site.
-1. Select the *New Batch Change* button.
-1. Add a description.
-1. Add record changes in one of two ways:
- - Select the *Add a Change* button to add additional rows for data entry as needed.
- - Select the *Import CSV* button to choose and upload a CSV file of the record changes. See [Batch Change CSV Import](#dns-change-csv-import) for more information.
-1. Select the submit button. Confirm your submission.
- - If your submission was successful you'll redirect to the Batch Change summary page where you will see the status of the Batch Change request overall and of the individual records in the Batch Change.
- - If there are errors in the Batch Change you will remain on the form with prompts to correct errors before you attempt to submit again.
-
-[![Batch Changes main page screenshot](../img/portal/dns-change-main-annotated.png){: .screenshot}](../img/portal/dns-change-main-annotated.png)
-[![New Batch Change form screenshot](../img/portal/dns-change-new-annotated.png){: .screenshot}](../img/portal/dns-change-new-annotated.png)
-[![Submitted Batch Change screenshot](../img/portal/dns-change-summary.png){: .screenshot}](../img/portal/dns-change-summary.png)
-
-#### Batch Change CSV Import
-[Download a sample CSV here](../static/dns-changes-csv-sample.csv)
-* The header row is required. The order of the columns is `Change Type, Record Type, Input Name, TTL, Record Data`.
-* The TTL field is optional for each record, but the column is still required. If TTL is empty VinylDNS will use the existing TTL value for record updates or the default TTL value for new records.
-
-### Review a Batch Change
-You can review your submitted Batch Change requests by selecting the linked Batch ID or View button for the Batch Change on the main page of the Batch Change section in the portal.
-
-[![List of Batch Change requests screenshot](../img/portal/dns-change-list-annotated.png){: .screenshot}](../img/portal/dns-change-annotated.png)

modules/docs/src/main/mdoc/portal/dns-changes.md

@@ -14,7 +14,7 @@ DNS Changes is an alternative to submitting individual RecordSet changes and pro
 
 #### Access
 * Access permissions will follow existing rules (admin group or ACL access). Note that an update (delete and add of the same record name *or* delete of single entry of multi-record DNS record set, zone and record type combination) requires **Write** or **Delete** access.
-* <span class="important">**NEW**</span> **Records in shared zones.** All users are permitted to create new records or update unowned records in shared zones.
+* **Records in shared zones.** All users are permitted to create new records or update unowned records in shared zones.
 
 #### Supported record types
 * Current supported record types for DNS change are: `A`, `AAAA`, `CNAME`, `PTR`, `TXT`, and `MX`.
@@ -53,4 +53,4 @@ This does not apply to zone administrators or users with specific ACL access rul
 ### Review a DNS Change
 You can review your submitted DNS Change requests by selecting the linked DNS Change ID or View button for the DNS Change on the main page of the DNS Changes section in the portal.
 
-[![List of DNS Change requests screenshot](../img/portal/dns-change-list-annotated.png){: .screenshot}](../img/portal/dns-change-annotated.png)
+[![List of DNS Change requests screenshot](../img/portal/dns-change-list-annotated.png){: .screenshot}](../img/portal/dns-change-list-annotated.png)

modules/docs/src/main/mdoc/portal/manage-access.md

@@ -3,13 +3,21 @@ layout: docs
 title:  "Manage Access"
 section: "portal_menu"
 ---
+
 ## Manage Access to Zones and Records <a id="access"></a>
+
 ### Full Access
-Members of a zone admin group have *full* access to all records and permissions in the zone.  Each zone is limited to one admin group.  Typically, this should be a limited set of
+
-users. If you wish to add other users to a group you can do so in the [Groups](manage-membership.html) section of the portal.
+Members of a zone admin group have *full* access to all records and permissions in the zone. Each zone is limited to one
+admin group. Typically, this should be a limited set of users. If you wish to add other users to a group you can do so
+in the [Groups](manage-membership.html) section of the portal.
 
 ### Limited Access
-If you don't want a user to have full access to a zone you can use ACL rules to give them more granular access. With ACL rules, the zone admins can grant individual users or groups read, write or delete access to all records in the zone, or a subset of record names and/or types.
+
+If you don't want a user to have full access to a zone you can use ACL rules to give them more granular access. With ACL
+rules, the zone admins can grant individual users or groups read, write or delete access to all records in the zone, or
+a subset of record names and/or types.
+
 1. Go to the desired zone
 1. Select the Manage Zone tab
 1. Select the Create ACL rule button
@@ -18,5 +26,11 @@ If you don't want a user to have full access to a zone you can use ACL rules to
 
 [![ACL rule form screenshot](../img/portal/create-acl-rule.png){:.screenshot}](../img/portal/create-acl-rule.png)
 
-### <span class="important">**NEW**</span> Shared Zones
+### Shared Zones
-The shared zone feature is designed to allow more granular record ownership and management in a flexible way. Super users can mark zones as 'shared' which then allow any users to create new records or claim existing unowned records in zones. Zone administrators can assign records in a shared zone to specific groups by designating a group when creating the record set or when updating existing records in the portal. Users who are not zone administrators can create new records in shared zones, or claim and modify unowned records in shared zones, through the [DNS Changes](dns-changes.html) interface.
+
+The shared zone feature is designed to allow more granular record ownership and management in a flexible way. Super
+users can mark zones as 'shared' which then allow any users to create new records or claim existing unowned records in
+zones. Zone administrators can assign records in a shared zone to specific groups by designating a group when creating
+the record set or when updating existing records in the portal. Users who are not zone administrators can create new
+records in shared zones, or claim and modify unowned records in shared zones, through
+the [DNS Changes](dns-changes.html) interface.