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.

I think the 404 is possibly better then "silently fail without error".

Uhm, seems I was somehow off by one line. I thought that this comes from escapeToken($repository->getCallsign()) being optional nowadays but seems to be triggered by escapeToken($repository->getRepositorySlug()) instead which indeed would be surprising. This might be a patch to abandon because might hide an underlying issue.

How can we end up with null here?

Rebase

I also faced this, tested @ D25623, and found out git format-patch was emitting that result which causes git apply to fail. See this git format-patch example.

Yeah, on my todo list for the weekend.

And my spam filter says:

(Premising that this is an answer to your question. Please move this as comment to your question.)

Nice but please smaller :D

Thanks! I was able to test visiting a profile image, and inspecting phlog() in the webserver log.

Thanks. I was able to test that the thing is just a string, not an object with a toString(), so no nuclear implosions

Garrr I am so sure I had tested it this morning but maybe I was sleepwalking? Tested again now and seems to work, thanks

Giving a +1 as I had tested this in D25080#16527 but I would prefer to see the two strings adjusted in D25080#16549

I currently cannot think of other potential side effects (mail notifications about task creation seem to have had a [Created] prefix taking priority over other actions for years, and web notifications in the top bar also still behave as before), so I'll give my +1

(If it does not work you may still need to call .toString() before doing this)

The coffee on my desk doesn't seem to work yet - use a proper comparison.

Use standard JS string concatenation instead of shiny padStart() because better backwards compatibility

In D25630#17685, @valerio.bozzolan wrote:

I think somebody here would propose to avoid padStart() and be boring:

if (d_m.length < 2) {
  d_m = '0' + d_m;
}

For some reasons I cannot cleanly apply the patch anymore.

In T15820#17365, @valerio.bozzolan wrote:

Just because we can, right? Or any real concern?

Just because we can, right? Or any real concern?

✅ Number.prototype.toString() supported by all browser webs https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/Number/toString

This fix was super-interesting. Thanks again for the report.

Thanks again. My only concern is that, if somebody has a 1 trillion file(s) then the patch may lock the involved tables for an unexpected long amount of time, and you cannot really undo, without causing a massive implicit rollback.

The approach taken in D25621 is more wholesome and preferable thus abandoning this

It worked in line 109, it will work in line 154. Tested.

Cover more cases that require login:

Wow you are fast. I was going to create this :D I can reproduce