Fix an issue with editing pre-space objects using a form with no visibility controls
ClosedPublic
Actions

Authored by epriestley on Feb 18 2016, 5:52 PM.

Details

Reviewers

20after4
chad

Commits

Summary

WMF ran into this after their update. Here's the setup:

When you enable Spaces, we leave all existing objects set to null, which means "these belong to the default space". This is so we don't have to go update a trillion objects.
New objects get set to the default space explicitly (PHID-SPCE-...) but older ones stay with null.
If you edit an older object (like a task) from the time before Spaces, and the form doesn't have a Visbility/Spaces control, we would incorrectly poplate the value with null when the effective value should be the default space PHID.
This caused a "You must choose a space." error in the UI.

Instead, populate the control with the effective value instead of the literal database value. This makes the edit go through cleanly.

Also add a note about this for future-me.

Test Plan

Repository

rP Phabricator

Lint

Lint Not Applicable

Unit

Tests Not Applicable

epriestley retitled this revision from to Fix an issue with editing pre-space objects using a form with no visibility controls.

epriestley updated this object.

epriestley edited the test plan for this revision. (Show Details)

epriestley added a reviewer: chad.

src/applications/policy/editor/PhabricatorPolicyEditEngineExtension.php
104–105	This basically boils down to: $space_phid = $object->getSpacePHID(); if ($space_phid) { return $space_phid; } // This is the meaning of `null`. return "THE DEFAULT SPACE PHID";