What version of Phabricator you're running? See Providing Version Information for help figuring it out.

I think it's right to leave the options there, too. Sure, it's two controls, and they don't make much sense to use in certain combinations, but it's totally intuitive (as is the parent/subtask terminology, as opposed to the blocking/blocked terminology).

Other users at my work experience this (i.e. about 40 or so developers run into this on a regular basis). It's an issue which is particularly bad on Windows. I think it's bad because process startup / shutdown is much more expensive on Windows than it is on Linux, which means "git status" runs for a lot longer.

Ran into this today on this install. Seatrched for open/close tasks with term "javascript".
https://secure.phabricator.com/search/query/qi_sDFEgnw9i/#R

I think this was obsoleted by T10003 and EditEngine.

This UI is on life support until Facts (T1562) gets built, and I don't plan to make any upstream changes/improvements.

I think this is possibly undesirable to resolve in the general case, e.g.:

Phabricator's infrastructure has evolved a lot and CustomFields now serve a smaller role than they once did -- roughly, just custom fields. Later generation stuff (particularly EditEngine) feels better factored, and has reduced the responsibility of CustomFields.

When we make a hire we can make them do this "to become more familiar with Phabricator's codebase".

Just as a note: I had this happen again on another very low-power instance (same file storage backend, encryption enabled etc), but with the latest HEAD, simply reloading with Ctrl+R after the webserver timed out the request made it continue and work perfectly. So yes, this is fixed it seems.

I think we pretty much have clarity on stuff this task was tracking:

At HEAD of master, this is now supported. There's no default UI for it, but you can get to it in three ways:

Tentatively, I'm thinking about doing this (some discussion in T4788, too):

I think the commit stuff is working properly already -- the code is a little tangled, but we try to merge revisions into that section if we can, and only render it separately if we need to. That is, we attempt to render:

Yeah I think the need for corporate users to hide things from their enemies is probably outside of our control. Just try to find lots of bugs with it.

I'm a corporate user and I love hiding things :(

Oops -- I assumed that package was someone testing things since every other object that has ever been hidden has been and ran bin/policy unlock without examining it, but it's actually a legitimate package. I think I put it back the way it was.

You're currently the only user we're aware of who experiences this -- have you tried changing your IDE so it, e.g., only polls git while in the foreground?

See also T4788 for some other followup work.

Thanks for being so fast fixing this.

Because of the intermediary join to the edge table I wasn't actually able to get it working without HAVING either, but D16340 should fix the underlying issue here.

Thank you for your attention to this issue!

I believe the best way to construct these queries is like this:

I'm planning to make these changes:

A subproblem here is perhaps that Owners should have a "Can Create Packages" policy.

As a thought, it might be nice if Administrators could pin other items to the menu bar, not just Repositories and Projects. For us, it'd be nice to pin a "Developer Enchiridion" wiki page to the menu bar.

Currently debating if that menu should be available globally (on every page) from a menu item in the header if you're not on home. I don't know how much I'd use it. I sort of explored having it be a single "Favorites" that you could have everywhere and modify anywhere. But it might make more sense to have a simple home sidebar and a separate "favorites" to replace the quick create menu.

(That was my attempt at a different, less eye staring into your soul, logo).

That isn't the logo we're planning to use. We haven't settled on a final logo (we had external designers come up with new ideas). Still testing stuff locally.

(Though I really like the sidebar menu with projects / repositories / create new)

FYI the logo in the design / mock doesn't really look like an eye - it makes me think of a gear not an eye with a gear.

Related to T11344

There isn't a wordmark in the redesign, it will just be a text hyperlink (which you can customize).

For the very little it is worth, my coworkers consistently refer to our instance as Phab, matching the subdomain we gave it, and currently have a mark like

No biggie, although the UI effect is obviously crucial for my org

Whoops, yeah the strikethrough isn't for some reason. Sorry I thought you meant an issue with the graph itself.

For what its worth, the biggest violators at my company tend to be company executives who (sometimes) rightfully wish to skirt our process. But, when they see how trivial it is to skirt our process, they're tempted to do it more often. And then they do it more often.

See T7924 for current Calendar roadmap items.

I'm not exactly sure what this is asking for -- it sounds like you just want a more convenient way to post a comment asking revision authors to "Please re-run the optional tests."?

So CalDAV support (for iCloud and others) is not planned? Google Calendar API is propritary while CalDAV is a standard. There is a really good php implementation of client/server and card parsers: https://github.com/fruux/sabre-dav
@devurandom yes that is true, and it is really simple using save/dav.

I think you're free to fiddle -- there are some more adjustments and things, but nothing too significant. I think the only other really CSS-ish thing is that if you search for events in a specific range (July 5-7) on a calendar view, I'd like to make it clear which days your query covers.

land what you got and I can start fiddling? or did you have more?

This is working as intended.

Project menu?