- User Since
- Nov 28 2011, 9:35 AM (425 w, 5 d)
Sun, Jan 5
Nov 11 2019
Oct 8 2019
Sep 10 2019
Aug 13 2019
Aug 1 2019
Jul 12 2019
Jul 11 2019
@epriestley: Try removing a comment, it throws an exception
Apparently commits don't support CAN_INTERACT capability?
Could this be related to the custom footer markup? The code in question hasn't changed in a long time but I suspect maybe it's related to changes in the remarkup rendering code that's adding metadata where it didn't previously?
I toggled developer mode on for a moment and managed to get a stack trace:
Jul 3 2019
Jun 21 2019
I've been wishing for this literally forever. If I could award more mountains of wealth tokens, I most certainly would!
Apr 19 2019
Mar 26 2019
Mar 13 2019
Mar 9 2019
I wholeheartedly agree that all that proxy field mess needs to go away. With that gone the only moderately confusing part remaining would be the way in which custom fields interact with herald, email and notifications.
Feb 28 2019
Making a way to set fields to default: disabled would make this feature even better ;)
Feb 26 2019
Feb 25 2019
FWIW I appreciate and use the mute feature (though only occasionally)
Feb 23 2019
Feb 22 2019
This change broke the search dialog on tags typeaheads...
Feb 11 2019
This would be incredibly useful for the things we are trying to do at WMF. I've gone so far as to duplicate lots of forms for each subtype and remove fields as needed. This results in N * N forms and it's not at all manageable beyond a very small number of sub-types.
Jan 9 2019
Dec 16 2018
Dec 11 2018
Nov 8 2018
Nov 2 2018
Awesome, thanks @epriestley!
Oct 31 2018
Oct 29 2018
@dlgiang: if you go to maniphest and choose any of the existing saved queries, you will find the ID in the resulting url.
Oct 4 2018
Oct 1 2018
It seems to be a fairly recent problem so there must be some code change that started triggering it. The worst part, IMO, is that the workboard breaks in a not-entirely-obvious way instead of falling back to a default query. It took me a while to debug the issue the first time it occurred.
Could it be that a user assigns it to one of their "personal" custom queries and then later they delete that query by way of the maniphest saved query ui?
I'm not sure what's caused this either but I've seen it twice on wikimedia's production install.
Sep 20 2018
@epriestley: I can help with testing and validating on elasticsearch, if that helps at all.
@epriestley: I'm thinking about changing this to make it look more like your example (quoted below) as I think that would make custom fields and subtypes quite a lot more useful. Is this something that you would consider merging in the upstream?
Aug 16 2018
Aug 15 2018
Jul 2 2018
Jun 28 2018
Can't wait for "connect 2" to come out on playstation six.
Jun 18 2018
Jun 12 2018
Mar 17 2018
Jan 6 2018
Dec 24 2017
@epriestley: Thanks! Hope you're having a great holiday weekend :)
Dec 23 2017
Dec 22 2017
D18836 probably isn't the right solution, however, it's the only straightforward fix I could come up with. I didn't dig into the details of why it 404s when I fix the code in PhabricatorProjectViewController to avoid the fatal. The patch is probably good enough for Wikimedia, however, I'm not sure if it's good enough for upstream.
Another approach that might make sense would be to highlight the hash and then show a hovercard which lists the commits with that hash. Of course this wouldn't scale too far but it should handle the case where 2 or 3 commits have the same hash.
I tried to work around the immediate fatal by checking the return value of $engine->getDefaultItem() in PhabricatorProjectViewController, however, that resulted in hitting a 404 so it's a bit deeper of an issue. Perhaps the right solution is to prevent users from disabling both of the default items in the project "manage menu" UI?
Dec 13 2017
Nov 29 2017
Nov 14 2017
@epriestley: Sweet, thanks! landing...
Oct 9 2017
Sep 26 2017
@epriestley I have no problem patching it locally (already have) it just seemed like an obvious thing to show on the differential screen. If it's not wanted upstream then it's no sweat off my back :)
Sep 23 2017
Sep 22 2017
Sep 6 2017
Sep 1 2017
FWIW we ran into this problem at wikimedia. In fact, I think it was the thing that killed innodb enough times to motivate us to move to elasticsearch. Elastic handles whatever you throw at it.
Aug 30 2017
Whoops this is probably my bad :-/
Aug 10 2017
Jul 18 2017
For phabricator.wikimedia.org, we decided to go with elasticsearch, partially because we already have a massive elasticsearch cluster and a lot of institutional elasticsearch knowledge / experience. My opinion is that we made the right choice. I believe this opinion is shared by most of the folks who use our phabricator on a daily basis. I've seen zero complaints about search since we made the switch, which is a huge improvement from what I saw with mysql FTS. Conclusion: Elasticsearch seems to perform well and the results are generally better (obviously this is subjective, but like I said, no complaints from users)
looks good to me and confirmed to work by testing locally on my test instance running upstream master branch.
Jul 13 2017
I've seen complaints about this on phabricator.wikimedia.org as well, so I can confirm that this is an issue.
Jun 27 2017
doh! nice. I obviously need more coffee.
I know just maintaining the hooks is more work but certainly less than what's involved in maintaining the graph code.
Maybe provide some extension hook-points in diffusion so that the community can maintain the commit graph visualization as an extension?
Jun 20 2017
Jun 18 2017
Jun 16 2017
That does sound powerful. +1