I think that, after the hidden comment is loaded in its bulk, "some more comments" are loaded as context for the hidden comment 🤔 So I guess that extra loading is probably a feature and not a bug.

The email body says Herald added a comment.
The email subject line header says [Changed Project Column] (not [Commented On]).
So I wouldn't say it is incorrectly attributed.
AFAIK there are no Herald rules which trigger a separate email notification on its own (but I agree that the described behavior also has confused me in the past) as Herald rules are always triggered by some other previous action.

Uh! Out of curiosity, what does the notification look like in your web notifications?

The hacky solution would be to duplicate the current diff block, and then hide the green text on one side and the red text on the other side.

Agree. But the best I can do is... adding a slider that, the more you scroll it, the more it hides the red text/green text... LOL

Thanks again. Let's see if we receive some feedback from users in master branch

Maybe interesting, there is this different non-deprecated API:

I'm not skilled enough to look into the bigger picture, however maybe the Edit Column dialog could have a third field apart from Name and Point Limit to also have Task Limit (or Card Limit?). Point Limit and Task Limit then must be mutually exclusive (do not allow to set both for a column, or even...board?), somehow.

Five months later it seems that we survived. Anything left to do?

I haven't looked at Phorge's internals much yet, but perhaps the user could unmark a task as duplicate, or have the "Close As Duplicate" box be prefilled with the task that closed it and let the user deselect that and choose another one?

Once we remove this, we'll need to handle this edge-case:

• I've closed a ticket as "duplicate of T1", but I was wrong and want to mark it as "duplicate of T2" instead (and say it's not a dup of T1).

On a more meta level, Maniphest isn't well-suited to be an entry-form to be filled by a non-expert user; Nuance is/was intended for this use-case.

on the technical level, Herald can't block object creation - it runs after the fact, by the Daemons.

I don't believe in playing whack-a-mole on "could this be a password" but a use case I've been recently thinking of is "Do not allow task creation when task content/data is exactly the defaults provided by the Form used to create the task". Basically: You were supposed to fill in some stuff but you did not when creating your task.

Yeah sorry. That exception also occurred to me, before this change: https://we.phorge.it/transactions/detail/PHID-XACT-TASK-tuchgj42nb2ujtc/

I could not even reproduce but get an informative error instead:

Thanks avivey. Added this:

Look into the "is creation xaction" - we had a similar diff recently about creating Revision from raw diff that had a similar behavior.

In T15719#15304, @Tgr wrote:

Given how it's displayed on the Gmail UI, IMO unsubscribing from all emails or at least all emails of the given type (e.g. all Maniphest emails if it's a Maniphest notification) is the only thing that makes sense. If I mark an email as spam, and then use the unsubscribe option instead, I would not expect to continue getting identical email from all the other tasks.
No idea how (or if) other email clients handle the header, though.

In T15719#15280, @avivey wrote:

I'm left wondering when a "list-unsubscribe" header is appropriate - looks like anything that would need it will also need the one-click?

In T15719#15280, @avivey wrote:

This suggests to me that there isn't a third category - everything is either promotional or transactional.

I'd argue that none of our emails are "marketing" or "promotional" (or "commercial"), even if it's hard to claim they are "transactional".
But as long as 98%[1] of the users agree that our mails aren't commercial, we don't need the one-click solution.

Do all messages require one-click unsubscribe?
No. One-click unsubscribe is required only for marketing and promotional messages. Transactional messages are excluded from this requirement. ...

In T15719#15272, @avivey wrote:

1. Would adding List-Unsubscribe: https://we.phorge.it/settings/panel/emailpreferences/ header be enough to solve this?

In T15719#15276, @Dzahn wrote:

@phab1004:/srv/phab/phabricator/bin# ./mail volume

Killed

In T15719#15272, @avivey wrote:

using bin/mail volume, to see if they need to worry about this. It just collects all mails created in the last N days and counts them by user.

This is promising, from the Email sender guidelines FAQ:

Re: 1), the doc makes it sound like not, but I'm not entirely sure.

1. Would adding List-Unsubscribe: https://we.phorge.it/settings/panel/emailpreferences/ header be enough to solve this?

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

Obviously, any fixes should be in ManiphestTransactionEditor and not spill into generic parent PhabricatorApplicationTransactionEditor.

Historical references: rP69eab4196de462e42b07b60e2b52071631f4a3c8 and rP4041a7e0f66406dbaa31faa3807d50833b7c7efd (which didn't help much).

Partially related to

Here is the homepage feed after I created this task. Nothing indicates that there was a task creation, just a triage:

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?

Why would it need to be a that?
Is this a bug or a feature request?

OK this was easy, but it really cannot be improved more than this in Legalpad or Phame. And this deserves a dedicated fix.

Increasing priority to normal since this feature is supposed to help to collaborate with others, but at the moment you only collaborate with yourself as default

I'm quite sure we have to set PhabricatorApplicationTransaction.php::setIgnoreOnNoEffect(bool) somewhere but I don't know where ihih