I marked D14023 as resolving this since I think I took care of most of the really silly/old stuff and this now works in a fairly reasonable way, at least for the most part.

This sort of exists in HEAD now, but with major limitations:

Awesome! Thanks @epriestley :)

Awesome, glad to hear it!

@epriestley: Sounds good to me. Agreed that object policies are working well, I've already replaced the hacked-up policy rule with your Subscribers rule and it's working as expected.

I'm going to wait until the Harbormaster doc gets split up a bit before writing details on how to use this, but here's the rough version.

I'm pushing T8442 out since we don't really have enough understanding of use cases yet, and would like to give installs time to adopt and use Spaces before we move forward with it, since there are a number of different possible approaches with different tradeoffs.

Status here:

I think we've pretty much tied up all the loose ends for v1 here.

We have pretty good saturation now and I don't think there are any real-world use cases driving other applications at the moment. A few more applications will probably get support eventually.

This stuff is now in relatively good shape in HEAD. Some followups:

From my experience playing with this and some user feedback:

• Spaces would greatly benefit from having colours and icons. Then not only could the selector show different (and hopefully more obvious) icons, but the header (or site background) colour could also be changed to the colour of the space. A less intrusive coloured line below the header, possibly combined with coloured text in the spaces selector, would also be fine.
• The benefit that this small patch alone does to UX feels immense. Instead of having to adjust spaces for each and every object I create (which actually reduces usability instead of increasing it), I can switch "modes" or "projects" globally, which means a lot if your instance contains objects from very different projects which are being worked on by distinct groups of people.
• User feedback suggests that the position (central header) and combination with a text (space name) improves usability of spaces a lot and makes it very obvious which space one is currently working in.
• Filtering the page contents to show only objects in the currently selected space might help users switching over from Redmine (which is the majority in our case) to understand the concept.

The patch could still need a bit of polishing, but should I already submit a review request anyway, so it becomes easier to discuss necessary changes?

I updated P1834 to fix the mentioned issues:

I've got a patch ready, which basically copies the search scope selector implementation, and is still rather crude and unpolished: P1834

Oh no that's not a "Phacility" quote. I'm just trying to say I really don't know what we'd end up building without a decent effort upfront.

So that makes it $3-6k (according to your Paid Prioritization scheme). Which means we'll have to go with a local patch, unless more funders weigh in.

I no idea what the end result will be, design wise. I would personally probably re-think the entire header. (20-40 design hours).

I gather that you still consider the menu-on-eye-icon the best way to present this UI? Would it help you, if I tried to come up with a patch that does exactly that?

@devurandom, see {I4} if you'd like a personalized status update on this task.

Has any progress been made in the last month? Any new decisions on how it should work?

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".

In this case, they manually update them (And they find them interesting - these are things like "when we expect a fix to be released").

Do users manually update the JIRA fields, or does something synchronize them?

A use-case I have with JIRA:
We have a bunch of custom fields, most of them are of no interest to me, so I'd like to ignore them when they change; But I'd rather black-list uninteresting fields than white-list interesting ones (Which risks missing interesting changes).
So the condition I'd like is Transaction is limited to these fields: [field], [field], [field].

A partial solution is to (ab)use the List-ID header, which Gmail does understand. GitHub took this approach.

Development Log

Development Log

Concrete stuff here is probably something like this (this might not be the optimal order):

In the newer design, the space name has a red callout so it should be pretty hard to miss. Here's an example on the detail view:

The clearly-desirable integrations now work. I want to wait for use cases for the others; they likely aren't technically hard, but are potentially bad/confusing/ambiguous.

I'm going to close this since we seem to have made it to a state that no one hates too much. There are some followups in T8420 and T7870, and we'll adjust the UI a bit more and bring hiding to Diffusion in the future.

Development Log