Add guidance and a rule for the word 'disallow'

Also fix instances of 'disallow' in the documentation.

doc/.vale/gitlab/Substitutions.yml

@@ -13,6 +13,7 @@ ignorecase: true
 swap:
   codequality: code quality
   Customer [Pp]ortal: Customers Portal
+  disallow: prevent
   frontmatter: front matter
   GitLabber: GitLab team member
   GitLabbers: GitLab team members

doc/administration/feature_flags.md

@@ -26,7 +26,7 @@ Features behind flags can be gradually rolled out, typically:
 1. The feature becomes enabled by default.
 1. The feature flag is removed.
 
-These features can be enabled and disabled to allow or disallow users to use
+These features can be enabled and disabled to allow or prevent users from using
 them. It can be done by GitLab administrators with access to GitLab Rails
 console.
 

doc/api/merge_request_approvals.md

@@ -58,9 +58,9 @@ POST /projects/:id/approvals
 | `id`                                             | integer or string | yes      | The ID or [URL-encoded path of a project](index.md#namespaced-path-encoding)  |
 | `approvals_before_merge`                         | integer | no       | How many approvals are required before an MR can be merged. Deprecated in 12.0 in favor of Approval Rules API. |
 | `reset_approvals_on_push`                        | boolean | no       | Reset approvals on a new push                                                                       |
-| `disable_overriding_approvers_per_merge_request` | boolean | no       | Allow/Disallow overriding approvers per MR                                                          |
-| `merge_requests_author_approval`                 | boolean | no       | Allow/Disallow authors from self approving merge requests; `true` means authors can self approve |
-| `merge_requests_disable_committers_approval`     | boolean | no       | Allow/Disallow committers from self approving merge requests                                        |
+| `disable_overriding_approvers_per_merge_request` | boolean | no       | Allow or prevent overriding approvers per MR                                                          |
+| `merge_requests_author_approval`                 | boolean | no       | Allow or prevent authors from self approving merge requests; `true` means authors can self approve |
+| `merge_requests_disable_committers_approval`     | boolean | no       | Allow or prevent committers from self approving merge requests                                        |
 | `require_password_to_approve`                    | boolean | no       | Require approver to enter a password to authenticate before adding the approval         |
 
 ```json

doc/development/documentation/styleguide/word_list.md

@@ -252,6 +252,11 @@ Do not use **Developer permissions**. A user who is assigned the Developer role
 See [the Microsoft style guide](https://docs.microsoft.com/en-us/style-guide/a-z-word-list-term-collections/d/disable-disabled) for guidance on **disable**.
 Use **inactive** or **off** instead. ([Vale](../testing.md#vale) rule: [`InclusionAbleism.yml`](https://gitlab.com/gitlab-org/gitlab/-/blob/master/doc/.vale/gitlab/InclusionAbleism.yml))
 
+
+## disallow
+
+Use **prevent** instead of **disallow**. ([Vale](../testing.md#vale) rule: [`Substitutions.yml`](https://gitlab.com/gitlab-org/gitlab/-/blob/master/doc/.vale/gitlab/Substitutions.yml))
+
 ## dropdown list
 
 Use **dropdown list** to refer to the UI element. Do not use **dropdown** without **list** after it.

doc/development/insert_into_tables_in_batches.md

@@ -122,7 +122,7 @@ Large parts of ActiveRecord's persistence API are built around the notion of cal
 of these callbacks fire in response to model life cycle events such as `save` or `create`.
 These callbacks cannot be used with bulk insertions, since they are meant to be called for
 every instance that is saved or created. Since these events do not fire when
-records are inserted in bulk, we currently disallow their use.
+records are inserted in bulk, we currently prevent their use.
 
 The specifics around which callbacks are explicitly allowed are defined in
 [`BulkInsertSafe`](https://gitlab.com/gitlab-org/gitlab/-/blob/master/app/models/concerns/bulk_insert_safe.rb).

doc/development/kubernetes.md

@@ -136,7 +136,7 @@ Mitigation strategies include:
 
 1. Not allowing redirects to attacker controller resources:
    [`Kubeclient::KubeClient`](https://gitlab.com/gitlab-org/gitlab/-/blob/master/lib/gitlab/kubernetes/kube_client.rb#)
-   can be configured to disallow any redirects by passing in
+   can be configured to prevent any redirects by passing in
    `http_max_redirects: 0` as an option.
 1. Not exposing error messages: by doing so, we
    prevent attackers from triggering errors to expose results from

doc/development/snowplow/implementation.md

@@ -520,7 +520,7 @@ To install and run Snowplow Micro, complete these steps to modify the
 ### Troubleshoot
 
 To control content security policy warnings when using an external host, modify `config/gitlab.yml`
-to allow or disallow them. To allow them, add the relevant host for `connect_src`. For example, for
+to allow or prevent them. To allow them, add the relevant host for `connect_src`. For example, for
 `https://snowplow.trx.gitlab.net`:
 
 ```yaml

doc/security/two_factor_authentication.md

@@ -74,7 +74,7 @@ The following are important notes about 2FA:
   2FA enabled, 2FA is **not** required for those individually added members.
 - If there are multiple 2FA requirements (for example, group + all users, or multiple
   groups) the shortest grace period is used.
-- It is possible to disallow subgroups from setting up their own 2FA requirements:
+- It is possible to prevent subgroups from setting up their own 2FA requirements:
   1. Go to the top-level group's **Settings > General**.
   1. Expand the **Permissions and group features** section.
   1. Uncheck the **Allow subgroups to set up their own two-factor authentication rule** field.

doc/user/group/saml_sso/group_managed_accounts.md

@@ -65,7 +65,7 @@ This restriction also applies to projects forked from or to those groups.
 
 > [Introduced](https://gitlab.com/gitlab-org/gitlab/-/issues/34648) in GitLab 12.9.
 
-Groups with group-managed accounts can disallow forking of projects to destinations outside the group.
+Groups with group-managed accounts can prevent forking of projects to destinations outside the group.
 To do so, enable the "Prohibit outer forks" option in **Settings > SAML SSO**.
 When enabled **at the parent group level**, projects within the group can be forked
 only to other destinations within the group (including its subgroups).