In T4788#185851, @chad wrote:

If you have more than 100 subtasks, the task should probably be a project so it can be properly organized.

And what is the intention behind that? None of those requested information are sensitive.

I understand the point, but then, what do you think about "automatically" assign users to a space depending on the autentication they used to login? (i.e. only who autenticated with LDAP will belong to internal users)

I understand the point, but then, what do you think about "automatically" assign users to a space depending on the autentication they used to login? (i.e. only who autenticated with LDAP will belong to internal users)

Upgrade.

It's intentional that you can not see information about tasks you don't have permission to see.

If you have more than 100 subtasks, the task should probably be a project so it can be properly organized.

Also, before that is done, rather than showing "Task graph too large to display ..." message, have fallback to the old plain list of tasks. Therefore the information will still be available, but just simply not provided as fancy...

Re the limiting to hardcoded 100 nodes without any criteria:

https://secure.phabricator.com/book/phabricator/article/spaces/

Hello! What you think about make correct behavior while clicking on inline comment thumbnails? Its hard work? I can try to contribute it?

Hey guys, where should I hook my custom parser if I need to add any additional behaviour on 'CodeReviewed' keyword in commit message due to parsing from repository?
Actually I need to mark commit as audited when commit message contains previously specified string.

The best of the best is of course our https://phabricator.wikimedia.org/T4007 ;-)

In T4788#185751, @bd808 wrote:

The task graph can get a bit out of hand -- https://phabricator.wikimedia.org/T2001

In T4788#184537, @epriestley wrote:

so the UI should still look good given that edge-case.

Understanding the use case is important in choosing how the UI degrades.

Thanks for listening to my hair-brained schemes. Yeah, the motivation is totally clear to me FWIW, and thinking about it more, I strongly suggest this is related to T9161.

Thanks for looking into this further.

Looks like that fix affects Differential, but not Diffusion? After reading through that bug, I can totally reproduce this on demand in Audit
I have a test instance here that reproduces this problem (both actively able to reproduce and has commits in the database that are exhibiting the behavior already): https://test-kdauzhhtarbi.phacility.com/rLIBdde2f74f2793f0216f0d76618ed335a9c802cfec, but I reproduced it reliably on 3 separate instances now.

Calendar needs design work after intervening redesigns, but the views have been responsive for some time.

calendar.event.search is still pretty useless/bare-bones (you don't get very much information back), but we can expand that as use cases arise. We don't have specific needs for this yet.

T8267 briefly discussed the idea of automatically selecting an icon if one isn't provided.

Currently, there's no way to create an event without explicitly selecting an icon, so there's no way to really implement this.

This UI needs some cleanup in all browsers after some intervening redesign, but I don't see anything specifically wrong about it in Firefox at HEAD of master.

I'm just going to close this:

We can revisit this later if use cases develop, but we haven't seen any need for it yet.

This is on EditEngine + Modular Transactions now. There are probably still some remaining issues I didn't catch.

I've marked D16287 as fixing this, although it does not fix Countdown (today, only Calendar has the new behavior).

Sounds similar to T11092, which was recently resolved.

Needs a check for empty and at least a better error message in DiffusionBrowseQueryConduitAPIMethod.php:115

We are seeing this as well when attempting to browse an empty commit: https://phabricator.wikimedia.org/T140236

I'm unable to reproduce on a test install right now, but then again, I stopped reproducing on my install after rebooting the server. It looks like something happens eventually to cause this to break and I start getting these broken comments.
Looks like every time I get a broken one it doesn't have a transaction PHID associated with it and all comments submitted together have the same wrong associated commitPHID.

oh neat!

You can use a free instance at http://phacility.com/ if you need a clean, up to date place to test privately.

This is, by the way, on a brand new install that's not even a month old.
I tried to reproduce it on another install that is older and I'm not having any luck.

This actually is a lot worse than I originally thought.
All inline comments that are made on an audit are actually applied to the audit I was previously commenting on (like an off by 1 error). I've isolated the following things:

• This happens across repositories (i.e. if I have multiple repositories, commenting on one commit and then switching to another repository's commit and commenting on it will produce a comment on the first commit)
• This happens for all users
• This happens regardless of audit status - i.e. commits with audit requested exhibit this as much as commits that don't require audit.
• Submitting an empty comment first thing before adding any content to a commit works around this problem - subsequently added commits appear as expected.
• The broken state can be easily detected by unavailability of the "hover state" of the overall commit field - pressing "z" does nothing

(Presuming that fixed things until we see evidence otherwise.)

I should add that their plans for mid-2016 is to integrate all of this Windows OpenSSH support into the OpenSSH upstream repository, which is likely to be the time that Microsoft declares it production ready.