Also without that comment in 1942. Feel free to omit. It's self-explaining.
- Queries
- All Stories
- Search
- Advanced Search
- Transactions
- Transaction Logs
All Stories
Aug 19 2024
The root cause seems an array(null) here in the base case:
Do what Valerio says :)
Thanks for this prototype but unfortunately this approach has the problem that it's verticalized on Maniphest and it should really not be expanded for Phriction or to any other component that may have a description and may suffer the same thing.
Thanks! While it does not work for all and anything (e.g. top bar search button), it is still an improvement when it comes to consistency between mouseclick and return/enter button, so I approve as I haven't seen any fallout and could not find collisions/interference with other existing functionality. (For the records, there is similar code existing in webroot/rsrc/externals/javelin/core/Event.js calling JX.Stratcom.listen() this way.)
How could existing installation be potentially affected by an added option? (The name should be different, of course, if it includes all users from all projects, for example, "Members of linked projects" vs "Project members".)
Do what avivey analyzed (thanks!) and wrote in D25743#20738
@arp: Sure, changing underlying semantics can solve some problems (and create new ones for existing installations). :)
Both proposals would solve the problem. Proposal A is more general, so it would cover more ground but also require more manual configuration.
@aklapper it would totally work if every linked project's users would get access.
In T15914#19057, @aklapper wrote:Ctrl-clicking on the button opens the form in a new tab
@BlankEclair: Hmm, at least for the magnifier search button in the top bar search field that doesn't seem the case for me (Firefox, Linux). Do I misunderstand?
Edit: Ah, yes, it works with the "Search" button at the bottom of maniphest/query/advanced/, I see.
Aug 18 2024
Ctrl-clicking on the button opens the form in a new tab
Hard to tell if it checks all and anything that could ever be tested (ICS files can be a looot of phun), on the other hand I cannot come up with any downsides of merging this either as it could always be expanded or adjusted and it passes currently for me, so I'll accept.
Fix a bug, grow another bug 🌈 https://t.me/phabricator/889
Updating D25790: Make table of contents visible when using wide screens
Aug 17 2024
The solution was to take direct children project and call $child->setParentProjectPHID($my_parent_phid).
This was more tricky than expected. Basically we "just" need to call PhabricatorProjectsMembershipIndexEngineExtension method materialize() on the parent.
Finally in my Phorge I can kill these milestones \o/
Thanks. Maybe it happens only to me but if my content is very short I see an UX regression
After only 30 hours of work. Wow. asd
Aug 16 2024
Fix some ambiguous URIs to Phorge commits/tasks; remove two empty lines
Aug 15 2024
Any patch is welcome :)
Thanks. Tested and it works! no regressions.
Is there any plans for this?
Aug 14 2024
Exactly. Like I said probably you will find interesting things debugging $old_text. I guess it's empty. That's probably our root cause. What do you think about?
Maybe interesting, there is this different non-deprecated API:
I mean, it should do exactly that,
Double-slam accept
Do as Valerio said. Tested before and after, two errors less in PHPStan output.
I saw that in my searching but I just end up with Argument 1 passed to PhabricatorCustomField::getObjectField() must implement interface PhabricatorCustomFieldInterface whenever I try to use it, perhaps because I'm unsure what to actually pass it as the $object other than $this, though I second-guess my second-guessing because ManifestCustomField, which I'm extending, does seem to have the interface the error is claiming I'm missing?
In your opinion, why is the current code not working? I mean, it should do exactly that, checking the text before, and the text after, so, to only mention newly-introduced mentions.
Eh, there is a trade-off: Editing the description of an existing task to add a @mention will not add this newly mentioned user as a task subscriber anymore.
Sorry for the delay with this. I've moved the null check as suggested.
Move null check to earlier in function