I think one of the issues was people making a public task, and then deciding they should change it to security, but not having the permissions to do so?

Awesome, glad to hear things sound promising. Thanks for the update!

@epriestley: We haven't pushed this to production but my initial impression from configuring forms on https://phab-01.wmflabs.org is that this should work pretty well. The only thing I haven't figured out is a way to easily transition a task between private & security sensitive and public. It seems that will require someone with adequate permissions to manually edit the task policies, which isn't the end of the world. We could possibly continue to use herald rules to make the transition easier, though I am more keen on the idea of totally killing off both the herald rules and the custom event listeners.

We haven't seen more of these for a few months and I've been more consistent about tidying them up so I'm just going to close this out, but let us know if anyone catches more of these.

So this is just T6802#93770?

User (or project) based policies produce useful error messages if you can't view an object:

We also now have Describing Root Problems as a guide to help people give us more details on issues they face. It's important for us to understand root issues so we can be sure we're correctly solving your problem.

I don't know what this ticket is about. If it's a bug report, please provide steps to reproduce per Contributing Bug Reports. If it's a feature request, please describe the core problem per Contributing Feature Requests.

In T8434#147963, @epriestley wrote:

I ultimately expanded the scope here into a lot of adjacent work in T9132, but a rough version of "better templating" is now available in HEAD and deployed and configured on this server. There's documentation here:

https://secure.phabricator.com/book/phabricator/article/forms/

This is still a bit rough in places and probably has some bugs, but I think the big picture stuff is working reasonably well and mostly usable.

I ultimately expanded the scope here into a lot of adjacent work in T9132, but a rough version of "better templating" is now available in HEAD and deployed and configured on this server. There's documentation here:

Perfect! This should be easy to fix.

I think I made some here: https://secure.phabricator.com/project/profile/1387/ by editing the Custom View Policy and trying to open the transaction in an Incognito window.

I can reproduce the bug on what I think is a relatively up-to-date production installation.

I can't examine any of those either, but I can reproduce the bug on what I think is a relatively up-to-date production installation.
If it helps, this URL was linked from https://phabricator.wikimedia.org/project/profile/1090/#17189 (edit policy entry)

You need to give us steps we can actually follow in a development environment to reproduce the issue. We can not examine database data, logs, etc, on the WMF install.

In T9869#146119, @chad wrote:

Please file bugs with more information, specifically steps to reproduce. See Contributing Bug Reports.

Here's what I get. Note:

I can't reproduce, those steps work fine for me on this install. I can click "Show Details" on the transaction above while logged out and get a dialog showing the details.

Here's my guess at how to reproduce:

Please file bugs with more information, specifically steps to reproduce. See Contributing Bug Reports.

Some feedback from our Phabricator instance. At the moment, the way we have been testing usage of Spaces is:

• S 1: Public (Default). Our open-source projects go there.
• S 2: Internal. Visible only to employees. For this, we would really, really like some way to batch assign/add users to a Policy/Space, as discussed in T9780 and T4103#145539. Handling this manually quickly becomes impractical with large numbers of employees.
• S 3+: Long-running special interest projects. They do exist, and they tend to value their privacy.

We apply a Space constraint when executing this query and the object never makes it as far as the application. This is broadly by design, as it hugely improves the scalability of Spaces.

You may also be interested in T9212 which explains a bit better why "free support" is increasing burdensome for the upstream.

More specifically we'd prefer if people:

We prefer people follow our posted guidelines on filing feature requests. We don't take feature requests that don't state a problem. Specifically "feature does not exist" does not satisfy our criteria for requesting features.

Sorry, I don't understand, why you closed this. The problem is:

• You can block commits, for example, if you don't want to see private data there
  • But if you want to block private data, you need to put in that data in a global herald rule, which is public visible
    • But if you don't use regex, you can block private data, yes, but everyone who can access herald, can see the data, so this feature is not very useful at the moment.

https://secure.phabricator.com/book/phabcontrib/article/feature_requests/

Ah thanks for the fix! I was going to try taking a swing at this soon, but I'll keep in mind about policy-related things and noise.

Sorry, this fell through the cracks -- feel free to make noise about anything policy-related like this if I don't pick it up in a couple of days.

that's cool

We've removed the dot rules from the upstream for security reasons (see T9408) so this is no longer relevant, although it is a concern we might want to address in T4190.

See also T4136.

It's been moving out of Config and into Applications gradually and I want to have ~all of it in Applications eventually, a lot of it just predates Applications.

It also seems strange to have some application config in Config and some in Applications

(The dialog might also be inaccurate if the link was actually on a dashboard panel.)

I could imagine this, purely motivated by flavor:

Yes, but it's real dumb:

Do you know why Applications application doesn't show in search?

mgroup

One other thing we might want to consider is making "Prototype" more prominent, just in the hope of reducing upstream support burden a little. We could link it to the "Prototype" docs too, perhaps.

I've been thinking about this for a while since the redesign, I'll toss a diff together today.

Yeah, likely just a didRejectResult() issue.

I guess this is related to / a duplicate of T4345.

A lot of the practical cases here are resolved, but the root problem still exists. Basically, the core issue is that an object can say: