Page MenuHomePhabricator

Generate newValue for ManiphestTaskPointTransaction
ClosedPublic

Authored by chad on May 15 2017, 6:07 PM.
Tags
None
Referenced Files
F14019888: D17885.diff
Tue, Nov 5, 11:45 PM
F13996169: D17885.id43022.diff
Wed, Oct 23, 6:36 PM
F13992360: D17885.id43023.diff
Tue, Oct 22, 3:59 PM
F13969347: D17885.id43021.diff
Thu, Oct 17, 2:03 AM
F13954889: D17885.id43023.diff
Sun, Oct 13, 11:26 PM
Unknown Object (File)
Sep 28 2024, 7:02 PM
Unknown Object (File)
Sep 26 2024, 7:12 PM
Unknown Object (File)
Sep 25 2024, 7:27 AM
Subscribers

Details

Summary

I think this is the correct fix, sets a consistent value for transactions, old and new, for Maniphest point values.

Test Plan

Edit title, see no point feed story, set points, see point story, set points to same value, see no story, remove points, see remove point story.

image.png (274×852 px, 52 KB)

Diff Detail

Repository
rP Phabricator
Lint
Lint Not Applicable
Unit
Tests Not Applicable

Event Timeline

I'm confused by the name setValueForPoints(...) -- this doesn't "set" anything?

welllllll it "sets" the "value" for "points". just change it to "get" ?

This all seemed to work, but I'm not great at understanding what's under the hood here.

Yeah, maybe rename to "get".

src/applications/maniphest/xaction/ManiphestTaskPointsTransaction.php
16–17

This should be unnecessary, since the conversion already occurs in generateNewValue().

This revision is now accepted and ready to land.May 15 2017, 6:14 PM
This revision was automatically updated to reflect the committed changes.

The one in generateOldValue() is necessary because of T12678. When we load data from MySQL, it always comes back as "3.5" (a string) even if we wrote 3.5 (a double) to the database. If we fixed T12678, we could remove the extra code in generateOldValue().

The one in generateNewValue() is necessary because data coming through Conduit and the web isn't always strongly-typed today. This is getting better going forward, but we still have some cases -- at least, in general -- where data makes it to an Editor without type enforcement. In Maniphest, two examples are possibly the frozen method maniphest.createtask and the batch editor. I think neither of these can actually set point values, but since we still have a fair amount of this stuff kicking around we're a bit safer with extra typecasting. We could reduce or remove this in the long run as all the weird pathways to get to an Editor get cleaned up, and then make validateTransactions() stricter (explicitly require a double, not just a numeric string).

The one in applyInternalEffects() should not be necessary because we call generateNewValue() on the value first. That is, the sequence here is:

  • Something generates the value, e.g. a user posting a form. The data is a probably a string a this point, like "3.5", since HTTP POST doesn't have datatypes.
  • The value gets turned into a transaction, possibly without typecasting. It may be a double by now, but it may still be a string like "3.5".
  • The value gets validated by validateTransactions(). This allows "3.5" (string) or 3.5 (double) through, but not "cat" or false or -6.
  • The value gets normalized by generateNewValue(). This always leaves us with 3.5 (double) or null.
  • The value gets applied by applyInternalEffects().

I sure hope that comment is VERY sincere!!!

I thought hard about how many exclamation marks to use to convey internet sincerity.