In my scenario the external companies would not see eachother's tasks (separate Spaces), nor other internal items (default Space). However the developers within my company would need to see things from across multiple Spaces.

Yeah, but I still want Spaces to be "hard walls" around content. If it's just some minor dashboard permissions, it might be overkill (ie, they both need to see same tasks).

Do these dashboards contain sensitive information?

For the use-case I was trying to outline in T9501, this would be the case. We work with a handful of external companies and use Phabricator for organizing and communicating work. We also use Phabricator for our code review. Each project with external company (People, Projects, Maniphest) is organized into separate Spaces so that they are fully isolated, and we have a default space for internal use for Diffusion/Differential. Ideally when a user from Company A logs in they would land on a dashboard that shows only the Projects/Maniphest for them, while Company B user logs in and only shows the Projects/Maniphest for them.

In T12308#212972, @chad wrote:

Do these dashboards contain sensitive information?

Basically we're in feature request territory, and we'll want to understand the root problem installing all these dashboards solves before deciding on what to build.

Do these dashboards contain sensitive information?

In T12308#212968, @chad wrote:

What is your expectation here that we do?

I think this is still the best way we have to let you if the dashboard visibility is over-restrictive or mis-installed. I'm not sure magically disappearing it solves anything. It might help to know more about what you are trying to do (was this on purpose, or a mistake) in order to try to better inform admins when they order dashboards like this.

What is your expectation here that we do?

Probably very similar or even dupe of T9501

It is expected that taskmasters will exit and restart after an unexpected failure, but this should not trigger setup warnings. I'll see if I can reproduce this.

This might be the same as T12302, but I'll see what's going on.

Persistent chat was originally a separate column (so it didn't overlap with anything on the page) but was brought into the main page recently.

FWIW I think this is pretty genius. Especially the repro-or-it-didn't-happen aspect.

Just as a side note: PHP 7.1.2 was released like a week ago, and I have not seen any more spurious segfaults on my instances when doing imports or anything like that on the server. The arc liberate bug remains dead and I have not seen any more faults in arc either. Builds should now be available in most PHP 7.1 repositories (in multiple distros/systems), so I suggest an upgrade for anyone who's affected.

Yeah I'll take it, pretty sure it's my fault.

Yeah I was planning on bisecting, but sounds like you're claiming this?

I think this is probbbbbbbably an actual bug unless I'm totally out of it -- possibly my fault from D17372.

I realise this is a wontfix, but you kept asking for root problems.

@epriestley The import has finished, but some commits show as importing still?

We have a hosted instance and seem to be running into the same issue. How do we get this going in this case? (Warning: we are new to phab!)

Agreed this dialog is pretty annoying.

No.

@epriestley Would you guys be willing to accept a patch that implements this?

I could be wrong

Also, note that in this install, Create Form links to /transactions/editengine/maniphest.task/edit/nocreate/, not to /transactions/editengine/transactions.editengine.config/edit/nocreate/. So, to the correct place, but "forbidden" one.
And there is simply no any other button to push.

This also seems related: https://secure.phabricator.com/D17262

Yep. How do I create the form I need then?

This isn't a bug, but is confusing.

Removed apache settings:

<LocationMatch "\.(?i:os)$">
    ForceType application/octet-stream
    Header set Content-Disposition attachment
</LocationMatch>

I don't believe we've seen this pop up again. I can't be certain because right now all the log files are empty, but that means the errors went away?

I believe this is effectively resolved now -- we're running all the daemons on multiple hosts on secure. There's remaining followup work (T6768, T6615, T10753, T10754) but I think the core is in reasonable shape.

T11708 has almost nothing to do with this, but the fix for this will rewrite the code that's running into issues and probably moot them.

I'm just going to merge this into T12115, which isn't really related, but will rewrite this code and probably "fix" this, since a reproduction case seems elusive.

This could probably be built with RRULEs now, but we don't currently have use cases / plans around a general-purpose cron-like tool.

Use cases seem to be fairly well covered now.

This is 2+ years old and autoscaling probably covers it now. T5401 is probably a more tangible attack on this.

This got a little more work when clustering was written but it's essentially a log of two-year-old ghost sightings at this point and not actionable.

I guess this one can live for now since that's reproducible/actionable.

Probably a dupe of T11708? I'm just going to kill this one since it's old as dirt.

I believe this was likely resolved by D16460. This (binary transport over Conduit) is still a problem in general, and T5955 is the general remedy, but diffusion.rawdiffquery specifically now returns data via Files.

I think it is likely that this was resolved by D17123. If it wasn't, we don't have a reproduction case anyway so we can't move forward. I'm going to call this one dead until more information turns up.

We were never able to reproduce this convincingly and as far as we know the reporting install no longer uses Phabricator, so I'm going to close this out.

I believe I have the first part of this (restructuring the code into a more sensible Overseer > Pool > Daemon sort of thing) working, but it could use more testing. I'm going to see if we have anything else in Daemons that I can fix while I'm here to help me kick the tires a bit.

You can make your own extension to Remarkup to allow auto-linking. I have one setup which I based off of P1129, P1209 which regex matches on Task-xxxx and uses the xxxx to link to our system. That works well and is sufficient for what we need.

This request doesn't describe a root problem, just suggests we do about a thousand hours of work integrating with remote APIs. See Describing Root Problems.

Some possible approaches here: