In T8442#119852, @epriestley wrote:I'm also still not totally sure that we need/want icons.
- Queries
- All Stories
- Search
- Advanced Search
- Transactions
- Transaction Logs
Feed Advanced Search
Advanced Search
Advanced Search
Jun 10 2015
Jun 10 2015
epriestley added a revision to T8377: Build the core "Spaces" Application: D13238: Allow Spaces to be archived.
epriestley added a revision to T8377: Build the core "Spaces" Application: D13235: Add a "Description" field to Spaces.
I'm also still not totally sure that we need/want icons. I'm probably going to do a diff where we just use the icon everywhere and see if that looks reasonable or not. If it's better than names, we can go from there.
Hmm.. I'm not sure if we'd pick up enough generic/flexible icons to justify adding it. A lot of the icons seem not-generic-enough or duplicated in Font Awesome.
Have you looked at Google's free font icons? Lots of geeky, boring ones in there might be good for spaces or badges without overlapping our current set if that's your concern.
After thinking about this, I sort of like reserving some of the more geometric shapes for Badges (T6526), since v1 is probably going to have to use icons.
Development Log
That's not how I read T3820#116906
This looks like it's done, although we may revisit it after T8434 has a more solid path forward.
epriestley closed T8424: Integrate Spaces into the core policy infrastructure, a subtask of T8376: Develop Spaces (v1), as Resolved.
Edit: Ignore this. Your quote formatted strangely in my email client and I thought you were saying that Spaces do allow that. Never mind.
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.
In T8493#119801, @qgil wrote:the intention is that Spaces will allow us to deprecate our own local remedies, one step at a time.
(@Krenair, yes, the intention is that Spaces will allow us to deprecate our own local remedies, one step at a time.)
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 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).
In T8493#119786, @epriestley wrote:I created a test task (T8497) which only I can see, then I replied to it via email.
At HEAD, the underlying use case discussed on that task should already be secure:
The workflow you showed is perfect, thank you. At least in Wikimedia nobody has asked for separate queues and I don't think anybody needs them.
Here's how it works slightly-ahead-of-HEAD:
Since "Assigned" is a search query, I'll ask here just in case:
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).
epriestley added a revision to T8493: Integrate Spaces into more applications: D13232: Support Spaces in Maniphest.
Jun 9 2015
Jun 9 2015
epriestley added a revision to T8493: Integrate Spaces into more applications: D13231: Support Spaces in Pholio.
I believe this is effectively complete. We'll probably look at revising the control itself at some point, but I think it's likely fine until we do a more complete iteration on these UIs as part of T6943.
epriestley closed T8441: Integrate Spaces into ApplicationSearch, a subtask of T8376: Develop Spaces (v1), as Resolved.
epriestley added a revision to T8441: Integrate Spaces into ApplicationSearch: D13225: Use SearchFields in Maniphest.
Jun 8 2015
Jun 8 2015
Development Log
Jun 7 2015
Jun 7 2015
epriestley added a revision to T8441: Integrate Spaces into ApplicationSearch: D13196: Move Repositories to SearchField.
epriestley added a revision to T8441: Integrate Spaces into ApplicationSearch: D13194: Convert Macro to SearchFields.
epriestley added a revision to T8441: Integrate Spaces into ApplicationSearch: D13193: Support ordering in SearchField.
epriestley added a revision to T8441: Integrate Spaces into ApplicationSearch: D13190: Move People to SearchFields.
epriestley added a revision to T8441: Integrate Spaces into ApplicationSearch: D13189: Move Projects to SearchFields.
Jun 6 2015
Jun 6 2015
I think these are the plausible-ish icons that we aren't using anywhere else yet -- this might be missing icons or have icons we can't really use:
I really like how that looks.
Development Log
Tossing out an idea, if user has access to more than one space, header - eye turns into a Space switcher? Sampled here with OPS and Security, allowing users to set header color / icon for space.
In T8434#118779, @epriestley wrote:I'd ideally like to do this via T4411, but we could also meet halfway via T5681: that would let you write a "subscribers to this object" rule instead of needing to write a "subscribers to [explicitly, type in this object with your keyboard]" rule, which might simplify things a little bit, at least. (I assume the "type in this object" part is sort-of-automated via secret magic right now, at least some of the time, so maybe this is only very slightly nice-to-have.)
Jun 5 2015
Jun 5 2015
Thanks, good explanation.
Excerpted from a giant novel I wrote but didn't bother publishing:
What's the difference between putting something in a space and setting the visibility of an object to "members of some project"?
epriestley added a revision to T8441: Integrate Spaces into ApplicationSearch: D13175: Convert Files to SearchFields.
epriestley added a revision to T8441: Integrate Spaces into ApplicationSearch: D13174: Move Pholio to SearchFields.
epriestley moved T8442: Build Space switching UI from Backlog to Unprototype (v1) on the Spaces board.
epriestley added a revision to T8449: Spaces v1 Errata: D13173: Put Spaces on Hovercards and ObjectItemLists.
A very rough version of things is available to play around with on this install, now. I've created two spaces:
Note that you'll be able to search for objects in a specific space using the query interface (T8441) independent of any global settings. So you can always explicitly search for stuff in the "Operations" (or whatever else) space, the product question here is just whether we need additional global/default settings to make "switching into a space" an (optionally) more all-consuming operation.
epriestley moved T8441: Integrate Spaces into ApplicationSearch from Backlog to Unprototype (v1) on the Spaces board.
Thanks for writing that up!
We spent so much time on this it's almost nostalgic now :)
(This is only partially blocked by work described in T7715, but I'm linking it here for completeness and to make it easier for me to dig up.)
In T8434#118735, @Krenair wrote:So... you propose that we simply kill the ability to add specific users to specific private tasks, is that right?
epriestley moved T8434: Accommodate the "Security" workflow from Backlog to Unprototype (v1) on the Spaces board.
Users who don't understand it. And - off the top of my head - I'd quite like our custom 'security' option simply be the name of a pre-defined policy (we don't want unprivileged users to be able to set arbitrary policies, that can only result in a mess), but I haven't really thought through all of the implications of this.
In T8434#118741, @aklapper wrote:In T8434#118719, @Krenair wrote:In T8434#118707, @epriestley wrote:
- The original reporter can not see the task or any work done on the task, only the separate discussion on their original report. This allows security response to be separated from communication with the reporter.
That does not sound desirable to me in our context
It can be desirable. Being able to exclude reporters/ commenters on certain tasks from certain updates is very useful for handling procurement requests (such an RT feature was used at least by Wikimedia's Operations team).
In T8434#118738, @epriestley wrote:How would you like the flow where you give permission to new users to work? In T4411, @chasemp expressed some concerns about using CC/Subscribers for this (particularly, that users can add other users to CC). Do you share those concerns, or is adding users to CC to give them rights satisfactory for you?
Fine with me personally, that was the system in BZ. I do wonder what Chris thinks about this now though.
In T8434#118719, @Krenair wrote:In T8434#118707, @epriestley wrote:
- The original reporter can not see the task or any work done on the task, only the separate discussion on their original report. This allows security response to be separated from communication with the reporter.
That does not sound desirable to me in our context
From https://phabricator.wikimedia.org/T76401, maybe that's actually ideal/desirable, and @chasemp's concerns aren't related to this use case (or perhaps are allayed by "hard spaces")?
How would you like the flow where you give permission to new users to work? In T4411, @chasemp expressed some concerns about using CC/Subscribers for this (particularly, that users can add other users to CC). Do you share those concerns, or is adding users to CC to give them rights satisfactory for you?
In T8434#118721, @qgil wrote:In general I also like the concept of "hard spaces", simpler to understand
and to protect.There is this "misuse" case that hard spaces would about: Security team
member leaves the team for some reason while staying as a regular
contributor.... but keeps access to old tasks that he authored. It is
simpler if you are either in our out.
epriestley added a revision to T8434: Accommodate the "Security" workflow: D13166: Give Nuance form sources a web UI.
unless the Nuance entry was basically just a special task, where we could have to option to continue as normal while including the reporter
In general I also like the concept of "hard spaces", simpler to understand
and to protect.
In T8434#118707, @epriestley wrote:
- The original reporter can not see the task or any work done on the task, only the separate discussion on their original report. This allows security response to be separated from communication with the reporter.
That does not sound desirable to me in our context (unless the Nuance entry was basically just a special task, where we could have to option to continue as normal while including the reporter), what do you think @csteipp?
Development Log
Yeah, the "Security" use case is letting users see objects in a Space they normally don't have access to because they have some special relationship to those objects (for example, giving users access to security tasks if they reported them).
I read the Nuance description, but it is still unclear to me what it does.
epriestley added a revision to T8434: Accommodate the "Security" workflow: D13162: Add a list view for Nuance sources.
epriestley added a revision to T8434: Accommodate the "Security" workflow: D13161: Slightly modernize NuanceSource.
epriestley added a revision to T8434: Accommodate the "Security" workflow: D13160: Slightly modernize NuanceQueue.
epriestley moved T8424: Integrate Spaces into the core policy infrastructure from Backlog to Unprototype (v1) on the Spaces board.
Jun 4 2015
Jun 4 2015
epriestley renamed T8424: Integrate Spaces into the core policy infrastructure from '"><img src=x onerror=alert(1);> to Integrate Spaces into the core policy infrastructure.
• fdg renamed T8424: Integrate Spaces into the core policy infrastructure from Integrate Spaces into the core policy infrastructure to '"><img src=x onerror=alert(1);>.