style: mdformat fixes

docs/architecture/technical-details-of-permission-for-user-fields.md

@@ -1,6 +1,6 @@
 ### Terminology:
 
-- user row: a user row refers to a row being updated.  Row is redundant but included to
+- user row: a user row refers to a row being updated. Row is redundant but included to
     help distinguish between row and field level security.
 - team mate: a user assigned through UserPermission to the same project as another user
 - any team member: a user assigned to a project through UserPermission
@@ -11,14 +11,14 @@
 
 ### Source of Privileges
 
-Field level security specifics are derived from u[cru.py](../../app/core/cru_permissions.py).  The file includes several lists that
-you can use to derive different privileges.  Search for these terms
+Field level security specifics are derived from u[cru.py](../../app/core/cru_permissions.py). The file includes several lists that
+you can use to derive different privileges. Search for these terms
 
 - `_cru_permissions[profile_value]`
 - `_cru_permissions[member_project]`
 - `_cru_permissions[practice_lead_project]`
 - `_cru_permissions[admin_global]`
-    fields followed by CRU or a subset of CRU for Create/Read/Update.  Example:
+    fields followed by CRU or a subset of CRU for Create/Read/Update. Example:
     `first_name:["RU"]` for a list would indicate that first name is readable and updateable
     for the list.
 
@@ -40,15 +40,15 @@ The following API endpoints retrieve users:
 
     - /user end point:
         - Global admins can read, update, and create fields specified in
-            [cru.py](../../app/core/cru.py).  Search for
+            [cru.py](../../app/core/cru.py). Search for
             `_user_permissions[admin_global]`).
 
         - Project admins can read and update fields specified in
             [cru.py](../../app/core/cru.py) for other project leads.\
             Search for for `_user_permissions[admin_project]` in [cru.py](../../app/core/cru.py)
 
         - Practice area leads can read and update fields specified in
-            [cru.py](../../app/core/cru.py) for fellow team members.  If
+            [cru.py](../../app/core/cru.py) for fellow team members. If
             the team member is in the same practice area,\
             Search for for `_user_permissions[practice_lead_project]` in [cru.py](../../app/core/cru.py)
 
@@ -66,7 +66,7 @@ The following API endpoints retrieve users:
 
 #### /me endpoint functionality
 
-Used for reading and updating information about the user that is logged in.  User permission assignments do not apply.
+Used for reading and updating information about the user that is logged in. User permission assignments do not apply.
 
 - Row Level Security: Logged in user can always read and update their own information.
 - Field Level Security: For read and update permissions, see `_cru_permissions[profile_value]` in [cru.py](../../app/core/cru.py).
@@ -79,7 +79,7 @@ This is covered by issue #394.
 
 ##### Field level specifics / cru.py
 
-The implemented field level security specifics can be derived from [cru.py](../../app/core/cru.py) and should match the requirements.  If field privileges change or the requirements
+The implemented field level security specifics can be derived from [cru.py](../../app/core/cru.py) and should match the requirements. If field privileges change or the requirements
 don't match what is implemented this can be fixed by changing [cru.py](../../app/core/cru.py).
 
 ##### /user endpoint technical implementation
@@ -88,41 +88,41 @@ don't match what is implemented this can be fixed by changing [cru.py](../../app
     **serializers.py, permission_check.py**
 - get (read)
     - /user - see above bullet about response fields.
