As a complete aside, I used [REDACTED]'s bug tracker for years, and despite the blasphemously vomit inducing UI (you can find with a Google Image search) it happens to be amazingly powerful after you put a few months into figuring it out.

Phabricator is the only thing I've seen that has come close to a workable solution, and it's pretty and super functional to boot. You folks are gods amongst men. GODS I TELL YOU!

T3820 is how we're going to build visibility walls inside Phabricator, would that work for you?

Will it work for me? Yes, but it kind or breaks down here:

In T3820#16, @epriestley wrote:

Additionally, objects you create are put in the current namespace (eventually, there might be controls here).

The idea of namespaces is fantastic, I was a little surprised Phabricator didn't have the idea of "groups" when I was playing with things. I kind of still want them but figured I could make things work with the automatically generated project groups. I can see how namespaces solve a lot of problems, especially for folks who need completely different "worlds" for unrelated projects, clients, etc.

…but it's kind of hitting a nail with [insert something much larger than a sledge hammer] for my specific quibble.

I'd like to default permissions (namespace or otherwise) for any new tasks based on a project level setting rather than inheriting them from my namespace / perspective at the time of creation.

Namespace seems more like an environmental UX perspective for the specific user. Assigning permissions based on the user's chosen perspective (namespace) doesn't really relate to the permissions they may want for new tasks. Let's say I'm the guy in charge and I'm firing a bunch of tasks off to my minions. I'd like to do that as things pop into my head, which means I'll need to fiddle with the namespace just to specify the visibility for new tasks. …what if I forget to switch namespaces? What if I walk away from my desk and use my iPad to create a new task? I assume the namespace attribute will be stored client side, at the very least switching it on my Mac wouldn't instantly change it on my iPad. It seems silly but this could easily lead to misnamespaced tasks.

Ultimately creating tasks with project specific permissions seems more trustworthy and easier to understand. Namespaces are a bit more amorphous. I totally see a lot of other reasons to add the namespace feature, but it doesn't precisely match my nitpicking request.

I realize it gets complicated when multiple projects are involved, otherwise it seems pretty straight forward to replicate the project name in the permissions fields for a task (they're literally the same word). If possible a task could use the union of the two project's permissions, although that would probably cause some sort icky performance / spaghetti permissions.

Again, I come from a different system that took years to master. I may be thinking about this the wrong way. Feel free to tell me I'm stupid and that there's a better method (because all I ever wanted was something better than [RDARACTED] in the first place).

FWIW, I realized "create another" saves the permissions settings to I have a decent workaround when adding multiple items with repetitive unique permissions. It's not as tight as I'd like but it helps a lot.

Sounds good to me. Thanks!