Groups setup issues into Important, PHP, MySQL, and Base for easier parsing on initial installations.
Details
Details
- Reviewers
epriestley btrahan - Maniphest Tasks
- T7207: Consolidate MySQL Setup Issues?
- Commits
- Restricted Diffusion Commit
rPb701313e0ef2: Split Setup Issues into Groups
Test my internal server and various issues.
Diff Detail
Diff Detail
- Repository
- rP Phabricator
- Lint
Lint Not Applicable - Unit
Tests Not Applicable
Event Timeline
Comment Actions
I think we can simplify this by moving most of the logic to newIssue(), see inline. Basically:
- Have newIssue() do $issue->setGroup($this->getDefaultGroup()).
- Remove all setGroup(self::getGroup()).
- If any SetupCheck classes raise issues outside of their group (maybe some of the PHP stuff?), they can call setGroup() explicitly to change the group.
- Maybe consider defining constants on the base SetupCheck class, like GROUP_PHP, GROUP_MYSQL, etc., so this stuff is easier to grep for.
| src/applications/config/check/PhabricatorAuthSetupCheck.php | ||
|---|---|---|
| 5–7 | Maybe call this getDefaultGroup(), since the check itself isn't in a group, per se, and could issue warnings into multiple groups. | |
| 40 | You can just have newIssue() do this by default. Then specific checks can call it explicitly to override the default if they need to. | |
| src/applications/config/controller/PhabricatorConfigIssueListController.php | ||
| 38 | Maybe call these "Other Setup Issues"? The phrase "Base Setup Issues" isn't very clear to me. | |
| 38–59 | Maybe don't render these boxes when there are no issues? That is, if you have no MySQL issues, just don't show the group? Then we'd need to show something if you have no issues at all. But this seems cleaner and less overwhelming in the case where there are only a few issues, to me. | |