Page MenuHomePhabricator

Improve some setInitialValue() behavior for PhortuneMerchants
ClosedPublic

Authored by epriestley on Oct 28 2016, 8:29 PM.
Tags
None
Referenced Files
F12851920: D16764.diff
Fri, Mar 29, 6:58 AM
Unknown Object (File)
Wed, Mar 27, 6:51 PM
Unknown Object (File)
Thu, Mar 21, 3:13 AM
Unknown Object (File)
Wed, Mar 20, 10:26 PM
Unknown Object (File)
Feb 9 2024, 6:39 PM
Unknown Object (File)
Feb 3 2024, 12:37 PM
Unknown Object (File)
Jan 26 2024, 9:50 AM
Unknown Object (File)
Jan 22 2024, 1:43 PM
Subscribers
None

Details

Summary

This fixes the permissions issue with D16750, which is actually not really a permissions issue, exactly.

This is the only place anywhere that we use a tokenizer field and give it a default value which is not the same as the object value (when creating a merchant, we default it to the viewer).

In other cases (like Maniphest) we avoid this because you can edit the form to have defaults, which would collide with whatever default we provide. Some disucssion in T10222.

Since we aren't going to let you edit these forms for the forseeable future, this behavior is reasonable here though.

However, it triggered a sort-of-bug related to conflict detection for these fields (see T4768). These fields actually have two values: a hidden "initial" value, and a visible edited value.

When you submit the form, we compute your edit by comparing the edited value to the initial value, then applying adds/removes, instead of just saying "set value equal to new value". This prevents issues when two people edit at the same time and both make changes to the field.

In this case, the initial value was being set to the display value, so the field would say "Value: [(alincoln x)]" but internally have that as the intitial value, too. When you submitted, it would see "you didn't change anything", and thus not add any members.

So the viewer wouldn't actually be added as a member, then the policy check would correctly fail.

Note that there are still some policy issues here (you can remove yourself from a Merchant and lock yourself out) but they fall into the realm of stuff discussed in D16677.

Test Plan

Created a merchant account with D16750 applied.

Diff Detail

Repository
rP Phabricator
Branch
phortune3
Lint
Lint Passed
Unit
Tests Passed
Build Status
Buildable 14262
Build 18549: Run Core Tests
Build 18548: arc lint + arc unit

Event Timeline

epriestley retitled this revision from to Improve some setInitialValue() behavior for PhortuneMerchants.
epriestley updated this object.
epriestley edited the test plan for this revision. (Show Details)
epriestley added a reviewer: chad.
chad edited edge metadata.
This revision is now accepted and ready to land.Oct 28 2016, 8:39 PM

oh I didn't see you landed the other thing

I was too busy taking screenshots of oauths

This revision was automatically updated to reflect the committed changes.