[trafficcontrol] 14/46: replaced images with figures, sections with term definitions

[mi...@apache.org]

This is an automated email from the ASF dual-hosted git repository.

mitchell852 pushed a commit to branch master
in repository https://gitbox.apache.org/repos/asf/trafficcontrol.git

commit bb41f029ca62bf3c8976aa712869514bc51e533d
Author: ocket8888 <oc...@gmail.com>
AuthorDate: Thu Sep 13 05:59:37 2018 -0600

    replaced images with figures, sections with term definitions
---
 docs/source/admin/quick_howto/ds_requests.rst | 71 ++++++++++-----------------
 1 file changed, 27 insertions(+), 44 deletions(-)

diff --git a/docs/source/admin/quick_howto/ds_requests.rst b/docs/source/admin/quick_howto/ds_requests.rst
index 997935e..45fb5b6 100644
--- a/docs/source/admin/quick_howto/ds_requests.rst
+++ b/docs/source/admin/quick_howto/ds_requests.rst
@@ -18,64 +18,47 @@
 Delivery Service Requests
 =========================
 
-When enabled in traffic_portal_properties.json, delivery service requests are created when ALL users attempt to create, update or delete a delivery service.
-This allows users with higher level permissions (ops or admin) to review the changes for completeness and accuracy before deploying the changes.
-In addition, most delivery service changes require cache config updates (aka queue updates) and/or a cdn snapshot. Both of these actions are reserved for users with elevated permissions.
+When enabled in ``traffic_portal_properties.json``, Delivery Service requests are created when *all* users attempt to create, update or delete a Delivery Service. This allows users with higher level permissions (ops or admin) to review the changes for completeness and accuracy before deploying the changes. In addition, most Delivery Service changes require cache configuration updates (aka queue updates) and/or a CDN snapshot. Both of these actions are reserved for users with elevated per [...]
 
-A list of the delivery service requests associated with your tenant can be found here:
+A list of the Delivery Service requests associated with your tenant can be found under 'Services' -> 'Delivery Service Requests'
 
-``https://traffic-portal.domain.com/#!/delivery-service-requests``
+.. figure:: ../traffic_portal/images/tp_table_ds_requests.png
+	:width: 60%
+	:align: center
+	:alt: A screenshot of the Traffic Portal UI depicting an example list of Delivery Service Requests
 
-.. image:: ../traffic_portal/images/tp_table_ds_requests.png
+	Example Delivery Service Request Listing
 
 Who Can Create a Delivery Service Request and How?
-##################################################
+--------------------------------------------------
 
-Users with the Portal role (or above) can create delivery service requests by doing one of three things:
+Users with the Portal role (or above) can create Delivery Service Requests by doing one of three things:
 
-1. Creating a new delivery service
-2. Updating an existing delivery service
-3. Deleting an exiting delivery service
+- Creating a new Delivery Service
+- Updating an existing Delivery Service
+- Deleting an exiting Delivery Service
 
-By performing one of these actions, a delivery service request will be created for you with a status of draft or submitted. You determine the status of your request. Only change the status of your request to submitted once the request is ready for review and deployment.
+By performing one of these actions, a Delivery Service Request will be created for you with a status of 'draft' or 'submitted'. You determine the status of your request upon submission. Only change the status of your request to 'submitted' once the request is ready for review and deployment.
 
 Who Can Fulfill a Delivery Service Request and How?
-###################################################
+---------------------------------------------------
 
-Users with elevated permissions (Operations or above) can fulfill (apply the changes) or reject the delivery service request. In fact, they can do all of the following:
+Users with elevated permissions (Operations or above) can fulfill (apply the changes) or reject the Delivery Service Request. In fact, they can do all of the following:
 
-Update the contents of the delivery service request
-***************************************************
+Update the contents of the Delivery Service request
+	This will update the "Last Edited By" field to indicate who last updated the request.
 
-Optional. This will update the "Last Edited By" field to indicate who last updated the request.
-
-Assign or unassign the delivery service request
-***********************************************
-
-Optional. Assignment is currently limited to current user. This is optional as fulfillment will auto-assign the request to the user doing the fulfillment.
-
-Reject the delivery service request
-***********************************
-
-Rejecting a delivery service request will set status to ``rejected`` and the request can no longer be modified. This will auto-assign the request to the user doing the rejection.
-
-Fulfill the delivery service request
-************************************
-
-Fulfilling a delivery service request will show the requested changes and, once committed, will apply the desired changes and set status to ``pending``. The request is pending because many types of changes will require cache config updates (aka queue updates) and/or a cdn snapshot. Once queue updates and/or cdn snapshot is complete, the request should be marked ``complete``.
-
-Complete the delivery service request
-*************************************
-
-Only after the delivery service request has been fulfilled and the changes have been applied can a delivery service request be marked as complete. Marking a delivery service as complete is currently a manual step because some changes require cache config updates (aka queue updates) and/or a cdn snapshot.
-Once that is done and the changes have been deployed, the request status should be changed from ``pending`` to ``complete``.
-
-
-Delete the delivery service request
-***********************************
-
-Delivery service requests with a status of draft or submitted can always be deleted entirely if appropriate.
+Assign or Unassign the Delivery Service Request
+	Assignment is currently limited to current user. This is optional as fulfillment will auto-assign the request to the user doing the fulfillment.
 
+Reject the Delivery Service Request
+	Rejecting a Delivery Service Request will set status to 'rejected' and the request can no longer be modified. This will auto-assign the request to the user doing the rejection.
 
+Fulfill the Delivery Service Request
+	Fulfilling a Delivery Service Request will show the requested changes and, once committed, will apply the desired changes and set status to 'pending'. The request is pending because many types of changes will require cache configuration updates (aka queue updates) and/or a CDN snapshot. Once queue updates and/or CDN snapshot is complete, the request should be marked 'complete'.
 
+Complete the Delivery Service Request
+	Only after the Delivery Service Request has been fulfilled and the changes have been applied can a Delivery Service Request be marked as 'complete'. Marking a Delivery Service as 'complete' is currently a manual step because some changes require cache configuration updates (aka queue updates) and/or a CDN snapshot. Once that is done and the changes have been deployed, the request status should be changed from 'pending' to 'complete'.
 
+Delete the Delivery Service request
+	Delivery Service Requests with a status of 'draft' or 'submitted' can always be deleted entirely if appropriate.