At least for Wikimedia, Files clearly wins over Pholio. While our design workflows are usually public, we have several private workflows where the most private part is a document attached (a file).

See for instance Moving procurement from RT to Phabricator.

But yes, with Maniphest and Files we would have basically enough, and if Pholio is added, then I cannot think about other scenarios where other apps would be needed.

"Projects" themselves don't need Spaces. Either they can be public (even if their content is fully private) or their policy can be fine tuned individually if really needed.

At HEAD, the underlying use case discussed on that task should already be secure:

If it fixes "email an attachment into the task & ensure its attachment isn't viewable to anyone not in the NDA group", yes. If it is unrelated to permissions on attachments added via email, no.

My expectation is that these files are created with permissions set to "Visible To: No One" and then have the sending user set as the owner and are attached to the task, which gives permission only to: the user who sent the file; and users who can see the task.

This is consistent with the behavior I observe on this install: I created a test task (T8497) which only I can see, then I replied to it via email. My attachment (F492117) was created with "Visible To: No One", and other users can not see it.

Is there a separate workflow or use case I'm missing here? I don't expect Spaces to impact this workflow.

There are some other workflows Spaces + Files would impact, but they're mostly stuff that I think isn't relevant for the WMF use case.

For example, if you have some users jailed in a contractor/client space, you might not want to let them see files you drag-and-drop onto the home page, which they otherwise could (by default, these files have more-open permissions to facilitate sharing screenshots, etc). This seems like a reasonable thing to use Spaces to handle, but I don't think it's too important unless you're jailing some users.

In T8493#119786, @epriestley wrote:

I created a test task (T8497) which only I can see, then I replied to it via email.

I think the difference with the Wikimedia Procurement use case is that tasks with files are created via email (i.e. a provider sends an offer to an email address).

Accordng to your explanation, the file itself shouldn't be problematic, but perhaps we need to discuss somewhere else whether it will be possible to create a task in a specific space via email, so it acquires the policy of the space since its inception, securely.

I think the difference with the Wikimedia Procurement use case is that tasks with files are created via email (i.e. a provider sends an offer to an email address).

Aha! Okay, that makes perfect sense.

I hadn't thought about this yet, but I think we'll probably just let you assign a Space to each application email address, so everything to procurement-bugs@ would default into the procurement space and everything to normal-bugs@ would go into the default space.

(We can implement a !space mail command, too, if there are automated or more complex cases here where the same address might receive mail destined for multiple spaces.)

I'll file a task for this specifically -- I believe it's pretty straightforward.

In T8493#119789, @epriestley wrote:

I think the difference with the Wikimedia Procurement use case is that tasks with files are created via email (i.e. a provider sends an offer to an email address).

I hadn't thought about this yet, but I think we'll probably just let you assign a Space to each application email address, so everything to procurement-bugs@ would default into the procurement space and everything to normal-bugs@ would go into the default space.

(We can implement a !space mail command, too, if there are automated or more complex cases here where the same address might receive mail destined for multiple spaces.)

I'm not involved in WMF Procurement at all but a separate email address would be my recommendation as well. I'm not sure how much I'd trust a !space command to be honest. It would be too easy to typo (or encounter some sort of message parsing bug) and accidentally expose something confidential.

@qgil: I'm wondering if it might make sense to create a space for wmf-nda as well? Maybe even security. If I understand correctly, we'd still be able to set custom policies and move things into the default space where we want to include others on specific objects, but then people would be able to email in private tasks securely (I can think of some WMF-internal people who'd like to be able to do things like this). Maybe we don't want to have to deal with two separate systems for these sorts of things though... Just a thought. I think I'm going off-topic here so I'll shut up.

@epriestley, perfect!

(@Krenair, yes, the intention is that Spaces will allow us to deprecate our own local remedies, one step at a time.)

In T8493#119801, @qgil wrote:

the intention is that Spaces will allow us to deprecate our own local remedies, one step at a time.

Well that can't actually happen in full for Security or WMF-NDA until Spaces allow you to bring individual users into individual objects regardless of space policy.

I'm not sure how much I'd trust a !space command to be honest.

Yeah, I have the same concern about the mail command flavor of this. We can reject email with bad arguments to the !space command, but can't know that we need to reject !sapec or similar. And we can't really detect that a human user forgot to add !space.

I think this might have some use cases when the mail is being sent from automated tools (they won't typo or forget) but probably isn't a very good approach for humans. Giving addresses a default space should be good for humans, though, and we can do the !space thing too later on if reasonable use cases arise.

(T8498 has the followup discussion.)

Well that can't actually happen in full for Security or WMF-NDA until Spaces allow you to bring individual users into individual objects regardless of space policy.

sounds like T8434: Accommodate the "Security" workflow

Edit: Ignore this. Your quote formatted strangely in my email client and I thought you were saying that Spaces do allow that. Never mind.

That's not how I read T3820#116906

errr, yeah, sorry. I had read that at some point...

I'd just like to mention that Spaces support to Phriction was the first thing I wanted to do. I am about to restructure our wiki so we can make certain documents available to a subset of people involved in a project. My solution was going to be create another project for the subset of people then set documents with custom policies of members in both projects. This requires that we restructure the wiki though because of the inherited permissions of wiki pages. Conceptually it will be restructured into separate branches that represent "spaces".

I thought Spaces might have solved the need for my restructuring task. But I'm not sure that it will because permissions will still be inherited. The hierarchy of permissions has caused a few issues for certain people's access to documents intended for them. Mainly if I create a document under another that the person doesn't have access to. I do expect the permissions hierarchy to work this way but sometimes I feel it would be useful to check a box to say "inherit permissions". Perhaps to make it less likely to be abused it could be in the custom policy set up.

Without fully understanding the why Phriction integration "might be pretty messy", my guess is that it is because the document hierarchy adds complexity. i.e. you can't have a child object in another space to a parent. Is this correct?

Perhaps if a Phriction document has been added to a space then all child documents are automatically placed into that space and the selection of spaces for child documents is locked. Or, going back to a "inherit permissions" option, maybe if spaces implicitly disable permission inheritance? I can see why that might not be a great idea though.

I'm not sure if this helps or not. In the mean time I'm going to go and restructure sections of my Wiki =)