Implement a basic version of ApplicationEditor in Paste
Summary:
Ref T9132. Ref T4768. This is a rough v0 of ApplicationEditor, which replaces the edit workflow in Paste.
This mostly looks and works like ApplicationSearch, and is heavily modeled on it.
Roughly, we define a set of editable fields and the ApplicationEditor stuff builds everything else.
This has no functional changes, except:
- I removed "Fork Paste" since I don't think it's particularly useful now that pastes are editable. We could restore it if users miss it.
- Subscribers are now editable.
- Form field order is a little goofy (this will be fixed in a future diff).
- Subscribers and projects are now race-resistant.
The race-resistance works like this: instead of submitting just the new value ("subscribers=apple, dog") and doing a set operation ("set subscribers = apple, dog"), we submit the old and new values ("original=apple" + "new=apple, dog") then apply the user's changes as an add + remove ("add=dog", "remove=<none>"). This means that two users who do "Edit Paste" at around the same time and each add or remove a couple of subscribers won't overwrite each other, unless they actually add or remove the exact same subscribers (in which case their edits legitimately conflict). Previously, the last user to save would win, and whatever was in their field would overwrite the prior state, potentially losing the first user's edits.
Test Plan:
- Created pastes.
- Created pastes via API.
- Edited pastes.
- Edited every field.
- Opened a paste in two windows and did project/subscriber edits in each, saved in arbitrary order, had edits respected.
Reviewers: chad
Reviewed By: chad
Maniphest Tasks: T4768, T9132
Differential Revision: https://secure.phabricator.com/D14390
2015-11-02 18:58:32 -08:00
|
|
|
<?php
|
|
|
|
|
|
|
|
final class PhabricatorSelectEditField
|
|
|
|
extends PhabricatorEditField {
|
|
|
|
|
|
|
|
private $options;
|
Allow numeric constants to act as aliases for task priorities in the web UI <select />
Summary:
Ref T12124. This is a fairly narrow fix for existing saved EditEngine forms with a default priority value.
These saved forms have a numeric (or probably "string-numeric") default value, like "50". They lost their meaning after D18111, when "50" no longer appears in the dropdown. Instead, these forms all select the highest available priority.
At time of writing, this form was broken on this install, for example:
> https://secure.phabricator.com/transactions/editengine/maniphest.task/view/13/
Additionally, `/task/edit/form/123/?priority=...` (for templating forms) stopped working with `priority=50`. This isn't nearly as important, but a larger and more sudden compatiblity break than we need to make.
Add support for an "alias map" on `<select />` controls, so if the value comes in with something we don't recognize we'll treat it like some other value. Then alias all the numeric constants -- and other keywords -- to the right constants.
This ended up only affecting the `<select />` control in the web UI.
Test Plan:
- On `stable`, created a form with "Priority: Low".
- Before patch: form has "Priority: Unbreak Now!" on `master`.
- After patch: form has "Priority: Low" again.
- Used `?priority=25`, `?priority=wish`, `?priority=wishlist` to template forms: all forms worked.
Reviewers: amckinley, chad
Reviewed By: amckinley
Maniphest Tasks: T12124
Differential Revision: https://secure.phabricator.com/D18134
2017-06-19 12:15:26 -07:00
|
|
|
private $optionAliases = array();
|
Implement a basic version of ApplicationEditor in Paste
Summary:
Ref T9132. Ref T4768. This is a rough v0 of ApplicationEditor, which replaces the edit workflow in Paste.
This mostly looks and works like ApplicationSearch, and is heavily modeled on it.
Roughly, we define a set of editable fields and the ApplicationEditor stuff builds everything else.
This has no functional changes, except:
- I removed "Fork Paste" since I don't think it's particularly useful now that pastes are editable. We could restore it if users miss it.
- Subscribers are now editable.
- Form field order is a little goofy (this will be fixed in a future diff).
- Subscribers and projects are now race-resistant.
The race-resistance works like this: instead of submitting just the new value ("subscribers=apple, dog") and doing a set operation ("set subscribers = apple, dog"), we submit the old and new values ("original=apple" + "new=apple, dog") then apply the user's changes as an add + remove ("add=dog", "remove=<none>"). This means that two users who do "Edit Paste" at around the same time and each add or remove a couple of subscribers won't overwrite each other, unless they actually add or remove the exact same subscribers (in which case their edits legitimately conflict). Previously, the last user to save would win, and whatever was in their field would overwrite the prior state, potentially losing the first user's edits.
Test Plan:
- Created pastes.
- Created pastes via API.
- Edited pastes.
- Edited every field.
- Opened a paste in two windows and did project/subscriber edits in each, saved in arbitrary order, had edits respected.
Reviewers: chad
Reviewed By: chad
Maniphest Tasks: T4768, T9132
Differential Revision: https://secure.phabricator.com/D14390
2015-11-02 18:58:32 -08:00
|
|
|
|
|
|
|
public function setOptions(array $options) {
|
|
|
|
$this->options = $options;
|
|
|
|
return $this;
|
|
|
|
}
|
|
|
|
|
|
|
|
public function getOptions() {
|
|
|
|
if ($this->options === null) {
|
|
|
|
throw new PhutilInvalidStateException('setOptions');
|
|
|
|
}
|
|
|
|
return $this->options;
|
|
|
|
}
|
|
|
|
|
Allow numeric constants to act as aliases for task priorities in the web UI <select />
Summary:
Ref T12124. This is a fairly narrow fix for existing saved EditEngine forms with a default priority value.
These saved forms have a numeric (or probably "string-numeric") default value, like "50". They lost their meaning after D18111, when "50" no longer appears in the dropdown. Instead, these forms all select the highest available priority.
At time of writing, this form was broken on this install, for example:
> https://secure.phabricator.com/transactions/editengine/maniphest.task/view/13/
Additionally, `/task/edit/form/123/?priority=...` (for templating forms) stopped working with `priority=50`. This isn't nearly as important, but a larger and more sudden compatiblity break than we need to make.
Add support for an "alias map" on `<select />` controls, so if the value comes in with something we don't recognize we'll treat it like some other value. Then alias all the numeric constants -- and other keywords -- to the right constants.
This ended up only affecting the `<select />` control in the web UI.
Test Plan:
- On `stable`, created a form with "Priority: Low".
- Before patch: form has "Priority: Unbreak Now!" on `master`.
- After patch: form has "Priority: Low" again.
- Used `?priority=25`, `?priority=wish`, `?priority=wishlist` to template forms: all forms worked.
Reviewers: amckinley, chad
Reviewed By: amckinley
Maniphest Tasks: T12124
Differential Revision: https://secure.phabricator.com/D18134
2017-06-19 12:15:26 -07:00
|
|
|
public function setOptionAliases(array $option_aliases) {
|
|
|
|
$this->optionAliases = $option_aliases;
|
|
|
|
return $this;
|
|
|
|
}
|
|
|
|
|
|
|
|
public function getOptionAliases() {
|
|
|
|
return $this->optionAliases;
|
|
|
|
}
|
|
|
|
|
2017-06-20 15:20:41 -07:00
|
|
|
protected function getDefaultValueFromConfiguration($value) {
|
|
|
|
return $this->getCanonicalValue($value);
|
|
|
|
}
|
|
|
|
|
Allow numeric constants to act as aliases for task priorities in the web UI <select />
Summary:
Ref T12124. This is a fairly narrow fix for existing saved EditEngine forms with a default priority value.
These saved forms have a numeric (or probably "string-numeric") default value, like "50". They lost their meaning after D18111, when "50" no longer appears in the dropdown. Instead, these forms all select the highest available priority.
At time of writing, this form was broken on this install, for example:
> https://secure.phabricator.com/transactions/editengine/maniphest.task/view/13/
Additionally, `/task/edit/form/123/?priority=...` (for templating forms) stopped working with `priority=50`. This isn't nearly as important, but a larger and more sudden compatiblity break than we need to make.
Add support for an "alias map" on `<select />` controls, so if the value comes in with something we don't recognize we'll treat it like some other value. Then alias all the numeric constants -- and other keywords -- to the right constants.
This ended up only affecting the `<select />` control in the web UI.
Test Plan:
- On `stable`, created a form with "Priority: Low".
- Before patch: form has "Priority: Unbreak Now!" on `master`.
- After patch: form has "Priority: Low" again.
- Used `?priority=25`, `?priority=wish`, `?priority=wishlist` to template forms: all forms worked.
Reviewers: amckinley, chad
Reviewed By: amckinley
Maniphest Tasks: T12124
Differential Revision: https://secure.phabricator.com/D18134
2017-06-19 12:15:26 -07:00
|
|
|
protected function getValueForControl() {
|
|
|
|
$value = parent::getValueForControl();
|
2017-06-20 15:20:41 -07:00
|
|
|
return $this->getCanonicalValue($value);
|
Allow numeric constants to act as aliases for task priorities in the web UI <select />
Summary:
Ref T12124. This is a fairly narrow fix for existing saved EditEngine forms with a default priority value.
These saved forms have a numeric (or probably "string-numeric") default value, like "50". They lost their meaning after D18111, when "50" no longer appears in the dropdown. Instead, these forms all select the highest available priority.
At time of writing, this form was broken on this install, for example:
> https://secure.phabricator.com/transactions/editengine/maniphest.task/view/13/
Additionally, `/task/edit/form/123/?priority=...` (for templating forms) stopped working with `priority=50`. This isn't nearly as important, but a larger and more sudden compatiblity break than we need to make.
Add support for an "alias map" on `<select />` controls, so if the value comes in with something we don't recognize we'll treat it like some other value. Then alias all the numeric constants -- and other keywords -- to the right constants.
This ended up only affecting the `<select />` control in the web UI.
Test Plan:
- On `stable`, created a form with "Priority: Low".
- Before patch: form has "Priority: Unbreak Now!" on `master`.
- After patch: form has "Priority: Low" again.
- Used `?priority=25`, `?priority=wish`, `?priority=wishlist` to template forms: all forms worked.
Reviewers: amckinley, chad
Reviewed By: amckinley
Maniphest Tasks: T12124
Differential Revision: https://secure.phabricator.com/D18134
2017-06-19 12:15:26 -07:00
|
|
|
}
|
|
|
|
|
Implement a basic version of ApplicationEditor in Paste
Summary:
Ref T9132. Ref T4768. This is a rough v0 of ApplicationEditor, which replaces the edit workflow in Paste.
This mostly looks and works like ApplicationSearch, and is heavily modeled on it.
Roughly, we define a set of editable fields and the ApplicationEditor stuff builds everything else.
This has no functional changes, except:
- I removed "Fork Paste" since I don't think it's particularly useful now that pastes are editable. We could restore it if users miss it.
- Subscribers are now editable.
- Form field order is a little goofy (this will be fixed in a future diff).
- Subscribers and projects are now race-resistant.
The race-resistance works like this: instead of submitting just the new value ("subscribers=apple, dog") and doing a set operation ("set subscribers = apple, dog"), we submit the old and new values ("original=apple" + "new=apple, dog") then apply the user's changes as an add + remove ("add=dog", "remove=<none>"). This means that two users who do "Edit Paste" at around the same time and each add or remove a couple of subscribers won't overwrite each other, unless they actually add or remove the exact same subscribers (in which case their edits legitimately conflict). Previously, the last user to save would win, and whatever was in their field would overwrite the prior state, potentially losing the first user's edits.
Test Plan:
- Created pastes.
- Created pastes via API.
- Edited pastes.
- Edited every field.
- Opened a paste in two windows and did project/subscriber edits in each, saved in arbitrary order, had edits respected.
Reviewers: chad
Reviewed By: chad
Maniphest Tasks: T4768, T9132
Differential Revision: https://secure.phabricator.com/D14390
2015-11-02 18:58:32 -08:00
|
|
|
protected function newControl() {
|
|
|
|
return id(new AphrontFormSelectControl())
|
|
|
|
->setOptions($this->getOptions());
|
|
|
|
}
|
|
|
|
|
2015-11-04 05:05:10 -08:00
|
|
|
protected function newHTTPParameterType() {
|
|
|
|
return new AphrontSelectHTTPParameterType();
|
2015-11-03 05:38:06 -08:00
|
|
|
}
|
|
|
|
|
2015-12-15 06:57:32 -08:00
|
|
|
protected function newCommentAction() {
|
|
|
|
return id(new PhabricatorEditEngineSelectCommentAction())
|
|
|
|
->setOptions($this->getOptions());
|
2015-12-04 07:56:03 -08:00
|
|
|
}
|
|
|
|
|
2015-12-16 05:09:21 -08:00
|
|
|
protected function newConduitParameterType() {
|
|
|
|
return new ConduitStringParameterType();
|
|
|
|
}
|
|
|
|
|
2017-06-20 15:20:41 -07:00
|
|
|
private function getCanonicalValue($value) {
|
|
|
|
$options = $this->getOptions();
|
|
|
|
if (!isset($options[$value])) {
|
|
|
|
$aliases = $this->getOptionAliases();
|
|
|
|
if (isset($aliases[$value])) {
|
|
|
|
$value = $aliases[$value];
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
|
|
|
return $value;
|
|
|
|
}
|
|
|
|
|
Implement a basic version of ApplicationEditor in Paste
Summary:
Ref T9132. Ref T4768. This is a rough v0 of ApplicationEditor, which replaces the edit workflow in Paste.
This mostly looks and works like ApplicationSearch, and is heavily modeled on it.
Roughly, we define a set of editable fields and the ApplicationEditor stuff builds everything else.
This has no functional changes, except:
- I removed "Fork Paste" since I don't think it's particularly useful now that pastes are editable. We could restore it if users miss it.
- Subscribers are now editable.
- Form field order is a little goofy (this will be fixed in a future diff).
- Subscribers and projects are now race-resistant.
The race-resistance works like this: instead of submitting just the new value ("subscribers=apple, dog") and doing a set operation ("set subscribers = apple, dog"), we submit the old and new values ("original=apple" + "new=apple, dog") then apply the user's changes as an add + remove ("add=dog", "remove=<none>"). This means that two users who do "Edit Paste" at around the same time and each add or remove a couple of subscribers won't overwrite each other, unless they actually add or remove the exact same subscribers (in which case their edits legitimately conflict). Previously, the last user to save would win, and whatever was in their field would overwrite the prior state, potentially losing the first user's edits.
Test Plan:
- Created pastes.
- Created pastes via API.
- Edited pastes.
- Edited every field.
- Opened a paste in two windows and did project/subscriber edits in each, saved in arbitrary order, had edits respected.
Reviewers: chad
Reviewed By: chad
Maniphest Tasks: T4768, T9132
Differential Revision: https://secure.phabricator.com/D14390
2015-11-02 18:58:32 -08:00
|
|
|
}
|