Oh, I miss-understood the problem statement. The 4096 limit is on the size of the image that we can resize from...

Maybe since "we live in interesting times" we can increase such limit indeed also, but that logic makes some sense (but terrible user experience, I agree lol)

I also thought that, but I think the current limitation (4096 x 4096) is reasonable and was introduced to avoid to scale huge things and mitigate resource exhaustion in thumb generation.

I'd expect it to just resize the image as needed....

Abandoning in favor of T15890 and D25774 per previous discussion

The solution was to take direct children project and call $child->setParentProjectPHID($my_parent_phid).

This was more tricky than expected. Basically we "just" need to call PhabricatorProjectsMembershipIndexEngineExtension method materialize() on the parent.

Finally in my Phorge I can kill these milestones \o/

OK. If you are partially mentioning nonsenses in we.phorge.it itself, you are indeed right.

We might come from different user journeys.
Your users might be aware what the project means, and that the project (and its workboard) is archived, and they do have an initial reason to look at this archived workboard (e.g. default view is not "open tasks" but "all tasks")?
My users clicked an external link to some project tag in something called Phorge, and that project has been archived in the meantime, and that project is set to show the workboard by default, and that is now just empty columns (as the default view of workboards is "open tasks"), and that is confusing and unhelpful.

I mean. See this archived Project (archived Milestone), that is linked from our changelogs:

For example, some people then may ask "why my default view was changed?" and they will start manually "rollbacking" this to their desired view (e.g. showing closed tasks, from the Workboard, with a filter "Show all tasks").

Premising that I like the implementation but I think it's not the desired solution.

OK I'm stupid. I just need to visit the Milestone and create a Workboard.

Premising that the root problem is that it's difficult to understand if a project is archived just looking at other parts.

+lots for removing the words "storage containers" - projects are very much not "storage".
A better metaphor is "labels" or "index" (like in a printed book? Is that something young people know about?).

I'd like to keep this boring:
Projects are hashtags are tags. You can use them for code bases, teams, or anything you need to group.

Probably, the "color change" should be handled as "expanded transaction" - whatever it means - so that it changes only after its related cause (status change to → archived) and not always as long as the current value is archived.

In T15448#9857, @avivey wrote:

In any case, it should be generic - on "search results page", although probably requires each SearchEngine to define the available fields in order to actually support this feature.

Currently, only Commits show anything like "description" (commit hovercard shows the commit message.

Just as clarification do you have any other Hovercard in mind that has a description?

In any case, it should be generic - on "search results page", although probably requires each SearchEngine to define the available fields in order to actually support this feature.

Yep that is my current workaround. Premising I pretty damn like the current export engine in Maniphest. It should not be that impossible to replicate to Projects as well.

You can already "export" to json from the conduit. Maybe "teach conduit search methods to produce csv" would be a better solution.
Alternatively, an external script to convert the resulting json to a csv.

So apparently this is not a problem in the unit test itself but just with T15375

By the way it happened again here :D