I agree, badges seems like the right way to go. They are an underutilized feature really, IMO.

I've looked down some of the links of this request, and it looks like the definition of "new user" should be install-specific, and open to interpretation.

there is a presentation from eric brechner, who was in microsofts xbox development, about kanban. he does it on whiteboard, extremely sinple:
https://www.youtube.com/watch?v=CD0y-aU1sXo

I don't see the point in having this feature. What is it for?

Should this be configurable and behind a feature flag, as some Phorge installations may not want this (plus may slow down performance a little bit)?

I think a dedicated policy for "Can send messages" would be better, to cover more cases. It would be strange that all participants must also be allowed to edit all settings.

Ah! Indeed it would be lovely

Note: the <ins> tag is typically rendered as underlined text, so this would be very similar to the <u> formatting that is produced with __foobar__ → foobar. In fact, it might be worth repurposing that rule to produce <ins> instead, since ~~foobar~~ actually creates a semantic <del> tag rather than the presentational equivalent <s> (strikethrough) tag.

Ugh. I added this to the UX project but forgot to remove the test content from the comment box, so my changes ended up coupled with a comment that said "- List Item". I tried to delete the comment but now it looks weird like some sort of redacted content :( anway, though I'd leave the note here in case anyone is confused with the deleted comment.

This is now resolved.

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.

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?).

• Automatically continued bulleted list upon new line

clicking such a link w/javascript disabled will do nothing. Changing it to #123 and no JS will do something....

Implicitly, Phorge generally works fine for browsers where Javascript is completely disabled.

4. Why these nice URLs are set in these links, if nobody visit them?

Less priority of course, since this Task I authored is super-stupid

OK I've done my best :D I admit it helped me psychologically.

If this is a feature request, then add all the things needed for a feature request - as in, "why would this feature be needed" and "what problem you're trying to solve".

Is this a bug or a feature request?

Should this be documented here? I think yes

@aklapper can you please re-write this ticket with the information required from a feature request?

For completeness - Landing revisions from the UI Since they wouldn't be able to land from git? - Would have to be enabled in the UI

I've added both links to the preamble for easy discovery.

Good content but unfortunately undiscoverable if not linked from a form preamble

• Feature request: https://we.phorge.it/book/contrib/article/feature_requests/
• Bug report: https://we.phorge.it/book/contrib/article/bug_reports/

For completeness, my arguments against this:

Please describe the thing using 3 backticks like in this comment (see raw remarkup)

In T15491#10740, @speck wrote:

Just clarifying - this is for specifying the initial default value for the Default Branch field that can currently be edited after creation?

In T15491#10740, @speck wrote:

Just clarifying - this is for specifying the initial default value for the Default Branch field that can currently be edited after creation?

Just clarifying - this is for specifying the initial default value for the Default Branch field that can currently be edited after creation?

I think updating the user script is a good idea if this functionality is needed.

Then let's decline this ticket to reflect the status.

(I'm against this, but I don't have the time to go into details right now. I suggest a CLI tool (like ./bin/user) to expose this information).

Yep indeed. I just mentioned MediaWiki to talk about a similar situation, where being a "sysop" does not necessarily mean being a sysadmin with CLI / root access.

The sysop sees the email addresses of recipients already anyway by running an SQL query in the database if they operate the system anyway.
Running SQL queries is what I've been doing so far and it's cumbersome. Thus my request to allow this on an API level.
(I don't mind how MediaWiki behaves as that software covers different use cases.)

On this I think it does more or less the same as MediaWiki: the sysop does not see the emails of participants, not even via API.