Page MenuHomePhorge

Paste previous milestone's description text when creating a new milestone
Needs RevisionPublic

Authored by aklapper on Feb 5 2025, 12:16.
Tags
None
Referenced Files
F3801325: D25864.1745947463.diff
Mon, Apr 28, 17:24
F3720587: D25864.1745714673.diff
Sat, Apr 26, 00:44
F3712099: D25864.1745671741.diff
Fri, Apr 25, 12:49
F3701964: D25864.1745612021.diff
Thu, Apr 24, 20:13
F3675510: D25864.1745513050.diff
Wed, Apr 23, 16:44
F3657306: D25864.1745439182.diff
Tue, Apr 22, 20:13
F3648780: D25864.1745433058.diff
Tue, Apr 22, 18:30
F3621936: D25864.1745316442.diff
Mon, Apr 21, 10:07

Details

Summary

In the Milestone creation form, by default paste the description text of the previous milestone, and add instructions to review and edit that text.
This increases consistency of descriptions across milestones by streamlining workflows a bit.

Closes T15991

Test Plan
  • Select "Create Next Milestone" in a project which already has a previous milestone with Description text set: See additional instructions above the Description field, plus the Description text from the previous milestone pre-filled in the Description field.
  • Select "Create Next Milestone" in a project which already has a previous milestone with no Description text: Code not triggered.
  • Create a milestone in a project which has no milestones yet: Code not triggered.
  • Create a subproject in a project which has no subprojects yet: Code not triggered.
  • Create a subproject in a project which has a previous subproject: Code not triggered.

Diff Detail

Repository
rP Phorge
Branch
T15991 (branched from master)
Lint
Lint Passed
Unit
Tests Passed
Build Status
Buildable 1772
Build 1772: arc lint + arc unit

Event Timeline

aklapper requested review of this revision.Feb 5 2025, 12:16
aklapper retitled this revision from Allow pasting previous milestone's description when creating a new milestone to Allow copying previous milestone's description when creating a new milestone.Feb 5 2025, 13:45

Uh. Nice.

Question: in an ideal world would you love even more the same button, that "just" prefills the textarea? That could be also probably done server-side, without JavaScript. That would help T15991 even more I think.

If you say "uhm yes" maybe we can keep this patch stalled (and find some time to understand how to put some more object-oriented in PhabricatorEditEngine), and play a bit in another patch. So, if we are capable of the different thing, good, if not, we continue this, so at least you have something in WMF. What do you think about?

Question: in an ideal world would you love even more the same button, that "just" prefills the textarea?

Yes. One manual action less which needs to be done anyway.

That could be also probably done server-side, without JavaScript.

Very very likely. But I'm too stupid to find out how, so far.

If you say "uhm yes" maybe we can keep this patch stalled (and find some time to understand how to put some more object-oriented in PhabricatorEditEngine), and play a bit in another patch.

"Whatever makes me feel like there is some progress into the right direction", as I would probably reply to my manager at work. :P

Directly put the text of the previous milestone into the description field and display additional info about this new behavior. Less code complexity, less manual user actions.

Make funtion private now that it's all in the same class; fix a doc typo

aklapper retitled this revision from Allow copying previous milestone's description when creating a new milestone to Paste previous milestone's description text when creating a new milestone.Mar 8 2025, 13:17
aklapper edited the summary of this revision. (Show Details)
aklapper edited the test plan for this revision. (Show Details)
aklapper edited the test plan for this revision. (Show Details)

Super nice prototype but flagging as "more digging probably needed for production"

src/applications/project/engine/PhabricatorProjectEditEngine.php
143

Super nice prototype but this check, here, with getLabel() === 'Description is too much hacky.

  1. I wonder if we can avoid to patch the field here in this loop. Probably we can find the callers of willConfigureFields($fields) and find where this field is defined (?)
  2. even if not able to do 1, the label is not an identifier but a translation. The check does not work for other languages. We also should not adopt getLabel() === phg('Description') because it would be probably more correct but more hacky. Maybe better to afford point (1)
This revision now requires changes to proceed.Mon, Apr 28, 07:13