more
- Queries
- All Stories
- Search
- Advanced Search
- Transactions
- Transaction Logs
All Stories
Today
Yesterday
What could go wrong
I'm happy because when a coworker creates a new sub-project "Nonsense Sub", now you can just destroy it (the project, not the coworker lol) and everything is rollbacked as before successfully.
Added a "Limitations" section to clarify what this patch is not about, and clarifying why direct Milestones must be removed (so you don't need to read all the subtasks)
After applying this patch, phpstan throws a bunch of additional output here, like Class PhabricatorAuthPasswordQuery extends generic class PhabricatorCursorPagedPolicyAwareQuery but does not specify its types: R and such. Probably that is totally fine. Just saying, as a phpstan newbie.
If somebody can share the resulting query, to compare it A/B, that would be super
Put minus icon back in
Pasting full unit test output here before garbage collection kicks in:
Assertion failed, expected values to be equal (at PhutilSearchQueryCompilerTestCase.php:303): Function compilation of query: cat title:="Meow Meow" Expected vs Actual Output Diff --- Old Value +++ New Value @@ -1,18 +1 @@ -Array -( - [0] => Array - ( - [0] => - [1] => and - [2] => cat - ) - - [1] => Array - ( - [0] => title - [1] => exact - [2] => Meow Meow - ) - -) - +false
- Go to http://phorge.localhost/search/query/advanced/
- In the Query field enter z a a "a phrase" a a a a ~a -b =foo title:u which includes duplicate values
- Click Search button
I think the description of this task should be "It's too much difficult to understand what that red thing is about" or something similar
I very much like the new tip,
Don't output "1 Terms" but "x Term(s)"
It seems that Diviner still runs. Well done both for double-checking.
(about my last phrase I just mean we can have everywhere protected function runWorkflow() and we can avoid to introduce the argument - so for example we could rollback the file PhageExecWorkflow.php 🤯 🤯 🤯 lol )
(You are soo fast woow)
Mon, Jun 2
In D26037#27779, @aklapper wrote:Yes to the idea however a related elephant in the room (IMHO) are those non-standard types like list or map or wild being replaced, no clue if that has any effects on...something™ (Diviner docs? Code?) as I haven't managed to understand the consequences of code in https://we.phorge.it/source/arcanist/browse/master/src/parser/PhutilTypeSpec.php yet. (Technically speaking map and list seem to be just arrays, indeed.)
Yeah, I've been wanting to put up a codemod diffs that get rid of all the custom types: wild, dict, dictionary, map, etc. None of these are understood by modern phpdoc tooling and while we could configure phpstan to understand them, it's probably easiest to just use whatever everyone else is using, especially because some editor extensions don't have a way to add custom types so we'd be leaving potential contributors at a disadvantage if they don't have phpstan.
Update signature to protected and add missing argument everywhere.
In D26040#27816, @aklapper wrote:Running phpstan analyse, [...] Method ArcanistWorkflow::runWorkflow() invoked with 1 parameter, 0 required, both in src/workflow/ArcanistWorkflow.php:227. That looks like an improvement indeed.
In D26040#27819, @valerio.bozzolan wrote:In D26040#27816, @aklapper wrote:Keeping it protected will throw Protected method PhageExecWorkflow::runWorkflow() overriding public method ArcanistWorkflow::runWorkflow() should also be public.
Exactly what I mean: this patch introduced a public method, but what about just introducing a protected method? and rollback src/phage/workflow/PhageExecWorkflow.php
Hi and welcome, thanks for bringing this up! I guess you could Edit Question and change the View Policy of this Ponder Question to either "Trusted Contributors", or something more restrictive via the "Custom Policy" option, like administrators and subscribers, or such.
Hi and welcome, thanks for bringing this up! I guess you could Edit Question and change the View Policy of this Ponder Question to either "Trusted Contributors", or something more restrictive via the "Custom Policy" option, like administrators and subscribers, or such.
Looks like https://we.phorge.it/source/phorge/browse/master/src/infrastructure/query/policy/PhabricatorCursorPagedPolicyAwareQuery.php$2118-2125 and https://we.phorge.it/source/phorge/browse/master/src/infrastructure/query/policy/PhabricatorCursorPagedPolicyAwareQuery.php$2499-2506 already do this silently but only for JOIN clauses.
Hi, please explain specifically what "support for large monitors" means to you.
Large monitors are "supported" as all the content on a Phorge page is correctly displayed, layouted, readable on large monitors, as your screenshot proves. :)
Hi!
I agree that this is not a problem and it does not prevent me from explicitly using the features of the service, but for convenience, it would be good if there was support for large monitors.
Yes, it is possible to use a browser that does not cover the entire width of the monitor, but this is not very convenient for me personally, since other sites support such a diagonal of the monitor, which allows me to better read and write texts, code, and so on.
If you think that it is not worth adding support for such a diagonal, then I agree, since so far few people use such large diagonals. Personally, it wouldn't hurt for me to use phorge on my server.
Hi, could you please describe actual problems due to the current layout? Free space is not an issue per-se, for example limiting the content width makes sense.
I'm also a bit wondering why you would put/use the browser full screen when having such a ratio?
Sun, Jun 1
diff --git a/src/view/phui/PHUIObjectBoxView.php b/src/view/phui/PHUIObjectBoxView.php index dce9d57568..13a0a3d061 100644 --- a/src/view/phui/PHUIObjectBoxView.php +++ b/src/view/phui/PHUIObjectBoxView.php @@ -318,6 +318,10 @@ final class PHUIObjectBoxView extends AphrontTagView { $lists, $this->table, $pager, + // When the anchor link scrolled us below the $showhide search parameters + // box, repeat the error message hidden and unseen at the top of the page + ($this->showHideOpen == true ? $this->formErrors : null), $this->renderChildren(), );
^ This would simply be ugly repeating of the error message below the search params box on http://phorge.localhost/maniphest/query/advanced/.
For testing the patch behavior with a results list, replace the line
($this->showHideOpen == true ? $this->formErrors : null),
with
($this->showHideOpen == true ? $header : null),