Remove variable definition now unneeded outside of the if clause

Here's a revision which does not throw a red box via ->setFormErrors() at the user but at least it is displaying the Required text and turning it into bold red after clicking Award without having defined a recipient. So the line $errors[] = pht('Badge name is required.'); is currently never ever shown.

Thanks for the hints how to improve this! Appreciated.

Damn celerity. Thanks.

Damn celerity

That was a merged JS change so I should have also run ./bin/celerity map. Sorry. Followup patch in https://we.phorge.it/D25637

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.