Summary: Ref T9640. On 7.0 we had signal handling issues so we can never support it, but async signals should resolve them on 7.1 or newer.
Test Plan: On PHP 7.1, got through the setup warning.
Reviewers: chad
Reviewed By: chad
Maniphest Tasks: T9640
Differential Revision: https://secure.phabricator.com/D17197
Summary: Ref T9640. This option was removed in PHP7, so there's no reason to warn about it.
Test Plan: No longer saw a setup warning on PHP7.
Reviewers: chad
Reviewed By: chad
Maniphest Tasks: T9640
Differential Revision: https://secure.phabricator.com/D17196
Summary:
Fixes T9482. Historically, Audit was somewhat confused about whether queries and views should act on the viewer's status or the object's status.
This realigns Audit to work like Differential: we show overall status for the commit, just like we show overall status for revisions. This better aligns with expectation and isn't weird/confusing, and bucketing should handle all the "what do //I// need to do" stuff now (or, at least, seems to have in Differential).
This is also how every other type of object works in every other application, AFAIK (all of them show object status, not viewer's-relationship-to-the-object status).
Test Plan:
- Viewed commit lists in Owners and Audit.
- Saw commit overall statuses, not my personal status.
Reviewers: chad
Reviewed By: chad
Maniphest Tasks: T9482
Differential Revision: https://secure.phabricator.com/D17195
Summary: Ref T10978. This is bare bones, but the SearchEngine is at least mostly in reasonable shape now, so get it in place and freeze the old stuff. I previously froze `audit.query`, which did much the same thing.
Test Plan: Issued some queries with the API, technically got results back.
Reviewers: chad
Reviewed By: chad
Maniphest Tasks: T10978
Differential Revision: https://secure.phabricator.com/D17194
Summary:
Fixes T7076. This could probably use some tweaking but should get the basics in place.
This shows overall object state (e.g., "Needs Review"), not individual viewer state (e.g., "you need to review this"). After the bucketing changes it seems like we're mostly in a reasonable place on showing global state instead of viewer state. This makes the overall change much easier than it might otherwise have been.
Test Plan: {F2351867}
Reviewers: chad
Reviewed By: chad
Maniphest Tasks: T7076
Differential Revision: https://secure.phabricator.com/D17193
Summary:
Fixes T9430. Fixes T9362. Fixes T9544. This changes the default view of Audit to work like Differential, where commits you need to audit or respond to are shown in buckets.
This is a bit messy and probably needs some followups. This stuff has changed from a compatibility viewpoint:
- The query works differently now (but in a better, modern way), so existing saved queries will need to be updated.
- I've removed the counters from the home page instead of updating them, since they're going to get wiped out by ProfileMenu soon anyway.
- When bucketed queries return too many results (more than 1,000) we now show a warning about it. This isn't greaaaat but it seems good enough for now.
Test Plan: {F2351123}
Reviewers: chad
Reviewed By: chad
Maniphest Tasks: T9430, T9362, T9544
Differential Revision: https://secure.phabricator.com/D17192
Summary: Ref T11114. Ref T10978. These hadn't made it over to EditEngine yet.
Test Plan:
- Took various actions on revisions and commits.
- Used `bin/mail show-outbound --id ...` to examine the "Vary Subject", saw it properly generate "[Accepted]", "[Resigned]", etc.
Reviewers: chad
Reviewed By: chad
Maniphest Tasks: T11114, T10978
Differential Revision: https://secure.phabricator.com/D17191
Summary: Ref T10978. Until T10448 makes mail tags modular, keep the old tags working.
Test Plan: Made some commit edits, ran `bin/phd debug task` to process mail for them.
Reviewers: chad
Reviewed By: chad
Maniphest Tasks: T10978
Differential Revision: https://secure.phabricator.com/D17190
Summary: Ref T10978. Since "Resigned" is a status in Audit, you could repeatedly resign. This is confusing; prevent it.
Test Plan: Tried to resign twice; was only allowed to resign once.
Reviewers: chad
Reviewed By: chad
Maniphest Tasks: T10978
Differential Revision: https://secure.phabricator.com/D17187
Summary:
Fixes T6630. Long ago, "Audit", "Diffusion" and "Repositories" were three totally separate applications.
This separation isn't useful and the three rapidly became intertwined. Ideally, they would all be one application.
This doesn't take us quite that far, but Audit no longer has any controllers and has little actual behavior.
The "Audit" screen has always just been a SearchEngine view of commits with some filters on it, and this formalizes that and puts a link to it in Diffusion. (This view has other uses, too.)
Test Plan:
- Accessed audit from home page.
- Accessed audit/commits from Diffusion.
- Could no longer uninstall Audit on its own.
- Grepped for `/audit/` and `AuditApplication`.
Reviewers: chad
Reviewed By: chad
Maniphest Tasks: T6630
Differential Revision: https://secure.phabricator.com/D17186
Summary: Fixes T7504. I think that task legitimately describes a bug and that the current behavior is counterintuitive.
Test Plan: Manually added an auditor to a commit with none; saw it become "Audit Required" as an overall state.
Reviewers: chad
Reviewed By: chad
Maniphest Tasks: T7504
Differential Revision: https://secure.phabricator.com/D17185
Summary:
Fixes T8739. Currently, Diffusion inline comments in the timeline are sorted arbitrarily, mostly by creation order.
Instead, sort them by line number, like Differential.
Test Plan:
Made comments in "C", "B", "A" order, saw them in line order after submit:
{F2343032}
Reviewers: chad
Reviewed By: chad
Maniphest Tasks: T8739
Differential Revision: https://secure.phabricator.com/D17184
Summary:
Ref T10978. This prepares for swapping the comment UI to stacked actions.
These are only accessible via the API.
Test Plan: Used the API to accept, raise concern with, and reject commits.
Reviewers: chad
Reviewed By: chad
Maniphest Tasks: T10978
Differential Revision: https://secure.phabricator.com/D17182
Summary: Ref T10978. Ref T7676. Make auditors work more like reviewers, so they can be freely added or removed.
Test Plan:
- Interacted with auditors via "Edit Commit" and API.
- Comment area is still oldschool and doesn't work yet.
Reviewers: chad
Reviewed By: chad
Maniphest Tasks: T10978, T7676
Differential Revision: https://secure.phabricator.com/D17181
Summary: Ref T11957, builds out `/home/menu/` as a basic structure for adding/editing the homepage menu.
Test Plan: visit `/home/menu/` and add items to global and personal. Not wired to anything.
Reviewers: epriestley
Reviewed By: epriestley
Subscribers: Korvin
Maniphest Tasks: T11957
Differential Revision: https://secure.phabricator.com/D17180
Summary: Ref T10978. This currently does almost nothing, but gets it in place so I can add stuff to it.
Test Plan: Made a comment on a commit using the API.
Reviewers: chad
Reviewed By: chad
Maniphest Tasks: T10978
Differential Revision: https://secure.phabricator.com/D17178
Summary: Ref T10978. The new controller now does everything the old one did, so swap 'em and nuke the old one.
Test Plan: Edited a commit, hit the new controller, things worked real good.
Reviewers: chad
Reviewed By: chad
Maniphest Tasks: T10978
Differential Revision: https://secure.phabricator.com/D17177
Summary: Ref T10978. The current "Edit" flow has some autoclose info. This isn't necessarily the best place to put it in the long run, but preseve it for now since the documentation refers to it.
Test Plan: {F2340658}
Reviewers: chad
Reviewed By: chad
Maniphest Tasks: T10978
Differential Revision: https://secure.phabricator.com/D17176
Summary:
Fixes T12097. In D16413, I simplified this code but caused us to load the //commit's// projects instead of the //repository's// projects, which is incorrect.
Normally, commits don't have any project tags when Herald evaluates, so using the commit's projects is generally meaningless.
Test Plan:
- Tagged a repository with `#X`.
- Created a Herald object rule for commits with `#X` as the object ("Always ... do nothing.")
- Ran a commit from the repository.
- Before patch: rule failed to evaluate.
- After patch: rule evaluated and passed.
Reviewers: chad
Reviewed By: chad
Maniphest Tasks: T12097
Differential Revision: https://secure.phabricator.com/D17179
Summary:
Ref T10978. After T11114, we have some features (like the old code for the haunted comment panel) which are only used by Diffusion. I want to modernize it so I can nuke them. T10978 also describes many bugs which are only fixable after modernizing.
This adds very basic EditEngine support for commits/audit. You can't create new commits with this workflow, just tag/update existing ones.
Test Plan: {F2340347}
Reviewers: chad
Reviewed By: chad
Maniphest Tasks: T10978
Differential Revision: https://secure.phabricator.com/D17175
Summary: Add in some basic defaults, Tasks, Projects, Repositories... anything else? Also switches "manage" context if you are an admin or user. Hides link if you are not logged in.
Test Plan: Review Global/Personal in Favorites app, click on each link.
Reviewers: epriestley
Reviewed By: epriestley
Subscribers: Korvin
Differential Revision: https://secure.phabricator.com/D17174
Summary: Moves basic colors into the processor.
Test Plan: Review a diff in sandbox with and without change.
Reviewers: epriestley
Reviewed By: epriestley
Subscribers: Korvin
Differential Revision: https://secure.phabricator.com/D17173
Summary:
Fixes T12092. D17164 made `DiffQuery` more strict about arguments using modern conventions, but `differential.querydiffs` uses bizarre ancient conventions.
Give it more modern conventions instead.
Test Plan: Made a `querydiffs` call with only revision IDs.
Reviewers: chad
Reviewed By: chad
Maniphest Tasks: T12092
Differential Revision: https://secure.phabricator.com/D17172
Summary: Ref T12089. This reverts back to using "bright" colors for full width changes in green and red.
Test Plan:
Review diffs, see full width colors.
{F2333933}
Reviewers: epriestley
Reviewed By: epriestley
Subscribers: Korvin
Maniphest Tasks: T12089
Differential Revision: https://secure.phabricator.com/D17171
Summary:
Fixes T12087. When transitioning into a clustered configuration for the first time, the documentation recommends using a one-device cluster as a transitional step.
However, installs may not do this for whatever reason, and we aren't as clear as we could be in warning about clusterizing directly into a multi-device cluster.
Roughly, when you do this, we end up believing that working copies exist on several different devices, but have no information about which copy or copies are up to date. //Usually// they all were already synchronized and are all up to date, but we can't make this assumption safely without risking data.
Instead, we err on the side of caution, and require a human to tell us which copy we should consider to be up-to-date, using `bin/repository thaw --promote`.
Test Plan:
```
$ ./bin/repository clusterize rLOCKS --service repos001.phacility.net
Service "repos001.phacility.net" is actively bound to more than one device
(local002.local, local001.phacility.net).
If you clusterize a repository onto this service it will be unclear which
devices have up-to-date copies of the repository. This leader/follower
ambiguity will freeze the repository. You may need to manually promote a
device to unfreeze it. See "Ambiguous Leaders" in the documentation for
discussion.
Continue anyway? [y/N]
```
Read other changes.
Reviewers: chad
Reviewed By: chad
Maniphest Tasks: T12087
Differential Revision: https://secure.phabricator.com/D17169
Summary: Fixes T12090. In obscure situations lost to the mists of time, the `changes` column could be `null`. Force a string cast so the migration finishes, even though these changesets are likely meaningless.
Test Plan:
I did a force-reapply as a sanity check:
```
$ ./bin/storage upgrade -f --apply phabricator:20161213.diff.01.hunks.php
```
That went cleanly; it would only have caught dramatic errors, but I didn't completely butcher things.
Reviewers: chad
Reviewed By: chad
Maniphest Tasks: T12090
Differential Revision: https://secure.phabricator.com/D17168
Summary: Ref T5867. Rough in a Favorites application, not wired to anything.
Test Plan: tbd. currently 404s so... I messed up something. Tossing up to read.
Reviewers: epriestley
Reviewed By: epriestley
Subscribers: Korvin
Maniphest Tasks: T5867
Differential Revision: https://secure.phabricator.com/D17160
Summary: Fixes T12086. This got dropped by accident while cleaning up haunting.
Test Plan: Loaed a revision, hit "?", hit n/j/p/etc
Reviewers: chad
Reviewed By: chad
Maniphest Tasks: T12086
Differential Revision: https://secure.phabricator.com/D17166
Summary:
See D17160. Previously, the `/edit/` route was never linked, but fataled when accessed. Make it 404 instead.
Also, fix an issue where editing "Application" menu items would fail because they didn't have a viewer.
Test Plan:
- Hit `/edit/`, got a 404.
- Edited an "Application" item.
- Moved, added, deleted, and edited other items.
Reviewers: chad
Reviewed By: chad
Differential Revision: https://secure.phabricator.com/D17165
Summary:
Fixes T10968. In rare situations, we can generate a diff, then hit an error which causes this update to fail.
When it does, we tend to get stuck in a loop creating diffs, which can fill the database up with garbage. We saw this once in the Phacility cluster, and one instance hit it, too.
Instead: when we create a diff, keep track of which commit we generated it from. The next time through, reuse it if we already built it.
Test Plan:
- Used `bin/differential attach-commit <commit> <revision>` to hit this code.
- Simulated a filesystem write failure, saw the diff get reused.
- Also did a normal update, which worked properly.
Reviewers: chad
Reviewed By: chad
Maniphest Tasks: T10968
Differential Revision: https://secure.phabricator.com/D17164
Summary:
Ref T12074. This uses more consistent Conduit keys for constraint names.
This is a minor compatibility break on watchers/members but since these methods are more useful now this is probably a good time to try to get away with it, and a more consistent API is better in the long run. I need to issue compatibility guidance for the milestones thing anyway and that one isn't avoidable, so try to rip the bandage off all in one go.
Test Plan: Reviewed new constraint names from console, called methods using them.
Reviewers: chad
Reviewed By: chad
Maniphest Tasks: T12074
Differential Revision: https://secure.phabricator.com/D17161
Summary:
Fixes T12082. Ref T11114. When modular transaction render a handle list, they use HandleListView, which has a text mode.
However, the HandleListView is a TagView, and currently TagViews always render a tag of some kind. Allow them to return `null` to decline to render any tag.
Test Plan:
- Added a pile of debugging stuff to `ApplicationTransactionEditor` to throw during mail generation.
- Added a reviewer to a revision.
- Used `bin/worker execute --id ...` to hit the mail generation repeatedly.
- Before patch: mail generated with a <span>, even in text mode.
- After patch: clean mail generation.
Reviewers: chad
Reviewed By: chad
Maniphest Tasks: T12082, T11114
Differential Revision: https://secure.phabricator.com/D17162
Summary: Ref T11114. After evaluating typeahead tokens, we could process blocking reviewer removals incorrectly: we may get structures back.
Test Plan: Removed blocking reviewers from the web UI.
Reviewers: chad
Reviewed By: chad
Maniphest Tasks: T11114
Differential Revision: https://secure.phabricator.com/D17163
Summary:
Ref T12074. The "v3" API methods (`*.search`, `*.edit`) are currently marked as "unstable", but they're pretty stable and essentially all new code should be using them.
Although these methods are seeing some changes, almost all changes are additive (support for new constraints or attachemnts) and do not break backward compatibility. We have no major, compatibility-breaking changes planned.
I don't want to mark the older methods "deprecated" yet since `arc` still uses a lot of them and there are some capabilities not yet available on the v3 methods, but introduce a new "frozen" status with pointers to the new methods.
Overall, this should gently push users toward the newer methods.
Test Plan: {F2325323}
Reviewers: chad
Reviewed By: chad
Maniphest Tasks: T12074
Differential Revision: https://secure.phabricator.com/D17158
Summary:
Ref T12074. Provide a basic but functional v3 API endpoint for reading workboard column information.
There is no equivalent to this in the UI yet, although there may be some day (perhaps adjacent to T5024).
Test Plan:
- Queried for all columns.
- Queried for columns on a particular board using `projectPHIDs`.
Reviewers: chad
Reviewed By: chad
Maniphest Tasks: T12074
Differential Revision: https://secure.phabricator.com/D17157
Summary:
Ref T12074. This allows callers to identify which columns an object appears in (currently, always tasks).
There are a few major cases:
- Object is in a normal column: we return column information.
- Object is in a proxy column (subproject or milestone). For example, when you look at the board for "Some Parent Project", the task might show up in a milestone column. I've chosen to not return anything in this case: you can figure out that the task is there by looking at the project structure, and this is kind of an internal artifact of the implementation and probably not useful to callers.
- Project does not have a workboard: we return nothing.
These seem fairly reasonable, I think?
Test Plan:
- Queried for tasks, using the "columns" attachment.
- Dragged a task across a board, querying it repeatedly. Got expected results for normal column (the column), subprojects with no board (nothing), milestones with no board (nothing) and mielstones/subprojects with a board (the column on //that// board, only, not the proxy column on the parent).
Reviewers: chad
Reviewed By: chad
Maniphest Tasks: T12074
Differential Revision: https://secure.phabricator.com/D17156
Summary:
Ref T12074. Allows querying for project by direct parent (find only immediate children) or any ancestor (find all descendants) using the API.
There's no proper web UI for this since I'm not sure how useful it is, but you can `/project/?parent=PHID-PROJ-...` or `/project/?ancestor=...` for now. We can add UI later if/when use cases arise, but it's not immediately clear to me that this is useful to do from the web.
Test Plan:
- From API, queried with `parentPHIDs` and `ancestorPHIDs`, finding direct children only and all descendants, respectively.
- From web UI, fiddled with `?parent=...` and `?ancestor=...` to make sure they work too. This isn't intended to be a user-facing feature.
Reviewers: chad
Reviewed By: chad
Maniphest Tasks: T12074
Differential Revision: https://secure.phabricator.com/D17155
Summary:
Ref T12074.
- Adds a new "parent" property on main results. This shows an abbreviated version of the project's parent, or `null` if the project is a root project.
- Adds a new "ancestor" attachment to pull the entire ancestor list.
- Adds a new "depth" property on main results.
- You can use "parent" or "depth" to tell if a project is a subproject or not.
These attempt to balance convenience, power, and performance: the full ancestor list can be big so I made it an attachment, but the other stuff isn't too big and is cheap and seems reasonable to always include.
Test Plan:
In API results:
- Saw null parent (root projects) and non-null parent (subprojects/milestones).
- Used "ancestors" attchment, got full list of ancestors.
- Saw appropriate "depth" values.
Reviewers: chad
Reviewed By: chad
Maniphest Tasks: T12074
Differential Revision: https://secure.phabricator.com/D17154
Summary:
Ref T12074.
- `project.search` now returns milestones by default.
- A new constraint, `isMilestone`, allows filtering to milestones, non-milestones, or both (API and web UI).
- `project.search` now returns a milestone number for milestones, or `null` for non-milestones.
NOTE: Existing custom saved queries in projects which previously did not return milestones now will. I expect this to have little-to-no impact on users, and these queries are easy to correct, but I'll note this in changelogs.
Test Plan:
- Ran various queries with `project.search` and in the web UI, searching for milestones, non-milestones, and both.
- Web UI default behavior (no milestones) is unchanged, but you can now get milestones if you want them.
- Queried a milestone by ID/PHID via API.
Reviewers: chad
Reviewed By: chad
Maniphest Tasks: T12074
Differential Revision: https://secure.phabricator.com/D17153
Summary:
Ref T9058. The stricter filtering is over-filtering Handles. For example, in the Phacility cluster, users can not see Almanac services.
So this filtering happens:
- The AlmanacServiceQuery filters the service beacuse they can't see the application.
- The HandleQuery generates a "you can't see this" handle.
- But then the HandleQuery filters that handle! It has a "service" PHID and the user can't see Almanac.
This violates the assumption that all application code makes about handles: it's OK to query handles for objects you can't see, and you'll get something back.
Instead, don't do application filtering on handles.
Test Plan:
- Added a failing test and made it pass.
- As a user who can not see Almanac, viewed an Instances timeline.
- Before patch: fatal on trying to load a handle for a Service.
- After patch: smooth sailing.
Reviewers: chad
Maniphest Tasks: T9058
Differential Revision: https://secure.phabricator.com/D17152
Summary: Fixes T12080. This was missing a "/", but stop hard-coding these URIs.
Test Plan: Clicked both links with Quickling as a logged-in and logged-out user, ended up in the right place.
Reviewers: chad
Reviewed By: chad
Maniphest Tasks: T12080
Differential Revision: https://secure.phabricator.com/D17151
Summary: Ref T5867, adds a customPHID field, nullable, and lets you query by it... i think? Not fully able to grok all the EditEngine stuff, but I think this is the right place for the query.
Test Plan: Not wired to anything, but pulling up project menu, editing, all still works.
Reviewers: epriestley
Reviewed By: epriestley
Subscribers: Korvin
Maniphest Tasks: T5867
Differential Revision: https://secure.phabricator.com/D17149
Summary: Ref T11816. The underlying format of recurrence end dates swapped around a bit and we now try to compare `null` to a valid date if you're setting it for the first time.
Test Plan:
- On a new event, set a recurrence end date.
- Then, removed a recurrence end date.
Reviewers: chad
Reviewed By: chad
Maniphest Tasks: T11816
Differential Revision: https://secure.phabricator.com/D17150
Summary:
Fixes T10687. Fixes T12064.
- Primarily, adds a margin around the edge of the screen for the purposes of aligning the tooltip.
- Also, tries to flip the tooltip if it can (e.g., if the tooltip normally goes east, try west first), then tries other positions exhastively.
Test Plan:
{F2309363}
{F2309364}
Reviewers: chad
Reviewed By: chad
Maniphest Tasks: T12064, T10687
Differential Revision: https://secure.phabricator.com/D17145
Summary:
Ref T11114. When you comment, we try to upgrade your review status to "commented".
This can conflict with upgrading it to "accepted" or "rejected", or removing it entirely.
For now, just avoid making this update. After T10967, I expect "you commented" to be orthogonal to accepted/rejected so it should stop conflicting on its own.
Test Plan:
- As an "added" reviewer, accepted a revision with a comment in the same transaction.
- Before patch: accept didn't stick.
- After patch: accept sticks.
This may be somewhat magical/order-dependent but I was able to reproduce it locally.
Reviewers: chad
Reviewed By: chad
Maniphest Tasks: T11114
Differential Revision: https://secure.phabricator.com/D17146
Summary: Fixes T12068. These are inbound messages, not outbound.
Test Plan: Read carefully.
Reviewers: chad
Reviewed By: chad
Maniphest Tasks: T12068
Differential Revision: https://secure.phabricator.com/D17144
