In the general case:

Getting Datetime has no timezone or viewer timezone when viewing the main calendar.(https://gist.github.com/carlokok/570d524fe2a6dd1472835c0fa67b7faf) after import. Since the import contains a quite a bit of private data, how can I narrow down which record specifically it fails on?

@epriestley Thanks, that's fixed it! I'd not looked index engines at all before, so wasn't sure if I was just missing something stupid on that side.

PHP 7.1.0 has been released yesterday, and among the changes;

Absolutely makes sense - provided some more background on the problem. Looking forward to hearing your thoughts.

Basically, if this request is just a suggestion, we'll probably pass on accepting it (see Hypotheticals). But if people are frequently having issues (we haven't seen this) please give us more details on the workflow, etc, people are tripping up on. I don't think just adding the word "Git" somewhere will necessarily solve any core problem since people are not likely to read, for instance.

Ok, appreciate the feedback - I'll try to tackle it in a bit more detail.

We only take feature requests that state root problems, see Contributing Feature Requests and Describing Root Problems.

I'm pretty sure this this was just a straightforward fix that escaped detection for this long because any other repository edit would rebuild the index. D16972 rebuilds the index on any repository URI edit. Let us know if you're seeing issues after that. Thanks for the report!

From what I understand it's something Google is working on. I've been dealing with the limitations myself for a while and it sucks, but hopefully it'll be fixed on their end sooner rather than later.

We aren't interested in introducing complexity into Phabricator to work around limitations in GCloud SQL at this time. Instead, you should ask Google to fix this limitation with their service.

Does making any other edit to the repository (e.g., changing the description) correct the issue?

Specifically I'm looking at GCloud SQL, which does not yet allow you to use config options that require system-level changes. You can still use a dedicated SQL GCE instance, but using the managed SQL itself isn't yet possible without running into errors about the sql_mode.

As far as I can tell, Amazon RDS allows configuration of sql_mode. Here's their announcement of support (from May 2016):

I'm in the same situation. This would be a great addition.

OK, this is interesting: having tried reproducing it on a test Phacility instance, it works as expected there. Perhaps one difference is that my local installations don't have Diffusion serving repositories itself over, e.g., SSH? These repositories do not have any URIs other than a remote Git URI which Diffusion is observing.

See also T7787 for plans to support existing !cc stuff from arc on the CLI.

(This doesn't really follow the rules as a feature request because it's just 35 copies of "other systems implement it so you should too", but I think it's something we would probably implement anyway sooner or later so I'm fine with keeping it open.)

Presuming this was resolved by D16967, let me know if there was more to be done.

It makes sense in retrospect, but not from the workflow no.

Thank you! I'll do that and report back.

Try putting MaxStartups 1024 in your /etc/ssh/sshd_config (or similar).

My management would like to flag Commits for Audit if they either don't have an accepted Revision (already have this setup in Herald) OR they have failed Harbormaster Builds. We're not terribly interested in notifications/emails for this. This use case seems a bit different than others discussed above.

@csilvers, not sure if you got directed here from IRC. See also T11932. At HEAD, we'll now issue more explicit guidance about the required index rebuild.

Hmm, I'm guessing this wasn't clear from the workflow either, then?

My apologies. I read over that bit and presumed it meant edit the calendar items

Why did you allow everyone everyone edit the event?

In T11816#202107, @epriestley wrote:

Everyone can see from which url a calendar event came.

This isn't expected. Can you give me reproduction steps for this?

Everyone can see from which url a calendar event came.

Please read Contributing Feature Requests carefully before filing a feature request.

My only concern with the current ics importing is that the url for importing from google, owncloud/nextcloud usually contains secrets other users shouldn't see, like in the case of owncloud: un/pw. Everyone can see from which url a calendar event came.

did anyone fix this issue?

Same problem here. A way around this problem is to not re-use panels: Creating a completely new panel is adding it only once, however picking an existing panel is adding it twice.

Separately I managed to grab this output from top at an impacted time, but this looks to be a different issue now since the CPU time is being reported against the taskmasters themselves:

That didn't seem to be the case. It might have been because we only enforced Google authentication around one year ago, before that users could use a password for authentication. I can check later today, but perhaps the users that ended up with duplicate accounts never setup Google Auth.

If the only way to register is Google, it should be impossible to create more than one account per Google account.

Why is registration disabled?

To provide some additional context, we originally allowed users to register their own accounts, but we eventually disabled this because we ended up with around 30 duplicate accounts (users with more than one account). I think that this happened because users had listed an alias address in their Phabricator settings, but Google was using a canonical email address to authenticate, which didn't map to any existing user accounts (we have a lot of users that have aliases set up. For example, abraham@mycompany.com would be an alias for the canonical alincoln@mycompany.com address).

This one is fine, I'm still going to fiddle with "in" too.

In T8510#200946, @aklapper wrote:

In https://phabricator.wikimedia.org/T76732#2803813 ksmith brings up that

In the search bar in the toolbar at the top of the screen, searching for "Maps" brings up Maps as the third option. Searching for "Discovery" brings up Discovery as the second option.
When editing a task and entering tags, autocomplete does bring up Maps and Discovery as the first items.

but that could be a separate (unprioritized) task I guess.

I know this is more than a year old but...

(Also, I can't reproduce this.)

Generally there shouldn't bee a "New <object>" on edit object pages. I think this goes away with EditEngine.