NOISSUE - Remove MG related things in ATOM#11
Conversation
Signed-off-by: Arvindh <arvindh91@gmail.com>
![chatgpt-codex-connector[bot]](https://avatars.githubusercontent.com/in/1144995?s=60&v=4){kind=small}
There was a problem hiding this comment.
💡 Codex Review
Here are some automated review suggestions for this pull request.
Reviewed commit: ad8c77aa05
ℹ️ About Codex in GitHub
Your team has set up Codex to review pull requests in this repo. Reviews are triggered when you
- Open a pull request for review
- Mark a draft as ready
- Comment "@codex review".
If Codex has suggestions, it will comment; otherwise it will react with 👍.
Codex can also answer questions or update the PR. Try commenting "@codex address that feedback".
| ('entity', 'entity:service'), | ||
| ('entity', 'entity:workload'), | ||
| ('entity', 'entity:application'), | ||
| ('resource', 'resource:channel'), | ||
| ('resource', 'resource:rule'), | ||
| ('resource', 'resource:report'), | ||
| ('resource', 'resource:alarm'), | ||
| ('group', NULL) | ||
| ) AS applicability(object_kind, object_type) | ||
| WHERE actions.name IN ('read', 'write', 'delete') |
There was a problem hiding this comment.
Because startup runs sqlx::migrate::Migrator::run from src/main.rs, any database that has already applied migration version 1 will have the old checksum recorded in _sqlx_migrations; changing 001_initial.sql in place makes upgrades fail migration validation before the service starts. Put these seed-data removals in a new migrations/NNN_*.sql migration instead of rewriting the applied initial migration.
Useful? React with 👍 / 👎.
| ('entity', 'entity:service'), | ||
| ('entity', 'entity:workload'), | ||
| ('entity', 'entity:application'), | ||
| ('resource', 'resource:channel'), | ||
| ('resource', 'resource:rule'), | ||
| ('resource', 'resource:report'), | ||
| ('resource', 'resource:alarm'), | ||
| ('group', NULL) | ||
| ) AS applicability(object_kind, object_type) | ||
| WHERE actions.name IN ('read', 'write', 'delete') |
There was a problem hiding this comment.
After removing the resource-specific rows here, there is no action_applicability entry for read/write/delete on resource at all. The resource listing path (resources query via authorized_resource_ids) only returns objects when the requested read action has a matching resource applicability row, so fresh databases will show zero resources and PDP checks for read on resources report the action as unknown even for admins. Replace the MG-specific types with a generic ('resource', NULL) entry for these actions if resources are still supported.
Useful? React with 👍 / 👎.
2 participants
What type of PR is this?
What does this do?
Which issue(s) does this PR fix/relate to?
Have you included tests for your changes?
Did you document any new/modified features?
Notes