1
0
Fork 0
mirror of https://we.phorge.it/source/phorge.git synced 2024-11-30 18:52:42 +01:00
phorge-phorge/src/applications/transactions/query/PhabricatorEditEngineConfigurationQuery.php

285 lines
6.9 KiB
PHP
Raw Normal View History

Allow ApplicationEditor forms to be reconfigured Summary: Ref T9132. This diff doesn't do anything interesting, it just lays the groundwork for more interesting future diffs. Broadly, the idea here is to let you create multiple views of each edit form. For example, we might create several different "Create Task" forms, like: - "New Bug Report" - "New Feature Request" These would be views of the "Create Task" form, but with various adjustments: - A form might have additional instructions ("how to file a good bug report"). - A form might have prefilled values for some fields (like particular projects, subscribers, or policies). - A form might have some fields locked (so they can not be edited) or hidden. - A form might have a different field order. - A form might have a limited visibility policy, so only some users can access it. This diff adds a new storage object (`EditEngineConfiguration`) to keep track of all those customizations and represent "a form which has been configured to look and work a certain way". This doesn't let these configurations do anything useful/interesting, and you can't access them directly yet, it's just all the boring plumbing to enable more interesting behavior in the future. Test Plan: ApplicationEditor forms now let you manage available forms and edit the current form: {F959025} There's a new (bare bones) list of all available engines: {F959030} And if you jump into an engine, you can see all the forms for it: {F959038} The actual form configurations have standard detail/edit pages. The edit pages are themselves driven by ApplicationEditor, of course, so you can edit the form for editing forms. Reviewers: chad Reviewed By: chad Maniphest Tasks: T9132 Differential Revision: https://secure.phabricator.com/D14453
2015-11-04 21:52:52 +01:00
<?php
final class PhabricatorEditEngineConfigurationQuery
extends PhabricatorCursorPagedPolicyAwareQuery {
private $ids;
private $phids;
private $engineKeys;
private $builtinKeys;
private $identifiers;
private $default;
Allow EditEngine forms to be marked as "edit" forms Summary: Ref T9132. Ref T9908. This attempts to move us forward on answering this question: > Which form gets used when a user clicks "Edit Task"? One answer is "the same form that was used to create the task". There are several problems with that: - The form might not exist anymore. - The user might not have permission to see it. - Some of the fields might be hidden, essentially preventing them from being edited. - We have to store the value somewhere and old tasks won't have a value. - Any instructions on the form probably don't apply to edits. One answer is "force the default, full form". That's not as problematic, but it means we have no ability to create limited access users who see fewer fields. The answer in this diff is: - Forms can be marked as "edit forms". - We take the user to the first edit form they have permission to see, from a master list. This allows you to create several forms like: - Advanced Edit Form (say, all fields -- visible to administrators). - Basic Edit Form (say, no policies -- visible to trusted users). - Noob Edit Form (say, no policies, priorities, or status -- visible to everyone). Then you can give everyone access to "noob", some people access to "basic", and a few people access to "advanced". This might only be part of the answer. In particular, you can still //use// any edit form you can see, so we could do these things in the future: - Give you an option to switch to a different form if you want. - Save the form the task was created with, and use that form by default. If we do pursue those, we can fall back to this behavior if there's a problem with them (e.g., original form doesn't exist or wasn't recorded). There's also no "reorder" UI yet, that'll be coming in the next diff. I'm also going to try to probably make the "create" and "edit" stuff a little more consistent / less weird in a bit. Test Plan: Marked various forms as edit forms or not edit forms, made edits, hit permissions errors, etc. Reviewers: chad Reviewed By: chad Maniphest Tasks: T9132, T9908 Differential Revision: https://secure.phabricator.com/D14702
2015-12-08 02:11:35 +01:00
private $isEdit;
private $disabled;
private $ignoreDatabaseConfigurations;
private $subtypes;
Allow ApplicationEditor forms to be reconfigured Summary: Ref T9132. This diff doesn't do anything interesting, it just lays the groundwork for more interesting future diffs. Broadly, the idea here is to let you create multiple views of each edit form. For example, we might create several different "Create Task" forms, like: - "New Bug Report" - "New Feature Request" These would be views of the "Create Task" form, but with various adjustments: - A form might have additional instructions ("how to file a good bug report"). - A form might have prefilled values for some fields (like particular projects, subscribers, or policies). - A form might have some fields locked (so they can not be edited) or hidden. - A form might have a different field order. - A form might have a limited visibility policy, so only some users can access it. This diff adds a new storage object (`EditEngineConfiguration`) to keep track of all those customizations and represent "a form which has been configured to look and work a certain way". This doesn't let these configurations do anything useful/interesting, and you can't access them directly yet, it's just all the boring plumbing to enable more interesting behavior in the future. Test Plan: ApplicationEditor forms now let you manage available forms and edit the current form: {F959025} There's a new (bare bones) list of all available engines: {F959030} And if you jump into an engine, you can see all the forms for it: {F959038} The actual form configurations have standard detail/edit pages. The edit pages are themselves driven by ApplicationEditor, of course, so you can edit the form for editing forms. Reviewers: chad Reviewed By: chad Maniphest Tasks: T9132 Differential Revision: https://secure.phabricator.com/D14453
2015-11-04 21:52:52 +01:00
public function withIDs(array $ids) {
$this->ids = $ids;
return $this;
}
public function withPHIDs(array $phids) {
$this->phids = $phids;
return $this;
}
public function withEngineKeys(array $engine_keys) {
$this->engineKeys = $engine_keys;
return $this;
}
public function withBuiltinKeys(array $builtin_keys) {
$this->builtinKeys = $builtin_keys;
return $this;
}
public function withIdentifiers(array $identifiers) {
$this->identifiers = $identifiers;
return $this;
}
public function withIsDefault($default) {
$this->default = $default;
return $this;
}
Allow EditEngine forms to be marked as "edit" forms Summary: Ref T9132. Ref T9908. This attempts to move us forward on answering this question: > Which form gets used when a user clicks "Edit Task"? One answer is "the same form that was used to create the task". There are several problems with that: - The form might not exist anymore. - The user might not have permission to see it. - Some of the fields might be hidden, essentially preventing them from being edited. - We have to store the value somewhere and old tasks won't have a value. - Any instructions on the form probably don't apply to edits. One answer is "force the default, full form". That's not as problematic, but it means we have no ability to create limited access users who see fewer fields. The answer in this diff is: - Forms can be marked as "edit forms". - We take the user to the first edit form they have permission to see, from a master list. This allows you to create several forms like: - Advanced Edit Form (say, all fields -- visible to administrators). - Basic Edit Form (say, no policies -- visible to trusted users). - Noob Edit Form (say, no policies, priorities, or status -- visible to everyone). Then you can give everyone access to "noob", some people access to "basic", and a few people access to "advanced". This might only be part of the answer. In particular, you can still //use// any edit form you can see, so we could do these things in the future: - Give you an option to switch to a different form if you want. - Save the form the task was created with, and use that form by default. If we do pursue those, we can fall back to this behavior if there's a problem with them (e.g., original form doesn't exist or wasn't recorded). There's also no "reorder" UI yet, that'll be coming in the next diff. I'm also going to try to probably make the "create" and "edit" stuff a little more consistent / less weird in a bit. Test Plan: Marked various forms as edit forms or not edit forms, made edits, hit permissions errors, etc. Reviewers: chad Reviewed By: chad Maniphest Tasks: T9132, T9908 Differential Revision: https://secure.phabricator.com/D14702
2015-12-08 02:11:35 +01:00
public function withIsEdit($edit) {
$this->isEdit = $edit;
return $this;
}
public function withIsDisabled($disabled) {
$this->disabled = $disabled;
return $this;
}
public function withIgnoreDatabaseConfigurations($ignore) {
$this->ignoreDatabaseConfigurations = $ignore;
return $this;
}
public function withSubtypes(array $subtypes) {
$this->subtypes = $subtypes;
return $this;
}
Allow ApplicationEditor forms to be reconfigured Summary: Ref T9132. This diff doesn't do anything interesting, it just lays the groundwork for more interesting future diffs. Broadly, the idea here is to let you create multiple views of each edit form. For example, we might create several different "Create Task" forms, like: - "New Bug Report" - "New Feature Request" These would be views of the "Create Task" form, but with various adjustments: - A form might have additional instructions ("how to file a good bug report"). - A form might have prefilled values for some fields (like particular projects, subscribers, or policies). - A form might have some fields locked (so they can not be edited) or hidden. - A form might have a different field order. - A form might have a limited visibility policy, so only some users can access it. This diff adds a new storage object (`EditEngineConfiguration`) to keep track of all those customizations and represent "a form which has been configured to look and work a certain way". This doesn't let these configurations do anything useful/interesting, and you can't access them directly yet, it's just all the boring plumbing to enable more interesting behavior in the future. Test Plan: ApplicationEditor forms now let you manage available forms and edit the current form: {F959025} There's a new (bare bones) list of all available engines: {F959030} And if you jump into an engine, you can see all the forms for it: {F959038} The actual form configurations have standard detail/edit pages. The edit pages are themselves driven by ApplicationEditor, of course, so you can edit the form for editing forms. Reviewers: chad Reviewed By: chad Maniphest Tasks: T9132 Differential Revision: https://secure.phabricator.com/D14453
2015-11-04 21:52:52 +01:00
public function newResultObject() {
return new PhabricatorEditEngineConfiguration();
}
protected function loadPage() {
// TODO: The logic here is a little flimsy and won't survive pagination.
// For now, I'm just not bothering with pagination since I believe it will
// take some time before any install manages to produce a large enough
// number of edit forms for any particular engine for the lack of UI
// pagination to become a problem.
if ($this->ignoreDatabaseConfigurations) {
$page = array();
} else {
$page = $this->loadStandardPage($this->newResultObject());
}
Allow ApplicationEditor forms to be reconfigured Summary: Ref T9132. This diff doesn't do anything interesting, it just lays the groundwork for more interesting future diffs. Broadly, the idea here is to let you create multiple views of each edit form. For example, we might create several different "Create Task" forms, like: - "New Bug Report" - "New Feature Request" These would be views of the "Create Task" form, but with various adjustments: - A form might have additional instructions ("how to file a good bug report"). - A form might have prefilled values for some fields (like particular projects, subscribers, or policies). - A form might have some fields locked (so they can not be edited) or hidden. - A form might have a different field order. - A form might have a limited visibility policy, so only some users can access it. This diff adds a new storage object (`EditEngineConfiguration`) to keep track of all those customizations and represent "a form which has been configured to look and work a certain way". This doesn't let these configurations do anything useful/interesting, and you can't access them directly yet, it's just all the boring plumbing to enable more interesting behavior in the future. Test Plan: ApplicationEditor forms now let you manage available forms and edit the current form: {F959025} There's a new (bare bones) list of all available engines: {F959030} And if you jump into an engine, you can see all the forms for it: {F959038} The actual form configurations have standard detail/edit pages. The edit pages are themselves driven by ApplicationEditor, of course, so you can edit the form for editing forms. Reviewers: chad Reviewed By: chad Maniphest Tasks: T9132 Differential Revision: https://secure.phabricator.com/D14453
2015-11-04 21:52:52 +01:00
// Now that we've loaded the real results from the database, we're going
// to load builtins from the edit engines and add them to the list.
$engines = PhabricatorEditEngine::getAllEditEngines();
if ($this->engineKeys) {
$engines = array_select_keys($engines, $this->engineKeys);
}
foreach ($engines as $engine) {
$engine->setViewer($this->getViewer());
}
// List all the builtins which have already been saved to the database as
// real objects.
$concrete = array();
foreach ($page as $config) {
$builtin_key = $config->getBuiltinKey();
if ($builtin_key !== null) {
$engine_key = $config->getEngineKey();
$concrete[$engine_key][$builtin_key] = $config;
}
}
$builtins = array();
foreach ($engines as $engine_key => $engine) {
$engine_builtins = $engine->getBuiltinEngineConfigurations();
foreach ($engine_builtins as $engine_builtin) {
$builtin_key = $engine_builtin->getBuiltinKey();
if (isset($concrete[$engine_key][$builtin_key])) {
continue;
} else {
$builtins[] = $engine_builtin;
}
}
}
foreach ($builtins as $builtin) {
$page[] = $builtin;
}
// Now we have to do some extra filtering to make sure everything we're
// about to return really satisfies the query.
if ($this->ids !== null) {
$ids = array_fuse($this->ids);
foreach ($page as $key => $config) {
if (empty($ids[$config->getID()])) {
unset($page[$key]);
}
}
}
if ($this->phids !== null) {
$phids = array_fuse($this->phids);
foreach ($page as $key => $config) {
if (empty($phids[$config->getPHID()])) {
unset($page[$key]);
}
}
}
if ($this->builtinKeys !== null) {
$builtin_keys = array_fuse($this->builtinKeys);
foreach ($page as $key => $config) {
if (empty($builtin_keys[$config->getBuiltinKey()])) {
unset($page[$key]);
}
}
}
if ($this->default !== null) {
foreach ($page as $key => $config) {
if ($config->getIsDefault() != $this->default) {
unset($page[$key]);
}
}
}
Allow EditEngine forms to be marked as "edit" forms Summary: Ref T9132. Ref T9908. This attempts to move us forward on answering this question: > Which form gets used when a user clicks "Edit Task"? One answer is "the same form that was used to create the task". There are several problems with that: - The form might not exist anymore. - The user might not have permission to see it. - Some of the fields might be hidden, essentially preventing them from being edited. - We have to store the value somewhere and old tasks won't have a value. - Any instructions on the form probably don't apply to edits. One answer is "force the default, full form". That's not as problematic, but it means we have no ability to create limited access users who see fewer fields. The answer in this diff is: - Forms can be marked as "edit forms". - We take the user to the first edit form they have permission to see, from a master list. This allows you to create several forms like: - Advanced Edit Form (say, all fields -- visible to administrators). - Basic Edit Form (say, no policies -- visible to trusted users). - Noob Edit Form (say, no policies, priorities, or status -- visible to everyone). Then you can give everyone access to "noob", some people access to "basic", and a few people access to "advanced". This might only be part of the answer. In particular, you can still //use// any edit form you can see, so we could do these things in the future: - Give you an option to switch to a different form if you want. - Save the form the task was created with, and use that form by default. If we do pursue those, we can fall back to this behavior if there's a problem with them (e.g., original form doesn't exist or wasn't recorded). There's also no "reorder" UI yet, that'll be coming in the next diff. I'm also going to try to probably make the "create" and "edit" stuff a little more consistent / less weird in a bit. Test Plan: Marked various forms as edit forms or not edit forms, made edits, hit permissions errors, etc. Reviewers: chad Reviewed By: chad Maniphest Tasks: T9132, T9908 Differential Revision: https://secure.phabricator.com/D14702
2015-12-08 02:11:35 +01:00
if ($this->isEdit !== null) {
foreach ($page as $key => $config) {
if ($config->getIsEdit() != $this->isEdit) {
unset($page[$key]);
}
}
}
if ($this->disabled !== null) {
foreach ($page as $key => $config) {
if ($config->getIsDisabled() != $this->disabled) {
unset($page[$key]);
Allow ApplicationEditor forms to be reconfigured Summary: Ref T9132. This diff doesn't do anything interesting, it just lays the groundwork for more interesting future diffs. Broadly, the idea here is to let you create multiple views of each edit form. For example, we might create several different "Create Task" forms, like: - "New Bug Report" - "New Feature Request" These would be views of the "Create Task" form, but with various adjustments: - A form might have additional instructions ("how to file a good bug report"). - A form might have prefilled values for some fields (like particular projects, subscribers, or policies). - A form might have some fields locked (so they can not be edited) or hidden. - A form might have a different field order. - A form might have a limited visibility policy, so only some users can access it. This diff adds a new storage object (`EditEngineConfiguration`) to keep track of all those customizations and represent "a form which has been configured to look and work a certain way". This doesn't let these configurations do anything useful/interesting, and you can't access them directly yet, it's just all the boring plumbing to enable more interesting behavior in the future. Test Plan: ApplicationEditor forms now let you manage available forms and edit the current form: {F959025} There's a new (bare bones) list of all available engines: {F959030} And if you jump into an engine, you can see all the forms for it: {F959038} The actual form configurations have standard detail/edit pages. The edit pages are themselves driven by ApplicationEditor, of course, so you can edit the form for editing forms. Reviewers: chad Reviewed By: chad Maniphest Tasks: T9132 Differential Revision: https://secure.phabricator.com/D14453
2015-11-04 21:52:52 +01:00
}
}
}
if ($this->identifiers !== null) {
$identifiers = array_fuse($this->identifiers);
foreach ($page as $key => $config) {
if (isset($identifiers[$config->getBuiltinKey()])) {
continue;
}
if (isset($identifiers[$config->getID()])) {
continue;
}
unset($page[$key]);
}
}
if ($this->subtypes !== null) {
$subtypes = array_fuse($this->subtypes);
foreach ($page as $key => $config) {
if (isset($subtypes[$config->getSubtype()])) {
continue;
}
unset($page[$key]);
}
}
Allow ApplicationEditor forms to be reconfigured Summary: Ref T9132. This diff doesn't do anything interesting, it just lays the groundwork for more interesting future diffs. Broadly, the idea here is to let you create multiple views of each edit form. For example, we might create several different "Create Task" forms, like: - "New Bug Report" - "New Feature Request" These would be views of the "Create Task" form, but with various adjustments: - A form might have additional instructions ("how to file a good bug report"). - A form might have prefilled values for some fields (like particular projects, subscribers, or policies). - A form might have some fields locked (so they can not be edited) or hidden. - A form might have a different field order. - A form might have a limited visibility policy, so only some users can access it. This diff adds a new storage object (`EditEngineConfiguration`) to keep track of all those customizations and represent "a form which has been configured to look and work a certain way". This doesn't let these configurations do anything useful/interesting, and you can't access them directly yet, it's just all the boring plumbing to enable more interesting behavior in the future. Test Plan: ApplicationEditor forms now let you manage available forms and edit the current form: {F959025} There's a new (bare bones) list of all available engines: {F959030} And if you jump into an engine, you can see all the forms for it: {F959038} The actual form configurations have standard detail/edit pages. The edit pages are themselves driven by ApplicationEditor, of course, so you can edit the form for editing forms. Reviewers: chad Reviewed By: chad Maniphest Tasks: T9132 Differential Revision: https://secure.phabricator.com/D14453
2015-11-04 21:52:52 +01:00
return $page;
}
protected function willFilterPage(array $configs) {
$engine_keys = mpull($configs, 'getEngineKey');
$engines = id(new PhabricatorEditEngineQuery())
->setParentQuery($this)
->setViewer($this->getViewer())
->withEngineKeys($engine_keys)
->execute();
$engines = mpull($engines, null, 'getEngineKey');
foreach ($configs as $key => $config) {
$engine = idx($engines, $config->getEngineKey());
if (!$engine) {
$this->didRejectResult($config);
unset($configs[$key]);
continue;
}
$config->attachEngine($engine);
}
return $configs;
}
Allow ApplicationEditor forms to be reconfigured Summary: Ref T9132. This diff doesn't do anything interesting, it just lays the groundwork for more interesting future diffs. Broadly, the idea here is to let you create multiple views of each edit form. For example, we might create several different "Create Task" forms, like: - "New Bug Report" - "New Feature Request" These would be views of the "Create Task" form, but with various adjustments: - A form might have additional instructions ("how to file a good bug report"). - A form might have prefilled values for some fields (like particular projects, subscribers, or policies). - A form might have some fields locked (so they can not be edited) or hidden. - A form might have a different field order. - A form might have a limited visibility policy, so only some users can access it. This diff adds a new storage object (`EditEngineConfiguration`) to keep track of all those customizations and represent "a form which has been configured to look and work a certain way". This doesn't let these configurations do anything useful/interesting, and you can't access them directly yet, it's just all the boring plumbing to enable more interesting behavior in the future. Test Plan: ApplicationEditor forms now let you manage available forms and edit the current form: {F959025} There's a new (bare bones) list of all available engines: {F959030} And if you jump into an engine, you can see all the forms for it: {F959038} The actual form configurations have standard detail/edit pages. The edit pages are themselves driven by ApplicationEditor, of course, so you can edit the form for editing forms. Reviewers: chad Reviewed By: chad Maniphest Tasks: T9132 Differential Revision: https://secure.phabricator.com/D14453
2015-11-04 21:52:52 +01:00
protected function buildWhereClauseParts(AphrontDatabaseConnection $conn) {
$where = parent::buildWhereClauseParts($conn);
if ($this->ids !== null) {
$where[] = qsprintf(
$conn,
'id IN (%Ld)',
$this->ids);
}
if ($this->phids !== null) {
$where[] = qsprintf(
$conn,
'phid IN (%Ls)',
$this->phids);
}
if ($this->engineKeys !== null) {
$where[] = qsprintf(
$conn,
'engineKey IN (%Ls)',
$this->engineKeys);
}
if ($this->builtinKeys !== null) {
$where[] = qsprintf(
$conn,
'builtinKey IN (%Ls)',
$this->builtinKeys);
}
if ($this->identifiers !== null) {
$where[] = qsprintf(
$conn,
'(id IN (%Ls) OR builtinKey IN (%Ls))',
$this->identifiers,
$this->identifiers);
}
if ($this->subtypes !== null) {
$where[] = qsprintf(
$conn,
'subtype IN (%Ls)',
$this->subtypes);
}
Allow ApplicationEditor forms to be reconfigured Summary: Ref T9132. This diff doesn't do anything interesting, it just lays the groundwork for more interesting future diffs. Broadly, the idea here is to let you create multiple views of each edit form. For example, we might create several different "Create Task" forms, like: - "New Bug Report" - "New Feature Request" These would be views of the "Create Task" form, but with various adjustments: - A form might have additional instructions ("how to file a good bug report"). - A form might have prefilled values for some fields (like particular projects, subscribers, or policies). - A form might have some fields locked (so they can not be edited) or hidden. - A form might have a different field order. - A form might have a limited visibility policy, so only some users can access it. This diff adds a new storage object (`EditEngineConfiguration`) to keep track of all those customizations and represent "a form which has been configured to look and work a certain way". This doesn't let these configurations do anything useful/interesting, and you can't access them directly yet, it's just all the boring plumbing to enable more interesting behavior in the future. Test Plan: ApplicationEditor forms now let you manage available forms and edit the current form: {F959025} There's a new (bare bones) list of all available engines: {F959030} And if you jump into an engine, you can see all the forms for it: {F959038} The actual form configurations have standard detail/edit pages. The edit pages are themselves driven by ApplicationEditor, of course, so you can edit the form for editing forms. Reviewers: chad Reviewed By: chad Maniphest Tasks: T9132 Differential Revision: https://secure.phabricator.com/D14453
2015-11-04 21:52:52 +01:00
return $where;
}
public function getQueryApplicationClass() {
return 'PhabricatorTransactionsApplication';
}
}