feat(quota): grant per-user quota for notes on platform-scoped subjects - #291
Merged
Merged
Conversation
Notes on contacts, users and organizations belong to no project, so milo meters them against the note's author instead. Without a grant the bucket limit is 0 and those notes are denied, so this must land before the milo side ships. No parentContext: these notes are created in the core control plane, where Users live, so the grant belongs there too. Creating locally also sets an owner reference on the User, so the grant is cleaned up with the user. The 1000 default is a starting point, not a researched number — it is meant to be generous enough not to bite real usage while making the notes countable.
ecv
approved these changes
Sep 16, 2026
3 tasks
kevwilliams
added a commit
that referenced
this pull request
Sep 19, 2026
Reverts #291. ## Why #291 granted every user an allowance for `notes.miloapis.com/user-notes`, to meter notes on contacts against their author. The milo side that defined and claimed that resource type (milo-os/milo#793) has been closed — notes on contacts are only ever created by platform users, so there's nothing to meter. That leaves this policy minting a `ResourceGrant` per user for a resource type that no longer exists anywhere, growing with every new user. ## Blast radius None. Nothing claims `user-notes` now that milo-os/milo#793 is closed, and a grant for a resource type with no claims is inert. The project-scoped notes grant (100 per project) is untouched and still doing real work. Contact notes keep working — milo-os/milo#792 is what fixed those, and it does so by not creating a claim at all, so it needs no grant. ## Test plan - [x] `kustomize build config/services/notes.miloapis.com` renders only the project grant policy - [x] All top-level kustomizations still build - [x] No remaining references to `user-notes` in config
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
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
2 participants
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
Grants each user an allowance for notes on platform-scoped subjects — contacts, users and organizations. Those notes belong to no project, so milo meters them against the note's author instead of a project.
Pairs with milo-os/milo#793, and this one has to land first: bucket limits come only from active grants and start at 0, so shipping the milo side without this grant would deny contact notes outright.
Why no parentContext
The existing project policy sets
parentContextbecause a note on a project-scoped subject is created in that project's control plane, so its claim lands there and the grant has to follow.These notes are different — they're created in the core control plane, where Users also live, so the grant belongs there and the policy writes locally. That's also the branch that sets an owner reference on the trigger, so a user's grant is garbage-collected with the user. The project-scoped policies don't get that.
The one thing needing a decision
The 1000 default is a starting point, not a researched number. It's meant to be generous enough not to bite real usage while making the notes countable — the point of this work is that they stop being invisible, not that the limit binds. Project notes are 100, but that's per project; this is per person across every contact they touch, so the same number would be much tighter in practice.
Happy to change it to whatever product thinks is right.
Test plan
kustomize build config/services/notes.miloapis.comrenders both grant policies