I think this is the correct fix, sets a consistent value for transactions, old and new, for Maniphest point values.
Details
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.
Diff Detail
- Repository
- rP Phabricator
- Lint
Lint Not Applicable - Unit
Tests Not Applicable
Event Timeline
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(). |
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().