In T15583#13304, @avivey wrote:

go for it.

There may already be a feature somewhere to automatically trigger a re-index because the code changed - I'll try to look for one this week.

edit: looks like it's just "add an autopatch" like resources/sql/autopatches/20191028.uriindex.01.rebuild.php. No worries.

This might be a Good Starter Task, I think - you'll need to add a class for the config, and pull the config value in diffusion.

go for it.

I don't love this, but this is a general fix:

Okay, my proposal:

a hack that might work: add a field in the document that's called "typeahead-text" or something, and put both title and callsign into it (and maybe number and short-name as well). Then use that field in the Datasource.
Since this is a full-text field, whatever the user types will fit this field...

Okay, I have tried to wrap my head around the ferret engine. Problem is: the repo callsign is not part of the indexed material. So I would have to construct some query like (just a schema): WHERE ferret-query like '%term%' OR callsign like 'term%' - but that is not possible with the phabricator query engine. The ferret query parts are separatly created and every other where clause is merged with AND. I don't think, there is a clean way out of this. You could make TWO queries: The old one and one with the ferret engine. And then merge the results and remove doubles. But I don't know... just doesn't feel right.

In T15583#13296, @avivey wrote:

I suspect that the code in People is the oldest one - this stuff blames to 2011! and does explicit sql stuff!

rP99c9df96b4ffbf7 (2015) is the big "convert to Full Text Search" commit, but looks like it's not about Ferret (2017?).

I suspect that the code in People is the oldest one - this stuff blames to 2011! and does explicit sql stuff!

I have searched through the code a little bit and there is another system for typeahaed results. It is token based. So, how does it work?

Yeah, that's probably good - that's the query for typeaheads and probably global search, but not for other cases.

There is no ferret involved in my fix. I have already implemented it in our company instance and the devs are loving it. The change is in this line: https://we.phorge.it/source/phorge/browse/master/src/applications/repository/query/PhabricatorRepositoryQuery.php$650

I also don't fully understand the "Phabricator way" to create full text queries still using indexes. That is my main concern.

Yeah, totally reasonable feature request.
Do you think you can implement?
This might involve the Ferret engine (like this thing, or maybe there's a simpler approach for the query (title LIKE %text% in the Query class?).

No interest in this? I can send a diff to differential and be mauled there 🦁

Ran arc unit first

Make code more readable

Accept whatever stuff is passed as $label as long as it's not null, per last comment

IDK - this was code was never explicitly about git am - I think it was about patch, which started in the stone age and predates things like "formal specification".

I will kindly mark this as request changes since unfortunately we have a crash if the $label is an object like PhutilSafeHTML.

In D25359#10790, @valerio.bozzolan wrote:

I noticed that Phorge exports the date in this format:

Date: 2023-08-02 23:23:38 (UTC+2)

While git exports the date in this format:

Thu Jun 29 23:23:28 2023 +0200

Is this known? Should we uniform these?

Thanks again \o/

OK so if I understand correctly:

Lint

Restored the previous selectors, added some code comments to try to explain better why I wrote them this way. I hope this clarifies things. Thanks!

FYI I proposed a partial patch in D25415 which makes the issue more contained at least.

I've invested 8 minutes in this and I'm somehow confused about the possible cause and solution :)

add noreferrer for privacy reasons

Thanks my friend

You are a good minion, thanks bob

I will kindly resign since I'm terrible at frontend :) Others: please help here

For faster review I would like to try to explain better to others why it was necessary to change so many selectors to change the Workboards scrollbar, but I'm not 100% sure about .phui-flank-view-body and the shadow thing.

Can somebody else test this? I need more time, since I have issues with hosted repositories at the moment :(

Thanks! Tested locally. This seems separated from the mentioned regression. Indeed the recurrence ID and the instance ISO seems that must be strings, or NULL, and any other value will cause a violent nuclear implosion as usual, and Phorge somehow likes it.

Interesting. ICS URI import was fixed in 02a4f8b0c8f1279fc but at the cost of breaking ICS file import.

Tested both cases, thanks

I confirm that there is no problem after running git revert 02a4f8b0c8f1279fc0040ad8077942fd8b0d948b.