small nits for bypass pr

backend/src/ee/services/secret-approval-request/secret-approval-request-service.ts

@@ -515,7 +515,7 @@ export const secretApprovalRequestServiceFactory = ({
 
       await smtpService.sendMail({
         recipients: approverUsers.filter((approver) => approver.email).map((approver) => approver.email!),
-        subjectLine: "Secret Request Bypassed",
+        subjectLine: "Infisical Secret Change Policy Bypassed",
 
         substitutions: {
           projectName: project.name,

backend/src/services/smtp/templates/accessSecretRequestBypassed.handlebars

@@ -1,35 +1,28 @@
-
 <html>
-
   <head>
     <meta charset="utf-8" />
     <meta http-equiv="x-ua-compatible" content="ie=edge" />
-    <title>Secret Approval Request Bypassed</title>
+    <title>Secret Approval Request Policy Bypassed</title>
   </head>
 
   <body>
-    <h2>Infisical</h2>
+    <h1>Infisical</h1>
-    <h2>A secret approval request has been bypassed</h2>
+    <h2>Secret Approval Request Bypassed</h2>
-    <p>A secret approval request has been merged without approval in project "{{projectName}}".</p>
+    <p>A secret approval request has been bypassed in the project "{{projectName}}".</p>
 
     <p>
-      {{requesterFullName}}
+      {{requesterFullName}} ({{requesterEmail}}) has merged
-      ({{requesterEmail}}) has merged
+      a secret to environment {{environment}} at secret path {{secretPath}}
-      a secret to
+      without obtaining the required approvals.
-      {{secretPath}}
-      in the
-      {{environment}}
-      environment.
     </p>
     <p>
-      The following reason was provided:
+      The following reason was provided for bypassing the policy:
       <em>{{bypassReason}}</em>
     </p>
 
     <p>
-      Go to the request panel
+      To review this action, please visit the request panel
       <a href="{{approvalUrl}}">here</a>.
     </p>
   </body>
-
 </html>

docs/documentation/platform/access-controls/access-requests.mdx

@@ -14,12 +14,14 @@ This functionality works in the following way:
 ![Access Request Create](/images/platform/access-controls/request-access.png)
 ![Access Request Dashboard](/images/platform/access-controls/access-requests-pending.png)
 
-3. If the access request matches woth a policy that has a **Soft** enforcement level, the requester could bypass the policy and get access to the resource without approval.
+4. An eligible approver can approve or reject the access request.
+{/* ![Access Request Review](/images/platform/access-controls/review-access-request.png) */}
 ![Access Request Bypass](/images/platform/access-controls/access-request-bypass.png)
 
-4. An eligible approver can approve or reject the access request. 
+<Info>
-![Access Request Review](/images/platform/access-controls/review-access-request.png)
+ If the access request matches with a policy that has a **Soft** enforcement level, the requester may bypass the policy and get access to the resource without full approval.
+</Info>
 
-4. As soon as the request is approved, developer is able to access the sought resources. 
+5. As soon as the request is approved, developer is able to access the sought resources. 
 ![Access Request Dashboard](/images/platform/access-controls/access-requests-completed.png)
 

docs/documentation/platform/pr-workflows.mdx

@@ -22,15 +22,13 @@ First, you would need to create a set of policies for a certain environment. In
 
 ![create secret update policy](../../images/platform/pr-workflows/secret-update-policy.png)
 
-### Defining enforcement level
+### Policy enforcement levels
 
-The enforcement level determines how strict the policy is. A **Hard** enforcement level means that any change that matches the policy will need approval prior merging. A **Soft** enforcement level means that a change requests that matches the policy could be bypassed if the requester provides a reason for the bypass. If a change request is bypassed, the approvers will be notified via email.
+The enforcement level determines how strict the policy is. A **Hard** enforcement level means that any change that matches the policy will need full approval prior merging. A **Soft** enforcement level allows for break glass functionality on the request. If a change request is bypassed, the approvers will be notified via email.
-
-Take into account that a **Soft** enforcement level is more flexible and allows for more flexibility in the approval process but it's more prone to human error.
 
 ### Example of creating a change policy
 
-When creating a policy, you can choce the type of policy you want to create. In this case, we will be creating a `Change Policy`. Other types of policies include `Access Policy` that creates policies for **[Access Requests](/documentation/platform/access-controls/access-requests)**.
+When creating a policy, you can choose the type of policy you want to create. In this case, we will be creating a `Change Policy`. Other types of policies include `Access Policy` that creates policies for **[Access Requests](/documentation/platform/access-controls/access-requests)**.
 
 ![create panel secret update policy](../../images/platform/pr-workflows/create-change-policy.png)
 
@@ -40,6 +38,6 @@ When a user submits a change to an enviropnment that is under a particular polic
 
 ![secret update change requests](../../images/platform/pr-workflows/secret-update-request.png)
 
-An approver is notified by email and/or Slack as soon as the request is initiated. In the Infisical Dashboard, they will be able to `approve` and `merge` (or `deny`) a request for a change in a particular environment. After that, depending on the workflows setup, the change will be automatically propagated to the right applications (e.g., using [Infisical Kubernetes Operator](https://infisical.com/docs/integrations/platforms/kubernetes)).
+Approvers are notified by email and/or Slack as soon as the request is initiated. In the Infisical Dashboard, they will be able to `approve` and `merge` (or `deny`) a request for a change in a particular environment. After that, depending on the workflows setup, the change will be automatically propagated to the right applications (e.g., using [Infisical Kubernetes Operator](https://infisical.com/docs/integrations/platforms/kubernetes)).
 
 ![secrets update pull request](../../images/platform/pr-workflows/secret-update-pr.png)

frontend/src/views/SecretApprovalPage/components/SecretApprovalRequest/components/SecretApprovalRequestAction.tsx

@@ -127,7 +127,7 @@ export const SecretApprovalRequestAction = ({
                 </Checkbox>
                 {byPassApproval && (
                   <FormControl
-                    label="Reason for Bypass"
+                    label="Reason for bypass"
                     className="mt-2"
                     isRequired
                     tooltipText="Enter a reason for bypassing the secret change policy"