- User Since
- Feb 21 2012, 9:22 PM (360 w, 4 d)
Nov 20 2018
Jan 8 2018
Dec 7 2017
So this would work in theory, but the problem is that the buildNavigation() method in PhabricatorProfileMenuEngine.php is called twice. The first time, the selection is properly set, but the second time around, it's reset back to the original buggy behavior. Wanted to know if I'm generally in the right direction or if I should pivot before it's too late.
Dec 5 2017
Make ambiguous commit identifier bold in the warning message
Dec 4 2017
- The commit identifier in the warning message isn't bold... should it be?
- The repository/branch in the crumbs isn't a link... should it be? I looked at the crumbs code a bit and I think I'd have to add a new parameter to pass to crumbs so that we can have a link without a branch appended to it.
Conforming to best practices for commit lists
Dec 3 2017
Dec 1 2017
Nov 30 2017
Nov 28 2017
@epriestley what do you think of creating another column in the calendar_eventinvitee table, something like a bool futureStatus so that when we get a list of invitees back, we can check for that flag. I think this would mean a lot of date comparisons (seems inefficient), and I'm not quite sure when to populate event stubs. For example, if the futureStatus flag is set to true for instance 10, and there are stubs for instances 15 and 20, when would 15 and 20 get converted to have the updated status?
Aug 25 2017
Mar 28 2017
Feb 12 2017
Feb 3 2017
Feb 2 2017
Nov 29 2016
Nov 3 2016
May 23 2016
Query for events that were not cancelled instead of filtering out cancelled events later.
This fixed the border on the panel:
but this means that the week panel in day view is going to be max width. Personally, I think it looks okay, but maybe there's a reason not to do this?
Css change to make week preview on day view border better
May 5 2016
This particular change was for testing and doesn't seem right anyways.
Apr 21 2016
Apr 20 2016
A few possible directions:
Yeah, I think the dialog should clarify.
I just think it might not look pretty on standard resolutions (like my Mac)
Alternatively, we can make reinstating a series un-cancel all cancelled instances. That would make some sense to me.
"Cancel All Recurrences" works because it will keep already cancelled instances that way. When you reinstate the series, all the individually cancelled instances won't be un-cancelled, so "Reinstate All Instances" doesn't really cover it. It should be more like "Reinstate All Previously Un-cancelled Instances". How would we put that succinctly?
Apr 15 2016
oops, wrong direction