This is expected:

The root is visible to users only.
We only marked certain docs for public, but they require login.

No interest from the upstream (we don't take design suggestions as feature requests), you are welcome to fork Phabricator to provide these locally if you need.

I can't reproduce this. Phriction is successfully public on this install:

It's a lot easier to merge stuff than split it, so don't worry about filing new stuff if there's any ambiguity. We can merge them with a couple clicks, but if you've really described a different issue then splitting them is much more of a pain.

Yes, we have several Spaces. But 90% of users are member to default space arranged by Custom policy if understand right report of reproduction bug coming from @cspeckmim.
I'm a user part of all spaces and I'm facing again that Locked task error.
The form for Create Task is common for all Spaces ( Default Create Form·Edit Form ). Default edit policy is only for subscribers.

Just noticed one more quirky thing about users with no view policy for any space. They can't log out and they get one more "No Access to Spaces" message in the modal. Just like email verification, I don't understand why log out should depend on space view policy.

In T12421#216121, @epriestley wrote:

Your workflow looks like this, right?

• Users register, but can't do anything with their accounts.
• Separately, users email a project administrator to get access (they know to do this via some out-of-band channel?).
• The project administrator grants them access to projects or directly to spaces.
• The project administrator emails them back to let them know they can continue.

We tested this style (black with shadow) on our install, but the consensus is that it looks awful...
I guess a simple black text color is a little subtle, but at least it isn't confusing (like the blue color) or ugly (like the shadow).
@chad what do you think?

Thanks @chad for the help and motivation~

The key ingredient is to next set the default View/Edit policy of Maniphest to the Employees group (for Default Space which user is not accessible to)

I only approve "code" from @epriestley

what's your policy on supporting "random" PHP snippets from "sources" into Phabricator code

should send it to the log

phlog($var);

i have hosed it?

sosneaky

phlog

itsasecret

shh

What is the best way to log something to the web server logs? I've been mostly using exceptions but that's proving to be more and more cumbersome.

FWIW I do truly believe we have a bug here, just no idea where. Might be worth adding some logging?

I tried reproducing this on my phacility instance but I couldn't. Additional steps I took to mimic my setup were:

1. Make the Default Space only accessible to a specific group (say, Employees)
2. Make the default Maniphest Task Form visible only to Employees
3. Make the new Contractors task form default to being in the {Contractors} Space, and only visible/editable by Contractors

Maybe this should've been reported on T10004?

I'm also running last week's install
libphutil: 24ede7a5dbfd38079c87fc61de64012551965837
arcanist: 822bc53ca306e06314560d8a76f68771d732e8e0
phabricator: 56dd1b297c3e5cdbb477acc7435d6aa5749f33f2

I am seeing this too. I've not confirmed 100% but I think it has to do with Spaces:

1. Create a Space (not the default Space) visible to Project Contractors
2. Create a Maniphest Task Form (/transactions/editengine/maniphest.task/) that is visible to Contractors, set as being Edit Form
3. Create a User that is only a member of Contractors and which does not have access to the default space
4. Log in as the new user and attempt to create a new task using that task form. You will be presented with the "Edit Locked Task" form.

I think most everything here is complete and will file individual follow up tasks if needed.

I can't say, I see a lot of questions about it with nginx though with a little googling. Going to close this, feel free to comment again if you can reliably reproduce it for us.

(And it's easier to build query panels.)

I'm fine with getting rid of the template, I think it's much less relevant now that home is no longer a single dashboard.

I think we could even default it to "fancy mode" without a setting, at least to start with. I'm not sure anyone will want to access the plain text mode with enough frequency that we need it to be sticky.

Once arc is installed, you can just run arc update. Given the plan to also distribute linters, etc, this would still be preferable for each individual installation vs. us.

Alright chad, from T8783 it seemed like Nuance was still far away, but 3 months doesn't sound that bad.
As suggested I commented on our use case for Nuance. I think we can probably stop annoying @epriestley with that Diff and I'll just patch it on my own installation while Nuance is still in development which is probably easier for all of us.

Commenting here since you merged T12429. I find surprising you put Arcanist in the same bucket as Phabricator. I think you don't even have to do all the work to make Arcanist users happy. I might be wrong, but I think there will be people adding support for Arcanist to their favorite package manager (I'm ignoring Windows), if only they'd have tags or marked releases to work with?

Coming from T12430: Stop cutting of Mail History for new Tasks I think Nuance could be a great Application for our Use Case of managing Requests to our Team.

Wondering if we should get rid of "template dashboard".

We're planning on building Nuance on the short-term roadmap (1-3 months) so use cases right now are very helpful. I'd have to leave the contribution question up to @epriestley. I don't recall other installs needing this sort of thing, so it could be a while before we look into it further.

Though I can't imagine a use case where keeping full mails for new objects makes anything worse than it is right now, I'll look into Nuance, which actually sounds nice, even though a bit overkill and far away in the stars for our use case. (and will probably bring the last of our Users who just learned to use Maniphest to finally resignate too ;-) ).

@epriestley this doesn't seem hard to build for a fledgling designer/intern engineer.

I'm going to punt this into Nuance since it's "help desk" essentially. Maybe add a comment there too.

Doesn't this make Phabricator worse in every other case?

In T12296#216132, @epriestley wrote:

While the git ls-remote change isn't really motivated as a performance improvement, it does seem to have reduced CPU usage a measurable amount (deployed on the morning of 3/18), maybe 15%:

While the git ls-remote change isn't really motivated as a performance improvement, it does seem to have reduced CPU usage a measurable amount (deployed on the morning of 3/18), maybe 15%:

The cause of this was mundane: the daemon queue has a large repository import in it, so the repository search update got stuck behind the import tasks. Manually forcing an index update with bin/search index Rx fixed the index.

We have no additional design plans around hovercards.

I don't really consider this behavior a bug, because this (users registering into zero spaces) isn't really a supported workflow. The menu rendering is less ambiguously a bug, but I'd likely fix it by just hiding the menu in this state, and that won't address your issue. And it doesn't cause any problems unless you get into this questionable state in the first place, so cleaning it up is difficult to prioritize.

Oh, I see...so, no luck there...but this would be a great option if it worked the way I initially understood.

Tezt comment

"Can Create (Non-Bot) Users" is a fake permission for Phacility SAAS disguised as a real permission. You must always have that permission and be an administrator to create users: that is, it can only be used to reduce the set of administrators who have permission to create users. In the Phacility SAAS cluster, we set this permission to "No One".

In the short term, if you want to email me at support@ with the details, I'll fix these manually. We've rarely seen this request and the cost to build this self-serve, even if it didn't have product issues, is greater than the cost to manually fix all known cases for now. I'll build some kind of self-serve solution at the point when I get tired of doing them manually.

Why should verifying email address depend on any space view policy?