In T11141#180280, @epriestley wrote:

Or, perhaps more specifically: why do you want to change your machine's local timezone, but not change Phabricator's timezone to be consistent? If you just didn't want to change your timezone at all, you could leave everything in PST while in London and your system clock and Phabricator would both remain in PST, but you did change your system clock.

why not using the browsers timezone by default and giving the possibility to set a static one in the settings if really required (without this message popping up)

"Adjust timezone" dialog doesn't have a way to cancel/ignore

why not using the browsers timezone by default and giving the possibility to set a static one in the settings if really required (without this message popping up)

Or, perhaps more specifically: why do you want to change your machine's local timezone, but not change Phabricator's timezone to be consistent? If you just didn't want to change your timezone at all, you could leave everything in PST while in London and your system clock and Phabricator would both remain in PST, but you did change your system clock.

Why don't you want to change your timezone?

Catching a couple more funky diffs:

I enabled Google for central auth since I think everything we need for it to work already works fine in the cluster, although it's possible some of the invite flow stuff is a little shaky.

I believe this is fixed now, but reproduction has always been somewhat elusive so I'm not completely certain. Please let us know if you still see issues after updating. Thanks for the report!

This commit now appears properly in the history view on this install, so I think the issue is resolved:

So fast :)) Many thanks for you work)

Look at my repo history without bug fixing.

No, not in full commit info. See history window with all commits of project.

I can't reproduce this -- rGITTESTaa541e7b324424e201c124dc58588c33e48d8bf5 seems to work fine for me.

I found source of problem: many lines of code in libphutil and phabricator use a strlen and substr functions instead of using mb_strlen and mb_substr. If you replace this functions to multibyte-analogs, this bug go away)

If the "Audit" setting for packages had three settings instead, would that solve your use case?

Thanks. That trace is consistent with the one I was able to reproduce, so I suspect the changes above fix this. I'll leave this open for a bit in case anyone else shows up, this fix is the kind of fix that's likely to have spooky side effects.

The command output was:

[2016-06-13 17:45:26] EXCEPTION: (InvalidArgumentException) Argument 1 passed to DiffusionCommandEngine::setURI() must be an instance of PhutilURI, instance of PhutilGitURI given, called in /home/ubuntu/phabricator/src/applications/repository/storage/PhabricatorRepository.php on line 511 and defined at [<phutil>/src/error/PhutilErrorHandler.php:200]
arcanist(head=stable, ref.master=e8a0ebaeffaa, ref.stable=7b0aac5c6f31), phabricator(head=1558175ec84c7b13ba3f692b897464901bc00578, ref.master=55767aac0f86, custom=2), phutil(head=stable, ref.master=dad3ab8d7e87, ref.stable=ad458fb7df59)
  #0 PhutilErrorHandler::handleError(integer, string, string, integer, array) called at [<phabricator>/src/applications/diffusion/protocol/DiffusionCommandEngine.php:52]
  #1 DiffusionCommandEngine::setURI(PhutilGitURI) called at [<phabricator>/src/applications/repository/storage/PhabricatorRepository.php:511]
  #2 PhabricatorRepository::newRemoteCommandEngine(array) called at [<phabricator>/src/applications/repository/storage/PhabricatorRepository.php:497]
  #3 PhabricatorRepository::newRemoteCommandFuture(array) called at [<phabricator>/src/applications/repository/storage/PhabricatorRepository.php:488]
  #4 PhabricatorRepository::getRemoteCommandFuture(string, string) called at [<phabricator>/src/applications/repository/engine/PhabricatorRepositoryPullEngine.php:350]
  #5 PhabricatorRepositoryPullEngine::executeGitUpdate() called at [<phabricator>/src/applications/repository/engine/PhabricatorRepositoryPullEngine.php:125]
  #6 PhabricatorRepositoryPullEngine::pullRepositoryWithLock() called at [<phabricator>/src/applications/repository/engine/PhabricatorRepositoryPullEngine.php:40]
  #7 PhabricatorRepositoryPullEngine::pullRepository() called at [<phabricator>/src/applications/repository/management/PhabricatorRepositoryManagementPullWorkflow.php:43]
  #8 PhabricatorRepositoryManagementPullWorkflow::execute(PhutilArgumentParser) called at [<phutil>/src/parser/argument/PhutilArgumentParser.php:410]
  #9 PhutilArgumentParser::parseWorkflowsFull(array) called at [<phutil>/src/parser/argument/PhutilArgumentParser.php:303]
  #10 PhutilArgumentParser::parseWorkflows(array) called at [<phabricator>/scripts/repository/manage_repositories.php:22]

