See T4788#184477 for current plans.

In T4788#185925, @CodeMouse92 wrote:

[...] Still, I think it would be pretty simple to just shut off the task graph (but not the list?) in those situations [...]

I definitely agree that in most cases, 100+ subtasks (especially direct subtasks) is better as a project. Still, I think it would be pretty simple to just shut off the task graph (but not the list?) in those situations if there is an exception that hasn't been thought of.

It might be useful if the dependency resolution was only two-levels deep. That wouldn't really solve the problem for extremely wide trees though.

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.

My test data is pretty sketchy:

got a full screenshot?

Ah, fair enough. Two options it is, then.

I would want to on admin.phacility.com

I poked at it a little bit but only got this far:

We can just replace ui.custom-header with two separate options I guess and put deprecation guidance in the old option.

I'll get you an update month view here this afternoon, I've been mulling it over.

@epriestley I think my rough plan here is:

(And no matter what the policy is, this allows attackers to compromise a support account and then strip MFA from a "better" account, upgrading access.)

In the general case, as with the upstream cluster (T7639) I think the quorum thing in T9515 that @eadler mentions is the most promising way forward to reduce MFA support costs. Briefly, it would work like this:

See also T6549 and T9515

Month view in desktop mode should be flush with box?

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: