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?

Maybe this should've been reported on T10004?

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.

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.

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

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

This sounds like the expected result to me. Even if they did get verified, they would immediately hit the same "No Access" dialog again.

well that was a waste. lolz. 🐈

I can't reproduce this with the steps provided. Here's what I tested:

You are my hero! :)

Also, really great bug report :)

Do you maybe have SELinux or AppArmor running?

@epriestley, I tested out the scenario with the change applied.

I apologize, just this error is so floating that I still can not understand at what level it is. Now I come home, I load the picture - and it loads well enough.

Instead of using open registration, can you invite users instead and immediately add them to spaces so this doesn't happen? Why are you allowing open registration if all registration must be coordinated with an administrator anyway?

This is vaguely involved.

It sounds like this is resolved.

Please provide complete reproduction steps the upstream can follow as well as your installs version information. This information is required before we accept any bug report. See Contributing Bug Reports for more information. If you'd like a clean environment to test in, please use a test instance at Phacility.

For example, just try to load few times this file from our webserver.

This should now be fixed in HEAD of master. I've also cherry-picked it to stable. Thanks for the report!

I think this commit in the Git upstream is probably the culprit (January 2016):

Just tried that too, and strangely: it does.

Does it work without the --?

In T12416#215813, @epriestley wrote:

I can't immediately reproduce this, although the systems I have immediate access to are all running Git 2.11.0.

Does this command work on your system?

$ git ls-remote -- https://github.com/phacility/libphutil.git

I can't immediately reproduce this, although the systems I have immediate access to are all running Git 2.11.0.

I'm going to put D17497 + D17498 into this release even though they don't directly tackle the issue here and I think they're slightly risky changes (mostly because git ls-remote may have odd behaviors in some cases, and we don't currently use it in other workflows). But they may help with T12296 and general cluster load issues, and the followup changes will generally be more complicated to reason about (more locking/concurrency stuff), so I think getting these in earlier spreads risk out somewhat even though they're something to watch out for in this release.

Thanks! This code has been churning recently (T12298 / T12217) and I likely broke this in D17389. I think I observed this behavior, but this report should save me a great deal of time hunting the bug down.

Thank you! This fixed the issue.

Thanks. D17507 should fix this, and will un-stick any tasks stuck in queue.

Thanks! D17506 isn't the most elegant possible patch, but should fix this. Let us know if you're still seeing issues after that lands.

(D17404 is an earlier fix for a similar issue, but for self-auditors added via Herald.)

After 6 month seeing the bug, i think i've found why it does that.

To move forward, we need complete reproduction instructions which we can follow to reproduce this issue in a clean environment. See Contributing Bug Reports and Providing Reproduction Steps.

Probably bump the version unconditionally now

(For example, if the goal was to very aggressively optimize for minimizing network traffic, we could read the entire repository history to figure out which refs were ancestors of other refs first? Then we could drop those and only ask for descendant refs. But this seems crazy, since it's saying that ~20 bytes of network traffic is more costly than like one hundred million disk I/O operations?)

it has to compare "What do I have" vs. "What do you have"

Do git ls-remote (which, curiously, seems to be significantly faster than git fetch even when git fetch is a no-op).

I think T12393 and this probably have a similar set of root causes.

Ah! That fixed it, thanks @epriestley. I'll let you know once I test out that configuration.

Remarkup is cached, so you'll need to run bin/cache purge --purge-remarkup (or make an edit, or create a new post) to purge the cache.

@epriestley, I wouldn't mind testing that scenario out this weekend (I'll have to change a couple of domain name settings to create the scenario, but that's easily undone).

In T12372#215275, @epriestley wrote:

Great, thanks for testing it! We'll upstream that and I'll file something to put a longer-term fix in place.

"witter.com" <fakeemailtest+163@t>

ah yes this is my very favorite email address of all

Great, thanks for testing it! We'll upstream that and I'll file something to put a longer-term fix in place.

Confirming that the patch above works (tested using send-test --to)!