fix: Permission docs #433
Open
fix: Permission docs #433
+416
−0
Conversation
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
|
The latest updates on your projects. Learn more about Vercel for GitHub.
|
✅ Deploy Preview for canarychecker canceled.
|
❌ Deploy Preview for flanksource-docs failed. Why did it fail? →
|
adityathebe
force-pushed
the
fix-permission-docs
branch
from
dec2461 to
beddf82
Compare
adityathebe
force-pushed
the
fix-permission-docs
branch
from
beddf82 to
8240db4
Compare
WalkthroughAdds comprehensive documentation for Mission Control's permissions scoping system, including a core concept guide for Scopes, an index page for examples, and eleven example pages covering selector patterns, resource targeting strategies, and multi-tenancy isolation patterns. Changes
🚥 Pre-merge checks | ✅ 2 | ❌ 1❌ Failed checks (1 inconclusive)
✅ Passed checks (2 passed)
✏️ Tip: You can configure your own custom pre-merge checks in the settings. ✨ Finishing touches🧪 Generate unit tests (beta)
Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out. Comment |
![coderabbitai[bot]](https://avatars.githubusercontent.com/in/347564?s=60&v=4){kind=small}
There was a problem hiding this comment.
Actionable comments posted: 15
🤖 Fix all issues with AI agents
In `@mission-control/docs/guide/permissions/concepts/scope.md`:
- Line 48: Replace the passive sentence "Scopes are designed to work seamlessly
with Attribute-Based Access Control (ABAC)" with an active-voice construction;
update the line that references Scopes and ABAC (the sentence containing "Scopes
are designed to work seamlessly") to an active form such as "We designed Scopes
to work seamlessly with Attribute‑Based Access Control (ABAC)" or "Scopes work
seamlessly with Attribute‑Based Access Control (ABAC)" so the document uses
active voice consistently.
- Line 73: Line reads "If the resource matches any target in any of the user's
Scopes, access is granted" and uses passive voice; change it to active voice by
replacing "access is granted" with an active subject, e.g., "the system grants
access" (resulting sentence: "If the resource matches any target in any of the
user's Scopes, the system grants access (subject to action restrictions)").
Update that sentence in scope.md accordingly.
- Line 14: Rewrite the passive sentence describing how multiple targets combine
into an active-voice sentence: replace "Multiple targets within a Scope are
combined with OR logic" with an active construction such as "When a Scope
contains multiple targets, the system combines them with OR logic, so a resource
matches the Scope if it matches any target"; update the line describing
Scope/targets to use this active phrasing and keep the rest of the sentence
about a resource matching any target intact.
- Around line 50-64: Replace the inline YAML example in scope.md (the Permission
example for dev-team-access) with a code block using the file= directive
pointing to a fixture and create that fixture; specifically remove the inline
Permission YAML and add a ```yaml title="dev-team-access.yaml" file=...```
block, then add a fixture named dev-team-access.yaml in the mission-control
submodule fixtures/permissions containing the original YAML (kind: Permission,
metadata.name: dev-team-access, subjects: Group dev-team, scopes:
[prod-agent-configs], actions: [read, update]) so the docs import the example
instead of embedding it inline.
In `@mission-control/docs/guide/permissions/examples/combining-selectors.md`:
- Around line 7-20: Replace the inline YAML with a code block that uses the
file= import directive pointing to a fixture named prod-west-configs.yaml and
create that fixture in the mission-control module fixtures (scopes) containing
the same Scope resource (kind: Scope, metadata.name: prod-west-configs,
namespace: default, spec.description: "Production configs in us-west region from
specific agent", spec.targets: - config: agent: agent-west-1, namespace:
production, tagSelector: "region=us-west"); update the doc code block to use
```yaml title="prod-west-configs.yaml" file=<point to that mission-control
fixture>``` so the example is imported rather than inlined.
In
`@mission-control/docs/guide/permissions/examples/global-resource-selectors.md`:
- Around line 7-18: Replace the inline YAML in global-resource-selectors.md with
a file-import code block that references the fixture file named
namespace-restricted.yaml (e.g. ```yaml title="namespace-restricted.yaml"
file=...```) and create that fixture in the mission-control module's
fixtures/scopes directory; the new fixture must contain the original Scope
manifest (kind: Scope, metadata.name: namespace-restricted, metadata.namespace:
default, spec.description: "All resources in specific namespace", spec.targets
-> global.namespace: restricted-zone) so the documentation imports the example
instead of inlining it.
- Around line 40-59: Replace the two inline YAML examples with imported
fixtures: create fixture files named global-example.yaml and
individual-targets-example.yaml inside the mission-control fixtures scopes, then
replace the inline code blocks in global-resource-selectors.md with fenced code
blocks using the file= directive to reference those two fixture filenames (keep
the title attributes as shown). Locate the existing inline blocks in
global-resource-selectors.md (the "global" example and the "Using individual
targets" example) and swap them for the file-import style code fences that point
to the new mission-control fixture files.
In `@mission-control/docs/guide/permissions/examples/multi-tenancy-patterns.md`:
- Line 68: The sentence "Each customer's resources are tagged appropriately, and
Scopes ensure customer data isolation." uses passive voice; replace it with an
active-voice construction such as "We tag each customer's resources and use
Scopes to ensure customer data isolation." Locate the sentence (the line
containing "Each customer's resources are tagged appropriately") and update it
to the active phrasing so the subject performs the actions ("We tag..." / "The
system tags...") and retain the mention of Scopes for isolation.
- Around line 34-47: Replace the inline YAML example for the Scope named
"platform-team-resources" with a code block that uses the file= directive (and
title "platform-team-resources.yaml") and create a fixture file in the
mission-control module's fixtures/scopes named platform-team-resources.yaml
containing the original YAML (apiVersion: mission-control.flanksource.com/v1,
kind: Scope, metadata.name: platform-team-resources, metadata.namespace:
default, spec.description, spec.targets with config/component namespace:
platform-team). Update the code block in multi-tenancy-patterns.md to reference
that fixture file instead of embedding the YAML.
- Around line 11-26: Replace the inline YAML block in multi-tenancy-patterns.md
with a code block using the file= directive that references a fixture (title
"production-resources.yaml"); then add a fixture file named
production-resources.yaml under the mission-control module's fixtures/scopes
directory containing the original Scope manifest (kind: Scope, metadata.name:
production-resources, metadata.namespace: default, spec.description: All
production resources, spec.targets with config/component/playbook tagSelector
"env=production") so the document imports the example instead of embedding it
inline.
- Around line 74-86: Replace the inline YAML in multi-tenancy-patterns.md (the
Scope example named team-a-prod-west) with a YAML code block using the file=
directive (title "team-a-prod-west.yaml" and file pointing to the fixture), and
create the corresponding fixture file team-a-prod-west.yaml under the
mission-control fixtures scopes directory containing the original Scope YAML
(apiVersion: mission-control.flanksource.com/v1, kind: Scope, metadata
name/team-a-prod-west namespace/default, spec description and targets with
config namespace/tagSelector) so the docs import the example instead of
embedding it inline.
- Around line 55-66: Replace the inline YAML block in
mission-control/docs/guide/permissions/examples/multi-tenancy-patterns.md with a
code block that uses the file= directive pointing to a fixture named
customer-acme-resources.yaml, and add that fixture to the mission-control
fixtures (scopes) submodule; the fixture should contain the original Scope
resource with metadata.name customer-acme-resources, metadata.namespace default
and the spec (description: "All resources for ACME Corp" and targets -> config
-> tagSelector: "customer=acme"). Ensure the code block uses
title="customer-acme-resources.yaml" and the file= directive referencing the new
fixture.
In `@mission-control/docs/guide/permissions/examples/multiple-resource-types.md`:
- Around line 7-22: Replace the inline YAML example for the Scope resource named
"monitoring-stack" with a code block using the file= directive (e.g., ```yaml
title="monitoring-stack.yaml" file=...```), and create the referenced fixture
file containing the original YAML content (Scope, metadata.name
monitoring-stack, namespace default, spec.description and targets for
config/component/canary with tagSelector "app=prometheus") in the
mission-control module's fixtures for scopes so the documentation imports the
example instead of embedding it inline.
In `@mission-control/docs/guide/permissions/examples/targeting-by-tags.md`:
- Line 5: Rewrite the passive sentence "Tag-based scoping is the most flexible
approach as it allows resources to be added or removed from the scope by simply
updating their tags." to active voice; for example, change it to "Tag-based
scoping is the most flexible approach because you can add or remove resources
from the scope by simply updating their tags." Update that sentence in the
document so the paragraph uses active voice throughout.
In `@mission-control/docs/guide/permissions/examples/targeting-with-wildcards.md`:
- Line 14: Rewrite the passive sentence to active voice: change "Prefix and
suffix wildcards (e.g., `nginx-*` or `*-prod`) are **NOT** supported." to an
active construction referencing the product (e.g., "Mission Control does **NOT**
support prefix and suffix wildcards (e.g., `nginx-*` or `*-prod`)."), leaving
the earlier clause about the `name` field and the special wildcard directive `*`
unchanged.
🧹 Nitpick comments (1)
mission-control/docs/guide/permissions/examples/multi-tenancy-patterns.md (1)
5-5: Consider rewording for stronger active voice.While not strictly passive, "Scopes are fundamental" could be rewritten more actively to align with Google Style Guide recommendations.
✍️ Suggested rewrite
-Scopes are fundamental to implementing multi-tenancy in Mission Control. Here are common patterns for partitioning resources across different tenants, teams, or organizational units. +Scopes provide the foundation for implementing multi-tenancy in Mission Control. The following sections describe common patterns for partitioning resources across different tenants, teams, or organizational units.
|
|
||
| ### Scope Structure | ||
|
|
||
| A Scope consists of one or more **targets**, where each target defines a collection of resources. Multiple targets within a Scope are combined with **OR logic**, meaning a resource matches the Scope if it matches any of the targets. |
There was a problem hiding this comment.
Replace passive voice with active voice.
Line 14 uses passive voice: "Multiple targets within a Scope are combined with OR logic". As per coding guidelines: "Use active voice; never use passive voice."
✍️ Suggested rewrite
-A Scope consists of one or more **targets**, where each target defines a collection of resources. Multiple targets within a Scope are combined with **OR logic**, meaning a resource matches the Scope if it matches any of the targets.
+A Scope consists of one or more **targets**, where each target defines a collection of resources. Mission Control combines multiple targets within a Scope using **OR logic**, meaning a resource matches the Scope if it matches any of the targets.📝 Committable suggestion
‼️ IMPORTANT
Carefully review the code before committing. Ensure that it accurately replaces the highlighted code, contains no missing lines, and has no issues with indentation. Thoroughly test & benchmark the code to ensure it meets the requirements.
Suggested change
| A Scope consists of one or more **targets**, where each target defines a collection of resources. Multiple targets within a Scope are combined with **OR logic**, meaning a resource matches the Scope if it matches any of the targets. | |
| A Scope consists of one or more **targets**, where each target defines a collection of resources. Mission Control combines multiple targets within a Scope using **OR logic**, meaning a resource matches the Scope if it matches any of the targets. |
🤖 Prompt for AI Agents
In `@mission-control/docs/guide/permissions/concepts/scope.md` at line 14, Rewrite
the passive sentence describing how multiple targets combine into an
active-voice sentence: replace "Multiple targets within a Scope are combined
with OR logic" with an active construction such as "When a Scope contains
multiple targets, the system combines them with OR logic, so a resource matches
the Scope if it matches any target"; update the line describing Scope/targets to
use this active phrasing and keep the rest of the sentence about a resource
matching any target intact.
|
|
||
| ## Integration with ABAC | ||
|
|
||
| Scopes are designed to work seamlessly with [Attribute-Based Access Control (ABAC)](abac.md). When using ABAC, you reference Scopes in your permission policies to define the resource boundaries for access control. |
There was a problem hiding this comment.
Replace passive voice with active voice.
Line 48 uses passive voice: "Scopes are designed to work seamlessly". As per coding guidelines: "Use active voice; never use passive voice."
✍️ Suggested rewrite
-Scopes are designed to work seamlessly with [Attribute-Based Access Control (ABAC)](abac.md). When using ABAC, you reference Scopes in your permission policies to define the resource boundaries for access control.
+Scopes work seamlessly with [Attribute-Based Access Control (ABAC)](abac.md). When using ABAC, you reference Scopes in your permission policies to define the resource boundaries for access control.📝 Committable suggestion
‼️ IMPORTANT
Carefully review the code before committing. Ensure that it accurately replaces the highlighted code, contains no missing lines, and has no issues with indentation. Thoroughly test & benchmark the code to ensure it meets the requirements.
Suggested change
| Scopes are designed to work seamlessly with [Attribute-Based Access Control (ABAC)](abac.md). When using ABAC, you reference Scopes in your permission policies to define the resource boundaries for access control. | |
| Scopes work seamlessly with [Attribute-Based Access Control (ABAC)](abac.md). When using ABAC, you reference Scopes in your permission policies to define the resource boundaries for access control. |
🤖 Prompt for AI Agents
In `@mission-control/docs/guide/permissions/concepts/scope.md` at line 48, Replace
the passive sentence "Scopes are designed to work seamlessly with
Attribute-Based Access Control (ABAC)" with an active-voice construction; update
the line that references Scopes and ABAC (the sentence containing "Scopes are
designed to work seamlessly") to an active form such as "We designed Scopes to
work seamlessly with Attribute‑Based Access Control (ABAC)" or "Scopes work
seamlessly with Attribute‑Based Access Control (ABAC)" so the document uses
active voice consistently.
Comment on lines
+50
to
+64
| ```yaml | ||
| apiVersion: mission-control.flanksource.com/v1 | ||
| kind: Permission | ||
| metadata: | ||
| name: dev-team-access | ||
| spec: | ||
| subjects: | ||
| - kind: Group | ||
| name: dev-team | ||
| scopes: | ||
| - prod-agent-configs # Reference to Scope | ||
| actions: | ||
| - read | ||
| - update | ||
| ``` |
There was a problem hiding this comment.
Replace inline YAML with file= directive import.
The YAML example is written directly in the documentation, which violates the coding guidelines. As per coding guidelines: "Never write YAML examples directly; import examples from submodules (mission-control, duty, config-db, canary-checker) using code blocks with file= directive."
📝 Required change
-```yaml
-apiVersion: mission-control.flanksource.com/v1
-kind: Permission
-metadata:
- name: dev-team-access
-spec:
- subjects:
- - kind: Group
- name: dev-team
- scopes:
- - prod-agent-configs # Reference to Scope
- actions:
- - read
- - update
-```
+```yaml title="dev-team-access.yaml" file=<rootDir>/modules/mission-control/fixtures/permissions/dev-team-access.yaml
+
+```Create the corresponding fixture file in the mission-control submodule.
🤖 Prompt for AI Agents
In `@mission-control/docs/guide/permissions/concepts/scope.md` around lines 50 -
64, Replace the inline YAML example in scope.md (the Permission example for
dev-team-access) with a code block using the file= directive pointing to a
fixture and create that fixture; specifically remove the inline Permission YAML
and add a ```yaml title="dev-team-access.yaml" file=...``` block, then add a
fixture named dev-team-access.yaml in the mission-control submodule
fixtures/permissions containing the original YAML (kind: Permission,
metadata.name: dev-team-access, subjects: Group dev-team, scopes:
[prod-agent-configs], actions: [read, update]) so the docs import the example
instead of embedding it inline.
| When a user attempts to access a resource: | ||
|
|
||
| 1. The system evaluates all Scopes referenced in the user's permissions | ||
| 2. If the resource matches any target in any of the user's Scopes, access is granted (subject to action restrictions) |
There was a problem hiding this comment.
Replace passive voice with active voice.
Line 73 uses passive voice: "access is granted". As per coding guidelines: "Use active voice; never use passive voice."
✍️ Suggested rewrite
1. The system evaluates all Scopes referenced in the user's permissions
-2. If the resource matches any target in any of the user's Scopes, access is granted (subject to action restrictions)
+2. If the resource matches any target in any of the user's Scopes, the system grants access (subject to action restrictions)
3. Multiple Scopes are combined with OR logic📝 Committable suggestion
‼️ IMPORTANT
Carefully review the code before committing. Ensure that it accurately replaces the highlighted code, contains no missing lines, and has no issues with indentation. Thoroughly test & benchmark the code to ensure it meets the requirements.
Suggested change
| 2. If the resource matches any target in any of the user's Scopes, access is granted (subject to action restrictions) | |
| 1. The system evaluates all Scopes referenced in the user's permissions | |
| 2. If the resource matches any target in any of the user's Scopes, the system grants access (subject to action restrictions) | |
| 3. Multiple Scopes are combined with OR logic |
🤖 Prompt for AI Agents
In `@mission-control/docs/guide/permissions/concepts/scope.md` at line 73, Line
reads "If the resource matches any target in any of the user's Scopes, access is
granted" and uses passive voice; change it to active voice by replacing "access
is granted" with an active subject, e.g., "the system grants access" (resulting
sentence: "If the resource matches any target in any of the user's Scopes, the
system grants access (subject to action restrictions)"). Update that sentence in
scope.md accordingly.
Comment on lines
+7
to
+20
| ```yaml | ||
| apiVersion: mission-control.flanksource.com/v1 | ||
| kind: Scope | ||
| metadata: | ||
| name: prod-west-configs | ||
| namespace: default | ||
| spec: | ||
| description: Production configs in us-west region from specific agent | ||
| targets: | ||
| - config: | ||
| agent: agent-west-1 | ||
| namespace: production | ||
| tagSelector: "region=us-west" | ||
| ``` |
There was a problem hiding this comment.
Replace inline YAML with file= directive import.
The YAML example is written directly in the documentation, which violates the coding guidelines. All YAML examples must be imported from submodules using the file= directive. As per coding guidelines: "Never write YAML examples directly; import examples from submodules (mission-control, duty, config-db, canary-checker) using code blocks with file= directive."
📝 Required change
-```yaml
-apiVersion: mission-control.flanksource.com/v1
-kind: Scope
-metadata:
- name: prod-west-configs
- namespace: default
-spec:
- description: Production configs in us-west region from specific agent
- targets:
- - config:
- agent: agent-west-1
- namespace: production
- tagSelector: "region=us-west"
-```
+```yaml title="prod-west-configs.yaml" file=<rootDir>/modules/mission-control/fixtures/scopes/prod-west-configs.yaml
+
+```You'll need to create the corresponding fixture file in the mission-control submodule.
🤖 Prompt for AI Agents
In `@mission-control/docs/guide/permissions/examples/combining-selectors.md`
around lines 7 - 20, Replace the inline YAML with a code block that uses the
file= import directive pointing to a fixture named prod-west-configs.yaml and
create that fixture in the mission-control module fixtures (scopes) containing
the same Scope resource (kind: Scope, metadata.name: prod-west-configs,
namespace: default, spec.description: "Production configs in us-west region from
specific agent", spec.targets: - config: agent: agent-west-1, namespace:
production, tagSelector: "region=us-west"); update the doc code block to use
```yaml title="prod-west-configs.yaml" file=<point to that mission-control
fixture>``` so the example is imported rather than inlined.
| tagSelector: "customer=acme" | ||
| ``` | ||
|
|
||
| Each customer's resources are tagged appropriately, and Scopes ensure customer data isolation. |
There was a problem hiding this comment.
Replace passive voice with active voice.
Line 68 uses passive voice: "Each customer's resources are tagged appropriately, and Scopes ensure customer data isolation." As per coding guidelines: "Use active voice; never use passive voice."
✍️ Suggested rewrite
-Each customer's resources are tagged appropriately, and Scopes ensure customer data isolation.
+Tag each customer's resources appropriately, and use Scopes to ensure customer data isolation.📝 Committable suggestion
‼️ IMPORTANT
Carefully review the code before committing. Ensure that it accurately replaces the highlighted code, contains no missing lines, and has no issues with indentation. Thoroughly test & benchmark the code to ensure it meets the requirements.
Suggested change
| Each customer's resources are tagged appropriately, and Scopes ensure customer data isolation. | |
| Tag each customer's resources appropriately, and use Scopes to ensure customer data isolation. |
🤖 Prompt for AI Agents
In `@mission-control/docs/guide/permissions/examples/multi-tenancy-patterns.md` at
line 68, The sentence "Each customer's resources are tagged appropriately, and
Scopes ensure customer data isolation." uses passive voice; replace it with an
active-voice construction such as "We tag each customer's resources and use
Scopes to ensure customer data isolation." Locate the sentence (the line
containing "Each customer's resources are tagged appropriately") and update it
to the active phrasing so the subject performs the actions ("We tag..." / "The
system tags...") and retain the mention of Scopes for isolation.
Comment on lines
+74
to
+86
| ```yaml | ||
| apiVersion: mission-control.flanksource.com/v1 | ||
| kind: Scope | ||
| metadata: | ||
| name: team-a-prod-west | ||
| namespace: default | ||
| spec: | ||
| description: Team A production resources in west region | ||
| targets: | ||
| - config: | ||
| namespace: team-a | ||
| tagSelector: "env=production,region=west" | ||
| ``` |
There was a problem hiding this comment.
Replace inline YAML with file= directive import.
The YAML example is written directly in the documentation, which violates the coding guidelines. As per coding guidelines: "Never write YAML examples directly; import examples from submodules (mission-control, duty, config-db, canary-checker) using code blocks with file= directive."
📝 Required change
-```yaml
-apiVersion: mission-control.flanksource.com/v1
-kind: Scope
-metadata:
- name: team-a-prod-west
- namespace: default
-spec:
- description: Team A production resources in west region
- targets:
- - config:
- namespace: team-a
- tagSelector: "env=production,region=west"
-```
+```yaml title="team-a-prod-west.yaml" file=<rootDir>/modules/mission-control/fixtures/scopes/team-a-prod-west.yaml
+
+```Create the corresponding fixture file in the mission-control submodule.
🤖 Prompt for AI Agents
In `@mission-control/docs/guide/permissions/examples/multi-tenancy-patterns.md`
around lines 74 - 86, Replace the inline YAML in multi-tenancy-patterns.md (the
Scope example named team-a-prod-west) with a YAML code block using the file=
directive (title "team-a-prod-west.yaml" and file pointing to the fixture), and
create the corresponding fixture file team-a-prod-west.yaml under the
mission-control fixtures scopes directory containing the original Scope YAML
(apiVersion: mission-control.flanksource.com/v1, kind: Scope, metadata
name/team-a-prod-west namespace/default, spec description and targets with
config namespace/tagSelector) so the docs import the example instead of
embedding it inline.
Comment on lines
+7
to
+22
| ```yaml | ||
| apiVersion: mission-control.flanksource.com/v1 | ||
| kind: Scope | ||
| metadata: | ||
| name: monitoring-stack | ||
| namespace: default | ||
| spec: | ||
| description: Complete monitoring stack resources | ||
| targets: | ||
| - config: | ||
| tagSelector: "app=prometheus" | ||
| - component: | ||
| tagSelector: "app=prometheus" | ||
| - canary: | ||
| tagSelector: "app=prometheus" | ||
| ``` |
There was a problem hiding this comment.
Replace inline YAML with file= directive import.
The YAML example is written directly in the documentation, which violates the coding guidelines. As per coding guidelines: "Never write YAML examples directly; import examples from submodules (mission-control, duty, config-db, canary-checker) using code blocks with file= directive."
📝 Required change
-```yaml
-apiVersion: mission-control.flanksource.com/v1
-kind: Scope
-metadata:
- name: monitoring-stack
- namespace: default
-spec:
- description: Complete monitoring stack resources
- targets:
- - config:
- tagSelector: "app=prometheus"
- - component:
- tagSelector: "app=prometheus"
- - canary:
- tagSelector: "app=prometheus"
-```
+```yaml title="monitoring-stack.yaml" file=<rootDir>/modules/mission-control/fixtures/scopes/monitoring-stack.yaml
+
+```Create the corresponding fixture file in the mission-control submodule.
🤖 Prompt for AI Agents
In `@mission-control/docs/guide/permissions/examples/multiple-resource-types.md`
around lines 7 - 22, Replace the inline YAML example for the Scope resource
named "monitoring-stack" with a code block using the file= directive (e.g.,
```yaml title="monitoring-stack.yaml" file=...```), and create the referenced
fixture file containing the original YAML content (Scope, metadata.name
monitoring-stack, namespace default, spec.description and targets for
config/component/canary with tagSelector "app=prometheus") in the
mission-control module's fixtures for scopes so the documentation imports the
example instead of embedding it inline.
| title: Targeting by Tags | ||
| --- | ||
|
|
||
| This example shows how to use tag selectors to dynamically scope resources based on their labels. Tag-based scoping is the most flexible approach as it allows resources to be added or removed from the scope by simply updating their tags. |
There was a problem hiding this comment.
Rewrite to use active voice.
The phrase "allows resources to be added or removed" uses passive voice. As per coding guidelines, documentation must use active voice only.
✍️ Suggested active voice alternatives
-This example shows how to use tag selectors to dynamically scope resources based on their labels. Tag-based scoping is the most flexible approach as it allows resources to be added or removed from the scope by simply updating their tags.
+This example shows how to use tag selectors to dynamically scope resources based on their labels. Tag-based scoping is the most flexible approach as updating tags automatically adds or removes resources from the scope.Alternative wording:
This example shows how to use tag selectors to dynamically scope resources based on their labels. Tag-based scoping is the most flexible approach as you can add or remove resources from the scope by simply updating their tags.As per coding guidelines: "Use active voice; never use passive voice"
📝 Committable suggestion
‼️ IMPORTANT
Carefully review the code before committing. Ensure that it accurately replaces the highlighted code, contains no missing lines, and has no issues with indentation. Thoroughly test & benchmark the code to ensure it meets the requirements.
Suggested change
| This example shows how to use tag selectors to dynamically scope resources based on their labels. Tag-based scoping is the most flexible approach as it allows resources to be added or removed from the scope by simply updating their tags. | |
| This example shows how to use tag selectors to dynamically scope resources based on their labels. Tag-based scoping is the most flexible approach as updating tags automatically adds or removes resources from the scope. |
🤖 Prompt for AI Agents
In `@mission-control/docs/guide/permissions/examples/targeting-by-tags.md` at line
5, Rewrite the passive sentence "Tag-based scoping is the most flexible approach
as it allows resources to be added or removed from the scope by simply updating
their tags." to active voice; for example, change it to "Tag-based scoping is
the most flexible approach because you can add or remove resources from the
scope by simply updating their tags." Update that sentence in the document so
the paragraph uses active voice throughout.
| Using `name: "*"` matches all components (topology items) in the system without any filtering. | ||
|
|
||
| :::info Wildcard Limitations | ||
| The `name` field only supports the special wildcard directive `*` which matches **any** resource. Prefix and suffix wildcards (e.g., `nginx-*` or `*-prod`) are **NOT** supported. |
There was a problem hiding this comment.
Rewrite to use active voice.
The phrase "are NOT supported" uses passive voice. As per coding guidelines, documentation must use active voice only.
✍️ Suggested active voice alternative
-The `name` field only supports the special wildcard directive `*` which matches **any** resource. Prefix and suffix wildcards (e.g., `nginx-*` or `*-prod`) are **NOT** supported.
+The `name` field only supports the special wildcard directive `*` which matches **any** resource. The system does **NOT** support prefix and suffix wildcards (e.g., `nginx-*` or `*-prod`).Alternative wording:
The `name` field only supports the special wildcard directive `*` which matches **any** resource. Mission Control does **NOT** support prefix and suffix wildcards (e.g., `nginx-*` or `*-prod`).As per coding guidelines: "Use active voice; never use passive voice"
📝 Committable suggestion
‼️ IMPORTANT
Carefully review the code before committing. Ensure that it accurately replaces the highlighted code, contains no missing lines, and has no issues with indentation. Thoroughly test & benchmark the code to ensure it meets the requirements.
Suggested change
| The `name` field only supports the special wildcard directive `*` which matches **any** resource. Prefix and suffix wildcards (e.g., `nginx-*` or `*-prod`) are **NOT** supported. | |
| The `name` field only supports the special wildcard directive `*` which matches **any** resource. The system does **NOT** support prefix and suffix wildcards (e.g., `nginx-*` or `*-prod`). |
🤖 Prompt for AI Agents
In `@mission-control/docs/guide/permissions/examples/targeting-with-wildcards.md`
at line 14, Rewrite the passive sentence to active voice: change "Prefix and
suffix wildcards (e.g., `nginx-*` or `*-prod`) are **NOT** supported." to an
active construction referencing the product (e.g., "Mission Control does **NOT**
support prefix and suffix wildcards (e.g., `nginx-*` or `*-prod`)."), leaving
the earlier clause about the `name` field and the special wildcard directive `*`
unchanged.
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Summary by CodeRabbit