Ref T7094. I am not sure when this text is legitimately exposed to users - they should be getting an error about not being able to see the object before they get an error about not being able to see a given transaction... That said, I think this text is logically correct at least.
Details
Details
- Reviewers
epriestley - Maniphest Tasks
- T7094: Clean up T603
- Commits
- Restricted Diffusion Commit
rP0969b0d8c87d: Policy - add an explanation for automatic capabilities for transactions and…
read the text
Diff Detail
Diff Detail
- Repository
- rP Phabricator
- Lint
Lint Not Applicable - Unit
Tests Not Applicable
Event Timeline
Comment Actions
Yeah, I think this isn't exposed to users.
The text seems a little bit off to me, since "edit the comment so long as ... edit capabilities for the underlying object" is not correct: you can edit comments even if you can not edit the underlying object.
From a purely technical point of view, these are the policies we implement:
- Comments are always publicly visible.
- A comment can only be edited by the author of the comment.
However, in practice, we also always add this rule:
- To see a comment, you must be able to see the object the comment is on.
So maybe text like this?
Comments are visible to users who can see the object which was commented on. Comments can be edited by their authors.
Comment Actions
The "murky" bit is just that we're setting public as the policy, technically speaking, and only enforcing the tighter policy in practice by always checking objects first.
Possibly, we should make Comments do an attach/load sort of thing and strictly bind them to the policies of their objects, but I think that would be a lot of work for a very marginal benefit. The only case I could see it preventing a programming error is in a future transaction.querycomments sort of method.