nice catch

There's already policy controls on these objects so the policy just isn't being set correctly I guess? Seems like we would not want users to be able to set these policies to overly permissive things as well.

Maybe the fix is thus

• if its phacility (how do we tell this?)
• set default view policy to $author->getPHID()
• lock the view policy control

?

I think I just didn't set the Almanac application "Can Use Application" policy correctly on this incarnation. Should be "Administrators + instance client", I think. Hard to force it to the correct setting or lock it, though, since the "instance client" user PHID isn't a constant.

We could set view policies on all the services and stuff, but I think a blanket policy on the whole application is cleaner and easier. Users do not need to access their own instance Service entry.

The most general fix I can come up with for this is to define a new custom policy type, "same policy as some other application policy", and then we could lock this to use the "Can Manage Instances" policy on Phaclity Admin servers. That's kind of a pain to build UI for, though, and maybe not worth it.

In the worst case where all this stuff gets opened up by accident the only sensitive information we'd be disclosing is the names of instances (which I think we realistically have to treat as not-all-that-private) and then internal stuff that I don't think we care about like how many clients/instances/servers we have (we currently publish most of this explicitly in the wiki).

I just set this restrictively on the latest iteration, can you still see the stuff / do you have errors where applications are breaking because you can't see the stuff?

Looks good from my end, its not pretty though, I just see a whole bunch of "Restricted" text I would say for normal users, to hide the audit trail at the bottom

That commit should just hide those transactions from normal users.