Make pressing "R" on your keyboard reload the card state on workboards
Summary:
Depends on D20638. Ref T4900. This is an incremental step toward proper workboard updates.
Currently, the client can mostly update its view because we do updates when you edit or move a card, and the client and server know how to send lists of card updates, so a lot of the work is already done.
However, the code assumes we're only updating/redrawing one card at a time. Make the client accept and process multiple card updates.
In future changes, I'll add versioning (so we only update cards that have actually changed), fix the "TODO" around ordering, and move toward actual Aphlict-based real-time updates.
Test Plan:
- Opened the same workboard in two windows.
- Edited cards in one window, pressed "R" (capital letter, with no modifier keys) to reload the second window.
- Saw edits and moves reflected accurately after sync, except for some special cases of header/order interaction (see "TODO").
Reviewers: amckinley
Reviewed By: amckinley
Maniphest Tasks: T4900
Differential Revision: https://secure.phabricator.com/D20639
2019-07-02 10:33:13 -07:00
|
|
|
<?php
|
|
|
|
|
|
|
|
|
|
final class PhabricatorProjectBoardReloadController
|
|
|
|
|
extends PhabricatorProjectBoardController {
|
|
|
|
|
|
|
|
|
|
public function handleRequest(AphrontRequest $request) {
|
|
|
|
|
$viewer = $request->getViewer();
|
|
|
|
|
|
|
|
|
|
$response = $this->loadProject();
|
|
|
|
|
if ($response) {
|
|
|
|
|
return $response;
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
$project = $this->getProject();
|
|
|
|
|
$state = $this->getViewState();
|
|
|
|
|
$board_uri = $state->newWorkboardURI();
|
|
|
|
|
|
|
|
|
|
$layout_engine = $state->getLayoutEngine();
|
|
|
|
|
|
|
|
|
|
$board_phid = $project->getPHID();
|
|
|
|
|
|
|
|
|
|
$objects = $state->getObjects();
|
|
|
|
|
$object_phids = mpull($objects, 'getPHID');
|
|
|
|
|
|
|
|
|
|
$engine = id(new PhabricatorBoardResponseEngine())
|
|
|
|
|
->setViewer($viewer)
|
|
|
|
|
->setBoardPHID($board_phid)
|
Move "BoardResponseEngine" toward a more comprehensive update model
Summary:
Depends on D20639. Ref T4900. Currently, "BoardResponseEngine" has a `setObjectPHID()` method. This is called after edit operations to mean "we just edited object X, so we know it needs to be updated".
Move toward `setUpdatePHIDs(...)` in all cases, with `setUpdatePHIDs(array(the-object-we-just-edited))` as a special case of that. After this change, callers pass:
- An optional list of PHIDs they know need to be updated on the client. Today, this is always be a card we just edited (on edit/move flows), or a sort of made-up list of PHIDs for the moment (when you press "R"). In the future, the "R" endpoint will do a better job of figuring out a more realistic update set.
- An optional list of PHIDs currently visible on the client. This is used to update ordering details and mark cards for removal. This is currently passed by edit/move, but not by pressing "R" (it will be in the future).
- An optional list of objects. The "R" workflow has to load these anyway, so we can save a couple queries by letting callers pass them. For now, the edit/move flows still rely on the engine to figure out what it needs to load.
This does very little to actually change client behavior, it mostly just paves the way for the next update to the "R" workflow to make it handle add/remove cases properly.
Test Plan:
- Edited and moved cards on a workboard.
- Pressed "R" to reload a workboard.
Neither of these operations seem any worse off than they were before. They still don't fully work:
- When you edit a card and delete the current workboard project from it, it remains visible. This is also the behavior on `master`. This is sort of intentional since we don't necessarily want to make these cards suddenly disappear? Ideally, we would probably have some kind of "tombstone" state where the card can still be edited but can't be dragged, and the next explicit user interaction would clean up old tombstones. This interaction is very rare and I don't think it's particularly important to specialize.
- When a card is removed from the board, "R" can't currently figure out that it should be removed from the client. This is because the client does not yet pass a "visiblePHIDs" state. It will in an upcoming change.
- The "R" flow always sends a full set of card updates, and can not yet detect that some cards have not changed.
- There's a TODO, but some ordering stuff isn't handled yet.
Reviewers: amckinley
Reviewed By: amckinley
Maniphest Tasks: T4900
Differential Revision: https://secure.phabricator.com/D20652
2019-07-17 10:12:39 -07:00
|
|
|
->setObjects($objects)
|
Make pressing "R" on your keyboard reload the card state on workboards
Summary:
Depends on D20638. Ref T4900. This is an incremental step toward proper workboard updates.
Currently, the client can mostly update its view because we do updates when you edit or move a card, and the client and server know how to send lists of card updates, so a lot of the work is already done.
However, the code assumes we're only updating/redrawing one card at a time. Make the client accept and process multiple card updates.
In future changes, I'll add versioning (so we only update cards that have actually changed), fix the "TODO" around ordering, and move toward actual Aphlict-based real-time updates.
Test Plan:
- Opened the same workboard in two windows.
- Edited cards in one window, pressed "R" (capital letter, with no modifier keys) to reload the second window.
- Saw edits and moves reflected accurately after sync, except for some special cases of header/order interaction (see "TODO").
Reviewers: amckinley
Reviewed By: amckinley
Maniphest Tasks: T4900
Differential Revision: https://secure.phabricator.com/D20639
2019-07-02 10:33:13 -07:00
|
|
|
->setUpdatePHIDs($object_phids);
|
|
|
|
|
|
|
|
|
|
// TODO: We don't currently process "order" properly. If a user is viewing
|
|
|
|
|
// a board grouped by "Owner", and another user changes a task to be owned
|
|
|
|
|
// by a user who currently owns nothing on the board, the new header won't
|
|
|
|
|
// generate correctly if the first user presses "R".
|
|
|
|
|
|
|
|
|
|
return $engine->buildResponse();
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
}
|