Closed by commit rPb655699a6cfb.

To see x/y/z/ you have to be able to see x/ and x/y/, so it should be moot I think.

Implementation wise, I think the handle fix is the way to go, mainly because....

word

This is mostly a product question so maybe @chad has some input on expectations / reasonableness.

I'm done-ish for today but I figure I should slap this on the ole queue.

Might be interesting to extend the Herald module ala Drupal rules (https://www.drupal.org/project/rules) so it can react to more events with more actions. Uber powerful stuff.

@michaeloa our current expectation for that is for you to write an registration event listener, which gives you unlimited possibilities.

Apologies if this has already been discussed, but a search didn't turn up anything. Putting this here, rather than starting a different task, as I guess the answer to the question will probably depend on how this task is solved.

T4778 is how we prioritize, this task specifically is on our roadmap.

I wonder what the state of this feature is. I really love to see this, because it's the only missing part stopping me to use phabricator to work together with clients.

Yeah, we don't want this in the upstream. You can add your patch to the wiki page @chad linked, though.

Sure. But since that will likely be a simple patch and not an extension then we could simply add a ref to this ticket in the community_resources wiki page when the patch is ready. Unless its possible to implement a phabricator extension for UI JavaScript code but I dunno since we haven't looked into this yet.

Maybe this could go here? https://secure.phabricator.com/w/community_resources/

@philippe.jadin: it's funny you suggest that as we had a very similar idea as you yesterday. We are are in the process of moving from Trac to Phabricator and have that same need for client-restricted projects. As an interim solution until namespaces or something similar is in place, we are planning to implement a small JavaScript patch in our local phabricator to do something similar to what you suggest here.

My 2 cents on this :

Closed by commit rP45bb77531c79.

In general, a user who can view a task can already take a screenshot of it and share it with whoever they want. I think of this as very similar to that, except that there's an audit log and the grant is revocable.

I'm going to disagree here with the utmost respect.

Support Impact The current behavior is unexpected and confusing.

Support Impact This is confusing and trivial.

(There's some fuzziness with the ruleset right now; I believe you can see the effects of their rules in transcripts, for example. Herald predates policies and is generally awkward to balance cleanly against them. There are things we could do better, but I think the major interactions are working correctly today.)

It's expected that you can't see other users' personal rules. Administrators can't violate policies, and users' personal rules are private.

One thing I do think could help, and maybe I'm just being an idiot. If I create a global rule as an admin, and then a non-admin user creates a personal rule. On my test installs I see both rules as the non-admin if I go to http://fabapi.wmflabs.org/herald/query/all/ but only the global rule as the admin. That seems weird? I would expect to see the same rules in both cases.

I think separating this policy out is also probably worth doing eventually, but it looks like it doesn't solve any immediate problems.

I discussed the WMF situation in particular in more detail with @rush898 on IRC, and it looks like T6211 is a good path forward for the "security" case.

In T6207#77543, @epriestley wrote:

Today:

• Users with access to the Phabricator host can destroy the rule with bin/remove destroy Hxxx.
• You can deactivate the rule by disabling the user's account.

How about this:

We're unlikely to expand the role of administrative power here, administrators intentionally have very little power. See:

Note that the fix won't apply retroactively, but if you edit existing questions (e.g., add a space or a period or something) that'll fix the files.

Closed by commit rPf605780893b3.

I'm 67% certain you made that number up.

I think you mean un-Prototype :P

I think there are still like 30 huge problems with it

I would vote to unbeta Ponder after this fix. I can't believe I said that.

Oh, haha, you're right. This should be a simple fix.

Crap. Since I also attached that file to this task, and you guys can view this task you can view the image.

Click "Attached" on the File page.

Is there a way to view what objects a file is attached to?

When I drag and drop and image in Ponder, I get the following when I click on the File's Policy:

Problem still occurs when updated to latest master.

Just kidding, got it to work on my test install

I actually can't seem to get it to reproduce at all. I can only figure that one of our developers restricted the permissions of the file he uploaded and then suffered amnesia about it.

(There may be a narrow issue here like "images in the main text of a ponder answer don't get the right permissions".)

I can see it.

Hmm, I might be wrong. Can anyone else see the image in the ponder question?

We use the same policy control everywhere, but some policies aren't meaningful in some contexts. We could do a better job about hiding them, although that would also create some confusion ("why can't I select 'no one' in this dropdown?"). Since it's fairly obvious why "no one" doesn't work with the current workflow once you save, I don't think this is too bad. It could be a bit cleaner, but the ideal version of this would look roughly the same ("no one" present, tells you why you can't use it when selected, just looks less exception-ey).

Closed by commit rP3238f1e09142.

• Add a new application capability, like "Can Lock Projects", to the Projects application, with a default setting of "administrators".
• Add a checkbox on the edit screen like [ ] Lock Project: Prevent members from leaving this project.. Require "Can Lock Projects" to adjust this. Use explainApplicationCapability() to render a link explaining why the user can or can not lock the project.
• When a project is locked, require CAN_EDIT to leave it.

I also have learned that the custom avatars in Recent Activity will not be shown to anonymous users either

... and now we have a real use case where the lack of public user profiles affects us.