Summary: Currently, we just create a default "backlog" column if / when you visit a workboard for the first time. Post this patch, instead you see a blocking dialog that lets you either create the default backlog column or import columns from another project. In the case of the latter, the user gets another dialog which lets them select any project of which they are a member that also has columns in it. Note that only not hidden columns get imported. Fixes T4431.
Test Plan:
- made a new workboard and got my new dialog. made a default backlog and it worked!
- made a new workboard again and tried the import flow - it also worked.
- verified projects with no columns do not show up in import dialog
- verified project with / without columns still all show up in maniphest project typeahead
Reviewers: epriestley
Reviewed By: epriestley
Subscribers: epriestley, Korvin
Maniphest Tasks: T4431
Differential Revision: https://secure.phabricator.com/D10153
Summary: Ref T4896. This was used by the old audit comment storage, which is now defunct.
Test Plan: Grepped for callsites in the codebase.
Reviewers: joshuaspence, btrahan
Reviewed By: btrahan
Subscribers: epriestley
Maniphest Tasks: T4896
Differential Revision: https://secure.phabricator.com/D10152
Summary:
Fixes T5728. In particular:
- `/tag/XYZ/` now works as an alias for `/tag/xyz/`.
- `arc todo --project ASDF` now works as an alias for `arc todo --project asdf`.
Test Plan: Called `project.query` and visited `/tag/LBHABLHBH/`.
Reviewers: btrahan
Reviewed By: btrahan
Subscribers: aklapper, epriestley
Maniphest Tasks: T5728
Differential Revision: https://secure.phabricator.com/D10144
Summary: Fixes T5510. This purely reduces false positives from HackerOne: we currently rotate CSRF tokens, but do not bind them explicitly to specific sessions. Doing so has no real security benefit and may make some session rotation changes more difficult down the line, but researchers routinely report it. Just conform to expectations since the expected behavior isn't bad and this is less work for us than dealing with false positives.
Test Plan:
- With two browsers logged in under the same user, verified I was issued different CSRF tokens.
- Verified the token from one browser did not work in the other browser's session.
Reviewers: btrahan
Reviewed By: btrahan
Subscribers: epriestley
Maniphest Tasks: T5510
Differential Revision: https://secure.phabricator.com/D10136
Summary:
Fixes T5509. Currently, existing sessions live on even if you change your password.
Over the course of the program, we've recieved a lot of HackerOne reports that sessions do not terminate when users change their passwords. I hold that this isn't a security vulnerability: users can explicitly manage sessions, and this is more general and more powerful than tying session termination to password resets. In particular, many installs do not use a password provider at all (and no researcher has reported this in a general, application-aware way that discusses multiple authentication providers).
That said, dealing with these false positives is vaguely time consuming, and the "expected" behavior isn't bad for users, so just align behavior with researcher expectations: when passwords are changed, providers are removed, or multi-factor authentication is added to an account, terminate all other active login sessions.
Test Plan:
- Using two browsers, established multiple login sessions.
- In one browser, changed account password. Saw session terminate and logout in the second browser.
- In one browser, removed an authentication provider. Saw session terminate and logout in the second browser.
- In one browser, added MFA. Saw session terminate and logout in the second browser.
Reviewers: btrahan
Reviewed By: btrahan
Subscribers: epriestley
Maniphest Tasks: T5509
Differential Revision: https://secure.phabricator.com/D10135
Summary:
Fixes T5506. Depends on D10133. When users remove an email address or change their primary email address, invalidate any outstanding password reset links.
This is a very small security risk, but the current behavior is somewhat surprising, and an attacker could sit on a reset link for up to 24 hours and then use it to re-compromise an account.
Test Plan:
- Changed primary address and removed addreses.
- Verified these actions invalidated outstanding one-time login temporary tokens.
- Tried to use revoked reset links.
- Revoked normally from new UI panel.
Reviewers: btrahan
Reviewed By: btrahan
Subscribers: epriestley
Maniphest Tasks: T5506
Differential Revision: https://secure.phabricator.com/D10134
Summary:
Ref T5506. This makes it easier to understand and manage temporary tokens.
Eventually this could be more user-friendly, since it's relatively difficult to understand what this screen means. My short-term goal is just to make the next change easier to implement and test.
The next diff will close a small security weakness: if you change your email address, password reset links which were sent to the old address are still valid. Although an attacker would need substantial access to exploit this (essentially, it would just make it easier for them to re-compromise an already compromised account), it's a bit surprising. In the next diff, email address changes will invalidate outstanding password reset links.
Test Plan:
- Viewed outstanding tokens.
- Added tokens to the list by making "Forgot your password?" requests.
- Revoked tokens individually.
- Revoked all tokens.
- Tried to use a revoked token.
Reviewers: btrahan
Reviewed By: btrahan
Subscribers: epriestley
Maniphest Tasks: T5506
Differential Revision: https://secure.phabricator.com/D10133
Summary:
Ref T4896. Now that we have a transaction editor, we can delete a giant block of hacks.
I believe this also resolves the commit/task attachment issues @joshuaspence and @mbishopim3 mentioned.
Test Plan: Attached and detached commits and tasks.
Reviewers: btrahan, joshuaspence, mbishopim3
Reviewed By: mbishopim3
Subscribers: mbishopim3, epriestley, joshuaspence
Maniphest Tasks: T4896
Differential Revision: https://secure.phabricator.com/D10138
Summary: Ref T4896. I got this logic slightly wrong when porting it over: we always want to write this relationship, to allow members of a project with an audit request against a commit to resign and get it out of their queue.
Test Plan:
- Resigned from a commit with an existing relationship.
- Resigned from a commit with no existing relationship, saw one added.
Reviewers: btrahan, joshuaspence, mbishopim3
Reviewed By: mbishopim3
Subscribers: epriestley
Maniphest Tasks: T4896
Differential Revision: https://secure.phabricator.com/D10137
Summary:
Ref T4589. We don't recognize task descriptions as remarkup blocks, so `{F...}` references in them do not get attached to the objects, and thus no policy exemption is created.
Recognize them, which activates `{F...}` and `@mentions`.
We probably have a few more of these in other applications, but it's not a big deal to clean them up as they arise.
Test Plan: Uploaded a file to a task in the description field, saw it attach and get a policy exemption.
Reviewers: btrahan
Reviewed By: btrahan
Subscribers: epriestley
Maniphest Tasks: T4589
Differential Revision: https://secure.phabricator.com/D10139
Summary:
Ref T4589. When you look at a file, we load attached objects in order to run the "you can see this if you can see any attached object" policy check.
However, right now the subquery inherits the "throw on filter" flag from the parent query. This inheritance makes sense in other cases[1], but because this is an "ANY" rule it does not make sense here. In practice, it means that if the file is attached to several objects, and any of them gets filtered, you can not see the file.
Instead, explicitly drop the flag for this subquery.
[1] Sort of. It doesn't produce wrong results in other cases, but now that I think about it might produce a less-tailored error than it could. I'll look into this the next time I'm poking around.
Test Plan:
- Viewed an "All Users" file attached to a private Mock.
- Prior to this patch, I incorrectly received an exception when the Mock was loaded. This is wrong; I should be able to see the file because the policy is "All Users".
- After the patch, I can correctly view the file, just not the associated mock.
{F127074}
Reviewers: btrahan
Reviewed By: btrahan
Subscribers: 20after4, aran, epriestley
Maniphest Tasks: T4589
Differential Revision: https://secure.phabricator.com/D8498
Summary:
Fixes T4589. This implements much better policy behavior for files that aligns with user expectations.
Currently, all files have permissive visibility.
The new behavior is:
- Files uploaded via drag-and-drop to the home page or file upload page get permissive visibility, for ease of quickly sharing things like screenshots.
- Files uploaded via the manual file upload control get permissive visibility by default, but the user can select the policy they want at upload time in an explicit/obvious way.
- Files uploaded via drag-and-drop anywhere else (e.g., comments or Pholio) get restricted visibility (only the uploader).
- When the user applies a transaction to the object which uses the file, we attach the file to the object and punch a hole through the policies: if you can see the object, you can see the file.
- This rule requires things to use ApplicationTransactions, which is why this took so long to fix.
- The "attach stuff to the object" code has been in place for a long time and works correctly.
I'll land D8498 after this lands, too.
Test Plan:
- Uploaded via global homepage upload and file drag-and-drop upload, saw permissive visibility.
- Uploaded via comment area, saw restricted visibility.
- After commenting, verified links were established and the file became visible to users who could see the attached object.
- Verified Pholio (which is a bit of a special case) correctly attaches images.
Reviewers: btrahan
Reviewed By: btrahan
Subscribers: epriestley
Maniphest Tasks: T4589
Differential Revision: https://secure.phabricator.com/D10131
Summary: Ref T4589. Depends on D10129. In addition to letting users change the visibility policy for files, also allow them to choose a policy explicitly when a file is uploaded.
Test Plan: Uploaded several files using the plain old uploader, saw appropriate visibility policies applied.
Reviewers: btrahan
Reviewed By: btrahan
Subscribers: epriestley
Maniphest Tasks: T4589
Differential Revision: https://secure.phabricator.com/D10130
Summary: Ref T4589. Allow users to adjust visibility settings on files explicitly. This makes it easier to understand and manage upcoming changes in T4589.
Test Plan: Changed the view policy for a file several times.
Reviewers: btrahan
Reviewed By: btrahan
Subscribers: epriestley
Maniphest Tasks: T4589
Differential Revision: https://secure.phabricator.com/D10129
Summary: Ref T4896. This converts the last "CommentEditor" to a transaction editor and removes a large part of the old code.
Test Plan:
- Added comments.
- Accepted / added auditors.
- Added inline comments.
Reviewers: joshuaspence, btrahan
Reviewed By: btrahan
Subscribers: epriestley
Maniphest Tasks: T4896
Differential Revision: https://secure.phabricator.com/D10128
Summary: Ref T4896. Invoke the new editor directly instead of in a roundabout way when handling Audit email.
Test Plan: Used `bin/mail receive-test` to simulate mail, saw comment post with proper content source.
Reviewers: joshuaspence, btrahan
Reviewed By: btrahan
Subscribers: epriestley
Maniphest Tasks: T4896
Differential Revision: https://secure.phabricator.com/D10127
Summary: Ref T4896. Use the new transaction-oriented `PhabricatorAuditEditor` directly instead of invoking it via the old editor.
Test Plan: Used Conduit to add a comment, use silent mode, and accept a commit.
Reviewers: joshuaspence, btrahan
Reviewed By: btrahan
Subscribers: epriestley
Maniphest Tasks: T4896
Differential Revision: https://secure.phabricator.com/D10126
Summary: Ref T4896. Applies these actions using new transaction stuff.
Test Plan:
- Accepted and raised concern with my own commit, verifying the special project/package behavior.
- Accepted and raised concern with another author's commit, verifying the authority-over-packages/projects behavior.
- Accepted a commit I was not affiliated wiht, verifying the "join as an auditor" behavior.
Reviewers: joshuaspence, btrahan
Reviewed By: btrahan
Subscribers: epriestley
Maniphest Tasks: T4896
Differential Revision: https://secure.phabricator.com/D10125
Summary: Ref T4896. Hook these up with new stuff.
Test Plan:
- Closed an audit.
- Resigned from an audit.
Reviewers: joshuaspence, btrahan
Reviewed By: btrahan
Subscribers: epriestley
Maniphest Tasks: T4896
Differential Revision: https://secure.phabricator.com/D10124
Summary:
Ref T4896. Move the write for "Add Auditors" inside the new Editor.
There are no longer any readers or writers for metadata, so remove the calls for it.
Test Plan: Added auditors from the web UI.
Reviewers: joshuaspence, btrahan
Reviewed By: btrahan
Subscribers: epriestley
Maniphest Tasks: T4896
Differential Revision: https://secure.phabricator.com/D10123
Summary: Ref T4659. Because we JOIN, tasks with no value are filtered out. Instead, LEFT JOIN.
Test Plan: Issued an "Order by" and got all applicable tasks. Adjusted values and saw order change.
Reviewers: btrahan, hach-que
Reviewed By: hach-que
Subscribers: epriestley
Maniphest Tasks: T4659
Differential Revision: https://secure.phabricator.com/D10119
Summary:
Resolves T4659. This implements support for sorting tasks by custom fields.
Some of this feels hacky in the way it's hooked up to the Maniphest search engine and task query.
Test Plan: Queryed on a custom date field, with a small page size, and moved back and forth through the result set.
Reviewers: #blessed_reviewers, epriestley
Reviewed By: #blessed_reviewers, epriestley
Subscribers: epriestley, Korvin
Maniphest Tasks: T4659
Differential Revision: https://secure.phabricator.com/D10106
Summary: This class was renamed in D9991 but the filename is incorrect.
Test Plan: Eyeball it
Reviewers: epriestley, #blessed_reviewers
Reviewed By: epriestley, #blessed_reviewers
Subscribers: epriestley, Korvin
Differential Revision: https://secure.phabricator.com/D10118
Summary: Ref T4896. Instead of using custom stuff, use standard stuff.
Test Plan: Viewed a bunch of feed stories and published some over the Asana bridge.
Reviewers: joshuaspence, btrahan
Reviewed By: btrahan
Subscribers: epriestley
Maniphest Tasks: T4896
Differential Revision: https://secure.phabricator.com/D10114
Summary: Ref T4896. Replace custom stuff with standard stuff.
Test Plan:
- Sent a bunch of email and it all looked sensible/correct.
- Made sure to test inlines, specifically, as they're a bit tricky.
Reviewers: joshuaspence, btrahan
Reviewed By: btrahan
Subscribers: epriestley
Maniphest Tasks: T4896
Differential Revision: https://secure.phabricator.com/D10112
Summary: Ref T4896.
Test Plan: Made an unusual comment, then found it by searching.
Reviewers: btrahan, joshuaspence
Reviewed By: btrahan, joshuaspence
Subscribers: epriestley
Maniphest Tasks: T4896
Differential Revision: https://secure.phabricator.com/D10110
Summary:
Ref T4896. Replaces more custom stuff with standard stuff. In particular:
- No more fake proxy writes;
- no more fake detection of `@mentions`.
For now, the old code still applies most of the effects and handles feed and email.
Test Plan:
- Added comments.
- Added comments with inline comments.
- Added just inline comments.
- Added comments with Conduit.
- Previewed comments.
- Added CCs explicitly and with `@mentions`.
- Added auditors.
- Accepted a commit.
Reviewers: joshuaspence, btrahan
Reviewed By: btrahan
Subscribers: epriestley
Maniphest Tasks: T4896
Differential Revision: https://secure.phabricator.com/D10109
Summary:
Ref T4896. Currently, subscriptions to commits are stored as auditors with a special "CC" type.
Instead, use normal subscriptions storage, reads and writes.
Test Plan:
- Ran migration and verified data still looked good.
- Viewed commits in UI and saw "subscribers".
- Saw "Automatically Subscribed", clicked Subscribe/Unsubscribe on a non-authored commit, saw subscriptions update.
- Pushed a commit through Herald rules and saw them trigger subscriptions and auditors.
- Used "Add CCs".
- Added CCs with mentions.
Reviewers: btrahan, joshuaspence
Reviewed By: btrahan, joshuaspence
Subscribers: epriestley
Maniphest Tasks: T4896
Differential Revision: https://secure.phabricator.com/D10103
Summary: This class was renamed in D9991, but the filename is incorrect.
Test Plan: Eyeball it
Reviewers: epriestley, #blessed_reviewers
Reviewed By: epriestley, #blessed_reviewers
Subscribers: epriestley, Korvin
Differential Revision: https://secure.phabricator.com/D10117
Summary:
Fixes T5666. When we have a pretty link right now it can conflict with form data; e.g. if you have 'statuses=open' in the URI and then uncheck status = open in the UI, you will still get the open status in the next search.
To fix this, set the form action explicitly to lose all the get parameter junk.
Test Plan: tried the test case in T5666 / this description and it no longer failed...!
Reviewers: epriestley
Reviewed By: epriestley
Subscribers: epriestley, Korvin
Maniphest Tasks: T5666
Differential Revision: https://secure.phabricator.com/D10115
Summary:
pre-patch "Mark All Read" marks *all* unread notifications as read. This is a race condition in that the user is looking at some set of notiifcations and that set may update such that the newest notifications aren't shown. An example might be if sitting on the notifications page or having the menu open while a new notification comes in... Note re-opening the menu would show the latest notifications.
This patch makes it so "Mark All Read" links only marks the notifications currently loaded (and older.) Fixes T5764.
Additionally, if there is nothing to "mark read" the button / link "Mark All Read" will have a disabled style and yield a dialog saying "nothing to mark as read".
Test Plan: carefully tracked ?chronoKey populating correctly in various links. Verified query constructed properly too.
Reviewers: epriestley
Reviewed By: epriestley
Subscribers: epriestley, Korvin
Maniphest Tasks: T5764
Differential Revision: https://secure.phabricator.com/D10113
Summary: $this->id wasn't being set in this case so just set it explicitly after we finish loading the project. Fixes T5763.
Test Plan: links were broken no longer!
Reviewers: epriestley
Reviewed By: epriestley
Subscribers: epriestley, Korvin
Maniphest Tasks: T5763
Differential Revision: https://secure.phabricator.com/D10108
Summary: This moves the status property of the build to the bottom of the property list so that it matches the build targets.
Test Plan: Viewed a build, saw the status in the right position.
Reviewers: #blessed_reviewers, epriestley
Reviewed By: #blessed_reviewers, epriestley
Subscribers: epriestley, Korvin
Differential Revision: https://secure.phabricator.com/D10096
Summary: This shows the status icon and color along side the build status on the build view controller.
Test Plan: Viewed a build, saw the icon appear.
Reviewers: epriestley, #blessed_reviewers
Reviewed By: epriestley, #blessed_reviewers
Subscribers: epriestley, Korvin
Differential Revision: https://secure.phabricator.com/D10094
Summary:
Ref T1049. This uses tabs on build targets to hide the configuration details and variables by default, instead promoting the target name, it's status and a description of the build step. The description is a new field on each build step.
The primary advantage of having a description on build steps is that DevOps can configure appropriate description information (including any troubleshooting information for build failures) on build steps, and developers who have builds fail against their code review can then look at this information.
Test Plan: Viewed a build plan and saw the appropriate information.
Reviewers: #blessed_reviewers, epriestley
Reviewed By: #blessed_reviewers, epriestley
Subscribers: epriestley, Korvin
Maniphest Tasks: T1049
Differential Revision: https://secure.phabricator.com/D10093
Summary: Ref T1049. This hides the build target messages area if there are no messages for the target. Since most of the time a build target won't recieve any messages, this area is confusing because it's always empty.
Test Plan: Viewed a build, saw the empty build target message areas disappear.
Reviewers: #blessed_reviewers, epriestley
Reviewed By: #blessed_reviewers, epriestley
Subscribers: epriestley, Korvin
Maniphest Tasks: T1049
Differential Revision: https://secure.phabricator.com/D10092
Summary: We've received feedback that the "core - exception" is incredibly confusing, to the point where developers see this and write off the build failure as a Phabricator error that is unrelated to their changes.
Test Plan: Ran a build with a `exit 1` run step, didn't see the "core - exception" appear.
Reviewers: epriestley, #blessed_reviewers
Reviewed By: epriestley, #blessed_reviewers
Subscribers: epriestley, Korvin
Differential Revision: https://secure.phabricator.com/D10090
Summary: This fix is wrong - should be load and not get - but moreover this is actually correctly set as the reply handler is instantiated inside the DifferentialRevisionMailReceiver correctly; $this->getExclude was correct. Ref T5185.
Test Plan: this shall stop the fatal in production.
Reviewers: chad, epriestley
Reviewed By: epriestley
Subscribers: epriestley, Korvin
Maniphest Tasks: T5185
Differential Revision: https://secure.phabricator.com/D10101
Summary: This makes input artifacts imply the appropriate build step dependencies in the build plan. That is, if you use a host artifact in a build step, it will then implicitly depend on the 'Lease Host' step.
Test Plan: Viewed the build plan with the artifacts, saw the dependencies. Ran a build, saw everything execute in the correct order.
Reviewers: #blessed_reviewers, epriestley
Reviewed By: #blessed_reviewers, epriestley
Subscribers: epriestley, Korvin
Differential Revision: https://secure.phabricator.com/D10089
Summary: Ref T5185. By code inspection, I am pretty sure before this patch it was doing a set of a get on itself which does nothing. Now, being careful not to break Facebook we get the proper exclusion phids. I am pretty sure the folks in T5185 are experiencing this in Differential only.
Test Plan: Get some folks on T5185 to play with this
Reviewers: epriestley
Reviewed By: epriestley
Subscribers: epriestley, Korvin
Maniphest Tasks: T5185
Differential Revision: https://secure.phabricator.com/D10087
Summary:
Depends on D9806. This implements the build simulator, which is used to calculate the order of build steps in the plan editor. This includes a migration script to convert existing plans from sequential based to dependency based, and then drops the sequence column.
Because build plans are now dependency based, the grippable and re-order behaviour has been removed.
Test Plan: Tested the migration, saw the dependencies appear correctly.
Reviewers: epriestley, #blessed_reviewers
Reviewed By: epriestley, #blessed_reviewers
Subscribers: epriestley, Korvin
Differential Revision: https://secure.phabricator.com/D9847
Summary: Fixes T5751. Currently, we incorrectly overwrite `$xactions`.
Test Plan: Closed a blocking task, got an email about the correct transaction set ("closed task; added comment") instead of an overwritten transaction set ("closed blocking task").
Reviewers: chad, btrahan
Reviewed By: btrahan
Subscribers: epriestley
Maniphest Tasks: T5751
Differential Revision: https://secure.phabricator.com/D10088
Summary: This was causing a crash according to a conversation with @rfergu in IRC. The issue is that if `$images_to_show` is empty, then `$image` never gets set, and it attempts to call `getID` on a null / unset variable.
Test Plan: @rfergu confirmed this fixed the crash.
Reviewers: #blessed_reviewers, epriestley
Reviewed By: #blessed_reviewers, epriestley
Subscribers: Korvin, rfergu, epriestley
Differential Revision: https://secure.phabricator.com/D10073
Summary: Fixes T5653.
Test Plan: made a macro with sound and it played. changed it to not play and it did not play. changed it back and it played once more.
Reviewers: epriestley
Reviewed By: epriestley
Subscribers: epriestley, Korvin
Maniphest Tasks: T5653
Differential Revision: https://secure.phabricator.com/D10085
Summary:
This Fixes T5737. Apparently the functionality to search by different
statuses in differential was already there, but the options weren't
exposed in the frontend. I can't think of any reason why this should've
been the case, so I just added the other options.
Test Plan: Tested against some local diffs to match new query option.
Reviewers: joshuaspence, epriestley, #blessed_reviewers
Reviewed By: epriestley, #blessed_reviewers
Subscribers: epriestley, Korvin
Maniphest Tasks: T5737
Differential Revision: https://secure.phabricator.com/D10076
Summary: At least on my install, sorting was pretty borked from a type issue. (e.g. "unbreak now" of 100 sorting as less than "High" of 90). Fix this with some parseInt action. Also support adding new cards with the new colsort stuff. The clever bit here is to include the task ID in the sorting vector because the task ID wins ties at the moment I think / new tasks need to show up before older tasks when they are initially created. Fixes T5716.
Test Plan: added many "normal" priority cards and saw them fly in correctly. changed priority and moved correctly. made no edits and no moves were made correctly.
Reviewers: epriestley
Reviewed By: epriestley
Subscribers: epriestley, Korvin
Maniphest Tasks: T5716
Differential Revision: https://secure.phabricator.com/D10081
Summary: been some changes here and this code was broked. turns out we re-assign $action like two lines later and never used the initial value, so we can simply delete the offending line. Fixes T5745.
Test Plan: submitted inline comment pre-patch and fatal. re-submitted post patch and great success!
Reviewers: epriestley
Reviewed By: epriestley
Subscribers: epriestley, Korvin
Maniphest Tasks: T5745
Differential Revision: https://secure.phabricator.com/D10078
Summary: Currently, content runs before header. Instead, run header, content, footer. This makes it easier to use `header.php` for includes, for Phacility.
Test Plan: Made Phacility blog work better, see next diff.
Reviewers: chad
Reviewed By: chad
Subscribers: epriestley
Differential Revision: https://secure.phabricator.com/D10067
Summary:
Ref T4896. Depends on D10056. Moves search indexing to standard infrastructure.
Also, fixes a bug where inline comments would not be indexed.
Test Plan: Used `bin/search index ... --trace` to view index construction of a commit, saw all the comments and inlines get indexed.
Reviewers: btrahan, joshuaspence
Reviewed By: joshuaspence
Subscribers: epriestley
Maniphest Tasks: T4896
Differential Revision: https://secure.phabricator.com/D10057
Summary: Ref T4896. Depends on D10055. This uses core rendering stuff for audit comments, and fixes all the wonkiness with inlines so we can actually land the migration.
Test Plan: Viewed, previewed and edited various types of comments in Diffusion.
Reviewers: chad, btrahan, joshuaspence
Reviewed By: joshuaspence
Subscribers: epriestley
Maniphest Tasks: T4896
Differential Revision: https://secure.phabricator.com/D10056
Summary:
Ref T4896. Depends on D10052. This is the major/scary migration, but not really so bad. It is substantially similar to D8210, but less complex because there are fewer actions here.
This moves `PhabricatorAuditComment` storage to `PhabricatorAuditTransaction`, then reads `PhabricatorAuditComment`s as a proxy around the new objects.
Test Plan:
- Before migrating, browsed around. Nothing appeared broken.
- Migrated cleanly.
- Viewed old transactions (inlines, comments, accept/reject/etc, add auditors, add ccs, implicit CCs).
- Added all of those comment types.
- Edited a draft.
- Deleted a draft.
- Spot checked the database for sanity.
Reviewers: btrahan, joshuaspence
Reviewed By: joshuaspence
Subscribers: epriestley
Maniphest Tasks: T4896
Differential Revision: https://secure.phabricator.com/D10055
Summary:
Ref T4896. Depends on D10023. Prepares the code for the final migration.
The transaction table stores one row per distinct effect (e.g., add CCs) rather than one row per user action (e.g., "add CCs + comment"). We can double-read that table as long as the code doesn't expect transactions/comments to have multiple different effects, and doesn't try to write any such rows.
Everywhere that we were writing a big "X + Y" comment, write two separate "X" and "Y" comments instead. Like D10023, this disrupts the UI a little (you get more boxes), but that will be resolved once the rendering code swaps over. Otherwise, this retains the existing behavior.
Test Plan:
- Used `diffusion.createcomment` to add comments, raise concern, and accept.
- Previewed commenting, adding auditors/ccs, accepting, raising concern.
- Actually performed commenting, adding auditors/ccs, accepting, raising concern.
- Added a user with mentions.
- Added an explicit CC and a mention user.
Reviewers: btrahan, joshuaspence
Reviewed By: joshuaspence
Subscribers: epriestley
Maniphest Tasks: T4896
Differential Revision: https://secure.phabricator.com/D10052
Summary:
Ref T4896. Moves us closer to migrating comments to transactions by building a transaction per inline.
This makes the UI a little wonky, and it will get slightly worse until we swap to the new UI and grouping/collapsing starts working. It's still usable, there's just a box per inline.
Test Plan:
- Added a comment.
- Added an inline comment.
- Added a comment and an inline comment.
Reviewers: btrahan, joshuaspence
Reviewed By: joshuaspence
Subscribers: epriestley
Maniphest Tasks: T4896
Differential Revision: https://secure.phabricator.com/D10023
Summary: Adds Phriction to list of apps that use Source Sans as default font in addition to Legalpad and Diviner.
Test Plan: Tested various layouts imported from secure. Should be reasonably tested, but will follow up on secure.
Reviewers: epriestley
Reviewed By: epriestley
Subscribers: epriestley, Korvin
Differential Revision: https://secure.phabricator.com/D10064
Summary:
Fixes T5707. After work on T5245, the `$task` object may not have the correct set of task PHIDs attached to it when Herald is invoked.
Instead, just fetch the authoritative set. This is simple, and Herald is not super performance sensitive (happens on a write) so hitting the DB once is fine.
Test Plan: Created a task with projects, verified the projects field contained the correct values when processed by Herald.
Reviewers: chad, btrahan, joshuaspence
Reviewed By: joshuaspence
Subscribers: epriestley
Maniphest Tasks: T5707
Differential Revision: https://secure.phabricator.com/D10060
Summary: Fixes T5717. Like other partial edits, object links should not be blocked by unrelated missing fields on the object.
Test Plan:
- Linked two objects.
- Verified the inverse editor already sets "continue on missing fields" and "continue on no effect".
Reviewers: chad, btrahan, joshuaspence
Reviewed By: joshuaspence
Subscribers: epriestley
Maniphest Tasks: T5717
Differential Revision: https://secure.phabricator.com/D10059
Summary: Initially the change is aimed to solve issue with line breaks being lost in projects descriptions. But it is done in a general place so line breaks behavior is more consistent all over the place.
Test Plan:
- Write a multiline description of the project, using single \n for line breakers.
- View project details in project/view/X?
Reviewers: #blessed_reviewers, epriestley
Reviewed By: #blessed_reviewers, epriestley
Subscribers: epriestley, Korvin
Differential Revision: https://secure.phabricator.com/D10014
Summary:
Handling readmes with no extension is a bit of a hack, but seemed like a small cost.
The Big Win here is that you can commit README.remarkup and README.md and have both Phabricator and GitHub render __with__ //all// ##the## ~~pretty~~ **markup**.
Test Plan: Looked at some readme files.
Reviewers: epriestley, #blessed_reviewers
Reviewed By: epriestley, #blessed_reviewers
Subscribers: epriestley, Korvin
Differential Revision: https://secure.phabricator.com/D10047
Summary:
Instead of allowing all routes based on security.alternate-file-domain, now, when security.alternate-file-domain is set, and the request matches this domain, requests are validated against an explicit list. Allowed routes:
- /res/
- /file/data/
- /file/xform/
- /phame/r/
This will be redone by T5702 to be less of a hack.
Test Plan:
- browse around (incl. Phame live) to make sure there is no regression from this when security.alternate-file-domain is not used.
- check that celerity resources and files (incl. previews) are served with security.alternate-file-domain set.
- check that phame live blog is serving its css correctly with security.alternate-file-domain set.
- check that requests outside of the whitelist generate an exception for security.alternate-file-domain
Reviewers: #blessed_reviewers, epriestley
Reviewed By: #blessed_reviewers, epriestley
Subscribers: epriestley, Korvin
Differential Revision: https://secure.phabricator.com/D10048
Summary: As mentioned on rP8ce35e6b67e7e2a81b274bab7a6dd19dedb4df06, `setConcreteOnly(true)` can be omitted since (lacking magical powers) `loadObjects()` will always only instantiate concrete objects.
Test Plan: N/A
Reviewers: epriestley, #blessed_reviewers
Reviewed By: epriestley, #blessed_reviewers
Subscribers: epriestley, Korvin
Differential Revision: https://secure.phabricator.com/D10050
Fixes an issue with D9991. A user was hitting the following exception:
```
echo '{}' | arc --conduit-uri='http://phabricator.joshuaspence.com'
call-conduit conduit.query
Waiting for JSON parameters on stdin...
Exception
[HTTP/500] Internal Server Error
>>> UNRECOVERABLE FATAL ERROR <<<
Call to a member function getAPIMethodName() on a non-object
/usr/src/phabricator/src/applications/conduit/method/ConduitQueryConduitAPIMethod.php:34
┻━┻ ︵ ¯\_(ツ)_/¯ ︵ ┻━┻
(Run with --trace for a full exception trace.)
```
Auditors: epriestley
Summary: Fixes T5102. Bumps the version to clear caches and documents the `#` headers.
Test Plan: Read documentation.
Reviewers: asherkin, btrahan, chad
Reviewed By: chad
Subscribers: epriestley
Maniphest Tasks: T5102
Differential Revision: https://secure.phabricator.com/D10046
Summary: Fixes T5695. A Conduit "method does not exist" exception is somewhat expected... there is no need to `phlog` the exception.
Test Plan: Called a non-existent Conduit method. Saw no exceptions in the error logs.
Reviewers: #blessed_reviewers, epriestley
Reviewed By: #blessed_reviewers, epriestley
Subscribers: epriestley, Korvin
Maniphest Tasks: T5695
Differential Revision: https://secure.phabricator.com/D10042
Summary: Ref T4896. Begins laying groundwork to split comments apart so they behave like transactions, ultimately enabling the migration.
Test Plan: Made several different types of comments, verified resulting email looks OK.
Reviewers: btrahan, joshuaspence
Reviewed By: joshuaspence
Subscribers: epriestley
Maniphest Tasks: T4896
Differential Revision: https://secure.phabricator.com/D10022
Summary:
Ref T4896. This is substantially similar to D8196.
Migrate the comment text out of the `audit_comment` table and into the `audit_transaction_comment` table. Do double reads on `PhabricatorAuditComment` so the APIs aren't disturbed. The old table is still updated.
Test Plan:
- Before applying migration, cleared cache and browsed around. Things looked fine, except no comment text.
- Applied migration.
- Cleared cache, browsed around, saw all my old comments.
- Added some new comments.
- Spot checked migrated and new rows in database.
Reviewers: btrahan, joshuaspence
Reviewed By: joshuaspence
Subscribers: epriestley
Maniphest Tasks: T4896
Differential Revision: https://secure.phabricator.com/D10020
Summary: Ref T4896. Buries all direct access to the table so we can limit the surface area affected by the migration.
Test Plan:
- Grepped for `PhabricatorAuditComment`.
- Grepped for `audit_comment`.
- Viewed a bunch of comments.
- Added a comment.
- Reindexed a commit.
- Searched for unique term in new comment.
Reviewers: btrahan, joshuaspence
Reviewed By: joshuaspence
Subscribers: epriestley
Maniphest Tasks: T4896
Differential Revision: https://secure.phabricator.com/D10019
Summary:
Ref T4896. This is substantially identical to the process which Differential followed, and mostly copied from the original Differential migration and the Differential proxy object.
Basically, we move all the data over but the application can't tell, and the same APIs do reads and writes to the new table.
Test Plan:
- Browsed UI before migrating, everything looked fine (but no inlines).
- Ran migration.
- Verified draft and published comments survived migration.
- Added a draft.
- Previewed draft.
- Submitted draft.
- Viewed standalone with drafts and published comments.
- Sanity checked data in database, didn't see anything unusual.
Reviewers: btrahan, joshuaspence
Reviewed By: joshuaspence
Subscribers: epriestley
Maniphest Tasks: T4896
Differential Revision: https://secure.phabricator.com/D10018
Summary:
Ref T4896. This adds the new storage, without any code changes.
This storage is substantially identical to the Differential storage, except that `changesetID` has been replaced by `pathID`.
I've retained the properties intended to be used to implement T1460. They might not be quite right, but at least we'll be able to make any fixes consistently to both applications. For now, these fields are empty and ignored.
Test Plan: Ran `./bin/storage upgrade`. Nothing calls this code yet.
Reviewers: btrahan, joshuaspence
Reviewed By: joshuaspence
Subscribers: epriestley
Maniphest Tasks: T4896
Differential Revision: https://secure.phabricator.com/D10017
Summary: Ref T4896. Move all direct accesses to the inline comment table behind a small amount of API to make it easier to migrate the table.
Test Plan:
- Grepped for `PhabricatorAuditInlineComment`.
- Grepped for `audit_inlinecomment`.
- Created a draft comment.
- Previewed a draft comment.
- Reloaded page, still saw draft.
- Viewed standalone, still saw draft.
- Made comment, inline published.
- Added a draft, saw both.
- Edited inline comment.
- Reindexed commit.
- Searched for unique word in published comment, found commit.
- Searched for unique word in draft comment, no results.
Reviewers: btrahan, joshuaspence
Reviewed By: joshuaspence
Subscribers: epriestley
Maniphest Tasks: T4896
Differential Revision: https://secure.phabricator.com/D10016
Summary: Instead of implementing the `getCapabilityKey` method in all subclasses of `PhabricatorPolicyCapability`, provide a `final` implementation in the base class which uses reflection. See D9837 and D9985 for similar implementations.
Test Plan: N/A
Reviewers: epriestley, #blessed_reviewers
Reviewed By: epriestley, #blessed_reviewers
Subscribers: epriestley, Korvin, hach-que
Differential Revision: https://secure.phabricator.com/D10039
Summary:
The image was incorrectly served on /rsrc without using celerity. This
is no longer routable with recommendations in D9401.
Test Plan: Browse to home page and inspect javascript link for this resource.
Reviewers: epriestley, #blessed_reviewers
Reviewed By: epriestley, #blessed_reviewers
Subscribers: epriestley, Korvin
Differential Revision: https://secure.phabricator.com/D10040
Summary:
The ability to query by name(s) already exists
but is not bound to the conduit method. This binds it.
Test Plan:
Tested locally
echo '{"names": ["myprojectbyname"]}' | arc call-conduit project.query
Reviewers: epriestley, #blessed_reviewers
Reviewed By: epriestley, #blessed_reviewers
Subscribers: epriestley, Korvin, 20after4
Differential Revision: https://secure.phabricator.com/D10032
Summary: These files were added in D10001, which was submitted before (but landed after) D9982 had landed.
Test Plan: `arc unit`
Reviewers: epriestley, #blessed_reviewers, chad
Reviewed By: #blessed_reviewers, chad
Subscribers: epriestley, Korvin
Differential Revision: https://secure.phabricator.com/D10033
Summary: Ref T5655. Rename `PhabricatorPHIDType` subclasses for clarity (see discussion in D9839). I'm not too keen on some of the resulting class names, so feel free to suggest alternatives.
Test Plan: Ran unit tests.
Reviewers: epriestley, #blessed_reviewers
Reviewed By: epriestley, #blessed_reviewers
Subscribers: epriestley, Korvin, hach-que
Maniphest Tasks: T5655
Differential Revision: https://secure.phabricator.com/D9986
Summary: Ref T2787. There were some mega-uggo buttons and such; reduce the uggo-ness by a hair.
Test Plan: {F179686}
Reviewers: btrahan, chad
Reviewed By: chad
Subscribers: epriestley
Maniphest Tasks: T2787
Differential Revision: https://secure.phabricator.com/D10006
Summary:
Ref T2787. Carts need a status so we can tell if they've been purchased. Also kind of get WePay working as a one-time provider, and let charges not have a methodPHID (they won't for one-time providers).
All the status stuff is still super crazy rough and you can do things like start a checkout, add a bunch of stuff to your cart, complete the checkout, and have Phabricator think you paid for all the stuff you added. But this is fine for now since you can't actually edit carts, and also none of this is at all usable anyway. I'll refine some of the workflows in future diffs, for now I'm just getting things hooked up and technically working.
Test Plan:
- Purcahsed a cart and got a sort of status/done screen instead of a "your money is gone" exception.
- Went through the WePay flow and got a successful test checkout.
Reviewers: btrahan, chad
Reviewed By: chad
Subscribers: epriestley
Maniphest Tasks: T2787
Differential Revision: https://secure.phabricator.com/D10003
Summary: Ref T2787. Makes charges a real object, allows providers to apply them. We are now (just barely) capable of stealing users' money.
Test Plan: {F179584}
Reviewers: btrahan, chad
Reviewed By: chad
Subscribers: epriestley
Maniphest Tasks: T2787
Differential Revision: https://secure.phabricator.com/D10002
Summary:
Ref T2787. Make carts and purchases real objects, with storage, that kind-of work.
Roughly, the idea here is that applications create "purchases" (like "1 large t-shirt") and add them to "carts" (a user can have a lot of different carts at the same time), then hand things off to Phortune to deal with actualy charging a card. Roughly this works like Paypal or other similar systems do, except Phortune is the thing the user gets handed off to.
This doesn't do anything interesting/useful yet.
Also fix some bugs and update some UI.
Test Plan: Added a product to a cart, saw it in cart screen.
Reviewers: btrahan, chad
Reviewed By: chad
Subscribers: epriestley
Maniphest Tasks: T2787
Differential Revision: https://secure.phabricator.com/D10001
Summary: Provide an implementation for the `getName` method rather than automagically determining the application name.
Test Plan: Saw reasonable application names in the launcher.
Reviewers: #blessed_reviewers, epriestley
Reviewed By: #blessed_reviewers, epriestley
Subscribers: epriestley, Korvin
Differential Revision: https://secure.phabricator.com/D10027
Summary: Ref T5655. Some discussion in D9839. Generally speaking, `Phabricator{$name}Application` is clearer than `PhabricatorApplication{$name}`.
Test Plan:
# Pinned and uninstalled some applications.
# Applied patch and performed migrations.
# Verified that the pinned applications were still pinned and that the uninstalled applications were still uninstalled.
# Performed a sanity check on the database contents.
Reviewers: btrahan, epriestley, #blessed_reviewers
Reviewed By: epriestley, #blessed_reviewers
Subscribers: hach-que, epriestley, Korvin
Maniphest Tasks: T5655
Differential Revision: https://secure.phabricator.com/D9982
Summary: Instead of implementing the `getTypeConstant` method in all subclasses of `PhabricatorPHIDType`, provide a `final` implementation in the base class which uses reflection. See D9837 for a similar implementation.
Test Plan: Ran `arc unit`.
Reviewers: #blessed_reviewers, epriestley
Reviewed By: #blessed_reviewers, epriestley
Subscribers: epriestley, Korvin, hach-que
Differential Revision: https://secure.phabricator.com/D9985
Summary: Ref T5655. It is superfluous to include "base" in the name of an abstract base class. Furthermore, it is not done consistently within the code base.
Test Plan: Ran `arc unit`.
Reviewers: epriestley, #blessed_reviewers
Reviewed By: epriestley, #blessed_reviewers
Subscribers: epriestley, Korvin
Maniphest Tasks: T5655
Differential Revision: https://secure.phabricator.com/D9989
Summary: Ref T5655. The `PhabricatorDestructibleInterface` interface is misspelled as `PhabricatorDestructableInterface`. Fix the spelling mistake.
Test Plan: `grep`. Seeing as this interface is fairly recent, I don't expect that this would cause any widespread breakages.
Reviewers: epriestley, #blessed_reviewers
Reviewed By: epriestley, #blessed_reviewers
Subscribers: epriestley, Korvin
Maniphest Tasks: T5655
Differential Revision: https://secure.phabricator.com/D9988
Summary: Fixes T5661. We may now pick up a conflicting `dateCreated` field from an edge table join.
Test Plan: Ran a project + dateCreated filtering query, no longer got an exception.
Reviewers: btrahan, joshuaspence
Reviewed By: joshuaspence
Subscribers: epriestley
Maniphest Tasks: T5661
Differential Revision: https://secure.phabricator.com/D9997
Summary: Fixes T5659. When building a token after a user selection, we currently use the `value` as the token text, but sometimes that's an internal name which doesn't make much sense to users. For projects, it is now "sluga slugb Proper Display Name". If available, use `displayName` instead.
Test Plan: Typed some projects into a tokenizer, got display names only.
Reviewers: chad, joshuaspence
Reviewed By: joshuaspence
Subscribers: epriestley
Maniphest Tasks: T5659
Differential Revision: https://secure.phabricator.com/D9996
Summary: Allow `PhrictionDocument` to be permanently deleted with `./bin/remove destroy`.
Test Plan:
Deleted a Phriction document with `./bin/remove` and verified that the database was in the expected state.
```
> ./bin/remove destroy PHID-WIKI-auj57rauigvcqvv5feh6
IMPORTANT: OBJECTS WILL BE PERMANENTLY DESTROYED!
There is no way to undo this operation or ever retrieve this data.
These 1 object(s) will be completely destroyed forever:
- PHID-WIKI-auj57rauigvcqvv5feh6 (PhrictionDocument)
Are you absolutely certain you want to destroy these 1 object(s)? [y/N] y
Destroying objects...
Destroying PhrictionDocument PHID-WIKI-auj57rauigvcqvv5feh6...
Permanently destroyed 1 object(s).
```
Reviewers: #blessed_reviewers, epriestley
Reviewed By: #blessed_reviewers, epriestley
Subscribers: epriestley, Korvin
Differential Revision: https://secure.phabricator.com/D9976
Summary:
Commits don't support `PhabricatorApplicationTransactionInterface` yet, so the "Edit Maniphest Tasks" dialog from the commit UI currently bombs.
Hard-code it to do the correct writes in a low-level way. After T4896 we can remove this and do `ApplicationTransaction` stuff.
Test Plan: Used the "Edit Maniphest Tasks" UI from Diffusion.
Reviewers: joshuaspence
Reviewed By: joshuaspence
Subscribers: epriestley
Differential Revision: https://secure.phabricator.com/D9975
Summary: Allow `PhabricatorMetaMTAMailingList` to be permanently deleted with `./bin/remove destroy`.
Test Plan:
```
./bin/remove destroy PHID-MLST-nseux3r55escj573shsf
IMPORTANT: OBJECTS WILL BE PERMANENTLY DESTROYED!
There is no way to undo this operation or ever retrieve this data.
These 1 object(s) will be completely destroyed forever:
- PHID-MLST-nseux3r55escj573shsf (PhabricatorMetaMTAMailingList)
Are you absolutely certain you want to destroy these 1 object(s)? [y/N] y
Destroying objects...
Destroying PhabricatorMetaMTAMailingList PHID-MLST-nseux3r55escj573shsf...
Permanently destroyed 1 object(s).
```
Reviewers: #blessed_reviewers, epriestley
Reviewed By: #blessed_reviewers, epriestley
Subscribers: epriestley, Korvin
Differential Revision: https://secure.phabricator.com/D9979
Summary:
Some mailers remove the duplicate entries themselves, but some (Mailgun) don't.
This affects installations with metamta.one-mail-per-recipient set to false, and will cause
- ugly looking "to" entries. Gmail, for example, collapses to+cc entries to one list, so you get something that looks like "to: me me john"
- It sometimes causes duplicate delivery of the same message when used in conjuction with Google Groups. I suspect that their message de-dup mechanism is confused by it (I fuzzed it directly with Mailgun, and saw the same message delivered twice - once directly through mailgun, and bounced again through Google Groups). This doesn't happen when the entries are not duplicated.
Test Plan: Created some tasks. Added subscribers. Things seem to work reasonably well.
Reviewers: epriestley, #blessed_reviewers
Reviewed By: epriestley, #blessed_reviewers
Subscribers: epriestley, Korvin
Differential Revision: https://secure.phabricator.com/D9978
Summary: These got removed recently but I missed one callsite.
Test Plan: Used `git grep` to double check all other callsites.
Reviewers: joshuaspence
Reviewed By: joshuaspence
Subscribers: epriestley
Differential Revision: https://secure.phabricator.com/D9973
Summary:
Fixes T5614. Ref T4420. Other than the "users" datasource and a couple of others, many datasources ignore what the user typed and just return all results, then rely on the client to filter them.
This works fine for rarely used ("legalpad documents") or always small ("task priorities", "applications") datasets, but is something we should graudally move away from as datasets get larger.
Add a token table to projects, populate it, and use it to drive the datasource query. Additionally, expose it on the applicationsearch UI.
Test Plan:
- Ran migration.
- Manually checked the table.
- Searched for projects by name from ApplicationSearch.
- Searched for projects by name from typeahead.
- Manually checked the typeahead response.
Reviewers: btrahan
Reviewed By: btrahan
Subscribers: epriestley
Maniphest Tasks: T5614, T4420
Differential Revision: https://secure.phabricator.com/D9896
Summary: Ref T5651. Currently, the Aphlict server returns either `200 OKAY` or `400 Bad Request`. We could return more specific errors in some cases and this may assist with debugging.
Test Plan:
Sent myself a test notification at `/notification/status/` and saw the Aphlict server process the request (running in debug mode). Also poked around with `curl`:
```
> curl http://localhost:22281/
405 Method Not Allowed
> curl http://localhost:22281/ -d ""
400 Bad Request
> curl http://localhost:22281/foobar/
404 Not Found
```
Reviewers: #blessed_reviewers, epriestley
Reviewed By: #blessed_reviewers, epriestley
Subscribers: epriestley, Korvin
Maniphest Tasks: T5651
Differential Revision: https://secure.phabricator.com/D9967
Summary: Fixes T4420. This isn't perfect but is one step less janky, at least.
Test Plan: Viewed debugging view at `/typeahead/class/`, no unlabeled columns.
Reviewers: btrahan, chad
Reviewed By: chad
Subscribers: epriestley
Maniphest Tasks: T4420
Differential Revision: https://secure.phabricator.com/D9903
Summary: Ref T4420. We don't currently pass placeholder text properly, but should.
Test Plan: Saw placeholder text in Herald.
Reviewers: btrahan
Reviewed By: btrahan
Subscribers: epriestley
Maniphest Tasks: T4420
Differential Revision: https://secure.phabricator.com/D9901
Summary:
Ref T4420. This was a performance hack introduced long ago to make typeaheads for users a little cheaper. The idea was that you could load some of an object's columns and skip other ones.
We now always load users on demand, so the cost of loading the whole objects is very small. No other use cases ever arose for this, and it seems unlikely that they will in the future. Remove it all.
Test Plan:
- Grepped for `CONFIG_PARTIAL_OBJECTS`.
- Grepped for `dirtyFields`.
- Grepped for `missingFields`.
- Grepped for `resetDirtyFields`.
- Grepped for `loadColumns`.
- Grepped for `loadColumnsWhere`.
- Grepped for `loadRawDataWhere`.
- Loaded and saved some lisk objects.
Reviewers: btrahan
Reviewed By: btrahan
Subscribers: epriestley
Maniphest Tasks: T4420
Differential Revision: https://secure.phabricator.com/D9895
Summary:
Ref T4420. If a datasource does not specify an icon explicitly, check if the PHID type has a default, and use that.
This leaves us with only Projects and some special stuff setting explicit icons, and reduces code duplication.
Test Plan: Used typeahead to find all affected object types.
Reviewers: btrahan
Reviewed By: btrahan
Subscribers: epriestley
Maniphest Tasks: T4420
Differential Revision: https://secure.phabricator.com/D9894
Summary: Ref T4420. This one is users plus "upforgrabs". I renamed that to "none" and gave it a special visual style to make it more discoverable. Future diffs will improve this.
Test Plan:
- Used it in global search.
- Used it in batch editor.
Reviewers: btrahan
Reviewed By: btrahan
Subscribers: epriestley
Maniphest Tasks: T4420
Differential Revision: https://secure.phabricator.com/D9891
Summary: Ref T4420. This is just "project", plus the special "no project" token, but that doesn't actually work. Replace it with a normal project typeahead. This is only used in Maniphest's reports.
Test Plan: Searched for a couple of projects in reports.
Reviewers: btrahan
Reviewed By: btrahan
Subscribers: epriestley
Maniphest Tasks: T4420
Differential Revision: https://secure.phabricator.com/D9890
Summary: Ref T4420. Bring the global search up to date.
Test Plan: Typed various things into global search.
Reviewers: btrahan
Reviewed By: btrahan
Subscribers: epriestley
Maniphest Tasks: T4420
Differential Revision: https://secure.phabricator.com/D9889
Summary: Ref T4420. Call this "auditor" since that's what it is.
Test Plan:
- Edited auditors in auditor search.
- Edited auditors in "add auditors" in Diffusion.
Reviewers: btrahan
Reviewed By: btrahan
Subscribers: epriestley
Maniphest Tasks: T4420
Differential Revision: https://secure.phabricator.com/D9888
Summary: Ref T4420. These are used for some stuff like "reviewer".
Test Plan:
- Edited "reviewers" in differential edit.
- Edited "reviewers" in differential search.
- Edited "reviewers" in Differential "add reviewers..." action on detail page.
- Edited a "reviewers" field in a herald rule.
- Edited "owner" in owners search.
- Edited "primary owner", "owners" on owners edit.
Reviewers: btrahan
Reviewed By: btrahan
Subscribers: epriestley
Maniphest Tasks: T4420
Differential Revision: https://secure.phabricator.com/D9887
Summary: Ref T5245. Earlier changes in this stack introduced new edge strings, provide English translations.
Test Plan: This is hard to test exhastively, but I poked around the UI and saw some of these rendering correctly. If I messed anything up it's trivial to fix when someone spots it.
Reviewers: joshuaspence, chad
Reviewed By: joshuaspence, chad
Subscribers: epriestley
Maniphest Tasks: T5245
Differential Revision: https://secure.phabricator.com/D9920
Summary:
Ref T5245. We'll still display the old ones, but write real edge transactions now -- not TYPE_PROJECTS transactions.
Some code remains to show the existing transactions. The next diff will modernize the old transactions so we can remove this code.
Test Plan:
- Previewed a project-editing comment.
- Submitted a project-editing comment.
- Edited a task's projects.
- Batch edited a task's projects.
Reviewers: joshuaspence, chad, btrahan
Reviewed By: btrahan
Subscribers: epriestley
Maniphest Tasks: T5245
Differential Revision: https://secure.phabricator.com/D9852
Summary: Ref T5245. This property predates edges and is unusual in modern applications. Stop writes to it and populate it implicitly from edges when querying.
Test Plan:
- Viewed task list.
- Created a task.
- Added and removed projects from tasks.
Reviewers: joshuaspence, chad, btrahan
Reviewed By: btrahan
Subscribers: epriestley
Maniphest Tasks: T5245
Differential Revision: https://secure.phabricator.com/D9851
Summary: Ref T5245. This moves the actual storage over and stops reads and writes to the old table.
Test Plan:
- Verified tasks retained projects across the migration.
- Added and removed projects from tasks.
- Searched for: all, any, users' projects, not-in-projects, no-projects.
Reviewers: chad, btrahan, joshuaspence
Reviewed By: joshuaspence
Subscribers: epriestley
Maniphest Tasks: T5245
Differential Revision: https://secure.phabricator.com/D9850
Summary: Ref T5245. Updates the project/object edge to use a modern class definition. Moves further toward real edges.
Test Plan: Added projects to some objects, viewed transactions in transaction record.
Reviewers: chad, btrahan, joshuaspence
Reviewed By: joshuaspence
Subscribers: epriestley
Maniphest Tasks: T5245
Differential Revision: https://secure.phabricator.com/D9849
Summary: Ref T5245. With work elsewhere (notably, D9839) we can remove this TODO and use real transactions.
Test Plan: Pushed a `closes Txxx` commit and got a close + transaction.
Reviewers: chad, btrahan, joshuaspence
Reviewed By: joshuaspence
Subscribers: epriestley
Maniphest Tasks: T5245
Differential Revision: https://secure.phabricator.com/D9848
Summary:
Ref T5245. This hooks up the translation/rendering methods added previously.
These are messy, but now extractable/translatable.
Test Plan: Viewed edge transactions and stories, saw correct strings.
Reviewers: chad, btrahan, joshuaspence
Reviewed By: joshuaspence
Subscribers: epriestley
Maniphest Tasks: T5245
Differential Revision: https://secure.phabricator.com/D9841
Summary:
Ref T5245. These were a bad idea.
We no longer need actors for edge edits either, so remove those. Generally, edges have fit into the policy model as pure/low-level infrastructure, and they do not have any policy or capability information in and of themselves.
Test Plan: `grep`
Reviewers: chad, btrahan, joshuaspence
Reviewed By: joshuaspence
Subscribers: epriestley
Maniphest Tasks: T5245
Differential Revision: https://secure.phabricator.com/D9840
Summary:
Ref T5245. See some discussion in D9838.
When we attach object A to object B, we'd like to write transactions on both sides but only write the actual edges once.
To do this, allow edge types to `shouldWriteInverseTransactions()`. When an edge type opts into this, have editors apply the inverse transactions before writing the edge. These inverse transactions don't actually apply effects, they just show up in the transaction log.
Test Plan: Attached and detached revisions from tasks, saw transactions appear on both sides of the operation.
Reviewers: chad, btrahan, joshuaspence
Reviewed By: btrahan, joshuaspence
Subscribers: epriestley
Maniphest Tasks: T5245
Differential Revision: https://secure.phabricator.com/D9839
Summary:
Ref T5245. A very long time ago I had this terrible idea that we'd let objects react to edges being added and insert transactions in response.
This turned out to be a clearly bad idea very quickly, for like 15 different reasons. A big issue is that it inverts the responsibilities of editors. It's also just clumsy and messy.
We now have `PhabricatorApplicationTransactionInterface` instead, which mostly provides a cleaner way to deal with this.
Implement `PhabricatorApplicationTransactionInterface`, implicitly moving all the attach actions (task/task, task/revision, task/commit, task/mock) to proper edge transactions.
The cost of this is that the inverse edges don't write transactions -- if you attach an object to another object, only the object you were acting on posts a transaction record. This is sort of buggy anyway already. I'll fix this in the next diff.
Test Plan: Attached tasks, revisions and mocks to a task, then detached them.
Reviewers: chad, btrahan, joshuaspence
Reviewed By: joshuaspence
Subscribers: epriestley
Maniphest Tasks: T5245
Differential Revision: https://secure.phabricator.com/D9838
Summary:
Ref T5245. I want to add a new capability to edge types, which is a good opportunity to move away from `PhabricatorEdgeConfig`, which isn't modular.
This is basically the same as the modularization of PHID types, which has worked well. Add `PhabricatorEdgeType` and provide an adaption layer for the existing code.
This has no runtime changes, except the fixed edge constant.
Test Plan: Ran `var_dump(PhabricatorEdgeType::getAllTypes())` and got reasonable looking output.
Reviewers: chad, btrahan, joshuaspence
Reviewed By: joshuaspence
Subscribers: epriestley
Maniphest Tasks: T5245
Differential Revision: https://secure.phabricator.com/D9837
Summary: Ref T5245. Currently, task/project links rely on side effects in `save()`. Make them more transaction-oriented, with the goal of moving fully to edges a few diffs down the line.
Test Plan:
- Added and removed projects using "Edit Task", "Associate Projects" comment action, and Herald.
- Verified database ended up in the expected state.
Reviewers: chad, btrahan, joshuaspence
Reviewed By: joshuaspence
Subscribers: epriestley
Maniphest Tasks: T5245
Differential Revision: https://secure.phabricator.com/D9833
Summary: Fixes T5651. Sometime we'll send an object to the notification server for `subscribers`, which it will choke on. Use `array_values()` to make sure we're sending an array.
Test Plan: With `(object)` instead, got a consistent error ("no .filter method on object"). With `array_values()`, no error.
Reviewers: joshuaspence
Reviewed By: joshuaspence
Subscribers: epriestley
Maniphest Tasks: T5651
Differential Revision: https://secure.phabricator.com/D9963
Summary:
I think this pretty much does what you would expect?
The "active" item is always at the top of the stack.
Test Plan: Called `phrequent.tracking` and got reasonable results.
Reviewers: hach-que
Reviewed By: hach-que
Subscribers: epriestley
Differential Revision: https://secure.phabricator.com/D9939
Summary: Add a new line for clarity.
Test Plan: Inspected `./resources/celerity/map.php`.
Reviewers: epriestley, #blessed_reviewers
Reviewed By: epriestley, #blessed_reviewers
Subscribers: epriestley, Korvin
Differential Revision: https://secure.phabricator.com/D9931
Summary: `phutil_var_export` only accepts a single parameter. This bug was introduced in D9926.
Test Plan: Eye-ball it.
Reviewers: epriestley, #blessed_reviewers
Reviewed By: epriestley, #blessed_reviewers
Subscribers: epriestley, Korvin
Differential Revision: https://secure.phabricator.com/D9930
Summary: Currently, the external accounts page can die in a fire if an OAuth2 link is bad. Instead of exploding, just fail the specific link.
Test Plan: Faked an error and got "invalid token" instead of an exception.
Reviewers: btrahan, chad
Reviewed By: chad
Subscribers: epriestley
Differential Revision: https://secure.phabricator.com/D9937
Test Plan: Queried a revision that had a repository attached, got the PHID; queried one that didn't, got null.
Reviewers: epriestley, #blessed_reviewers
Reviewed By: epriestley, #blessed_reviewers
Subscribers: epriestley, Korvin
Differential Revision: https://secure.phabricator.com/D9928
Summary:
Ref T2787. Update some of the UI elements used by Phortune. Mostly gets rid of the old blue headers.
Also adds some sweet art.
Test Plan: Poked aroudn Phortune.
Reviewers: btrahan, chad
Reviewed By: chad
Subscribers: epriestley
Maniphest Tasks: T2787
Differential Revision: https://secure.phabricator.com/D9915
Summary:
Fixes T5613. A branch may have multiple heads in Mercurial, but `executeOne()` expects exactly one result.
Load them all instead. Equivalently, we could `limit(1)`, but it's likely that we'll use the cursors in the future to reduce the number of VCS operations we do, so this is probably a little more along the lines where we're headed.
Test Plan: Poked around some repos.
Reviewers: chad, richardvanvelzen
Reviewed By: richardvanvelzen
Subscribers: epriestley
Maniphest Tasks: T5613
Differential Revision: https://secure.phabricator.com/D9918
Summary: These have been moved into libphutil.
Test Plan: Browsed Phabricator, didn't see a crash.
Reviewers: #blessed_reviewers, epriestley
Reviewed By: #blessed_reviewers, epriestley
Subscribers: epriestley, Korvin
Differential Revision: https://secure.phabricator.com/D9907