The latest commit on stable fixes the problem for us 👍

I appear to have found a reproduction case for this in the cluster.

I'm deploying this to the cluster now.

In T10936#175435, @rencris wrote:

This specific issue also happens on my computer, which is running Windows 7 SP1 with PHP 5.6.20

I'm using stable versions of libphutil and arcanist as of May 16th.

If I rollback Arcanist to commit rARC737f5c0df976 the problem is gone.

@ivo, if you see this before I post a fix, can you show me the output of this command so I can make sure I'm reproducing exactly the same issue?

This issue describes a narrow issue with typehinting URIs, introduced by T10227.

I'm going to merge this into T11137. They don't describe the same issue, but I'm planning to fix them in the same way.

Reverted commit rP55a698a28a750017e787979a72dd125858997fa5 on our install and repository updates now work again.

sorry, I don't restart the php-fpm, maybe the old process is still running.

In T11126#179873, @eadler wrote:

Silly question but can't we use CSP Level 2's referrer directive (https://www.w3.org/TR/CSP11/#directive-referrer) to avoid leaking information without the need to build full image proxying?
If that doesn't work can we use <iframe seamless referrerpolicy="no-referrer"> ?

ɯɯɯɯɯɥ

hmmmmm

hmmmmm

(And those UIs might also not actually be useful for future-administrators, particularly since I don't really plan to ever help users with third-party stuff, although who knows.)

My intent with a lot of that stuff is to make administration and support (particularly in the future, once third-party applications are more common) easier, so they're targeted primarily at future-administrators who have questions like these, possibly because we've asked them for the information:

Some things in the side bar seem more deleoper related than configuration related. Trying to think where we could possibly move then maybe, like a developer app?

(And we can continue reducing the number of settings, but not very quickly.)

/config/ is already an attempt at chopping it up, vs /config/all/ which is the un-chopped version. If you have a better way of making it less scary there's no need to chop it up in the way it's currently chopped up, though.

Also "Config" is super scary. It might be helpful to chop that up a bit?

Thinking about the "Phacility" NUX case and unsure users really need to explore Config or Applications. Really we just want them to invite some people and pull in their repo. If new to Phabricator... learn about getting Arcanist up and maybe make a few projects. I'm mostly trying to separate things into "must do" and "useful tips". Useful tips can just go into Feed as the first post, like Quick Start guides for individual apps or following us on Twitter.

Comment deleting is to help with accidental information leaks or outright spam. It is not our expectation that users will delete information from Phabricator and warn against it.

It is not too much different from removing comments. And this people are allowed to remove. (BTW I wonder what happens if one removes a comment with a mention)

Audit-ability is a core feature of Phabricator. We're very limited in what we allow people to delete.

But then I unmention it and it's unreflected. This seems to be wrong. Perhaps another record like "Task Y does not mention this task anymore" could be added, but it looks better to just remove the initial record. Or, optionally, it would be sense-full to provide a person who did the mention a possibility to do it manually -- thus some judgement could be applied.

Yeah -- the highlighting code is more flexible about what it matches than the actual search code is, which makes T6740 worse / more confusing.

ah I guess it matched on 'username' elsewhere, it gives the impression that is matched on 'usernames' though since it highlighted it as usernames

"username" doesn't match "usernames" until T6740.

I couldn't find that task, actually. I searched for 'username' and closed, and I just double checked again and it still didn't appear?