Damn celerity. Thanks.
- Queries
- All Stories
- Search
- Advanced Search
- Transactions
- Transaction Logs
All Stories
May 13 2024
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
May 12 2024
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?
May 11 2024
Rebase
X-Spam-known-sender: no X-Spam-sender-reputation: 500 (none) X-Spam-score: 0.8 X-Spam-hits: BAYES_50 0.8, ME_SENDERREP_NEUTRAL 0.001, RCVD_IN_VALIDITY_CERTIFIED_BLOCKED 0.001, RCVD_IN_VALIDITY_RPBL_BLOCKED 0.001, SPF_HELO_PASS -0.001, SPF_PASS -0.001, LANGUAGES en, BAYES_USED user, SA_VERSION 3.4.6 X-Spam-source: IP='198.74.57.92', Host='secure.phorge.dev', Country='US', FromHeader='dev', MailFrom='dev' X-Spam-charsets: plain='utf-8'
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.
May 10 2024
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
May 9 2024
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