Note: Doc team updates the current version of the documentation and the
two previous versions (n-2), but we address *only high-priority, or
customer-reported issues* for -2 releases in support.
Describe the changes in the doc and link to your dev story:

1. - [x] Mandatory: Add the required version to the Fix version/s field.

2. - [x] Mandatory: Choose the type of documentation change or review.

• [x] We need to update to an existing topic

• [ ] We need to add a new document to an existing section

• [ ] We need a whole new section; this is a function not
  documented before and doesn't belong in any current section

• [ ] We need an Operator Advisory review and approval

• [ ] We need a z-Stream (Errata) Advisory and Release note for
  MCE and/or ACM

3. - [x] Mandatory: Find the link to where the documentation update
should go and add it to the recommended changes. You can either use the
published doc or the staged repo for this step:

Note: As the feature and doc is understood, this recommendation may
change. If this is new documentation, link to the section where you think
it should be placed.

Customer Portal published version

https://docs.redhat.com/en/documentation/red_hat_advanced_cluster_management_for_kubernetes/2.13/html-single/governance/index#operator-policy-yaml-table

Doc staged repo within the ACM Workspace:
https://github.com/stolostron/rhacm-docs/blob/2.13_stage/governance/operator_pol_ctrl.adoc

4. - [ ] Mandatory for GA content:

• [ ] Add steps, the diff, known issue, and/or other important
  conceptual information in the following space:

• [ ] *Add Required access level *(example, *Cluster
  Administrator*) for the user to complete the task:

• [ ] Add verification at the end of the task, how does the user
  verify success (a command to run or a result to see?)

• [ ] Add link to dev story here:

5. - [x] Mandatory for bugs: What is the diff? Clearly define what the
problem is, what the change is, and link to the current documentation. Only
use this for a documentation bug.

As mentioned in two Slack threads, the OperatorPolicy table does not mention that a `config` field can be supplied: https://redhat-internal.slack.com/archives/CU4QXLPQB/p1744789541991159 , https://redhat-internal.slack.com/archives/CU4QXLPQB/p1744981110251209 . It should be added as a valid sub-field somehow.

Unfortunately, the `config` field is not documented (as far as I could see) in the OpenShift documentation. The best source of information on is https://github.com/operator-framework/operator-lifecycle-manager/blob/master/doc/design/subscription-config.md . If GitHub links aren't allowed, I think it would be understood by most users that need this (keeping in mind that this is a somewhat "advanced" feature that most operators don't need or necessarily document) if we just mentioned something like:

`config`: Specify any additional details that would be embedded in the Subscription, such as environment variables or resource limits.

In my opinion, the table entry is already too long to be very helpful, and would benefit from other changes. Perhaps something like:

Specify details for the operator subscription here. The following fields work the same as they would in a Subscription object: `channel`, `source`, `sourceNamespace`, and `config`. Use `name` here, instead of the `package` that would be used in a Subscription. The `namespace` for the operator can also be included.

The `name` field is the only required field - all others will be inferred from the catalog information available on the managed cluster.

Note: if you define a value for `installPlanApproval` here, the policy becomes non-compliant. Use `spec.upgradeApproval` in the OperatorPolicy instead.

It is especially worth noting in this Jira that the final note in that table entry is currently incorrect in the published doc.

In addition, the `spec.operatorGroup` table entry is unclear. It should also likely mention the possible sub-fields: `name`, `namespace`, and `targetNamespaces`. See https://developers.redhat.com/articles/2024/05/14/use-operatorpolicy-manage-kubernetes-native-applications#operatorpolicy_overview for an example OperatorPolicy that has those fields set.