some more polish on various pages

Author: rsill-neo4j

modules/ROOT/pages/security/authorization.adoc

@@ -66,6 +66,9 @@ type Post @authorization(filter: [
 }
 ----
 
+[NOTE]
+If there is no `operations` argument with a list of operations, the GraphQL Library treats the authorization configuration as if the full list of operations had been provided.
+
 
 === Validating
 
@@ -115,6 +118,9 @@ type Post @authorization(validate: [
 }
 ----
 
+[NOTE]
+If there is no `operations` argument with a list of operations, the GraphQL Library treats the authorization configuration as if the full list of operations had been provided.
+
 
 == Authorization without authentication
 

modules/ROOT/pages/security/impersonation-and-user-switching.adoc

@@ -10,7 +10,7 @@ Impersonation still authenticates with the database as the original configured u
 When impersonating a user, the query is run within the complete security context of the impersonated user and not the authenticated user (home database, permissions etc).
 
 Consider the following an example of how to impersonate a different user per request.
-Here the user to impersonate is taken from a HTTP header `User`:
+Here the user to impersonate is taken from an HTTP header `User`:
 
 [.tabbed-example]
 ====

modules/ROOT/pages/security/operations.adoc

@@ -2,9 +2,9 @@
 //:page-aliases: /authentication-and-authorization/reference/operations.adoc, /security/reference/operations.adoc
 :description: This page describes how to set up authorization operations in the Neo4j GraphQL Library.
 
-This reference runs through a number of worked GraphQL queries and how each location in each query triggers the evaluation of different authentication/authorization rules.
+This page showcases a number of GraphQL queries and how you can trigger the evaluation of different authentication and authorization rules.
 
-Each relevant location has a comment such as `CREATE ON OBJECT Movie`, which means an authentication directive such as the following would be evaluated:
+Each relevant line has a comment such as `CREATE ON OBJECT Movie`, which means an authentication directive like the following is be evaluated:
 
 [source, graphql, indent=0]
 ----
@@ -14,15 +14,16 @@ type Movie @authentication(operations: [CREATE]) {
 }
 ----
 
-This also applies if the directive had no arguments, because `operations` defaults to _all_ operations.
+[NOTE]
+This also applies if the directive has no arguments because `operations` defaults to _all_ operations.
 
 The following examples apply to the `@authentication` directive, and also any rules within an `@authorization` directive.
 
 == Examples
 
 === Query
 
-For a simple query, rules with `READ` in the operations will be evaluated for any type being read:
+For a simple query, rules with `READ` in the operations are evaluated for any type being read:
 
 [source, graphql, indent=0]
 ----
@@ -38,7 +39,7 @@ query {
 
 === Mutation
 
-For create Mutations, `CREATE` rules on the object will be evaluated for each node created, as well as field definition rules:
+For `create` mutations, `CREATE` rules on the object are evaluated for each node created, as well as field definition rules:
 
 [source, graphql, indent=0]
 ----
@@ -55,7 +56,7 @@ mutation {
 }
 ----
 
-For single delete Mutations, rules with `DELETE` on the object will be evaluated:
+For single `delete` mutations, rules with `DELETE` on the object are evaluated:
 
 [source, graphql, indent=0]
 ----
@@ -66,7 +67,7 @@ mutation {
 }
 ----
 
-For delete Mutations with nested delete operations, rules with operation `DELETE` will be evaluated:
+For `delete` mutations with nested delete operations, rules with operation `DELETE` are evaluated:
 
 [source, graphql, indent=0]
 ----
@@ -80,7 +81,7 @@ mutation {
 }
 ----
 
-For a complex update Mutation with many effects, a variety of rules will be evaluated, as well as `READ` rules for the selection set:
+For a complex `update` mutation with many effects, a variety of rules is evaluated, as well as `READ` rules for the selection set:
 
 [source, graphql, indent=0]
 ----
@@ -104,7 +105,7 @@ mutation {
 
 === Subscription
 
-For a simple Subscription to creation events, both `SUBSCRIBE` and `READ` operations trigger rules:
+For a simple subscription to creation events, both `SUBSCRIBE` and `READ` operations trigger rules:
 
 [source, graphql, indent=0]
 ----
@@ -117,7 +118,7 @@ subscription {
 }
 ----
 
-For a more complex Subscription to relationship events, both `SUBSCRIBE` is an operation, as well as `READ` to all relevant types:
+For a more complex subscription to relationship events, `SUBSCRIBE` is an operation as well as `READ` to all relevant types:
 
 [source, graphql, indent=0]
 ----