• rebase again

Double slam-sgtm

./bin/celerity/map

Remove newNoMenuItemsView() instead

https://secure.phabricator.com/T13105 is the relevant historical meta-task, I didn't find a matching one here.

add little cute comment and newline, to make it clear that the comment belongs only to that line, and really nothing else lol

Makes sense looking at

I find the current iteration too difficult to read, although that may be partially caused by the mutual language barrier.

It works on my computer. Thaaaanks \o/

A comment in two parts:
First and most relevant to this task: It certainly would be nice to get some of this into documentation! It took me quite awhile to figure this out when doing my own extension development.

Took some fiddling with VS2022 to find exactly what I needed to install, but worked like a charm afterwards.

the vsts has a good workboard experience for this feature, it supply the mapping setting for the board relationship.

Uhm, right. A quick fix would be removing the margin-left: 300px; CSS rule for div.phui-document-content-outer.

Decreasing priority since this happens only if you have not any posts.

(Sorry @mturdus I didn't want to assign this to you. It was automatically assigned by sub-task.)

It works on my computer \o/ thanks

fix PhabricatorPeopleProfilePictureController and PhabricatorProjectEditPictureController,
thanks to generic "transform" stuff from PhabricatorFileTransform

Hoping to be useful I will amend to fix 2 new errors caused by my suggestion.

Ouch the non-static method raised an error. I'm investigating a possible fix to keep this non-static approach in the next 20 minutes

Do not use consts but keep the two pixel values defined in getMaxTransformDimensions(), make function non-static

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....

Still untested but seems nice thanks <3

Yes, I got the idea. It's a feasible workaround.

Yep, maybe the "Dummy project" can be a "personal project", that is, just a workboard with your name, like this:

In D25862#23134, @aklapper wrote:

@Cigaryno: What is your motivation behind and which actual problem are you trying to solve by this? For example, there are now 4 out of ~25000 patches tagged with Projects if I was about to search for patches tagged with Projects. I can imagine tags to be partially useful on Maniphest tasks and I fail to see the advantage for Differential patches so far.

@Cigaryno: What is your motivation behind and which actual problem are you trying to solve by this? For example, there are now 4 out of ~25000 patches tagged with Projects if I was about to search for patches tagged with Projects. I can imagine tags to be partially useful on Maniphest tasks and I fail to see the advantage for Differential patches so far.

@akplapper just to ask, is adding tags to revs pointless or this isn't the right revision for adding tags to?

@Cigaryno: Could you please not add project tags to patches? You seem to be the only person doing this lately, and it creates notifications that others need to read. Thanks.

• mb_chr(215) because arc lint dislikes funky ×
• const MAX_TRANSFORM_* because arc lint does not like private const, so maybe PhabricatorFileImageTransform::getMaxTransformDimensions() is overengineering as I could also access the two consts directly instead
• Cannot private const int because that requires PHP 8.3 (type safety haha)