I mean. See this archived Project (archived Milestone), that is linked from our changelogs:
- Queries
- All Stories
- Search
- Advanced Search
- Transactions
- Transaction Logs
All Stories
Jul 21 2024
Jul 20 2024
For example, some people then may ask "why my default view was changed?" and they will start manually "rollbacking" this to their desired view (e.g. showing closed tasks, from the Workboard, with a filter "Show all tasks").
Premising that I like the implementation but I think it's not the desired solution.
Additional consideration under control: an external class may have extended AphrontTypeaheadTemplateView and defining a renderToken() there, and making this snippet operative (I'm not saying that it's a good practice, I'm saying that it would work). But this extreme corner case is not the case.
Jul 19 2024
I personally don't see value in sharing a stacktrace in this case. YMMV :)
Seems super nice. Minor comment. If we do this, the stack trace is NOT shared:
Strip block
Uhmm, transcripts at http://phorge.localhost/herald/transcript/33065/ never ever render a Herald rule condition (disabled or not) within another rule, it seems
I'd be worried about DB performance running such a query as our DB has dozens of millions of files... (This is basically SELECT COUNT(*) FROM file_attachment fa WHERE fa.filePHID NOT IN (SELECT f.phid FROM file); in my understanding?)
Hmm I guess now my patch title is too narrow as it logs any Herald exceptions? :D
Per Valerio's previous comments
Marking as "probably something different should be done"
In short, requireFieldImplementation seems correct in their legacy version, and something is not ideal in the consumer, that has a try catch. That try-catch should be edited.
Note that every unmanaged exception is logged. So if you don't see a log, something is already managing this.
Unrelated but @aklapper I'm curious about the situation in WMF. If you can maybe report something like this:
Jul 18 2024
I think the behavior of not setting the timezone is probably correct, actually. GetFormattedDateFromParts below already constructs a date object again with the timezone set. So I think the timezone offset is being applied twice here.
Jul 17 2024
Still happens after backing out rP2295bcda14e71948516752f8fbada6601b9f0bde thus not a recent regression.
Jul 16 2024
Jul 15 2024
I guess I just do not enjoy a good number of HTTP 400 errors in our error logs when literally nothing went wrong at all.
The other option would be including "__form__":"1" in that call to avoid the 400.
👍👍
Jul 14 2024
In D25732#20029, @valerio.bozzolan wrote:
- was this improving the situation? rPf4d9d6920bcd: The feed "created this task" should be the first one seems yes, accordingly to your comments
- was this improving the situation? rPf4d9d6920bcd: The feed "created this task" should be the first one seems yes, accordingly to your comments
- was PhabricatorTransactions::TYPE_CREATE needing a nice action name? yes
- Am I confused about newActionStrengthSortVector? Yes. I don't know why it works, but it works. But this deserves further discussion.
Jul 13 2024
Applying the debug patch in P45, output when creating a new task shows that Updated (defined in https://we.phorge.it/source/phorge/browse/master/src/applications/transactions/storage/PhabricatorApplicationTransaction.php;877ac8a873f979f418064eb2f36f1148c9838694$1611-1612) wins over Created (defined in https://we.phorge.it/source/phorge/browse/master/src/applications/maniphest/xaction/ManiphestTaskTitleTransaction.php;877ac8a873f979f418064eb2f36f1148c9838694$24) as ActionName, likely due to rPf4d9d6920bcdcafedd6a05f34c28642589b3c285 :
[0] PHLOG: 'PATE: TransactionType: core:create' at [/var/www/html/phorge/phorge/src/applications/transactions/editor/PhabricatorApplicationTransactionEditor.php:1625] PHLOG: 'PAT: TA Type: core:create' at [/var/www/html/phorge/phorge/src/applications/transactions/storage/PhabricatorApplicationTransaction.php:1601] PHLOG: 'PATE: ActionName: Updated' at [/var/www/html/phorge/phorge/src/applications/transactions/editor/PhabricatorApplicationTransactionEditor.php:1626] PHLOG: 'PATE: ActionStrength: 140' at [/var/www/html/phorge/phorge/src/applications/transactions/editor/PhabricatorApplicationTransactionEditor.php:1627]
Jul 12 2024
OK I'm stupid. I just need to visit the Milestone and create a Workboard.
Seems that nothing internally accessed that method, and probably nothing externally. But we should probably keep that method since it's public. Thanks.
I was still able to generate QR codes, and I verified with alternative application "Barcode Scanner" that the desired URL is read.
Premising that the root problem is that it's difficult to understand if a project is archived just looking at other parts.
Thanks. Feature makes sense and implementation seems good (but I have untested).
Jul 11 2024
I think we're all aligned here...
Jul 10 2024
😆
Eh, the PHP pitfalls that I'll never learn by heart... Thanks! :)
Let's try if ($file !== null && $file !== '') instead of if ($file) then?
The best way is probably to make an Extension: