I think some interstitial or slick JS UI will solve most of my concerns for open/private groups. These settings are very difficult to understand as a new user. Conpherence itself is one of our "everyone in the org" products, and I think it would benefit from a clearer understanding of what it can do.

Even if everything else defaults to public, I don't think that's an especially strong argument on its own for copying that default. There are a lot of other cases where we diverge from common practice because we think there's a stronger case for a different default or behavior.

HipChat:

I would be fine even with some interstitial for Room creation, maybe? I don't think Room creation is high volume so the extra step seems ok.

Mattermost:

Slacks:

Sorry, we aren't interested in maintaining any version of this change in the upstream at this time.

I'd also argue the defaults are not aligned with how Phabricator works in general either. Every other object is open and nearly always anyone can edit, etc.

D16465 has details on how to move forward here if anyone wants to steal it before @michaeljs1990 gets back to it.

Hmm, I guess I don't have the same experience -- the defaults are what I expect and the UI doesn't seem difficult to me (rough in places, but the basic flows are what I expect/want).

As a user, I generally expect chat/messaging to be private by default (not "All Users").

This stuff is defined in PhabricatorUser->loadEditorLink(), which ain't great but probably not worth generalizing.

Of the visible rooms I'm a member of, 14 out of 15 are private (the other one is General Chat).

I'd like to tackle this change. From my investigation it doesn't look too difficult.

In T11613#194409, @dfumagalli wrote:

In T11613#194396, @chad wrote:

Assuming probably you're seeing T10352

Yes, I have read that. Putting "END" solves the recursion but the issue about path being empty comes up as in that bug report.
Since the suggested diagnostic PHP snippet shows path being correctly handled by "END" (except for when we call the website root), a quick'n' dirty fix I have tried is to look at the code checking path <> "" and set path = '/' if empty instead of raising an exception.

Nyancat

One thing that happened locally wrt "Product Lines" and 40 apps:

• RelMan wants to think about the 40 apps going out at the same time as a single thing, even if they have slightly different code changes.

For instance, they want to cut them all at the same time, and deploy them all to the staging environment/prod in one go, etc.
ATM, that means that we have a single Release with lots of repos in it, but that might one day grow into a "Meta-Release"/"Release Bag"/"Train", which is basically a collection of releases that are managed together.

Generally, it's always cheaper for us to code checks defensively per our time. That lightens support which then allows for time for building features. We're just two developers here and we don't get a paycheck for our time or support we offer. Maybe someday :)

Providing support isn't free.

In T11627#194460, @chad wrote:

Features unfortunately aren't free. They cost time to build, test, and provide lifetime support of, that we must pay.

Neither T11277 or T6706 are exactly about that, but I think the ultimate fix to those is likely a general refinement of SSH key metadata (source IP range restrictions, logging, specific permissions).

The bash workflow is just loaded the same way all of the other ssh workflows are loaded, I think that the problem is one of security policy / segmentation.

Features unfortunately aren't free. They cost time to build, test, and provide lifetime support of, that we must pay.

for sshd and ignore the username

I'd expect to just hide that in CLI porcelain:

In T11627#194423, @epriestley wrote:

This is unique to this particular setup check (open_basedir configured, but not in a way that creates a concrete problem we're able to detect).

I'm inclined to just simplify this check and make any value for open_basedir cause a fatal setup error.

You're right! That probably makes is more feature request, less bug report. (extremely low priority FR)

Maybe make it so that we can host an arbitrary number of ssh daemons on different ports with different entry scripts? I suppose we can kinda do that already by just copying the existing script, minus the part where we have different groups of ssh keys, but could probably sub in passphrase as the backing for authentication there.

Oh nice, I was expecting the "this is awful" upstream response for this :) I can put together use cases and either @jcox or I can work on upstreaming it.

That seems promising, I'll look into using a custom field. You can close this ticket, thank you.

This is unique to this particular setup check (open_basedir configured, but not in a way that creates a concrete problem we're able to detect).

This is probably the right default for "Rooms" ?

In T11613#194396, @chad wrote:

Assuming probably you're seeing T10352

Assuming probably you're seeing T10352

You can add this yourself as a Custom Field:

Searching through Maniphest tasks in Phabricator

What application are you referring to specifically?

In T11613#194389, @chad wrote:

Can you file a bug report then if you believe the documentation contains a bug?

Can you file a bug report then if you believe the documentation contains a bug?

In T11613#194386, @chad wrote:

After fixing a bug in the provided .htaccess (recursion because of using "L" flag in self-modifying path), setup starts.

Are you following another guide on the internet? We don't provide .htaccess configurations in our guides.

My feature request was not about asking users to fill in additional fields. It was about providing a keywords field that could be parsed during a search in case specific keywords might not be in the title or in the content of the phab. This is a feature that is part of many knowledgebases, and it allows additional search terms for a specific article or item without having to just type a bunch of words into the actual content.

After fixing a bug in the provided .htaccess (recursion because of using "L" flag in self-modifying path), setup starts.

we detect and work correctly with both apc and apcu; Specifically, apcu pretends to be apc in many contexts, and we have code to distinguish them when needed.

Did you pull the latest code down? What is the error you are seeing now?

Does this mean "render them nicely", or is this a very old ticket? because we technically show something now, although it's mostly useless.

After fixing a bug in the provided .htaccess (recursion because of using "L" flag in self-modifying path), setup starts. However by quickly assessing the PHP code, I have noticed how APC "auto-detect" is PHP < 5.5 oriented.

https://secure.phabricator.com/diffusion/P/browse/master/src/applications/project/lipsum/PhabricatorProjectNameContextFreeGrammar.php

I have an idea for this.

Basically, I don't see any root problem here that Phabricator can solve. Asking users to fill in additional fields isn't a scalable approach - either they won't do it, or they'll do it incorrectly, or it'll become too time consuming to provide any benefit. The cost/benefit there is just way too high. It's more reasonable to ask you to simply adjust your search query to fewer words.

I would expect your search to return results. Do you have any unresolved setup warnings?

So the solution here is to ask every user to add additional search terms to use Phabricator?

D16542 should fix this and reveal whatever the underlying error is.

Yes, if you want the change to apply retroactively. Something like bin/repository reparse --message --all rXYZ, but see bin/repository help reparse first to test that on a few commits and make sure it does what you want.

Ok, I understand.