2011-03-24 21:49:21 +01:00
|
|
|
<?php
|
|
|
|
|
2012-03-10 00:46:25 +01:00
|
|
|
final class HeraldTestConsoleController extends HeraldController {
|
2011-03-24 21:49:21 +01:00
|
|
|
|
|
|
|
public function processRequest() {
|
|
|
|
|
|
|
|
$request = $this->getRequest();
|
|
|
|
$user = $request->getUser();
|
|
|
|
|
|
|
|
$request = $this->getRequest();
|
|
|
|
|
|
|
|
$object_name = trim($request->getStr('object_name'));
|
|
|
|
|
|
|
|
$e_name = true;
|
|
|
|
$errors = array();
|
|
|
|
if ($request->isFormPost()) {
|
|
|
|
if (!$object_name) {
|
|
|
|
$e_name = 'Required';
|
|
|
|
$errors[] = 'An object name is required.';
|
|
|
|
}
|
|
|
|
|
|
|
|
if (!$errors) {
|
|
|
|
$matches = null;
|
|
|
|
$object = null;
|
|
|
|
if (preg_match('/^D(\d+)$/', $object_name, $matches)) {
|
|
|
|
$object = id(new DifferentialRevision())->load($matches[1]);
|
|
|
|
if (!$object) {
|
|
|
|
$e_name = 'Invalid';
|
|
|
|
$errors[] = 'No Differential Revision with that ID exists.';
|
|
|
|
}
|
|
|
|
} else if (preg_match('/^r([A-Z]+)(\w+)$/', $object_name, $matches)) {
|
|
|
|
$repo = id(new PhabricatorRepository())->loadOneWhere(
|
|
|
|
'callsign = %s',
|
|
|
|
$matches[1]);
|
|
|
|
if (!$repo) {
|
|
|
|
$e_name = 'Invalid';
|
|
|
|
$errors[] = 'There is no repository with the callsign '.
|
|
|
|
$matches[1].'.';
|
|
|
|
}
|
|
|
|
$commit = id(new PhabricatorRepositoryCommit())->loadOneWhere(
|
|
|
|
'repositoryID = %d AND commitIdentifier = %s',
|
|
|
|
$repo->getID(),
|
|
|
|
$matches[2]);
|
|
|
|
if (!$commit) {
|
|
|
|
$e_name = 'Invalid';
|
|
|
|
$errors[] = 'There is no commit with that identifier.';
|
|
|
|
}
|
2011-04-04 08:23:36 +02:00
|
|
|
$object = $commit;
|
2011-03-24 21:49:21 +01:00
|
|
|
} else {
|
|
|
|
$e_name = 'Invalid';
|
|
|
|
$errors[] = 'This object name is not recognized.';
|
|
|
|
}
|
|
|
|
|
|
|
|
if (!$errors) {
|
|
|
|
if ($object instanceof DifferentialRevision) {
|
2011-04-06 05:49:31 +02:00
|
|
|
$adapter = new HeraldDifferentialRevisionAdapter(
|
|
|
|
$object,
|
|
|
|
$object->loadActiveDiff());
|
2011-03-24 21:49:21 +01:00
|
|
|
} else if ($object instanceof PhabricatorRepositoryCommit) {
|
2011-04-04 08:23:36 +02:00
|
|
|
$data = id(new PhabricatorRepositoryCommitData())->loadOneWhere(
|
|
|
|
'commitID = %d',
|
|
|
|
$object->getID());
|
|
|
|
$adapter = new HeraldCommitAdapter(
|
|
|
|
$repo,
|
|
|
|
$object,
|
|
|
|
$data);
|
2011-03-24 21:49:21 +01:00
|
|
|
} else {
|
|
|
|
throw new Exception("Can not build adapter for object!");
|
|
|
|
}
|
|
|
|
|
|
|
|
$rules = HeraldRule::loadAllByContentTypeWithFullData(
|
Remove massive "rule applied" query
Summary:
Herald rules may be marked as "one-time". We track this by writing a row with
<ruleID, phid> when we apply a rule.
However, the current test for rule application involves loading every <ruleID,
*> pair. We also always write this row even for rules which are not one-time, so
if there are 100 rules, we'll load 1,000,000 rows after processing 10,000
objects.
Instead, load only the <phid, *> pairs, which are guaranteed to be bounded to at
most the number of rules.
I'll follow up with a diff that causes us to write rows only for one-time rules,
and deletes all historic rows which are not associated with one-time rules.
Test Plan:
Grepped for callsites to loadAllByContentTypeWithFullData(). Ran
rules in test console.
Reviewers: nh, btrahan, jungejason
Reviewed By: nh
CC: aran, epriestley
Differential Revision: https://secure.phabricator.com/D1483
2012-01-25 04:03:30 +01:00
|
|
|
$adapter->getHeraldTypeName(),
|
|
|
|
$object->getPHID());
|
2011-03-24 21:49:21 +01:00
|
|
|
|
|
|
|
$engine = new HeraldEngine();
|
|
|
|
$effects = $engine->applyRules($rules, $adapter);
|
|
|
|
|
|
|
|
$dry_run = new HeraldDryRunAdapter();
|
2012-01-25 20:53:39 +01:00
|
|
|
$engine->applyEffects($effects, $dry_run, $rules);
|
2011-03-24 21:49:21 +01:00
|
|
|
|
|
|
|
$xscript = $engine->getTranscript();
|
|
|
|
|
|
|
|
return id(new AphrontRedirectResponse())
|
|
|
|
->setURI('/herald/transcript/'.$xscript->getID().'/');
|
|
|
|
}
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
|
|
|
if ($errors) {
|
|
|
|
$error_view = new AphrontErrorView();
|
|
|
|
$error_view->setTitle('Form Errors');
|
|
|
|
$error_view->setErrors($errors);
|
|
|
|
} else {
|
|
|
|
$error_view = null;
|
|
|
|
}
|
|
|
|
|
|
|
|
$form = id(new AphrontFormView())
|
|
|
|
->setUser($user)
|
2013-02-07 23:39:04 +01:00
|
|
|
->appendChild(hsprintf(
|
2011-03-24 21:49:21 +01:00
|
|
|
'<p class="aphront-form-instructions">Enter an object to test rules '.
|
|
|
|
'for, like a Diffusion commit (e.g., <tt>rX123</tt>) or a '.
|
|
|
|
'Differential revision (e.g., <tt>D123</tt>). You will be shown the '.
|
2013-02-07 23:39:04 +01:00
|
|
|
'results of a dry run on the object.</p>'))
|
2011-03-24 21:49:21 +01:00
|
|
|
->appendChild(
|
|
|
|
id(new AphrontFormTextControl())
|
2013-01-19 21:15:41 +01:00
|
|
|
->setLabel(pht('Object Name'))
|
2011-03-24 21:49:21 +01:00
|
|
|
->setName('object_name')
|
|
|
|
->setError($e_name)
|
|
|
|
->setValue($object_name))
|
|
|
|
->appendChild(
|
|
|
|
id(new AphrontFormSubmitControl())
|
2013-01-19 21:15:41 +01:00
|
|
|
->setValue(pht('Test Rules')));
|
2011-03-24 21:49:21 +01:00
|
|
|
|
General Herald refactoring pass
Summary:
**Who can delete global rules?**: I discussed this with @jungejason. The current behavior is that the rule author or any administrator can delete a global rule, but this
isn't consistent with who can edit a rule (anyone) and doesn't really make much sense (it's an artifact of the global/personal split). I proposed that anyone can delete a
rule but we don't actually delete them, and log the deletion. However, when it came time to actually write the code for this I backed off a bit and continued actually
deleting the rules -- I think this does a reasonable job of balancing accountability with complexity. So the new impelmentation is:
- Personal rules can be deleted only by their owners.
- Global rules can be deleted by any user.
- All deletes are logged.
- Logs are more detailed.
- All logged actions can be viewed in aggregate.
**Minor Cleanup**
- Merged `HomeController` and `AllController`.
- Moved most queries to Query classes.
- Use AphrontFormSelectControl::renderSelectTag() where appropriate (this is a fairly recent addition).
- Use an AphrontErrorView to render the dry run notice (this didn't exist when I ported).
- Reenable some transaction code (this works again now).
- Removed the ability for admins to change rule authors (this was a little buggy, messy, and doesn't make tons of sense after the personal/global rule split).
- Rules which depend on other rules now display the right options (all global rules, all your personal rules for personal rules).
- Fix a bug in AphrontTableView where the "no data" cell would be rendered too wide if some columns are not visible.
- Allow selectFilter() in AphrontNavFilterView to be called without a 'default' argument.
Test Plan:
- Browsed, created, edited, deleted personal and gules.
- Verified generated logs.
- Did some dry runs.
- Verified transcript list and transcript details.
- Created/edited all/any rules; created/edited once/every time rules.
- Filtered admin views by users.
Reviewers: jungejason, btrahan
Reviewed By: btrahan
CC: aran, epriestley
Differential Revision: https://secure.phabricator.com/D2040
2012-03-30 19:49:55 +02:00
|
|
|
$nav = $this->renderNav();
|
|
|
|
$nav->selectFilter('test');
|
|
|
|
$nav->appendChild(
|
2011-03-24 21:49:21 +01:00
|
|
|
array(
|
|
|
|
$error_view,
|
Update form styles, implement in many places
Summary:
This creates a common form look and feel across the site. I spent a bit of time working out a number of kinks in our various renderings. Some things:
- Font Styles are correctly applied for form elements now.
- Everything lines up!
- Selects are larger, easier to read, interact.
- Inputs have been squared.
- Consistant CSS applied glow (try it!)
- Improved Mobile Responsiveness
- CSS applied to all form elements, not just Aphront
- Many other minor tweaks.
I tried to hit as many high profile forms as possible in an effort to increase consistency. Stopped for now and will follow up after this lands. I know Evan is not a super fan of the glow, but after working with it for a week, it's way cleaner and responsive than the OS controls. Give it a try.
Test Plan: Tested many applications, forms, mobile and tablet.
Reviewers: epriestley, btrahan
Reviewed By: epriestley
CC: aran, Korvin
Differential Revision: https://secure.phabricator.com/D5860
2013-05-07 23:07:06 +02:00
|
|
|
$form,
|
General Herald refactoring pass
Summary:
**Who can delete global rules?**: I discussed this with @jungejason. The current behavior is that the rule author or any administrator can delete a global rule, but this
isn't consistent with who can edit a rule (anyone) and doesn't really make much sense (it's an artifact of the global/personal split). I proposed that anyone can delete a
rule but we don't actually delete them, and log the deletion. However, when it came time to actually write the code for this I backed off a bit and continued actually
deleting the rules -- I think this does a reasonable job of balancing accountability with complexity. So the new impelmentation is:
- Personal rules can be deleted only by their owners.
- Global rules can be deleted by any user.
- All deletes are logged.
- Logs are more detailed.
- All logged actions can be viewed in aggregate.
**Minor Cleanup**
- Merged `HomeController` and `AllController`.
- Moved most queries to Query classes.
- Use AphrontFormSelectControl::renderSelectTag() where appropriate (this is a fairly recent addition).
- Use an AphrontErrorView to render the dry run notice (this didn't exist when I ported).
- Reenable some transaction code (this works again now).
- Removed the ability for admins to change rule authors (this was a little buggy, messy, and doesn't make tons of sense after the personal/global rule split).
- Rules which depend on other rules now display the right options (all global rules, all your personal rules for personal rules).
- Fix a bug in AphrontTableView where the "no data" cell would be rendered too wide if some columns are not visible.
- Allow selectFilter() in AphrontNavFilterView to be called without a 'default' argument.
Test Plan:
- Browsed, created, edited, deleted personal and gules.
- Verified generated logs.
- Did some dry runs.
- Verified transcript list and transcript details.
- Created/edited all/any rules; created/edited once/every time rules.
- Filtered admin views by users.
Reviewers: jungejason, btrahan
Reviewed By: btrahan
CC: aran, epriestley
Differential Revision: https://secure.phabricator.com/D2040
2012-03-30 19:49:55 +02:00
|
|
|
));
|
|
|
|
|
2013-01-21 16:46:13 +01:00
|
|
|
$crumbs = id($this->buildApplicationCrumbs())
|
|
|
|
->addCrumb(
|
|
|
|
id(new PhabricatorCrumbView())
|
|
|
|
->setName(pht('Transcripts'))
|
|
|
|
->setHref($this->getApplicationURI('/transcript/')))
|
|
|
|
->addCrumb(
|
|
|
|
id(new PhabricatorCrumbView())
|
|
|
|
->setName(pht('Test Console')));
|
|
|
|
$nav->setCrumbs($crumbs);
|
|
|
|
|
Update form styles, implement in many places
Summary:
This creates a common form look and feel across the site. I spent a bit of time working out a number of kinks in our various renderings. Some things:
- Font Styles are correctly applied for form elements now.
- Everything lines up!
- Selects are larger, easier to read, interact.
- Inputs have been squared.
- Consistant CSS applied glow (try it!)
- Improved Mobile Responsiveness
- CSS applied to all form elements, not just Aphront
- Many other minor tweaks.
I tried to hit as many high profile forms as possible in an effort to increase consistency. Stopped for now and will follow up after this lands. I know Evan is not a super fan of the glow, but after working with it for a week, it's way cleaner and responsive than the OS controls. Give it a try.
Test Plan: Tested many applications, forms, mobile and tablet.
Reviewers: epriestley, btrahan
Reviewed By: epriestley
CC: aran, Korvin
Differential Revision: https://secure.phabricator.com/D5860
2013-05-07 23:07:06 +02:00
|
|
|
return $this->buildApplicationPage(
|
General Herald refactoring pass
Summary:
**Who can delete global rules?**: I discussed this with @jungejason. The current behavior is that the rule author or any administrator can delete a global rule, but this
isn't consistent with who can edit a rule (anyone) and doesn't really make much sense (it's an artifact of the global/personal split). I proposed that anyone can delete a
rule but we don't actually delete them, and log the deletion. However, when it came time to actually write the code for this I backed off a bit and continued actually
deleting the rules -- I think this does a reasonable job of balancing accountability with complexity. So the new impelmentation is:
- Personal rules can be deleted only by their owners.
- Global rules can be deleted by any user.
- All deletes are logged.
- Logs are more detailed.
- All logged actions can be viewed in aggregate.
**Minor Cleanup**
- Merged `HomeController` and `AllController`.
- Moved most queries to Query classes.
- Use AphrontFormSelectControl::renderSelectTag() where appropriate (this is a fairly recent addition).
- Use an AphrontErrorView to render the dry run notice (this didn't exist when I ported).
- Reenable some transaction code (this works again now).
- Removed the ability for admins to change rule authors (this was a little buggy, messy, and doesn't make tons of sense after the personal/global rule split).
- Rules which depend on other rules now display the right options (all global rules, all your personal rules for personal rules).
- Fix a bug in AphrontTableView where the "no data" cell would be rendered too wide if some columns are not visible.
- Allow selectFilter() in AphrontNavFilterView to be called without a 'default' argument.
Test Plan:
- Browsed, created, edited, deleted personal and gules.
- Verified generated logs.
- Did some dry runs.
- Verified transcript list and transcript details.
- Created/edited all/any rules; created/edited once/every time rules.
- Filtered admin views by users.
Reviewers: jungejason, btrahan
Reviewed By: btrahan
CC: aran, epriestley
Differential Revision: https://secure.phabricator.com/D2040
2012-03-30 19:49:55 +02:00
|
|
|
$nav,
|
2011-03-24 21:49:21 +01:00
|
|
|
array(
|
Update form styles, implement in many places
Summary:
This creates a common form look and feel across the site. I spent a bit of time working out a number of kinks in our various renderings. Some things:
- Font Styles are correctly applied for form elements now.
- Everything lines up!
- Selects are larger, easier to read, interact.
- Inputs have been squared.
- Consistant CSS applied glow (try it!)
- Improved Mobile Responsiveness
- CSS applied to all form elements, not just Aphront
- Many other minor tweaks.
I tried to hit as many high profile forms as possible in an effort to increase consistency. Stopped for now and will follow up after this lands. I know Evan is not a super fan of the glow, but after working with it for a week, it's way cleaner and responsive than the OS controls. Give it a try.
Test Plan: Tested many applications, forms, mobile and tablet.
Reviewers: epriestley, btrahan
Reviewed By: epriestley
CC: aran, Korvin
Differential Revision: https://secure.phabricator.com/D5860
2013-05-07 23:07:06 +02:00
|
|
|
'title' => pht('Test Console'),
|
|
|
|
'dust' => true,
|
|
|
|
'device' => true,
|
2011-03-24 21:49:21 +01:00
|
|
|
));
|
|
|
|
}
|
|
|
|
|
|
|
|
}
|