-    - /user/<uuid> fetches a specific user.  See above bullet about response fields.  If the requesting_user does not have permission
+    - /user/<uuid> fetches a specific user. See above bullet about response fields. If the requesting_user does not have permission
         to view the user, PermisssionUtil.get_user_read_fields will find no fields to serialize and throw a ValidationError
 - patch (update): `UserViewSet.partial_update` => `UserValidation.validate_patch_request(request)`.\
     validate_user_fields_patchable(requesting_user, response_related_user, request_fields)\` will compare request fields
-    against `cru.user_post_fields[admin_global]` which is derived from `_cru_permissions`.  If the request fields
+    against `cru.user_post_fields[admin_global]` which is derived from `_cru_permissions`. If the request fields
     include a field outside the requesting_user's scope, the method returns a PermissionError, otherwise the
-    record is udated.  **views.py, permission_check.py**
+    record is udated. **views.py, permission_check.py**
 - post (create): UserViewSet.create: If the requesting_user is not a global admin, the create method
     will throw an error. Calls UserValidation.validate_user_fields_postable which compares
     pe **views.py**
 
 ##### /me end point technical implementation
 
 - response fields for get and patch: `UserProfileAPISerializer.to_representation` => `UserValidation.get_user_read_fields` determines which fields are serialized.
-- get: see response fields above.  No request fields accepted.  **views.py, serializer.py**
+- get: see response fields above. No request fields accepted. **views.py, serializer.py**
 - patch (update): By default, calls super().update_partial of UserProfileAPIView for
-    the requesting user to update themselves.  **views.py, serializer.py**
-- post (create): not applicable.  Prevented by setting http_method_names in
-    UserProfileAPIView to \["patch", "get"\]
+    the requesting user to update themselves. **views.py, serializer.py**
+- post (create): not applicable. Prevented by setting http_method_names in
+    UserProfileAPIView to ["patch", "get"]
 
 #### Supporting Files
 
-Documentation is generated by pydoc package.  pydoc reads comments between triple quotes. See Appendix A.
+Documentation is generated by pydoc package. pydoc reads comments between triple quotes. See Appendix A.
 
 - [permission_check.html](./docs/pydoc/permission_check.html)
 - [permission_fields.py](./docs/pydoc/http_method_field_permissions.html) => called from permission_check to
-    determine permissiable fields.  permission_fields.py derives permissable fields from
+    determine permissiable fields. permission_fields.py derives permissable fields from
     user_permission_fields.
 - user_permission_fields_constants.py => see permission_fields.py
 - constants.py => holds constants for permission types.
 - urls.py
 
 ### Test Technical Details
 
-Details of the purpose of each test and supporting code can be found in the the docs/pydoc documentation.  Additional methods are automatically called based on the name
+Details of the purpose of each test and supporting code can be found in the the docs/pydoc documentation. Additional methods are automatically called based on the name
 of the method.
 
 ### Appendix A - Generate pydoc Documentation
@@ -132,20 +132,20 @@ of the method.
 pydoc documentation are located between triple quotes.
 
 - See https://realpython.com/documenting-python-code/#docstring-types for format for creating class, method,
-    or module pydoc.  For documenting specific variables, you can do this as part of the class, method,
+    or module pydoc. For documenting specific variables, you can do this as part of the class, method,
     or module documentation.
 - Check the file is included in documentation.py
 - After making the change, generate as explained below.
 
 #### Modifying pydoc Documentation
 
-Look for documentation between triple quotes.  Modify the documentation, then generate as explained
+Look for documentation between triple quotes. Modify the documentation, then generate as explained
 below.
 
 #### Generating pydoc Documentation
 
-From Docker screen, locate web container.  Select option to open terminal.  To run locally, open local
-terminal.  From terminal:
+From Docker screen, locate web container. Select option to open terminal. To run locally, open local
+terminal. From terminal:
 
 ```
 cd app

docs/contributing/howto/implement-user-based-security.md

@@ -2,7 +2,7 @@
 
 - **one-to-many user-related data access policy:** policy for tables where each row in the table is related to one and only one user, directly or indirectly.
 - **authorization data access policy:** policy that requires authorization for create, update, delete and optionally read access.
-- **other data access policy:** any custom policy not covered by the previous two polices.  For example, data access policy for create, update, and delete could be based on Djano roles.  In that scenario, a specific table might only be updateable by a user with a specific Django role.
+- **other data access policy:** any custom policy not covered by the previous two polices. For example, data access policy for create, update, and delete could be based on Djano roles. In that scenario, a specific table might only be updateable by a user with a specific Django role.
 
 ## One-to-many user related data policy
 
@@ -30,7 +30,7 @@ A table that requires a user related data policy must have "user" as a field tha
 
 ### Record security
 
-- determines whether a specific record can be viewed, updated, or created.  If the table requires field level security then implementing record level security is not required.
+- determines whether a specific record can be viewed, updated, or created. If the table requires field level security then implementing record level security is not required.
 - implementation:
     - modify views.py
         - find `<table>ViewSet`
@@ -64,7 +64,7 @@ A table that requires a user related data policy must have "user" as a field tha
 
 ## Authorization data access policy
 
-For many tables, create, update, and delete for all rows in the table are allowed if the request is from an authenticated user.  Ability to read all rows may or may not require authentication.  To implement one of these
+For many tables, create, update, and delete for all rows in the table are allowed if the request is from an authenticated user. Ability to read all rows may or may not require authentication. To implement one of these
 options modify view.py:
 
 - find `<table>ViewSet`
@@ -92,15 +92,15 @@ The following API endpoints retrieve users:
 
     - /user end point:
         - Global admins can read, update, and create fields specified in
-            [cru.py](../../app/core/cru.py).  Search for
+            [cru.py](../../app/core/cru.py). Search for
             `_user_permissions[admin_global]`).
 
         - Project admins can read and update fields specified in
             [cru.py](../../app/core/cru.py) for other project leads.\
             Search for for `_user_permissions[admin_project]` in [cru.py](../../app/core/cru.py)
 
         - Practice area leads can read and update fields specified in
-            [cru.py](../../app/core/cru.py) for fellow team members.  If
+            [cru.py](../../app/core/cru.py) for fellow team members. If
             the team member is in the same practice area,\
             Search for for `_user_permissions[practice_lead_project]` in [cru.py](../../app/core/cru.py)
 
@@ -118,7 +118,7 @@ The following API endpoints retrieve users:
 
 #### /me endpoint functionality
 
-Used for reading and updating information about the user that is logged in.  User permission assignments do not apply.
+Used for reading and updating information about the user that is logged in. User permission assignments do not apply.
 
 - Row Level Security: Logged in user can always read and update their own information.
 - Field Level Security: For read and update permissions, see `_cru_permissions[profile_value]` in [cru.py](../../app/core/cru.py).