Page MenuHomePhabricator

Inherit Task Visibility & Edibility from Project
Closed, ResolvedPublic

Description

I'd really like tasks to inherit their permissions from the assigned project. Currently all new tasks are visible and editable for "all users" (I assume the public visibility option is gone because I disabled public access itself).

Steps to reproduce

  1. View a project
  2. Click Edit
  3. Change the permissions menus to the project's members (the group of the same name at the bottom of the list).
  4. Create a new task
  5. Default setting is visible to and editable by all users

Expected Results

The task would be visible only to the members of the specified project (or projects).

Workaround

Manually change the menus when creating a task (or afte the fDct).
UPDATE: 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.

Notes

I come from a system where a task can only be assigned to a single project, which certainly makes this much simpler to implement. I like the idea of multiple projects, and wish it would derive these permissions from the union of the task's projects.

I prefer to keep some projects within a small team during germination before opening it up to a larger group of folks for development.

Separately, this would be more acceptable if I could change permissions on the bulk edit screen, which doesn't seem to be the case.

I hope I'm totally nuts and that this type of automatic inheritance is possible, otherwise I'm happy to file another bug requesting permission options to the bulk edit screen.

Event Timeline

trev created this task.Sep 14 2014, 1:33 AM
trev updated the task description. (Show Details)
trev raised the priority of this task from to Needs Triage.
trev added a project: Maniphest.
trev added a subscriber: trev.
trev added a comment.EditedSep 14 2014, 1:38 AM

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!

trev updated the task description. (Show Details)Sep 14 2014, 1:41 AM
trev updated the task description. (Show Details)Sep 14 2014, 1:45 AM
trev updated the task description. (Show Details)Sep 14 2014, 1:55 AM
chad added a subscriber: chad.Sep 14 2014, 5:03 AM

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

trev added a subscriber: epriestley.EditedSep 14 2014, 7:36 AM

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

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.

trev updated the task description. (Show Details)Sep 14 2014, 9:33 AM
trev updated the task description. (Show Details)Sep 14 2014, 9:42 AM
epriestley closed this task as Wontfix.Sep 14 2014, 1:15 PM
epriestley claimed this task.

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.

This is basically why we don't intend to pursue this. You can find some discussion in https://secure.phabricator.com/T390#134. We'll do T3820, which may give you tools here. We'll also document Herald custom actions (T5194) which are a way you could potentially implement this yourself, at the cost of also needing to implement/manage the multiple-projects case. However, you might be able to choose a rule which is OK for your install ("just use the first project", "only these specific projects imply a policy") but would be too confusing in the general case.

Sounds good to me. Thanks!

Rockcena changed the task status from Wontfix to Resolved.Sep 15 2014, 9:05 PM
Rockcena added a subscriber: Rockcena.
ablekh added a subscriber: ablekh.Jan 31 2016, 1:57 AM