Thanks, that's useful to know!

I just created a separate space and moved one of my projects there. However, when I click on + Create Task from any of its columns, it chooses the Default Space and not the project's by default.

What I want is for it to set it by default to the space that the project belongs to. Can that be done? I would be glad to implement that if that's something that makes sense to you.

A custom form could work too, if I could choose different default Create form configurations for different projects as then I'd just set different defaults in the forms depending on the project.

...set it by default to the space that the project belongs to...

No, that's not possible.

You'll need a Custom Form for each Project. The button on boards seems to list all/most forms.
You can add a relevant link to the side Menu in each project.
Maybe we can think about adding having a button to each column that will have a selectable form/target.

Then, if every project could choose its own Task Create/Edit Form Configuration, it would solve the issue. Maybe form configurations could be tagged with projects, and when no tag = show for all projects?

Side menu link wouldn't solve it for the convenient in-column task addition.

But also, why is it impossible? When a task is created from a column, it automatically pre-populates the tag column with the project it is created from. It seems trivial to implement a patch that would auto-detect the project's space and set it accordingly for the task.

It's not "impossible" on the technical level, it's just not obviously the right solution.

The tags can be populated from the column because it's pretty obvious that the intention is "I want a new task in this column" and columns are more-or-less identical to tags.
But columns are not filtered by Spaces, so that might not be what the user expected.

I'll try to create a feature-request out of this, and we'll do some product thinking to come up with a solution that feels right.

To clarify: currently existing auto-tagging is not about the column from which the task is created. It's about tagging with the project to which the column belongs.

If I create a task from a column in a project that is in its own space, then I'd also like the task to also be in the same space by default. I think it's a reasonable expectation. In the same sense that columns belong to a project, the project also belongs to a space. That Phorge currently creates all tasks by default in the default space, no matter if the project it is creating them from belongs to a hidden space, is counter-intuitive and a privacy risk.

Another possible solution that doesn't involve spaces is to add an object policy that makes the task visible only to members of all tagged projects. There's already a similar option with the "Subscribers" and "Task Author" policy objects. If there was a "Project Members" policy object that would similarly dynamically resolve to the members of all tagged projects, I would achieve my goals by selecting it as the default option for the form configuration.

Also, thanks for looking into this! And let me know if you need any help with it -- I worked in Meta, so I've dealt with a lot of similar code. I might just go ahead and patch it locally for now to resolve it quickly.

In my installation this would not be a reasonable expectation. We have a public project tag used by a team. Some tasks associated with that public project tag are public tasks visible to everyone and anyone, so they are not in an access-restricted Space but default S1. Some tasks associated with that public project tag are temporarily non-public, "secret" tasks that should only be visible to that team and nobody else, so they are in an access-restricted Space that can only be accessed by team members.
So I'd rather envision a Herald rule: for a Maniphest task, if is newly created is true && Space is Sxx, then add project tag #whatever. (The other way round is not particularly feasible: The task would have a default view setting for a moment and potentially visible to outsiders, before moving it to a view-restricted Space).

Furthermore, "dynamically resolve to the members of all tagged projects" implies that there are some Join restriction by default on membership of all and any projects. That might not be the case in every installation (in ours there is not)...

To make this clearer (and as Ponder only allows 1 answer, thus I can only append mine):

We have Space 1 with some public tasks in project A and project B and project C "belonging" to it. We have Space 2 with some non-public tasks in project A and project B "belonging" to it. Thus no 1:1 connection between Space and Project ever, but an n:n connection.

We have a public project tag used by a team. Some tasks associated with that public project tag are public tasks visible to everyone and anyone, so they are not in an access-restricted Space but default S1. Some tasks associated with that public project tag are temporarily non-public, "secret" tasks that should only be visible to that team and nobody else, so they are in an access-restricted Space that can only be accessed by team members.

I'm not sure how Create Task form defaulting to the same space as the workboard's project would interfere with the scenario you describe here. I think these are unrelated use cases.

To clarify:

1. There's default Space 1 with open access. Project A belongs to it.
2. There's Space 2 with restricted access. Project B belongs to it.
3. When I'm on Workboard of Project A and click on pencil icon of any column, I want + Create Task to default task visibility to Space 1.
4. When I'm on Workboard of Project B and click on pencil icon of any column, I want + Create Task to default task visibility to Space 2.

Furthermore, "dynamically resolve to the members of all tagged projects" implies that there are some Join restriction by default on membership of all and any projects. That might not be the case in every installation (in ours there is not)...

That would only affect people who alter their form configuration and change default settings of Visible To / Editable By to Object Policies -> Project Members. Those who don't need it won't be affected.

Such object policy already exists for project access:
{F2392285}

So, it would only be natural for it to also exist as an option for tasks:
{F2392286}

(@arp - the images you pasted did not get Attached, so they are Private; Please set them manually to Public so they can be seen. We have an open ticket for that somewhere)

I've filed T15908 for the "quick create from column to do what I mean".

I'm not sure if "creating a task from workboard should be in the right space" is its own thing or not.

@avivey

• updated screenshot access to All Users
• thanks, that task would solve the problem!
• alternatively, "Project Members" option could be made available as an object policy for tasks

No, as project membership is unrelated to task object policy, as a task can associated to more than one project.

@aklapper it would totally work if every linked project's users would get access.

@arp: Sure, changing underlying semantics can solve some problems (and create new ones for existing installations). :)

How could existing installation be potentially affected by an added option? (The name should be different, of course, if it includes all users from all projects, for example, "Members of linked projects" vs "Project members".)

Both proposals would solve the problem. Proposal A is more general, so it would cover more ground but also require more manual configuration.