2014-01-01 03:04:25 +01:00
|
|
|
<?php
|
|
|
|
|
|
|
|
/**
|
|
|
|
* This file is automatically generated. Use 'bin/celerity map' to rebuild it.
|
2014-07-16 03:29:06 +02:00
|
|
|
*
|
2014-01-01 03:04:25 +01:00
|
|
|
* @generated
|
|
|
|
*/
|
|
|
|
return array(
|
2014-07-14 17:33:33 +02:00
|
|
|
'names' => array(
|
2015-03-05 23:02:06 +01:00
|
|
|
'core.pkg.css' => 'a9770fbb',
|
Conpherence - make the durable column kind of work and stuff
Summary:
Ref T7014. This hooks up the durable column such that when you open it up it loads your most recent Conpherence. You can then switch amongst the various widgets and stuff and everything works nicely.
Except...
- scroll bar does not work
- also doesn't work at HEAD when I add a ton of text to the UI with no changes? (wrapped $copy in array_fill(0, 1000, $copy))
- "widget selector" does not collapse when you select something else
- this part wasn't really specified so I used the aphlict dropdown stuff. didn't want to keep working on that if this was the wrong UI choice
- can not edit title
- do we still want that to be done by clicking on the title, which pops a dialogue?
- can not add participants or calendar events
- what should this UI be? maybe just a button on the top for "participants" and a button on the bottom for calendar? both on top?
- this is not pixel perfect to the mock or two I've seen around. Aside from generally being bad at that, I definitely didn't get the name + timestamps formatting correctly, because the standard DOM of that has timestamp FIRST which appears second due to a "float right". Seemed like a lot of special-casing for what might not even be that important in the UI so I punted. (And again, there's likely many unknown ways in which this isn't pixel perfect)
There's also code quality issues
- `ConpherenceWidgetConfigConstants` is hopefully temporary or at least gets more sleek as we keep progressing here
- copied some CSS from main Conpherence app
- DOM structure is pretty different
- there's some minor CSS tweaks too given the different width (not to mention the DOM structure being different)
- copied some JS from behavior-pontificate.js to sync threads relative to aphlict updates
- JS in general is like a better version of existing JS; these should collapse I'd hope?
- maybe the aphlict-behavior-dropdown change was badsauce?
...but all that said, this definitely feels really nice and I feel like adding stuff is going to be really easy compared to how normal Conpherence is.
Also includes a bonus bug fix - we now correctly update participation. The user would encounter this issue if they were in a conpherence that got some updates and then they went to a different page; they would have unread status for the messages that were ajax'd in. This patch fixes that by making sure we mark participation up to date with the proper transaction in all cases.
Test Plan: hit "\" to invoke the column and saw nice loading UI and my latest conpherence load. sent messages and verified they received A-OK by looking in DOM console. toggled various widges and verified they rendered correctly. opened up a second browser with a second user on the thread, sent a message, and it was received in a nice asynchronous fashion
Reviewers: chad, epriestley
Reviewed By: epriestley
Subscribers: Korvin, epriestley
Maniphest Tasks: T7014
Differential Revision: https://secure.phabricator.com/D11968
2015-03-05 19:33:39 +01:00
|
|
|
'core.pkg.js' => 'a77025a1',
|
2015-01-03 00:30:00 +01:00
|
|
|
'darkconsole.pkg.js' => '8ab24e01',
|
2015-03-05 23:11:36 +01:00
|
|
|
'differential.pkg.css' => '6641cdd5',
|
2015-03-05 23:11:51 +01:00
|
|
|
'differential.pkg.js' => '3fab5259',
|
2014-07-29 00:01:43 +02:00
|
|
|
'diffusion.pkg.css' => '591664fa',
|
2014-06-23 19:27:47 +02:00
|
|
|
'diffusion.pkg.js' => 'bfc0737b',
|
2015-01-27 19:24:28 +01:00
|
|
|
'maniphest.pkg.css' => '68d4dd3d',
|
2014-06-23 19:27:47 +02:00
|
|
|
'maniphest.pkg.js' => 'df4aa49f',
|
2014-01-01 16:46:25 +01:00
|
|
|
'rsrc/css/aphront/aphront-bars.css' => '231ac33c',
|
2014-01-06 06:47:21 +01:00
|
|
|
'rsrc/css/aphront/dark-console.css' => '6378ef3d',
|
2015-02-19 17:45:37 +01:00
|
|
|
'rsrc/css/aphront/dialog-view.css' => 'd2e76b88',
|
2014-02-27 20:06:55 +01:00
|
|
|
'rsrc/css/aphront/lightbox-attachment.css' => '7acac05d',
|
2014-05-02 23:25:05 +02:00
|
|
|
'rsrc/css/aphront/list-filter-view.css' => '2ae43867',
|
2015-01-12 19:04:01 +01:00
|
|
|
'rsrc/css/aphront/multi-column.css' => '41a848c0',
|
2014-10-15 19:33:26 +02:00
|
|
|
'rsrc/css/aphront/notification.css' => '9c279160',
|
2014-01-01 16:46:25 +01:00
|
|
|
'rsrc/css/aphront/pager-view.css' => '2e3539af',
|
2015-02-21 01:00:39 +01:00
|
|
|
'rsrc/css/aphront/panel-view.css' => '7e0c3a56',
|
2014-12-30 11:48:26 +01:00
|
|
|
'rsrc/css/aphront/phabricator-nav-view.css' => '7aeaf435',
|
2014-06-13 20:36:01 +02:00
|
|
|
'rsrc/css/aphront/table-view.css' => 'b22b7216',
|
2014-05-29 05:56:20 +02:00
|
|
|
'rsrc/css/aphront/tokenizer.css' => '82ce2142',
|
2014-11-24 20:57:29 +01:00
|
|
|
'rsrc/css/aphront/tooltip.css' => '4099b97e',
|
2014-06-22 20:37:52 +02:00
|
|
|
'rsrc/css/aphront/transaction.css' => '5d0cae25',
|
2014-01-01 16:46:25 +01:00
|
|
|
'rsrc/css/aphront/two-column.css' => '16ab3ad2',
|
2014-12-30 11:48:53 +01:00
|
|
|
'rsrc/css/aphront/typeahead.css' => '0e403212',
|
2014-12-17 20:10:50 +01:00
|
|
|
'rsrc/css/application/almanac/almanac.css' => 'dbb9b3af',
|
2014-01-01 16:46:25 +01:00
|
|
|
'rsrc/css/application/auth/auth.css' => '1e655982',
|
2015-02-20 21:57:57 +01:00
|
|
|
'rsrc/css/application/base/main-menu-view.css' => 'f9f5cd1b',
|
2014-08-15 02:19:01 +02:00
|
|
|
'rsrc/css/application/base/notification-menu.css' => '6aa0a74b',
|
2015-01-26 17:19:22 +01:00
|
|
|
'rsrc/css/application/base/phabricator-application-launch-view.css' => '16ca323f',
|
2015-02-27 21:04:41 +01:00
|
|
|
'rsrc/css/application/base/standard-page-view.css' => 'df338a4b',
|
2014-02-12 18:55:53 +01:00
|
|
|
'rsrc/css/application/chatlog/chatlog.css' => '852140ff',
|
2014-01-01 16:46:25 +01:00
|
|
|
'rsrc/css/application/config/config-options.css' => '7fedf08b',
|
2015-02-26 18:26:36 +01:00
|
|
|
'rsrc/css/application/config/config-template.css' => '8e6c6fcd',
|
2015-03-03 00:42:25 +01:00
|
|
|
'rsrc/css/application/config/config-welcome.css' => '6abd79be',
|
2015-02-03 18:07:00 +01:00
|
|
|
'rsrc/css/application/config/setup-issue.css' => '22270af2',
|
2015-01-02 22:48:18 +01:00
|
|
|
'rsrc/css/application/config/unhandled-exception.css' => '37d4f9a2',
|
Conpherence - make the durable column kind of work and stuff
Summary:
Ref T7014. This hooks up the durable column such that when you open it up it loads your most recent Conpherence. You can then switch amongst the various widgets and stuff and everything works nicely.
Except...
- scroll bar does not work
- also doesn't work at HEAD when I add a ton of text to the UI with no changes? (wrapped $copy in array_fill(0, 1000, $copy))
- "widget selector" does not collapse when you select something else
- this part wasn't really specified so I used the aphlict dropdown stuff. didn't want to keep working on that if this was the wrong UI choice
- can not edit title
- do we still want that to be done by clicking on the title, which pops a dialogue?
- can not add participants or calendar events
- what should this UI be? maybe just a button on the top for "participants" and a button on the bottom for calendar? both on top?
- this is not pixel perfect to the mock or two I've seen around. Aside from generally being bad at that, I definitely didn't get the name + timestamps formatting correctly, because the standard DOM of that has timestamp FIRST which appears second due to a "float right". Seemed like a lot of special-casing for what might not even be that important in the UI so I punted. (And again, there's likely many unknown ways in which this isn't pixel perfect)
There's also code quality issues
- `ConpherenceWidgetConfigConstants` is hopefully temporary or at least gets more sleek as we keep progressing here
- copied some CSS from main Conpherence app
- DOM structure is pretty different
- there's some minor CSS tweaks too given the different width (not to mention the DOM structure being different)
- copied some JS from behavior-pontificate.js to sync threads relative to aphlict updates
- JS in general is like a better version of existing JS; these should collapse I'd hope?
- maybe the aphlict-behavior-dropdown change was badsauce?
...but all that said, this definitely feels really nice and I feel like adding stuff is going to be really easy compared to how normal Conpherence is.
Also includes a bonus bug fix - we now correctly update participation. The user would encounter this issue if they were in a conpherence that got some updates and then they went to a different page; they would have unread status for the messages that were ajax'd in. This patch fixes that by making sure we mark participation up to date with the proper transaction in all cases.
Test Plan: hit "\" to invoke the column and saw nice loading UI and my latest conpherence load. sent messages and verified they received A-OK by looking in DOM console. toggled various widges and verified they rendered correctly. opened up a second browser with a second user on the thread, sent a message, and it was received in a nice asynchronous fashion
Reviewers: chad, epriestley
Reviewed By: epriestley
Subscribers: Korvin, epriestley
Maniphest Tasks: T7014
Differential Revision: https://secure.phabricator.com/D11968
2015-03-05 19:33:39 +01:00
|
|
|
'rsrc/css/application/conpherence/durable-column.css' => '3b836442',
|
2015-01-29 23:27:44 +01:00
|
|
|
'rsrc/css/application/conpherence/menu.css' => '73774137',
|
2015-01-30 23:29:24 +01:00
|
|
|
'rsrc/css/application/conpherence/message-pane.css' => '17a9517f',
|
2014-05-28 00:26:16 +02:00
|
|
|
'rsrc/css/application/conpherence/notification.css' => '04a6e10a',
|
2014-01-01 16:46:25 +01:00
|
|
|
'rsrc/css/application/conpherence/update.css' => '1099a660',
|
2014-12-30 11:48:53 +01:00
|
|
|
'rsrc/css/application/conpherence/widget-pane.css' => '3d575438',
|
2014-01-01 16:46:25 +01:00
|
|
|
'rsrc/css/application/contentsource/content-source-view.css' => '4b8b05d4',
|
|
|
|
'rsrc/css/application/countdown/timer.css' => '86b7b0a0',
|
2015-03-01 23:45:56 +01:00
|
|
|
'rsrc/css/application/dashboard/dashboard.css' => '17937d22',
|
2015-02-09 17:38:51 +01:00
|
|
|
'rsrc/css/application/diff/inline-comment-summary.css' => 'eb5f8e8c',
|
2014-01-01 16:46:25 +01:00
|
|
|
'rsrc/css/application/differential/add-comment.css' => 'c478bcaa',
|
2015-03-05 23:11:36 +01:00
|
|
|
'rsrc/css/application/differential/changeset-view.css' => 'bad09138',
|
2014-02-27 20:06:55 +01:00
|
|
|
'rsrc/css/application/differential/core.css' => '7ac3cabc',
|
2014-09-30 18:47:54 +02:00
|
|
|
'rsrc/css/application/differential/results-table.css' => '181aa9d9',
|
2014-01-01 16:46:25 +01:00
|
|
|
'rsrc/css/application/differential/revision-comment.css' => '48186045',
|
2014-03-12 21:53:04 +01:00
|
|
|
'rsrc/css/application/differential/revision-history.css' => '0e8eb855',
|
2014-01-01 16:46:25 +01:00
|
|
|
'rsrc/css/application/differential/revision-list.css' => 'f3c47d33',
|
2014-10-15 19:33:26 +02:00
|
|
|
'rsrc/css/application/differential/table-of-contents.css' => '63f3ef4a',
|
2014-06-13 20:36:01 +02:00
|
|
|
'rsrc/css/application/diffusion/diffusion-icons.css' => '9c5828da',
|
2014-01-01 16:46:25 +01:00
|
|
|
'rsrc/css/application/diffusion/diffusion-source.css' => '66fdf661',
|
2014-12-30 11:48:26 +01:00
|
|
|
'rsrc/css/application/feed/feed.css' => 'b513b5f4',
|
2014-01-01 16:46:25 +01:00
|
|
|
'rsrc/css/application/files/global-drag-and-drop.css' => '697324ad',
|
2014-01-06 06:47:21 +01:00
|
|
|
'rsrc/css/application/flag/flag.css' => '5337623f',
|
2014-08-06 02:28:13 +02:00
|
|
|
'rsrc/css/application/harbormaster/harbormaster.css' => '49d64eb4',
|
2014-04-27 20:18:48 +02:00
|
|
|
'rsrc/css/application/herald/herald-test.css' => '778b008e',
|
2014-11-17 23:06:05 +01:00
|
|
|
'rsrc/css/application/herald/herald.css' => '826075fa',
|
2015-01-28 17:45:23 +01:00
|
|
|
'rsrc/css/application/home/home.css' => 'e34bf140',
|
2014-02-27 20:06:55 +01:00
|
|
|
'rsrc/css/application/maniphest/batch-editor.css' => '8f380ebc',
|
2015-02-24 18:41:37 +01:00
|
|
|
'rsrc/css/application/maniphest/report.css' => 'd8ed71ad',
|
2014-01-01 16:46:25 +01:00
|
|
|
'rsrc/css/application/maniphest/task-edit.css' => '8e23031b',
|
2015-01-27 19:24:28 +01:00
|
|
|
'rsrc/css/application/maniphest/task-summary.css' => 'ab2fc691',
|
2014-01-01 16:46:25 +01:00
|
|
|
'rsrc/css/application/objectselector/object-selector.css' => '029a133d',
|
|
|
|
'rsrc/css/application/owners/owners-path-editor.css' => '2f00933b',
|
2015-02-27 21:04:41 +01:00
|
|
|
'rsrc/css/application/paste/paste.css' => 'eb997ddd',
|
2015-01-12 16:20:20 +01:00
|
|
|
'rsrc/css/application/people/people-profile.css' => '25970776',
|
2015-03-01 23:45:56 +01:00
|
|
|
'rsrc/css/application/phame/phame.css' => '88bd4705',
|
2014-06-16 00:00:43 +02:00
|
|
|
'rsrc/css/application/pholio/pholio-edit.css' => '3ad9d1ee',
|
2014-06-25 00:23:57 +02:00
|
|
|
'rsrc/css/application/pholio/pholio-inline-comments.css' => '8e545e49',
|
2014-10-21 19:06:10 +02:00
|
|
|
'rsrc/css/application/pholio/pholio.css' => '95174bdd',
|
2015-03-02 22:01:08 +01:00
|
|
|
'rsrc/css/application/phortune/phortune-credit-card-form.css' => '8391eb02',
|
2014-07-23 19:36:37 +02:00
|
|
|
'rsrc/css/application/phortune/phortune.css' => '9149f103',
|
2014-01-06 06:47:21 +01:00
|
|
|
'rsrc/css/application/phrequent/phrequent.css' => 'ffc185ad',
|
2015-02-27 21:04:41 +01:00
|
|
|
'rsrc/css/application/phriction/phriction-document-css.css' => '0d16bc9a',
|
2014-11-17 23:06:05 +01:00
|
|
|
'rsrc/css/application/policy/policy-edit.css' => '815c66f7',
|
2014-04-29 19:43:38 +02:00
|
|
|
'rsrc/css/application/policy/policy-transaction-detail.css' => '82100a43',
|
2014-01-01 16:46:25 +01:00
|
|
|
'rsrc/css/application/policy/policy.css' => '957ea14c',
|
|
|
|
'rsrc/css/application/ponder/comments.css' => '6cdccea7',
|
|
|
|
'rsrc/css/application/ponder/feed.css' => 'e62615b6',
|
|
|
|
'rsrc/css/application/ponder/post.css' => 'ebab8a70',
|
|
|
|
'rsrc/css/application/ponder/vote.css' => '8ed6ed8b',
|
2015-03-01 23:45:56 +01:00
|
|
|
'rsrc/css/application/profile/profile-view.css' => '1a20dcbf',
|
2014-05-24 06:48:15 +02:00
|
|
|
'rsrc/css/application/projects/project-icon.css' => 'c2ecb7f1',
|
2014-04-18 15:44:45 +02:00
|
|
|
'rsrc/css/application/releeph/releeph-core.css' => '9b3c5733',
|
2014-04-14 21:06:56 +02:00
|
|
|
'rsrc/css/application/releeph/releeph-preview-branch.css' => 'b7a6f4a5',
|
2014-01-01 16:46:25 +01:00
|
|
|
'rsrc/css/application/releeph/releeph-request-differential-create-dialog.css' => '8d8b92cd',
|
|
|
|
'rsrc/css/application/releeph/releeph-request-typeahead.css' => '667a48ae',
|
2015-03-03 16:18:40 +01:00
|
|
|
'rsrc/css/application/search/search-results.css' => '559cc554',
|
2014-01-01 16:46:25 +01:00
|
|
|
'rsrc/css/application/slowvote/slowvote.css' => '266df6a1',
|
2014-05-05 19:54:34 +02:00
|
|
|
'rsrc/css/application/tokens/tokens.css' => '3d0f239e',
|
2014-04-23 03:29:14 +02:00
|
|
|
'rsrc/css/application/uiexample/example.css' => '528b19de',
|
2015-03-05 23:02:06 +01:00
|
|
|
'rsrc/css/core/core.css' => '86bfbe8c',
|
2015-03-01 21:03:02 +01:00
|
|
|
'rsrc/css/core/remarkup.css' => '2dbff225',
|
2014-10-31 18:45:11 +01:00
|
|
|
'rsrc/css/core/syntax.css' => '56c1ba38',
|
Conpherence - make the durable column kind of work and stuff
Summary:
Ref T7014. This hooks up the durable column such that when you open it up it loads your most recent Conpherence. You can then switch amongst the various widgets and stuff and everything works nicely.
Except...
- scroll bar does not work
- also doesn't work at HEAD when I add a ton of text to the UI with no changes? (wrapped $copy in array_fill(0, 1000, $copy))
- "widget selector" does not collapse when you select something else
- this part wasn't really specified so I used the aphlict dropdown stuff. didn't want to keep working on that if this was the wrong UI choice
- can not edit title
- do we still want that to be done by clicking on the title, which pops a dialogue?
- can not add participants or calendar events
- what should this UI be? maybe just a button on the top for "participants" and a button on the bottom for calendar? both on top?
- this is not pixel perfect to the mock or two I've seen around. Aside from generally being bad at that, I definitely didn't get the name + timestamps formatting correctly, because the standard DOM of that has timestamp FIRST which appears second due to a "float right". Seemed like a lot of special-casing for what might not even be that important in the UI so I punted. (And again, there's likely many unknown ways in which this isn't pixel perfect)
There's also code quality issues
- `ConpherenceWidgetConfigConstants` is hopefully temporary or at least gets more sleek as we keep progressing here
- copied some CSS from main Conpherence app
- DOM structure is pretty different
- there's some minor CSS tweaks too given the different width (not to mention the DOM structure being different)
- copied some JS from behavior-pontificate.js to sync threads relative to aphlict updates
- JS in general is like a better version of existing JS; these should collapse I'd hope?
- maybe the aphlict-behavior-dropdown change was badsauce?
...but all that said, this definitely feels really nice and I feel like adding stuff is going to be really easy compared to how normal Conpherence is.
Also includes a bonus bug fix - we now correctly update participation. The user would encounter this issue if they were in a conpherence that got some updates and then they went to a different page; they would have unread status for the messages that were ajax'd in. This patch fixes that by making sure we mark participation up to date with the proper transaction in all cases.
Test Plan: hit "\" to invoke the column and saw nice loading UI and my latest conpherence load. sent messages and verified they received A-OK by looking in DOM console. toggled various widges and verified they rendered correctly. opened up a second browser with a second user on the thread, sent a message, and it was received in a nice asynchronous fashion
Reviewers: chad, epriestley
Reviewed By: epriestley
Subscribers: Korvin, epriestley
Maniphest Tasks: T7014
Differential Revision: https://secure.phabricator.com/D11968
2015-03-05 19:33:39 +01:00
|
|
|
'rsrc/css/core/z-index.css' => '9ec70c03',
|
2014-03-06 20:28:24 +01:00
|
|
|
'rsrc/css/diviner/diviner-shared.css' => '38813222',
|
2015-02-09 17:12:47 +01:00
|
|
|
'rsrc/css/font/font-awesome.css' => 'ae9a7b4d',
|
|
|
|
'rsrc/css/font/font-source-sans-pro.css' => '0d859f60',
|
2014-10-15 19:33:26 +02:00
|
|
|
'rsrc/css/font/phui-font-icon-base.css' => '3dad2ae3',
|
2014-05-30 01:04:50 +02:00
|
|
|
'rsrc/css/layout/phabricator-filetree-view.css' => 'fccf9f82',
|
2014-06-24 18:39:32 +02:00
|
|
|
'rsrc/css/layout/phabricator-hovercard-view.css' => '893f4783',
|
2015-01-12 19:04:01 +01:00
|
|
|
'rsrc/css/layout/phabricator-side-menu-view.css' => '7e8c6341',
|
2015-02-27 21:04:41 +01:00
|
|
|
'rsrc/css/layout/phabricator-source-code-view.css' => '2ceee894',
|
2014-02-24 19:04:23 +01:00
|
|
|
'rsrc/css/phui/calendar/phui-calendar-day.css' => 'de035c8a',
|
|
|
|
'rsrc/css/phui/calendar/phui-calendar-list.css' => 'c1d0ca59',
|
Fixing z-index on calendar date badges.
Summary: Fixes T4787, decreased z-index on calendar badges so that they don't sit on top of notification dropdowns when dropdowns are expanded. Not sure why the badges had z-index 10, but please let me know if there was a more substantial reason for this.
Test Plan: If neither notification dropdowns have content, create enough messages to populate at least 5 rows, open calendar, expand messages dropdown, verify that underlying calendar date badges do not appear over the dropdown.
Reviewers: chad, #blessed_reviewers, epriestley
Reviewed By: #blessed_reviewers, epriestley
Subscribers: epriestley, Korvin
Maniphest Tasks: T4787
Differential Revision: https://secure.phabricator.com/D8770
2014-04-13 17:18:16 +02:00
|
|
|
'rsrc/css/phui/calendar/phui-calendar-month.css' => 'a92e47d2',
|
2014-10-15 19:33:26 +02:00
|
|
|
'rsrc/css/phui/calendar/phui-calendar.css' => '8675968e',
|
2014-11-04 20:11:15 +01:00
|
|
|
'rsrc/css/phui/phui-action-header-view.css' => '89c497e7',
|
2014-06-24 18:39:32 +02:00
|
|
|
'rsrc/css/phui/phui-action-list.css' => '9ee9910a',
|
2015-02-21 15:38:27 +01:00
|
|
|
'rsrc/css/phui/phui-action-panel.css' => '3ee9afd5',
|
2014-04-18 15:44:45 +02:00
|
|
|
'rsrc/css/phui/phui-box.css' => '7b3a2eed',
|
2015-02-26 18:26:36 +01:00
|
|
|
'rsrc/css/phui/phui-button.css' => '21cb97f9',
|
2015-02-02 19:34:42 +01:00
|
|
|
'rsrc/css/phui/phui-crumbs-view.css' => '594d719e',
|
2015-03-03 00:42:25 +01:00
|
|
|
'rsrc/css/phui/phui-document.css' => '0f83a7df',
|
2015-01-25 23:14:41 +01:00
|
|
|
'rsrc/css/phui/phui-feed-story.css' => 'c9f3a0b5',
|
2015-03-03 00:42:25 +01:00
|
|
|
'rsrc/css/phui/phui-fontkit.css' => 'd30f4fa3',
|
2015-03-02 22:01:08 +01:00
|
|
|
'rsrc/css/phui/phui-form-view.css' => '76f0b086',
|
2015-02-26 18:26:36 +01:00
|
|
|
'rsrc/css/phui/phui-form.css' => 'f535f938',
|
2015-01-14 01:10:57 +01:00
|
|
|
'rsrc/css/phui/phui-header-view.css' => '083669db',
|
2015-01-26 17:19:22 +01:00
|
|
|
'rsrc/css/phui/phui-icon.css' => 'd35aa857',
|
2014-06-19 20:28:01 +02:00
|
|
|
'rsrc/css/phui/phui-image-mask.css' => '5a8b09c8',
|
2014-01-01 16:46:25 +01:00
|
|
|
'rsrc/css/phui/phui-info-panel.css' => '27ea50a1',
|
2015-03-02 18:01:04 +01:00
|
|
|
'rsrc/css/phui/phui-info-view.css' => '6c6cc4dd',
|
2014-12-30 11:48:53 +01:00
|
|
|
'rsrc/css/phui/phui-list.css' => '53deb25c',
|
2015-03-01 23:45:56 +01:00
|
|
|
'rsrc/css/phui/phui-object-box.css' => 'd68ce5dc',
|
|
|
|
'rsrc/css/phui/phui-object-item-list-view.css' => '9db65899',
|
2014-06-27 18:39:13 +02:00
|
|
|
'rsrc/css/phui/phui-pinboard-view.css' => '3dd4a269',
|
2014-12-18 23:42:26 +01:00
|
|
|
'rsrc/css/phui/phui-property-list-view.css' => '51480060',
|
2014-01-01 16:46:25 +01:00
|
|
|
'rsrc/css/phui/phui-remarkup-preview.css' => '19ad512b',
|
|
|
|
'rsrc/css/phui/phui-spacing.css' => '042804d6',
|
2014-10-16 22:12:03 +02:00
|
|
|
'rsrc/css/phui/phui-status.css' => '888cedb8',
|
2015-02-18 20:28:11 +01:00
|
|
|
'rsrc/css/phui/phui-tag-view.css' => 'ea469f3a',
|
2014-10-15 19:33:26 +02:00
|
|
|
'rsrc/css/phui/phui-text.css' => 'cf019f54',
|
2015-02-02 18:40:46 +01:00
|
|
|
'rsrc/css/phui/phui-timeline-view.css' => 'b0fbc4d7',
|
2015-01-12 19:04:01 +01:00
|
|
|
'rsrc/css/phui/phui-workboard-view.css' => '8896938c',
|
2014-12-30 11:48:53 +01:00
|
|
|
'rsrc/css/phui/phui-workpanel-view.css' => 'e495a5cc',
|
2014-06-24 18:39:32 +02:00
|
|
|
'rsrc/css/sprite-gradient.css' => '4bdb98a7',
|
2014-10-29 23:06:15 +01:00
|
|
|
'rsrc/css/sprite-login.css' => 'a355d921',
|
2015-03-01 21:03:02 +01:00
|
|
|
'rsrc/css/sprite-main-header.css' => '28d01b0b',
|
2015-02-19 23:43:33 +01:00
|
|
|
'rsrc/css/sprite-menu.css' => '9ef76324',
|
2015-01-14 19:49:36 +01:00
|
|
|
'rsrc/css/sprite-projects.css' => 'b0d9e24f',
|
2014-02-17 19:06:16 +01:00
|
|
|
'rsrc/css/sprite-tokens.css' => '1706b943',
|
2015-01-25 17:09:41 +01:00
|
|
|
'rsrc/externals/font/fontawesome/fontawesome-webfont.eot' => '5fb6fb0e',
|
|
|
|
'rsrc/externals/font/fontawesome/fontawesome-webfont.ttf' => 'a653cb11',
|
|
|
|
'rsrc/externals/font/fontawesome/fontawesome-webfont.woff' => '80526fc8',
|
2015-02-09 17:12:47 +01:00
|
|
|
'rsrc/externals/font/fontawesome/fontawesome-webfont.woff2' => '4924d54d',
|
|
|
|
'rsrc/externals/font/sourcesans/SourceSansPro-Bold.woff2' => '165f5f74',
|
2015-01-29 23:48:41 +01:00
|
|
|
'rsrc/externals/font/sourcesans/SourceSansPro-BoldIt.woff' => 'd09a7d54',
|
2015-02-09 17:12:47 +01:00
|
|
|
'rsrc/externals/font/sourcesans/SourceSansPro-BoldIt.woff2' => 'd2e33102',
|
2015-01-29 23:48:41 +01:00
|
|
|
'rsrc/externals/font/sourcesans/SourceSansPro-It.woff' => '3f21af52',
|
2015-02-09 17:12:47 +01:00
|
|
|
'rsrc/externals/font/sourcesans/SourceSansPro-It.woff2' => '30a7cf60',
|
|
|
|
'rsrc/externals/font/sourcesans/SourceSansPro-Regular.woff2' => 'e89b04b1',
|
2014-04-18 02:31:23 +02:00
|
|
|
'rsrc/externals/font/sourcesans/SourceSansPro.woff' => '3614608c',
|
|
|
|
'rsrc/externals/font/sourcesans/SourceSansProBold.woff' => 'cbf46566',
|
Introduce CAN_EDIT for ExternalAccount, and make CAN_VIEW more liberal
Summary:
Fixes T3732. Ref T1205. Ref T3116.
External accounts (like emails used as identities, Facebook accounts, LDAP accounts, etc.) are stored in "ExternalAccount" objects.
Currently, we have a very restrictive `CAN_VIEW` policy for ExternalAccounts, to add an extra layer of protection to make sure users can't use them in unintended ways. For example, it would be bad if a user could link their Phabricator account to a Facebook account without proper authentication. All of the controllers which do sensitive things have checks anyway, but a restrictive CAN_VIEW provided an extra layer of protection. Se T3116 for some discussion.
However, this means that when grey/external users take actions (via email, or via applications like Legalpad) other users can't load the account handles and can't see anything about the actor (they just see "Restricted External Account" or similar).
Balancing these concerns is mostly about not making a huge mess while doing it. This seems like a reasonable approach:
- Add `CAN_EDIT` on these objects.
- Make that very restricted, but open up `CAN_VIEW`.
- Require `CAN_EDIT` any time we're going to do something authentication/identity related.
This is slightly easier to get wrong (forget CAN_EDIT) than other approaches, but pretty simple, and we always have extra checks in place anyway -- this is just a safety net.
I'm not quite sure how we should identify external accounts, so for now we're just rendering "Email User" or similar -- clearly not a bug, but not identifying. We can figure out what to render in the long term elsewhere.
Test Plan:
- Viewed external accounts.
- Linked an external account.
- Refreshed an external account.
- Edited profile picture.
- Viewed sessions panel.
- Published a bunch of stuff to Asana/JIRA.
- Legalpad signature page now shows external accounts.
{F171595}
Reviewers: chad, btrahan
Reviewed By: btrahan
Subscribers: epriestley
Maniphest Tasks: T3732, T1205, T3116
Differential Revision: https://secure.phabricator.com/D9767
2014-07-10 19:18:10 +02:00
|
|
|
'rsrc/externals/javelin/core/Event.js' => '85ea0626',
|
2015-01-28 21:42:05 +01:00
|
|
|
'rsrc/externals/javelin/core/Stratcom.js' => '6c53634d',
|
2014-02-27 20:06:55 +01:00
|
|
|
'rsrc/externals/javelin/core/__tests__/event-stop-and-kill.js' => '717554e4',
|
|
|
|
'rsrc/externals/javelin/core/__tests__/install.js' => 'c432ee85',
|
2015-01-14 01:10:57 +01:00
|
|
|
'rsrc/externals/javelin/core/__tests__/stratcom.js' => '88bf7313',
|
|
|
|
'rsrc/externals/javelin/core/__tests__/util.js' => 'e251703d',
|
2015-01-28 21:42:05 +01:00
|
|
|
'rsrc/externals/javelin/core/init.js' => '2bd3c675',
|
2015-01-20 01:55:08 +01:00
|
|
|
'rsrc/externals/javelin/core/init_node.js' => 'c234aded',
|
2015-01-14 01:10:57 +01:00
|
|
|
'rsrc/externals/javelin/core/install.js' => '05270951',
|
2015-01-20 01:55:08 +01:00
|
|
|
'rsrc/externals/javelin/core/util.js' => '93cc50d6',
|
Introduce CAN_EDIT for ExternalAccount, and make CAN_VIEW more liberal
Summary:
Fixes T3732. Ref T1205. Ref T3116.
External accounts (like emails used as identities, Facebook accounts, LDAP accounts, etc.) are stored in "ExternalAccount" objects.
Currently, we have a very restrictive `CAN_VIEW` policy for ExternalAccounts, to add an extra layer of protection to make sure users can't use them in unintended ways. For example, it would be bad if a user could link their Phabricator account to a Facebook account without proper authentication. All of the controllers which do sensitive things have checks anyway, but a restrictive CAN_VIEW provided an extra layer of protection. Se T3116 for some discussion.
However, this means that when grey/external users take actions (via email, or via applications like Legalpad) other users can't load the account handles and can't see anything about the actor (they just see "Restricted External Account" or similar).
Balancing these concerns is mostly about not making a huge mess while doing it. This seems like a reasonable approach:
- Add `CAN_EDIT` on these objects.
- Make that very restricted, but open up `CAN_VIEW`.
- Require `CAN_EDIT` any time we're going to do something authentication/identity related.
This is slightly easier to get wrong (forget CAN_EDIT) than other approaches, but pretty simple, and we always have extra checks in place anyway -- this is just a safety net.
I'm not quite sure how we should identify external accounts, so for now we're just rendering "Email User" or similar -- clearly not a bug, but not identifying. We can figure out what to render in the long term elsewhere.
Test Plan:
- Viewed external accounts.
- Linked an external account.
- Refreshed an external account.
- Edited profile picture.
- Viewed sessions panel.
- Published a bunch of stuff to Asana/JIRA.
- Legalpad signature page now shows external accounts.
{F171595}
Reviewers: chad, btrahan
Reviewed By: btrahan
Subscribers: epriestley
Maniphest Tasks: T3732, T1205, T3116
Differential Revision: https://secure.phabricator.com/D9767
2014-07-10 19:18:10 +02:00
|
|
|
'rsrc/externals/javelin/docs/Base.js' => '74676256',
|
|
|
|
'rsrc/externals/javelin/docs/onload.js' => 'e819c479',
|
2014-01-01 16:46:25 +01:00
|
|
|
'rsrc/externals/javelin/ext/fx/Color.js' => '7e41274a',
|
|
|
|
'rsrc/externals/javelin/ext/fx/FX.js' => '54b612ba',
|
2014-02-27 20:06:55 +01:00
|
|
|
'rsrc/externals/javelin/ext/reactor/core/DynVal.js' => 'f6555212',
|
2015-01-14 01:10:57 +01:00
|
|
|
'rsrc/externals/javelin/ext/reactor/core/Reactor.js' => '2b8de964',
|
|
|
|
'rsrc/externals/javelin/ext/reactor/core/ReactorNode.js' => '1ad0a787',
|
2014-02-27 20:06:55 +01:00
|
|
|
'rsrc/externals/javelin/ext/reactor/core/ReactorNodeCalmer.js' => '76f4ebed',
|
2015-01-14 01:10:57 +01:00
|
|
|
'rsrc/externals/javelin/ext/reactor/dom/RDOM.js' => 'c90a04fc',
|
|
|
|
'rsrc/externals/javelin/ext/view/HTMLView.js' => 'fe287620',
|
2014-02-27 20:06:55 +01:00
|
|
|
'rsrc/externals/javelin/ext/view/View.js' => '0f764c35',
|
2015-01-14 01:10:57 +01:00
|
|
|
'rsrc/externals/javelin/ext/view/ViewInterpreter.js' => 'f829edb3',
|
|
|
|
'rsrc/externals/javelin/ext/view/ViewPlaceholder.js' => '47830651',
|
2014-02-27 20:06:55 +01:00
|
|
|
'rsrc/externals/javelin/ext/view/ViewRenderer.js' => '6c2b09a2',
|
|
|
|
'rsrc/externals/javelin/ext/view/ViewVisitor.js' => 'efe49472',
|
2014-01-01 16:46:25 +01:00
|
|
|
'rsrc/externals/javelin/ext/view/__tests__/HTMLView.js' => 'f92d7bcb',
|
2015-01-20 01:55:08 +01:00
|
|
|
'rsrc/externals/javelin/ext/view/__tests__/View.js' => '6450b38b',
|
2014-01-01 16:46:25 +01:00
|
|
|
'rsrc/externals/javelin/ext/view/__tests__/ViewInterpreter.js' => '7a94d6a5',
|
2015-01-14 01:10:57 +01:00
|
|
|
'rsrc/externals/javelin/ext/view/__tests__/ViewRenderer.js' => '6ea96ac9',
|
2015-01-20 01:55:08 +01:00
|
|
|
'rsrc/externals/javelin/lib/Cookie.js' => '62dfea03',
|
2015-01-28 17:26:10 +01:00
|
|
|
'rsrc/externals/javelin/lib/DOM.js' => '6f7962d5',
|
Quicksand, an ignoble successor to Quickling
Summary:
Ref T2086. Ref T7014. With the persistent column, there is significant value in retaining chrome state through navigation events, because the user may have a lot of state in the chat window (scroll position, text selection, room juggling, partially entered text, etc). We can do this by capturing navigation events and faking them with Javascript.
(This can also improve performance, albeit slightly, and I believe there are better approaches to tackle performance any problems which exist with the chrome in many cases).
At Facebook, this system was "Photostream" in photos and then "Quickling" in general, and the technical cost of the system was //staggering//. I am loathe to pursue it again. However:
- Browsers are less junky now, and we target a smaller set of browsers. A large part of the technical cost of Quickling was the high complexity of emulating nagivation events in IE, where we needed to navigate a hidden iframe to make history entries. All desktop browsers which we might want to use this system on support the History API (although this prototype does not yet implement it).
- Javelin and Phabricator's architecture are much cleaner than Facebook's was. A large part of the technical cost of Quickling was inconsistency, inlined `onclick` handlers, and general lack of coordination and abstraction. We will have //some// of this, but "correctly written" behaviors are mostly immune to it by design, and many of Javelin's architectural decisions were influenced by desire to avoid issues we encountered building this stuff for Facebook.
- Some of the primitives which Quickling required (like loading resources over Ajax) have existed in a stable state in our codebase for a year or more, and adoption of these primitives was trivial and uneventful (vs a huge production at Facebook).
- My hubris is bolstered by recent success with WebSockets and JX.Scrollbar, both of which I would have assessed as infeasibly complex to develop in this project a few years ago.
To these points, the developer cost to prototype Photostream was several weeks; the developer cost to prototype this was a bit less than an hour. It is plausible to me that implementing and maintaining this system really will be hundreds of times less complex than it was at Facebook.
Test Plan:
My plan for this and D11497 is:
- Get them in master.
- Some secret key / relatively-hidden preference activates the column.
- Quicksand activates //only// when the column is open.
- We can use column + quicksand for a long period of time (i.e., over the course of Conpherence v2 development) and hammer out the long tail of issues.
- When it derps up, you just hide the column and you're good to go.
Reviewers: btrahan, chad
Reviewed By: chad
Subscribers: epriestley
Maniphest Tasks: T2086, T7014
Differential Revision: https://secure.phabricator.com/D11507
2015-01-27 23:52:09 +01:00
|
|
|
'rsrc/externals/javelin/lib/History.js' => '2e0148bc',
|
Introduce CAN_EDIT for ExternalAccount, and make CAN_VIEW more liberal
Summary:
Fixes T3732. Ref T1205. Ref T3116.
External accounts (like emails used as identities, Facebook accounts, LDAP accounts, etc.) are stored in "ExternalAccount" objects.
Currently, we have a very restrictive `CAN_VIEW` policy for ExternalAccounts, to add an extra layer of protection to make sure users can't use them in unintended ways. For example, it would be bad if a user could link their Phabricator account to a Facebook account without proper authentication. All of the controllers which do sensitive things have checks anyway, but a restrictive CAN_VIEW provided an extra layer of protection. Se T3116 for some discussion.
However, this means that when grey/external users take actions (via email, or via applications like Legalpad) other users can't load the account handles and can't see anything about the actor (they just see "Restricted External Account" or similar).
Balancing these concerns is mostly about not making a huge mess while doing it. This seems like a reasonable approach:
- Add `CAN_EDIT` on these objects.
- Make that very restricted, but open up `CAN_VIEW`.
- Require `CAN_EDIT` any time we're going to do something authentication/identity related.
This is slightly easier to get wrong (forget CAN_EDIT) than other approaches, but pretty simple, and we always have extra checks in place anyway -- this is just a safety net.
I'm not quite sure how we should identify external accounts, so for now we're just rendering "Email User" or similar -- clearly not a bug, but not identifying. We can figure out what to render in the long term elsewhere.
Test Plan:
- Viewed external accounts.
- Linked an external account.
- Refreshed an external account.
- Edited profile picture.
- Viewed sessions panel.
- Published a bunch of stuff to Asana/JIRA.
- Legalpad signature page now shows external accounts.
{F171595}
Reviewers: chad, btrahan
Reviewed By: btrahan
Subscribers: epriestley
Maniphest Tasks: T3732, T1205, T3116
Differential Revision: https://secure.phabricator.com/D9767
2014-07-10 19:18:10 +02:00
|
|
|
'rsrc/externals/javelin/lib/JSON.js' => '69adf288',
|
2015-01-22 21:22:26 +01:00
|
|
|
'rsrc/externals/javelin/lib/Leader.js' => '331b1611',
|
Introduce CAN_EDIT for ExternalAccount, and make CAN_VIEW more liberal
Summary:
Fixes T3732. Ref T1205. Ref T3116.
External accounts (like emails used as identities, Facebook accounts, LDAP accounts, etc.) are stored in "ExternalAccount" objects.
Currently, we have a very restrictive `CAN_VIEW` policy for ExternalAccounts, to add an extra layer of protection to make sure users can't use them in unintended ways. For example, it would be bad if a user could link their Phabricator account to a Facebook account without proper authentication. All of the controllers which do sensitive things have checks anyway, but a restrictive CAN_VIEW provided an extra layer of protection. Se T3116 for some discussion.
However, this means that when grey/external users take actions (via email, or via applications like Legalpad) other users can't load the account handles and can't see anything about the actor (they just see "Restricted External Account" or similar).
Balancing these concerns is mostly about not making a huge mess while doing it. This seems like a reasonable approach:
- Add `CAN_EDIT` on these objects.
- Make that very restricted, but open up `CAN_VIEW`.
- Require `CAN_EDIT` any time we're going to do something authentication/identity related.
This is slightly easier to get wrong (forget CAN_EDIT) than other approaches, but pretty simple, and we always have extra checks in place anyway -- this is just a safety net.
I'm not quite sure how we should identify external accounts, so for now we're just rendering "Email User" or similar -- clearly not a bug, but not identifying. We can figure out what to render in the long term elsewhere.
Test Plan:
- Viewed external accounts.
- Linked an external account.
- Refreshed an external account.
- Edited profile picture.
- Viewed sessions panel.
- Published a bunch of stuff to Asana/JIRA.
- Legalpad signature page now shows external accounts.
{F171595}
Reviewers: chad, btrahan
Reviewed By: btrahan
Subscribers: epriestley
Maniphest Tasks: T3732, T1205, T3116
Differential Revision: https://secure.phabricator.com/D9767
2014-07-10 19:18:10 +02:00
|
|
|
'rsrc/externals/javelin/lib/Mask.js' => '8a41885b',
|
Quicksand, an ignoble successor to Quickling
Summary:
Ref T2086. Ref T7014. With the persistent column, there is significant value in retaining chrome state through navigation events, because the user may have a lot of state in the chat window (scroll position, text selection, room juggling, partially entered text, etc). We can do this by capturing navigation events and faking them with Javascript.
(This can also improve performance, albeit slightly, and I believe there are better approaches to tackle performance any problems which exist with the chrome in many cases).
At Facebook, this system was "Photostream" in photos and then "Quickling" in general, and the technical cost of the system was //staggering//. I am loathe to pursue it again. However:
- Browsers are less junky now, and we target a smaller set of browsers. A large part of the technical cost of Quickling was the high complexity of emulating nagivation events in IE, where we needed to navigate a hidden iframe to make history entries. All desktop browsers which we might want to use this system on support the History API (although this prototype does not yet implement it).
- Javelin and Phabricator's architecture are much cleaner than Facebook's was. A large part of the technical cost of Quickling was inconsistency, inlined `onclick` handlers, and general lack of coordination and abstraction. We will have //some// of this, but "correctly written" behaviors are mostly immune to it by design, and many of Javelin's architectural decisions were influenced by desire to avoid issues we encountered building this stuff for Facebook.
- Some of the primitives which Quickling required (like loading resources over Ajax) have existed in a stable state in our codebase for a year or more, and adoption of these primitives was trivial and uneventful (vs a huge production at Facebook).
- My hubris is bolstered by recent success with WebSockets and JX.Scrollbar, both of which I would have assessed as infeasibly complex to develop in this project a few years ago.
To these points, the developer cost to prototype Photostream was several weeks; the developer cost to prototype this was a bit less than an hour. It is plausible to me that implementing and maintaining this system really will be hundreds of times less complex than it was at Facebook.
Test Plan:
My plan for this and D11497 is:
- Get them in master.
- Some secret key / relatively-hidden preference activates the column.
- Quicksand activates //only// when the column is open.
- We can use column + quicksand for a long period of time (i.e., over the course of Conpherence v2 development) and hammer out the long tail of issues.
- When it derps up, you just hide the column and you're good to go.
Reviewers: btrahan, chad
Reviewed By: chad
Subscribers: epriestley
Maniphest Tasks: T2086, T7014
Differential Revision: https://secure.phabricator.com/D11507
2015-01-27 23:52:09 +01:00
|
|
|
'rsrc/externals/javelin/lib/Quicksand.js' => 'f960d43d',
|
2015-01-14 01:10:57 +01:00
|
|
|
'rsrc/externals/javelin/lib/Request.js' => '94b750d2',
|
|
|
|
'rsrc/externals/javelin/lib/Resource.js' => '44959b73',
|
Provide a global router for Ajax requests
Summary:
Fixes T430. Fixes T4834. Obsoletes D7641. Currently, we do some things less-well than we could:
- We just let the browser queue and prioritize requests, so if you load a revision with 50 changes and then click "Award Token", the action blocks until the changes load in most/all browsers. It would be better to prioritize this action and queue it immediately.
- Similarly, changes tend to load in order, even if the user has clicked to a specific file. When the user expresses a preference for a specific file, we should prioritize it.
- We show a spinning GIF when waiting on requests. This is appropriate for some types of reuqests, but distracting for others.
To fix this:
- Queue all (or, at least, most) requests into a new queue in JX.Router.
- JX.Router handles prioritizing the requests. Principally:
- You can submit a request with a specific priority (500 = general content loading, 1000 = default, 2000 = explicit user action) and JX.Router will get the higher stuff fired off sooner.
- You can name requests and then adjust their prorities later, if the user expresses an interest in specific results.
- Only use the spinner gif for "workflow" requests, which is bascially when the user clicked something and we're waiting on the server. I think it's useful and not-annoying in this case.
- Don't show any status for draft requests.
- For content requests, show a subtle hipster-style top loading bar.
Test Plan:
- Viewed a diff with 93 changes, and clicked award token.
- Prior to this patch, the action took many many seconds to resolve.
- After this patch, it resolves quickly.
- Viewed a diff with 93 changes and saw a pleasant subtle hipster-style loading bar.
- Viewed a diff with 93 changes and typed some draft text. Previews populated fairly quickly and there was no spinner.
- Viewed a diff with 93 changes and clicked something with workflow, saw a spinner after a moment.
- Viewed a diff with 93 changes and clicked a file in the table of contents near the end of the list.
- Prior to this patch, it took a long time to show up.
- After this patch, it loads directly.
Reviewers: chad, btrahan
Reviewed By: btrahan
Subscribers: epriestley
Maniphest Tasks: T430, T4834
Differential Revision: https://secure.phabricator.com/D8979
2014-05-05 19:57:42 +02:00
|
|
|
'rsrc/externals/javelin/lib/Routable.js' => 'b3e7d692',
|
|
|
|
'rsrc/externals/javelin/lib/Router.js' => '29274e2b',
|
2015-01-29 16:10:35 +01:00
|
|
|
'rsrc/externals/javelin/lib/Scrollbar.js' => '5b2f5a08',
|
Introduce CAN_EDIT for ExternalAccount, and make CAN_VIEW more liberal
Summary:
Fixes T3732. Ref T1205. Ref T3116.
External accounts (like emails used as identities, Facebook accounts, LDAP accounts, etc.) are stored in "ExternalAccount" objects.
Currently, we have a very restrictive `CAN_VIEW` policy for ExternalAccounts, to add an extra layer of protection to make sure users can't use them in unintended ways. For example, it would be bad if a user could link their Phabricator account to a Facebook account without proper authentication. All of the controllers which do sensitive things have checks anyway, but a restrictive CAN_VIEW provided an extra layer of protection. Se T3116 for some discussion.
However, this means that when grey/external users take actions (via email, or via applications like Legalpad) other users can't load the account handles and can't see anything about the actor (they just see "Restricted External Account" or similar).
Balancing these concerns is mostly about not making a huge mess while doing it. This seems like a reasonable approach:
- Add `CAN_EDIT` on these objects.
- Make that very restricted, but open up `CAN_VIEW`.
- Require `CAN_EDIT` any time we're going to do something authentication/identity related.
This is slightly easier to get wrong (forget CAN_EDIT) than other approaches, but pretty simple, and we always have extra checks in place anyway -- this is just a safety net.
I'm not quite sure how we should identify external accounts, so for now we're just rendering "Email User" or similar -- clearly not a bug, but not identifying. We can figure out what to render in the long term elsewhere.
Test Plan:
- Viewed external accounts.
- Linked an external account.
- Refreshed an external account.
- Edited profile picture.
- Viewed sessions panel.
- Published a bunch of stuff to Asana/JIRA.
- Legalpad signature page now shows external accounts.
{F171595}
Reviewers: chad, btrahan
Reviewed By: btrahan
Subscribers: epriestley
Maniphest Tasks: T3732, T1205, T3116
Differential Revision: https://secure.phabricator.com/D9767
2014-07-10 19:18:10 +02:00
|
|
|
'rsrc/externals/javelin/lib/URI.js' => '6eff08aa',
|
2015-01-28 17:26:10 +01:00
|
|
|
'rsrc/externals/javelin/lib/Vector.js' => '2caa8fb8',
|
Namespace Aphlict clients by request path, plus other fixes
Summary:
Fixes T7130. Fixes T7041. Fixes T7012.
Major change here is partitioning clients. In the Phacility cluster, being able to get a huge pile of instances on a single server -- without needing to run a process per instance -- is desirable.
To accomplish this, just bucket clients by the path they connect with. This will let us set client URIs to `/instancename/` and then route connections to a small set of servers. This degrades cleanly in the common case and has no effect on installs which don't do instancing.
Also fix two unrelated issues:
- Fix the timeouts, which were incorrectly initializing in `open()` (which is called during reconnect, causing them to reset every time). Instead, initialize in the constructor. Cap timeout at 5 minutes.
- Probably fix subscriptions, which were using a property with an object definition. Since this is by-ref, all concrete instances of the object share the same property, so all users would be subscribed to everything. Probably.
Test Plan:
- Hit notification status page, saw version bump and instance/path name.
- Saw instance/path name in client and server logs.
- Stopped server, saw reconnects after 2, 4, 16, ... seconds.
- Sent test notification; received test notification.
- Didn't explicitly test the subscription thing but it should be obvious by looking at `/notification/status/` shortly after a push.
Reviewers: joshuaspence, btrahan
Reviewed By: btrahan
Subscribers: epriestley
Maniphest Tasks: T7041, T7012, T7130
Differential Revision: https://secure.phabricator.com/D11769
2015-02-16 20:31:15 +01:00
|
|
|
'rsrc/externals/javelin/lib/WebSocket.js' => 'e292eaf4',
|
2015-01-29 16:10:14 +01:00
|
|
|
'rsrc/externals/javelin/lib/Workflow.js' => '84d6aea0',
|
2014-01-01 16:46:25 +01:00
|
|
|
'rsrc/externals/javelin/lib/__tests__/Cookie.js' => '5ed109e8',
|
|
|
|
'rsrc/externals/javelin/lib/__tests__/DOM.js' => 'c984504b',
|
2015-01-14 01:10:57 +01:00
|
|
|
'rsrc/externals/javelin/lib/__tests__/JSON.js' => '837a7d68',
|
2015-01-20 11:25:17 +01:00
|
|
|
'rsrc/externals/javelin/lib/__tests__/URI.js' => '1e45fda9',
|
2014-02-27 20:06:55 +01:00
|
|
|
'rsrc/externals/javelin/lib/__tests__/behavior.js' => '1ea62783',
|
Introduce CAN_EDIT for ExternalAccount, and make CAN_VIEW more liberal
Summary:
Fixes T3732. Ref T1205. Ref T3116.
External accounts (like emails used as identities, Facebook accounts, LDAP accounts, etc.) are stored in "ExternalAccount" objects.
Currently, we have a very restrictive `CAN_VIEW` policy for ExternalAccounts, to add an extra layer of protection to make sure users can't use them in unintended ways. For example, it would be bad if a user could link their Phabricator account to a Facebook account without proper authentication. All of the controllers which do sensitive things have checks anyway, but a restrictive CAN_VIEW provided an extra layer of protection. Se T3116 for some discussion.
However, this means that when grey/external users take actions (via email, or via applications like Legalpad) other users can't load the account handles and can't see anything about the actor (they just see "Restricted External Account" or similar).
Balancing these concerns is mostly about not making a huge mess while doing it. This seems like a reasonable approach:
- Add `CAN_EDIT` on these objects.
- Make that very restricted, but open up `CAN_VIEW`.
- Require `CAN_EDIT` any time we're going to do something authentication/identity related.
This is slightly easier to get wrong (forget CAN_EDIT) than other approaches, but pretty simple, and we always have extra checks in place anyway -- this is just a safety net.
I'm not quite sure how we should identify external accounts, so for now we're just rendering "Email User" or similar -- clearly not a bug, but not identifying. We can figure out what to render in the long term elsewhere.
Test Plan:
- Viewed external accounts.
- Linked an external account.
- Refreshed an external account.
- Edited profile picture.
- Viewed sessions panel.
- Published a bunch of stuff to Asana/JIRA.
- Legalpad signature page now shows external accounts.
{F171595}
Reviewers: chad, btrahan
Reviewed By: btrahan
Subscribers: epriestley
Maniphest Tasks: T3732, T1205, T3116
Differential Revision: https://secure.phabricator.com/D9767
2014-07-10 19:18:10 +02:00
|
|
|
'rsrc/externals/javelin/lib/behavior.js' => '61cbc29a',
|
2015-01-14 01:10:57 +01:00
|
|
|
'rsrc/externals/javelin/lib/control/tokenizer/Tokenizer.js' => '7644823e',
|
|
|
|
'rsrc/externals/javelin/lib/control/typeahead/Typeahead.js' => '70baed2f',
|
2015-01-09 23:09:13 +01:00
|
|
|
'rsrc/externals/javelin/lib/control/typeahead/normalizer/TypeaheadNormalizer.js' => '6f7a9da8',
|
Introduce CAN_EDIT for ExternalAccount, and make CAN_VIEW more liberal
Summary:
Fixes T3732. Ref T1205. Ref T3116.
External accounts (like emails used as identities, Facebook accounts, LDAP accounts, etc.) are stored in "ExternalAccount" objects.
Currently, we have a very restrictive `CAN_VIEW` policy for ExternalAccounts, to add an extra layer of protection to make sure users can't use them in unintended ways. For example, it would be bad if a user could link their Phabricator account to a Facebook account without proper authentication. All of the controllers which do sensitive things have checks anyway, but a restrictive CAN_VIEW provided an extra layer of protection. Se T3116 for some discussion.
However, this means that when grey/external users take actions (via email, or via applications like Legalpad) other users can't load the account handles and can't see anything about the actor (they just see "Restricted External Account" or similar).
Balancing these concerns is mostly about not making a huge mess while doing it. This seems like a reasonable approach:
- Add `CAN_EDIT` on these objects.
- Make that very restricted, but open up `CAN_VIEW`.
- Require `CAN_EDIT` any time we're going to do something authentication/identity related.
This is slightly easier to get wrong (forget CAN_EDIT) than other approaches, but pretty simple, and we always have extra checks in place anyway -- this is just a safety net.
I'm not quite sure how we should identify external accounts, so for now we're just rendering "Email User" or similar -- clearly not a bug, but not identifying. We can figure out what to render in the long term elsewhere.
Test Plan:
- Viewed external accounts.
- Linked an external account.
- Refreshed an external account.
- Edited profile picture.
- Viewed sessions panel.
- Published a bunch of stuff to Asana/JIRA.
- Legalpad signature page now shows external accounts.
{F171595}
Reviewers: chad, btrahan
Reviewed By: btrahan
Subscribers: epriestley
Maniphest Tasks: T3732, T1205, T3116
Differential Revision: https://secure.phabricator.com/D9767
2014-07-10 19:18:10 +02:00
|
|
|
'rsrc/externals/javelin/lib/control/typeahead/source/TypeaheadCompositeSource.js' => '503e17fd',
|
|
|
|
'rsrc/externals/javelin/lib/control/typeahead/source/TypeaheadOnDemandSource.js' => '8b3fd187',
|
|
|
|
'rsrc/externals/javelin/lib/control/typeahead/source/TypeaheadPreloadedSource.js' => '54f314a0',
|
2015-01-20 01:55:08 +01:00
|
|
|
'rsrc/externals/javelin/lib/control/typeahead/source/TypeaheadSource.js' => '2818f5ce',
|
Introduce CAN_EDIT for ExternalAccount, and make CAN_VIEW more liberal
Summary:
Fixes T3732. Ref T1205. Ref T3116.
External accounts (like emails used as identities, Facebook accounts, LDAP accounts, etc.) are stored in "ExternalAccount" objects.
Currently, we have a very restrictive `CAN_VIEW` policy for ExternalAccounts, to add an extra layer of protection to make sure users can't use them in unintended ways. For example, it would be bad if a user could link their Phabricator account to a Facebook account without proper authentication. All of the controllers which do sensitive things have checks anyway, but a restrictive CAN_VIEW provided an extra layer of protection. Se T3116 for some discussion.
However, this means that when grey/external users take actions (via email, or via applications like Legalpad) other users can't load the account handles and can't see anything about the actor (they just see "Restricted External Account" or similar).
Balancing these concerns is mostly about not making a huge mess while doing it. This seems like a reasonable approach:
- Add `CAN_EDIT` on these objects.
- Make that very restricted, but open up `CAN_VIEW`.
- Require `CAN_EDIT` any time we're going to do something authentication/identity related.
This is slightly easier to get wrong (forget CAN_EDIT) than other approaches, but pretty simple, and we always have extra checks in place anyway -- this is just a safety net.
I'm not quite sure how we should identify external accounts, so for now we're just rendering "Email User" or similar -- clearly not a bug, but not identifying. We can figure out what to render in the long term elsewhere.
Test Plan:
- Viewed external accounts.
- Linked an external account.
- Refreshed an external account.
- Edited profile picture.
- Viewed sessions panel.
- Published a bunch of stuff to Asana/JIRA.
- Legalpad signature page now shows external accounts.
{F171595}
Reviewers: chad, btrahan
Reviewed By: btrahan
Subscribers: epriestley
Maniphest Tasks: T3732, T1205, T3116
Differential Revision: https://secure.phabricator.com/D9767
2014-07-10 19:18:10 +02:00
|
|
|
'rsrc/externals/javelin/lib/control/typeahead/source/TypeaheadStaticSource.js' => '316b8fa1',
|
2014-01-01 16:46:25 +01:00
|
|
|
'rsrc/externals/raphael/g.raphael.js' => '40dde778',
|
|
|
|
'rsrc/externals/raphael/g.raphael.line.js' => '40da039e',
|
|
|
|
'rsrc/externals/raphael/raphael.js' => '51ee6b43',
|
2014-11-08 02:07:38 +01:00
|
|
|
'rsrc/favicons/apple-touch-icon-120x120.png' => '43742962',
|
|
|
|
'rsrc/favicons/apple-touch-icon-152x152.png' => '669eaec3',
|
|
|
|
'rsrc/favicons/apple-touch-icon-76x76.png' => 'ecdef672',
|
|
|
|
'rsrc/favicons/favicon-128.png' => '47cdff03',
|
|
|
|
'rsrc/favicons/favicon-16x16.png' => 'ee2523ac',
|
|
|
|
'rsrc/favicons/favicon-32x32.png' => 'b6a8150e',
|
|
|
|
'rsrc/favicons/favicon-96x96.png' => '8f7ea177',
|
2014-02-14 00:15:58 +01:00
|
|
|
'rsrc/image/BFCFDA.png' => 'd5ec91f4',
|
2014-01-01 16:46:25 +01:00
|
|
|
'rsrc/image/actions/edit.png' => '2fc41442',
|
2014-03-28 03:36:51 +01:00
|
|
|
'rsrc/image/avatar.png' => '3eb28cd9',
|
2014-01-01 16:46:25 +01:00
|
|
|
'rsrc/image/checker_dark.png' => 'd8e65881',
|
|
|
|
'rsrc/image/checker_light.png' => 'a0155918',
|
2014-06-15 16:44:12 +02:00
|
|
|
'rsrc/image/checker_lighter.png' => 'd5da91b6',
|
2014-01-01 16:46:25 +01:00
|
|
|
'rsrc/image/darkload.gif' => '1ffd3ec6',
|
|
|
|
'rsrc/image/divot.png' => '94dded62',
|
2014-06-18 23:09:37 +02:00
|
|
|
'rsrc/image/examples/hero.png' => '979a86ae',
|
2014-01-01 16:46:25 +01:00
|
|
|
'rsrc/image/grippy_texture.png' => 'aca81e2f',
|
|
|
|
'rsrc/image/icon/fatcow/arrow_branch.png' => '2537c01c',
|
|
|
|
'rsrc/image/icon/fatcow/arrow_merge.png' => '21b660e0',
|
|
|
|
'rsrc/image/icon/fatcow/bullet_black.png' => 'ff190031',
|
|
|
|
'rsrc/image/icon/fatcow/bullet_orange.png' => 'e273e5bb',
|
|
|
|
'rsrc/image/icon/fatcow/bullet_red.png' => 'c0b75434',
|
|
|
|
'rsrc/image/icon/fatcow/calendar_edit.png' => '24632275',
|
|
|
|
'rsrc/image/icon/fatcow/document_black.png' => '45fe1c60',
|
|
|
|
'rsrc/image/icon/fatcow/flag_blue.png' => 'a01abb1d',
|
|
|
|
'rsrc/image/icon/fatcow/flag_finish.png' => '67825cee',
|
|
|
|
'rsrc/image/icon/fatcow/flag_ghost.png' => '20ca8783',
|
|
|
|
'rsrc/image/icon/fatcow/flag_green.png' => '7e0eaa7a',
|
|
|
|
'rsrc/image/icon/fatcow/flag_orange.png' => '9e73df66',
|
|
|
|
'rsrc/image/icon/fatcow/flag_pink.png' => '7e92f3b2',
|
|
|
|
'rsrc/image/icon/fatcow/flag_purple.png' => 'cc517522',
|
|
|
|
'rsrc/image/icon/fatcow/flag_red.png' => '04ec726f',
|
|
|
|
'rsrc/image/icon/fatcow/flag_yellow.png' => '73946fd4',
|
|
|
|
'rsrc/image/icon/fatcow/folder.png' => '95a435af',
|
|
|
|
'rsrc/image/icon/fatcow/folder_go.png' => '001cbc94',
|
|
|
|
'rsrc/image/icon/fatcow/key_question.png' => '52a0c26a',
|
|
|
|
'rsrc/image/icon/fatcow/link.png' => '7afd4d5e',
|
|
|
|
'rsrc/image/icon/fatcow/page_white_edit.png' => '39a2eed8',
|
|
|
|
'rsrc/image/icon/fatcow/page_white_link.png' => 'a90023c7',
|
|
|
|
'rsrc/image/icon/fatcow/page_white_put.png' => '08c95a0c',
|
|
|
|
'rsrc/image/icon/fatcow/page_white_text.png' => '1e1f79c3',
|
|
|
|
'rsrc/image/icon/fatcow/source/conduit.png' => '4ea01d2f',
|
|
|
|
'rsrc/image/icon/fatcow/source/email.png' => '9bab3239',
|
|
|
|
'rsrc/image/icon/fatcow/source/fax.png' => '04195e68',
|
|
|
|
'rsrc/image/icon/fatcow/source/mobile.png' => 'f1321264',
|
|
|
|
'rsrc/image/icon/fatcow/source/tablet.png' => '49396799',
|
|
|
|
'rsrc/image/icon/fatcow/source/web.png' => '136ccb5d',
|
2014-06-15 17:03:04 +02:00
|
|
|
'rsrc/image/icon/fatcow/thumbnails/default.p100.png' => '7d490b01',
|
2014-01-01 16:46:25 +01:00
|
|
|
'rsrc/image/icon/fatcow/thumbnails/default160x120.png' => 'f2e8a2eb',
|
2014-06-15 17:03:04 +02:00
|
|
|
'rsrc/image/icon/fatcow/thumbnails/default280x210.png' => '43e8926a',
|
2014-01-01 16:46:25 +01:00
|
|
|
'rsrc/image/icon/fatcow/thumbnails/default60x45.png' => '0118abed',
|
2014-06-15 17:03:04 +02:00
|
|
|
'rsrc/image/icon/fatcow/thumbnails/image.p100.png' => 'da23cf97',
|
2014-01-01 16:46:25 +01:00
|
|
|
'rsrc/image/icon/fatcow/thumbnails/image160x120.png' => '79bb556a',
|
2014-06-15 17:03:04 +02:00
|
|
|
'rsrc/image/icon/fatcow/thumbnails/image280x210.png' => '91ae054a',
|
2014-01-01 16:46:25 +01:00
|
|
|
'rsrc/image/icon/fatcow/thumbnails/image60x45.png' => 'c5e1685e',
|
2014-06-15 17:03:04 +02:00
|
|
|
'rsrc/image/icon/fatcow/thumbnails/pdf.p100.png' => '87d5e065',
|
2014-01-01 16:46:25 +01:00
|
|
|
'rsrc/image/icon/fatcow/thumbnails/pdf160x120.png' => 'ac9edbf5',
|
2014-06-15 17:03:04 +02:00
|
|
|
'rsrc/image/icon/fatcow/thumbnails/pdf280x210.png' => '1c585653',
|
2014-01-01 16:46:25 +01:00
|
|
|
'rsrc/image/icon/fatcow/thumbnails/pdf60x45.png' => 'c0db4143',
|
2014-06-15 17:03:04 +02:00
|
|
|
'rsrc/image/icon/fatcow/thumbnails/zip.p100.png' => '6ea5aae4',
|
2014-01-01 16:46:25 +01:00
|
|
|
'rsrc/image/icon/fatcow/thumbnails/zip160x120.png' => '75f9cd0f',
|
2014-06-15 17:03:04 +02:00
|
|
|
'rsrc/image/icon/fatcow/thumbnails/zip280x210.png' => 'dfda5b8e',
|
2014-01-01 16:46:25 +01:00
|
|
|
'rsrc/image/icon/fatcow/thumbnails/zip60x45.png' => 'af11bf3e',
|
|
|
|
'rsrc/image/icon/lightbox/close-2.png' => 'cc40e7c8',
|
|
|
|
'rsrc/image/icon/lightbox/close-hover-2.png' => 'fb5d6d9e',
|
|
|
|
'rsrc/image/icon/lightbox/left-arrow-2.png' => '8426133b',
|
|
|
|
'rsrc/image/icon/lightbox/left-arrow-hover-2.png' => '701e5ee3',
|
|
|
|
'rsrc/image/icon/lightbox/right-arrow-2.png' => '6d5519a0',
|
|
|
|
'rsrc/image/icon/lightbox/right-arrow-hover-2.png' => '3a04aa21',
|
|
|
|
'rsrc/image/icon/subscribe.png' => 'd03ed5a5',
|
|
|
|
'rsrc/image/icon/tango/attachment.png' => 'ecc8022e',
|
|
|
|
'rsrc/image/icon/tango/edit.png' => '929a1363',
|
|
|
|
'rsrc/image/icon/tango/go-down.png' => '96d95e43',
|
|
|
|
'rsrc/image/icon/tango/log.png' => 'b08cc63a',
|
|
|
|
'rsrc/image/icon/tango/upload.png' => '7bbb7984',
|
|
|
|
'rsrc/image/icon/unsubscribe.png' => '25725013',
|
2014-01-18 17:31:47 +01:00
|
|
|
'rsrc/image/lightblue-header.png' => '5c168b6d',
|
2014-01-01 16:46:25 +01:00
|
|
|
'rsrc/image/loading.gif' => '75d384cc',
|
|
|
|
'rsrc/image/loading/boating_24.gif' => '5c90f086',
|
|
|
|
'rsrc/image/loading/compass_24.gif' => 'b36b4f46',
|
|
|
|
'rsrc/image/loading/loading_24.gif' => '26bc9adc',
|
|
|
|
'rsrc/image/loading/loading_48.gif' => '6a4994c7',
|
|
|
|
'rsrc/image/loading/loading_d48.gif' => 'cdcbe900',
|
|
|
|
'rsrc/image/loading/loading_w24.gif' => '7662fa2b',
|
|
|
|
'rsrc/image/main_texture.png' => '29a2c5ad',
|
|
|
|
'rsrc/image/menu_texture.png' => '5a17580d',
|
|
|
|
'rsrc/image/people/harding.png' => '45aa614e',
|
|
|
|
'rsrc/image/people/jefferson.png' => 'afca0e53',
|
|
|
|
'rsrc/image/people/lincoln.png' => '9369126d',
|
|
|
|
'rsrc/image/people/mckinley.png' => 'fb8f16ce',
|
|
|
|
'rsrc/image/people/taft.png' => 'd7bc402c',
|
|
|
|
'rsrc/image/people/washington.png' => '40dd301c',
|
|
|
|
'rsrc/image/phrequent_active.png' => 'a466a8ed',
|
|
|
|
'rsrc/image/phrequent_inactive.png' => 'bfc15a69',
|
|
|
|
'rsrc/image/search-white.png' => '64cc0d45',
|
|
|
|
'rsrc/image/search.png' => '82625a7e',
|
2014-06-24 18:39:32 +02:00
|
|
|
'rsrc/image/sprite-gradient.png' => 'ec15a417',
|
2014-10-29 23:06:15 +01:00
|
|
|
'rsrc/image/sprite-login-X2.png' => '5ae6de3a',
|
|
|
|
'rsrc/image/sprite-login.png' => '07f2c67c',
|
2015-03-01 21:03:02 +01:00
|
|
|
'rsrc/image/sprite-main-header.png' => '39419fa6',
|
2015-02-19 23:43:33 +01:00
|
|
|
'rsrc/image/sprite-menu-X2.png' => '1c90d7bc',
|
|
|
|
'rsrc/image/sprite-menu.png' => '619781ee',
|
2015-01-14 19:49:36 +01:00
|
|
|
'rsrc/image/sprite-projects-X2.png' => '8c91c839',
|
|
|
|
'rsrc/image/sprite-projects.png' => 'ef9dc9b5',
|
2014-02-17 19:06:16 +01:00
|
|
|
'rsrc/image/sprite-tokens-X2.png' => 'b4776580',
|
|
|
|
'rsrc/image/sprite-tokens.png' => '25b75533',
|
2014-01-01 16:46:25 +01:00
|
|
|
'rsrc/image/texture/card-gradient.png' => '815f26e8',
|
|
|
|
'rsrc/image/texture/dark-menu-hover.png' => '5fa7ece8',
|
|
|
|
'rsrc/image/texture/dark-menu.png' => '7e22296e',
|
|
|
|
'rsrc/image/texture/grip.png' => '719404f3',
|
|
|
|
'rsrc/image/texture/panel-header-gradient.png' => 'e3b8dcfe',
|
|
|
|
'rsrc/image/texture/phlnx-bg.png' => '8d819209',
|
|
|
|
'rsrc/image/texture/pholio-background.gif' => 'ba29239c',
|
|
|
|
'rsrc/image/texture/table_header.png' => '5c433037',
|
|
|
|
'rsrc/image/texture/table_header_hover.png' => '038ec3b9',
|
|
|
|
'rsrc/image/texture/table_header_tall.png' => 'd56b434f',
|
Multiplex AJAX calls
Summary: Fixes T5344. Essentially, we only make the AJAX request to `/notification/individual/` if we are the leader tab (i.e. only one tab will make this request). Once a response has been received from the server (containing the contents of the notification), we broadcast the message contents back to all other tabs for rendering.
Test Plan:
Opened two tabs on `/notification/status/` and clicked "Send Test Notification".
**Before**
```lang=bash, name=tail -f /var/log/phabricator-access.log | grep /notification/individual/
[Tue, 13 Jan 2015 20:10:37 +1100] 17033 phabricator 10.0.0.1 josh PhabricatorNotificationIndividualController - /notification/individual/-200 236036
[Tue, 13 Jan 2015 20:10:37 +1100] 17657 phabricator 10.0.0.1 josh PhabricatorNotificationIndividualController - /notification/individual/-200 24130
```
**After**
```lang=bash, name=tail -f /var/log/phabricator-access.log | grep /notification/individual/
[Tue, 13 Jan 2015 20:11:15 +1100] 17657 phabricator 10.0.0.1 josh PhabricatorNotificationIndividualController - /notification/individual/-200 180217
```
Reviewers: #blessed_reviewers, epriestley
Reviewed By: #blessed_reviewers, epriestley
Subscribers: Korvin, epriestley
Maniphest Tasks: T5344
Differential Revision: https://secure.phabricator.com/D11360
2015-01-15 21:05:31 +01:00
|
|
|
'rsrc/js/application/aphlict/Aphlict.js' => '2be71d56',
|
Conpherence - make the durable column kind of work and stuff
Summary:
Ref T7014. This hooks up the durable column such that when you open it up it loads your most recent Conpherence. You can then switch amongst the various widgets and stuff and everything works nicely.
Except...
- scroll bar does not work
- also doesn't work at HEAD when I add a ton of text to the UI with no changes? (wrapped $copy in array_fill(0, 1000, $copy))
- "widget selector" does not collapse when you select something else
- this part wasn't really specified so I used the aphlict dropdown stuff. didn't want to keep working on that if this was the wrong UI choice
- can not edit title
- do we still want that to be done by clicking on the title, which pops a dialogue?
- can not add participants or calendar events
- what should this UI be? maybe just a button on the top for "participants" and a button on the bottom for calendar? both on top?
- this is not pixel perfect to the mock or two I've seen around. Aside from generally being bad at that, I definitely didn't get the name + timestamps formatting correctly, because the standard DOM of that has timestamp FIRST which appears second due to a "float right". Seemed like a lot of special-casing for what might not even be that important in the UI so I punted. (And again, there's likely many unknown ways in which this isn't pixel perfect)
There's also code quality issues
- `ConpherenceWidgetConfigConstants` is hopefully temporary or at least gets more sleek as we keep progressing here
- copied some CSS from main Conpherence app
- DOM structure is pretty different
- there's some minor CSS tweaks too given the different width (not to mention the DOM structure being different)
- copied some JS from behavior-pontificate.js to sync threads relative to aphlict updates
- JS in general is like a better version of existing JS; these should collapse I'd hope?
- maybe the aphlict-behavior-dropdown change was badsauce?
...but all that said, this definitely feels really nice and I feel like adding stuff is going to be really easy compared to how normal Conpherence is.
Also includes a bonus bug fix - we now correctly update participation. The user would encounter this issue if they were in a conpherence that got some updates and then they went to a different page; they would have unread status for the messages that were ajax'd in. This patch fixes that by making sure we mark participation up to date with the proper transaction in all cases.
Test Plan: hit "\" to invoke the column and saw nice loading UI and my latest conpherence load. sent messages and verified they received A-OK by looking in DOM console. toggled various widges and verified they rendered correctly. opened up a second browser with a second user on the thread, sent a message, and it was received in a nice asynchronous fashion
Reviewers: chad, epriestley
Reviewed By: epriestley
Subscribers: Korvin, epriestley
Maniphest Tasks: T7014
Differential Revision: https://secure.phabricator.com/D11968
2015-03-05 19:33:39 +01:00
|
|
|
'rsrc/js/application/aphlict/behavior-aphlict-dropdown.js' => 'cc2d9c80',
|
Multiplex AJAX calls
Summary: Fixes T5344. Essentially, we only make the AJAX request to `/notification/individual/` if we are the leader tab (i.e. only one tab will make this request). Once a response has been received from the server (containing the contents of the notification), we broadcast the message contents back to all other tabs for rendering.
Test Plan:
Opened two tabs on `/notification/status/` and clicked "Send Test Notification".
**Before**
```lang=bash, name=tail -f /var/log/phabricator-access.log | grep /notification/individual/
[Tue, 13 Jan 2015 20:10:37 +1100] 17033 phabricator 10.0.0.1 josh PhabricatorNotificationIndividualController - /notification/individual/-200 236036
[Tue, 13 Jan 2015 20:10:37 +1100] 17657 phabricator 10.0.0.1 josh PhabricatorNotificationIndividualController - /notification/individual/-200 24130
```
**After**
```lang=bash, name=tail -f /var/log/phabricator-access.log | grep /notification/individual/
[Tue, 13 Jan 2015 20:11:15 +1100] 17657 phabricator 10.0.0.1 josh PhabricatorNotificationIndividualController - /notification/individual/-200 180217
```
Reviewers: #blessed_reviewers, epriestley
Reviewed By: #blessed_reviewers, epriestley
Subscribers: Korvin, epriestley
Maniphest Tasks: T5344
Differential Revision: https://secure.phabricator.com/D11360
2015-01-15 21:05:31 +01:00
|
|
|
'rsrc/js/application/aphlict/behavior-aphlict-listen.js' => '851f167c',
|
2015-01-14 22:08:08 +01:00
|
|
|
'rsrc/js/application/aphlict/behavior-aphlict-status.js' => 'ea681761',
|
2014-01-01 16:46:25 +01:00
|
|
|
'rsrc/js/application/auth/behavior-persona-login.js' => '9414ff18',
|
2014-06-23 19:27:47 +02:00
|
|
|
'rsrc/js/application/config/behavior-reorder-fields.js' => '14a827de',
|
2015-03-05 19:43:26 +01:00
|
|
|
'rsrc/js/application/conpherence/behavior-durable-column.js' => 'a88a26cc',
|
2015-02-26 19:27:28 +01:00
|
|
|
'rsrc/js/application/conpherence/behavior-menu.js' => '869e3445',
|
2015-02-26 00:14:27 +01:00
|
|
|
'rsrc/js/application/conpherence/behavior-pontificate.js' => '86df5915',
|
2014-05-05 19:57:23 +02:00
|
|
|
'rsrc/js/application/conpherence/behavior-widget-pane.js' => '40b1ff90',
|
2014-12-30 11:53:27 +01:00
|
|
|
'rsrc/js/application/countdown/timer.js' => 'e4cc26b3',
|
2014-05-19 23:04:26 +02:00
|
|
|
'rsrc/js/application/dashboard/behavior-dashboard-async-panel.js' => '469c0d9e',
|
2014-06-23 19:27:47 +02:00
|
|
|
'rsrc/js/application/dashboard/behavior-dashboard-move-panels.js' => '82439934',
|
2014-07-13 18:18:50 +02:00
|
|
|
'rsrc/js/application/dashboard/behavior-dashboard-query-panel-select.js' => '453c5375',
|
2014-06-23 19:27:47 +02:00
|
|
|
'rsrc/js/application/dashboard/behavior-dashboard-tab-panel.js' => 'd4eecc63',
|
Make "Show Context" persist rendering, whitespace, encoding, etc
Summary:
Ref T2009. Currently, we do not persist view parameters when making context rendering requests.
The big one is the renderer (1up vs 2up). This makes context on unified diffs come in with too many columns.
However, it impacts other parameters too. For example, at HEAD, if you change highlighting to "rainbow" and then load more context, the context uses the original highlighter instead of the rainbow highlighter.
This moves context loads into ChangesetViewManager, which maintains view parameters and can provide them correctly.
- This removes "ref"; it is no longer required, as the ChangesetViewManager tracks it.
- This removes URI management from `behavior-show-more`; it is no longer required, since the ChangesetViewManager knows how to render.
- This removes "whitespace" since this is handled properly by the view manager.
Test Plan:
- Used "Show Top" / "Show All" / "Show Bottom" in 1-up and 2-up views.
- Changed file highlighting to rainbow, loaded stuff, saw rainbow stick.
- Used "Show Entire File" in 1-up and 2-up views.
- Saw loading chrome.
- No loading chrome normally.
- Made inlines, verified `copyRows()` code runs.
- Poked around Diffusion -- it is missing some parameter handling, but works OK.
Reviewers: btrahan
Reviewed By: btrahan
Subscribers: epriestley
Maniphest Tasks: T2009
Differential Revision: https://secure.phabricator.com/D11977
2015-03-05 23:03:00 +01:00
|
|
|
'rsrc/js/application/differential/ChangesetViewManager.js' => 'fce415a0',
|
2015-03-05 23:11:51 +01:00
|
|
|
'rsrc/js/application/differential/DifferentialInlineCommentEditor.js' => '41060c54',
|
2014-06-23 19:27:47 +02:00
|
|
|
'rsrc/js/application/differential/behavior-add-reviewers-and-ccs.js' => 'e10f8e18',
|
2014-07-01 20:04:05 +02:00
|
|
|
'rsrc/js/application/differential/behavior-comment-jump.js' => '4fdb476d',
|
2014-08-28 22:08:32 +02:00
|
|
|
'rsrc/js/application/differential/behavior-comment-preview.js' => '6932def3',
|
2014-01-01 16:46:25 +01:00
|
|
|
'rsrc/js/application/differential/behavior-diff-radios.js' => 'e1ff79b1',
|
Make "Show Context" persist rendering, whitespace, encoding, etc
Summary:
Ref T2009. Currently, we do not persist view parameters when making context rendering requests.
The big one is the renderer (1up vs 2up). This makes context on unified diffs come in with too many columns.
However, it impacts other parameters too. For example, at HEAD, if you change highlighting to "rainbow" and then load more context, the context uses the original highlighter instead of the rainbow highlighter.
This moves context loads into ChangesetViewManager, which maintains view parameters and can provide them correctly.
- This removes "ref"; it is no longer required, as the ChangesetViewManager tracks it.
- This removes URI management from `behavior-show-more`; it is no longer required, since the ChangesetViewManager knows how to render.
- This removes "whitespace" since this is handled properly by the view manager.
Test Plan:
- Used "Show Top" / "Show All" / "Show Bottom" in 1-up and 2-up views.
- Changed file highlighting to rainbow, loaded stuff, saw rainbow stick.
- Used "Show Entire File" in 1-up and 2-up views.
- Saw loading chrome.
- No loading chrome normally.
- Made inlines, verified `copyRows()` code runs.
- Poked around Diffusion -- it is missing some parameter handling, but works OK.
Reviewers: btrahan
Reviewed By: btrahan
Subscribers: epriestley
Maniphest Tasks: T2009
Differential Revision: https://secure.phabricator.com/D11977
2015-03-05 23:03:00 +01:00
|
|
|
'rsrc/js/application/differential/behavior-dropdown-menus.js' => '2035b9cb',
|
2015-03-05 23:11:51 +01:00
|
|
|
'rsrc/js/application/differential/behavior-edit-inline-comments.js' => 'ae8e9b44',
|
2014-11-12 21:26:22 +01:00
|
|
|
'rsrc/js/application/differential/behavior-keyboard-nav.js' => '2c426492',
|
2015-03-05 23:03:15 +01:00
|
|
|
'rsrc/js/application/differential/behavior-populate.js' => '8694b1df',
|
2014-06-23 19:27:47 +02:00
|
|
|
'rsrc/js/application/differential/behavior-show-field-details.js' => 'bba9eedf',
|
2014-01-01 16:46:25 +01:00
|
|
|
'rsrc/js/application/differential/behavior-toggle-files.js' => 'ca3f91eb',
|
|
|
|
'rsrc/js/application/differential/behavior-user-select.js' => 'a8d8459d',
|
2014-06-23 19:35:39 +02:00
|
|
|
'rsrc/js/application/diffusion/DiffusionLocateFileSource.js' => 'b42eddc7',
|
2014-06-23 19:27:47 +02:00
|
|
|
'rsrc/js/application/diffusion/behavior-audit-preview.js' => 'd835b03a',
|
2014-02-27 20:06:55 +01:00
|
|
|
'rsrc/js/application/diffusion/behavior-commit-branches.js' => 'bdaf4d04',
|
|
|
|
'rsrc/js/application/diffusion/behavior-commit-graph.js' => 'f7f1289f',
|
2015-01-29 19:20:35 +01:00
|
|
|
'rsrc/js/application/diffusion/behavior-jump-to.js' => '73d09eef',
|
2014-01-01 16:46:25 +01:00
|
|
|
'rsrc/js/application/diffusion/behavior-load-blame.js' => '42126667',
|
2014-05-13 23:09:00 +02:00
|
|
|
'rsrc/js/application/diffusion/behavior-locate-file.js' => '6d3e1947',
|
2014-05-12 20:53:31 +02:00
|
|
|
'rsrc/js/application/diffusion/behavior-pull-lastmodified.js' => '2b228192',
|
2014-02-27 20:06:55 +01:00
|
|
|
'rsrc/js/application/doorkeeper/behavior-doorkeeper-tag.js' => 'e5822781',
|
|
|
|
'rsrc/js/application/files/behavior-icon-composer.js' => '8ef9ab58',
|
|
|
|
'rsrc/js/application/files/behavior-launch-icon-composer.js' => '48086888',
|
2015-01-29 23:15:38 +01:00
|
|
|
'rsrc/js/application/herald/HeraldRuleEditor.js' => '6e2de6f2',
|
2014-01-01 16:46:25 +01:00
|
|
|
'rsrc/js/application/herald/PathTypeahead.js' => 'f7fc67ec',
|
|
|
|
'rsrc/js/application/herald/herald-rule-editor.js' => '7ebaeed3',
|
2014-12-30 11:53:27 +01:00
|
|
|
'rsrc/js/application/maniphest/behavior-batch-editor.js' => 'f24f3253',
|
2014-06-23 19:27:47 +02:00
|
|
|
'rsrc/js/application/maniphest/behavior-batch-selector.js' => '7b98d7c5',
|
2015-02-24 18:41:37 +01:00
|
|
|
'rsrc/js/application/maniphest/behavior-line-chart.js' => '88f0c5b3',
|
2014-06-23 19:27:47 +02:00
|
|
|
'rsrc/js/application/maniphest/behavior-list-edit.js' => 'a9f88de2',
|
2014-01-01 16:46:25 +01:00
|
|
|
'rsrc/js/application/maniphest/behavior-subpriorityeditor.js' => '84845b5b',
|
2014-06-23 19:27:47 +02:00
|
|
|
'rsrc/js/application/maniphest/behavior-transaction-controls.js' => '44168bad',
|
|
|
|
'rsrc/js/application/maniphest/behavior-transaction-expand.js' => '5fefb143',
|
2014-01-01 16:46:25 +01:00
|
|
|
'rsrc/js/application/maniphest/behavior-transaction-preview.js' => 'f8248bc5',
|
2014-06-23 19:35:39 +02:00
|
|
|
'rsrc/js/application/owners/OwnersPathEditor.js' => 'aa1733d0',
|
2014-01-01 16:46:25 +01:00
|
|
|
'rsrc/js/application/owners/owners-path-editor.js' => '7a68dda3',
|
2015-03-02 22:01:00 +01:00
|
|
|
'rsrc/js/application/passphrase/passphrase-credential-control.js' => '3cb0b2fc',
|
2014-06-23 19:27:47 +02:00
|
|
|
'rsrc/js/application/phame/phame-post-preview.js' => 'be807912',
|
|
|
|
'rsrc/js/application/pholio/behavior-pholio-mock-edit.js' => '9c2623f4',
|
2014-12-30 11:56:42 +01:00
|
|
|
'rsrc/js/application/pholio/behavior-pholio-mock-view.js' => 'e58bf807',
|
2014-12-30 11:53:27 +01:00
|
|
|
'rsrc/js/application/phortune/behavior-balanced-payment-form.js' => 'b2c03e60',
|
|
|
|
'rsrc/js/application/phortune/behavior-stripe-payment-form.js' => '3f5d6dbf',
|
|
|
|
'rsrc/js/application/phortune/behavior-test-payment-form.js' => 'fc91ab6c',
|
2014-01-01 16:46:25 +01:00
|
|
|
'rsrc/js/application/phortune/phortune-credit-card-form.js' => '2290aeef',
|
2014-05-29 05:56:20 +02:00
|
|
|
'rsrc/js/application/policy/behavior-policy-control.js' => 'f3fef818',
|
2014-07-18 00:56:20 +02:00
|
|
|
'rsrc/js/application/policy/behavior-policy-rule-editor.js' => 'fe9a552f',
|
2014-06-23 19:27:47 +02:00
|
|
|
'rsrc/js/application/ponder/behavior-votebox.js' => '4e9b766b',
|
2014-06-25 21:30:53 +02:00
|
|
|
'rsrc/js/application/projects/behavior-boards-dropdown.js' => '0ec56e1d',
|
2015-01-07 02:50:40 +01:00
|
|
|
'rsrc/js/application/projects/behavior-project-boards.js' => '87cb6b51',
|
2014-01-01 16:46:25 +01:00
|
|
|
'rsrc/js/application/projects/behavior-project-create.js' => '065227cc',
|
2014-08-09 17:49:01 +02:00
|
|
|
'rsrc/js/application/projects/behavior-reorder-columns.js' => 'e1d25dfb',
|
2014-06-23 19:27:47 +02:00
|
|
|
'rsrc/js/application/releeph/releeph-preview-branch.js' => 'b2b4fbaf',
|
2015-01-25 17:46:22 +01:00
|
|
|
'rsrc/js/application/releeph/releeph-request-state-change.js' => 'a0b57eb8',
|
Introduce CAN_EDIT for ExternalAccount, and make CAN_VIEW more liberal
Summary:
Fixes T3732. Ref T1205. Ref T3116.
External accounts (like emails used as identities, Facebook accounts, LDAP accounts, etc.) are stored in "ExternalAccount" objects.
Currently, we have a very restrictive `CAN_VIEW` policy for ExternalAccounts, to add an extra layer of protection to make sure users can't use them in unintended ways. For example, it would be bad if a user could link their Phabricator account to a Facebook account without proper authentication. All of the controllers which do sensitive things have checks anyway, but a restrictive CAN_VIEW provided an extra layer of protection. Se T3116 for some discussion.
However, this means that when grey/external users take actions (via email, or via applications like Legalpad) other users can't load the account handles and can't see anything about the actor (they just see "Restricted External Account" or similar).
Balancing these concerns is mostly about not making a huge mess while doing it. This seems like a reasonable approach:
- Add `CAN_EDIT` on these objects.
- Make that very restricted, but open up `CAN_VIEW`.
- Require `CAN_EDIT` any time we're going to do something authentication/identity related.
This is slightly easier to get wrong (forget CAN_EDIT) than other approaches, but pretty simple, and we always have extra checks in place anyway -- this is just a safety net.
I'm not quite sure how we should identify external accounts, so for now we're just rendering "Email User" or similar -- clearly not a bug, but not identifying. We can figure out what to render in the long term elsewhere.
Test Plan:
- Viewed external accounts.
- Linked an external account.
- Refreshed an external account.
- Edited profile picture.
- Viewed sessions panel.
- Published a bunch of stuff to Asana/JIRA.
- Legalpad signature page now shows external accounts.
{F171595}
Reviewers: chad, btrahan
Reviewed By: btrahan
Subscribers: epriestley
Maniphest Tasks: T3732, T1205, T3116
Differential Revision: https://secure.phabricator.com/D9767
2014-07-10 19:18:10 +02:00
|
|
|
'rsrc/js/application/releeph/releeph-request-typeahead.js' => 'de2e896f',
|
2014-06-23 19:27:47 +02:00
|
|
|
'rsrc/js/application/repository/repository-crossreference.js' => 'f9539603',
|
|
|
|
'rsrc/js/application/search/behavior-reorder-queries.js' => 'e9581f08',
|
2015-01-23 22:29:15 +01:00
|
|
|
'rsrc/js/application/slowvote/behavior-slowvote-embed.js' => '887ad43f',
|
2015-01-28 17:26:10 +01:00
|
|
|
'rsrc/js/application/transactions/behavior-show-older-transactions.js' => 'dbbf48b6',
|
2014-06-21 21:50:40 +02:00
|
|
|
'rsrc/js/application/transactions/behavior-transaction-comment-form.js' => '9f7309fb',
|
2014-08-08 00:21:32 +02:00
|
|
|
'rsrc/js/application/transactions/behavior-transaction-list.js' => '13c739ea',
|
2014-01-01 16:46:25 +01:00
|
|
|
'rsrc/js/application/uiexample/JavelinViewExample.js' => 'd4a14807',
|
2014-06-23 19:35:39 +02:00
|
|
|
'rsrc/js/application/uiexample/ReactorButtonExample.js' => 'd19198c8',
|
2014-06-23 19:27:47 +02:00
|
|
|
'rsrc/js/application/uiexample/ReactorCheckboxExample.js' => '519705ea',
|
|
|
|
'rsrc/js/application/uiexample/ReactorFocusExample.js' => '40a6a403',
|
|
|
|
'rsrc/js/application/uiexample/ReactorInputExample.js' => '886fd850',
|
2014-06-23 19:35:39 +02:00
|
|
|
'rsrc/js/application/uiexample/ReactorMouseoverExample.js' => '47c794d8',
|
2014-06-23 19:27:47 +02:00
|
|
|
'rsrc/js/application/uiexample/ReactorRadioExample.js' => '988040b4',
|
|
|
|
'rsrc/js/application/uiexample/ReactorSelectExample.js' => 'a155550f',
|
|
|
|
'rsrc/js/application/uiexample/ReactorSendClassExample.js' => '1def2711',
|
|
|
|
'rsrc/js/application/uiexample/ReactorSendPropertiesExample.js' => 'b1f0ccee',
|
|
|
|
'rsrc/js/application/uiexample/busy-example.js' => '60479091',
|
|
|
|
'rsrc/js/application/uiexample/gesture-example.js' => '558829c2',
|
2014-12-30 11:54:21 +01:00
|
|
|
'rsrc/js/application/uiexample/notification-example.js' => '8ce821c5',
|
2014-01-01 16:46:25 +01:00
|
|
|
'rsrc/js/core/Busy.js' => '6453c869',
|
2014-08-21 01:21:50 +02:00
|
|
|
'rsrc/js/core/DragAndDropFileUpload.js' => '8c49f386',
|
2014-09-09 23:20:27 +02:00
|
|
|
'rsrc/js/core/DraggableList.js' => 'a16ec1c6',
|
2014-02-27 20:06:55 +01:00
|
|
|
'rsrc/js/core/FileUpload.js' => 'a4ae61bf',
|
2014-06-23 19:35:39 +02:00
|
|
|
'rsrc/js/core/Hovercard.js' => '7e8468ae',
|
2014-01-01 16:46:25 +01:00
|
|
|
'rsrc/js/core/KeyboardShortcut.js' => '1ae869f2',
|
2015-01-25 17:46:22 +01:00
|
|
|
'rsrc/js/core/KeyboardShortcutManager.js' => 'c1700f6f',
|
2014-11-17 23:06:05 +01:00
|
|
|
'rsrc/js/core/MultirowRowManager.js' => 'b5d57730',
|
2014-02-27 20:06:55 +01:00
|
|
|
'rsrc/js/core/Notification.js' => '0c6946e7',
|
2015-01-09 23:53:56 +01:00
|
|
|
'rsrc/js/core/Prefab.js' => '72da38cc',
|
Provide a global router for Ajax requests
Summary:
Fixes T430. Fixes T4834. Obsoletes D7641. Currently, we do some things less-well than we could:
- We just let the browser queue and prioritize requests, so if you load a revision with 50 changes and then click "Award Token", the action blocks until the changes load in most/all browsers. It would be better to prioritize this action and queue it immediately.
- Similarly, changes tend to load in order, even if the user has clicked to a specific file. When the user expresses a preference for a specific file, we should prioritize it.
- We show a spinning GIF when waiting on requests. This is appropriate for some types of reuqests, but distracting for others.
To fix this:
- Queue all (or, at least, most) requests into a new queue in JX.Router.
- JX.Router handles prioritizing the requests. Principally:
- You can submit a request with a specific priority (500 = general content loading, 1000 = default, 2000 = explicit user action) and JX.Router will get the higher stuff fired off sooner.
- You can name requests and then adjust their prorities later, if the user expresses an interest in specific results.
- Only use the spinner gif for "workflow" requests, which is bascially when the user clicked something and we're waiting on the server. I think it's useful and not-annoying in this case.
- Don't show any status for draft requests.
- For content requests, show a subtle hipster-style top loading bar.
Test Plan:
- Viewed a diff with 93 changes, and clicked award token.
- Prior to this patch, the action took many many seconds to resolve.
- After this patch, it resolves quickly.
- Viewed a diff with 93 changes and saw a pleasant subtle hipster-style loading bar.
- Viewed a diff with 93 changes and typed some draft text. Previews populated fairly quickly and there was no spinner.
- Viewed a diff with 93 changes and clicked something with workflow, saw a spinner after a moment.
- Viewed a diff with 93 changes and clicked a file in the table of contents near the end of the list.
- Prior to this patch, it took a long time to show up.
- After this patch, it loads directly.
Reviewers: chad, btrahan
Reviewed By: btrahan
Subscribers: epriestley
Maniphest Tasks: T430, T4834
Differential Revision: https://secure.phabricator.com/D8979
2014-05-05 19:57:42 +02:00
|
|
|
'rsrc/js/core/ShapedRequest.js' => '7cbe244b',
|
2014-08-19 23:46:37 +02:00
|
|
|
'rsrc/js/core/TextAreaUtils.js' => '5c93c52c',
|
2014-09-10 19:17:49 +02:00
|
|
|
'rsrc/js/core/Title.js' => '5c1c758c',
|
2015-01-20 01:55:08 +01:00
|
|
|
'rsrc/js/core/ToolTip.js' => '1d298e3a',
|
2014-06-23 19:27:47 +02:00
|
|
|
'rsrc/js/core/behavior-active-nav.js' => 'e379b58e',
|
2014-01-01 16:46:25 +01:00
|
|
|
'rsrc/js/core/behavior-audio-source.js' => '59b251eb',
|
|
|
|
'rsrc/js/core/behavior-autofocus.js' => '7319e029',
|
2014-06-26 18:41:07 +02:00
|
|
|
'rsrc/js/core/behavior-choose-control.js' => '6153c708',
|
2014-06-23 19:27:47 +02:00
|
|
|
'rsrc/js/core/behavior-crop.js' => 'fa0f4fc2',
|
2015-01-03 00:30:00 +01:00
|
|
|
'rsrc/js/core/behavior-dark-console.js' => '08883e8b',
|
2014-01-01 16:46:25 +01:00
|
|
|
'rsrc/js/core/behavior-device.js' => '03d6ed07',
|
2014-06-23 19:35:39 +02:00
|
|
|
'rsrc/js/core/behavior-drag-and-drop-textarea.js' => '92eb531d',
|
2014-12-30 11:51:31 +01:00
|
|
|
'rsrc/js/core/behavior-error-log.js' => '6882e80a',
|
2014-08-16 23:55:22 +02:00
|
|
|
'rsrc/js/core/behavior-fancy-datepicker.js' => 'c51ae228',
|
2014-06-23 19:27:47 +02:00
|
|
|
'rsrc/js/core/behavior-file-tree.js' => '88236f00',
|
2014-08-02 23:44:35 +02:00
|
|
|
'rsrc/js/core/behavior-form.js' => '5c54cbf3',
|
2014-06-23 19:27:47 +02:00
|
|
|
'rsrc/js/core/behavior-gesture.js' => '3ab51e2c',
|
Give files uploaded to objects a very restrictive view policy
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
2014-08-02 23:46:13 +02:00
|
|
|
'rsrc/js/core/behavior-global-drag-and-drop.js' => '07f199d8',
|
2014-04-28 02:31:35 +02:00
|
|
|
'rsrc/js/core/behavior-high-security-warning.js' => '8fc1c918',
|
2014-01-01 16:46:25 +01:00
|
|
|
'rsrc/js/core/behavior-history-install.js' => '7ee2b591',
|
2014-06-23 19:27:47 +02:00
|
|
|
'rsrc/js/core/behavior-hovercard.js' => 'f36e01af',
|
|
|
|
'rsrc/js/core/behavior-keyboard-pager.js' => 'a8da01f0',
|
2014-01-01 16:46:25 +01:00
|
|
|
'rsrc/js/core/behavior-keyboard-shortcuts.js' => 'd75709e6',
|
|
|
|
'rsrc/js/core/behavior-konami.js' => '5bc2cb21',
|
2014-12-23 18:28:57 +01:00
|
|
|
'rsrc/js/core/behavior-lightbox-attachments.js' => 'f8ba29d7',
|
2014-12-30 11:50:26 +01:00
|
|
|
'rsrc/js/core/behavior-line-linker.js' => '1499a8cb',
|
2014-06-23 19:27:47 +02:00
|
|
|
'rsrc/js/core/behavior-more.js' => 'a80d0378',
|
2014-11-03 17:20:15 +01:00
|
|
|
'rsrc/js/core/behavior-object-selector.js' => '49b73b36',
|
2014-06-23 19:35:39 +02:00
|
|
|
'rsrc/js/core/behavior-oncopy.js' => '2926fff2',
|
2014-06-23 19:27:47 +02:00
|
|
|
'rsrc/js/core/behavior-phabricator-nav.js' => '14d7a8b8',
|
2014-07-01 20:04:05 +02:00
|
|
|
'rsrc/js/core/behavior-phabricator-remarkup-assist.js' => 'e32d14ab',
|
Provide a global router for Ajax requests
Summary:
Fixes T430. Fixes T4834. Obsoletes D7641. Currently, we do some things less-well than we could:
- We just let the browser queue and prioritize requests, so if you load a revision with 50 changes and then click "Award Token", the action blocks until the changes load in most/all browsers. It would be better to prioritize this action and queue it immediately.
- Similarly, changes tend to load in order, even if the user has clicked to a specific file. When the user expresses a preference for a specific file, we should prioritize it.
- We show a spinning GIF when waiting on requests. This is appropriate for some types of reuqests, but distracting for others.
To fix this:
- Queue all (or, at least, most) requests into a new queue in JX.Router.
- JX.Router handles prioritizing the requests. Principally:
- You can submit a request with a specific priority (500 = general content loading, 1000 = default, 2000 = explicit user action) and JX.Router will get the higher stuff fired off sooner.
- You can name requests and then adjust their prorities later, if the user expresses an interest in specific results.
- Only use the spinner gif for "workflow" requests, which is bascially when the user clicked something and we're waiting on the server. I think it's useful and not-annoying in this case.
- Don't show any status for draft requests.
- For content requests, show a subtle hipster-style top loading bar.
Test Plan:
- Viewed a diff with 93 changes, and clicked award token.
- Prior to this patch, the action took many many seconds to resolve.
- After this patch, it resolves quickly.
- Viewed a diff with 93 changes and saw a pleasant subtle hipster-style loading bar.
- Viewed a diff with 93 changes and typed some draft text. Previews populated fairly quickly and there was no spinner.
- Viewed a diff with 93 changes and clicked something with workflow, saw a spinner after a moment.
- Viewed a diff with 93 changes and clicked a file in the table of contents near the end of the list.
- Prior to this patch, it took a long time to show up.
- After this patch, it loads directly.
Reviewers: chad, btrahan
Reviewed By: btrahan
Subscribers: epriestley
Maniphest Tasks: T430, T4834
Differential Revision: https://secure.phabricator.com/D8979
2014-05-05 19:57:42 +02:00
|
|
|
'rsrc/js/core/behavior-refresh-csrf.js' => '7814b593',
|
2014-01-01 16:46:25 +01:00
|
|
|
'rsrc/js/core/behavior-remarkup-preview.js' => 'f7379f45',
|
2014-06-23 19:27:47 +02:00
|
|
|
'rsrc/js/core/behavior-reorder-applications.js' => '76b9fc3e',
|
|
|
|
'rsrc/js/core/behavior-reveal-content.js' => '60821bc7',
|
2015-01-25 17:46:22 +01:00
|
|
|
'rsrc/js/core/behavior-scrollbar.js' => '834a1173',
|
2014-11-18 00:32:37 +01:00
|
|
|
'rsrc/js/core/behavior-search-typeahead.js' => '724b1247',
|
2014-06-23 19:27:47 +02:00
|
|
|
'rsrc/js/core/behavior-select-on-click.js' => '4e3e79a6',
|
Introduce CAN_EDIT for ExternalAccount, and make CAN_VIEW more liberal
Summary:
Fixes T3732. Ref T1205. Ref T3116.
External accounts (like emails used as identities, Facebook accounts, LDAP accounts, etc.) are stored in "ExternalAccount" objects.
Currently, we have a very restrictive `CAN_VIEW` policy for ExternalAccounts, to add an extra layer of protection to make sure users can't use them in unintended ways. For example, it would be bad if a user could link their Phabricator account to a Facebook account without proper authentication. All of the controllers which do sensitive things have checks anyway, but a restrictive CAN_VIEW provided an extra layer of protection. Se T3116 for some discussion.
However, this means that when grey/external users take actions (via email, or via applications like Legalpad) other users can't load the account handles and can't see anything about the actor (they just see "Restricted External Account" or similar).
Balancing these concerns is mostly about not making a huge mess while doing it. This seems like a reasonable approach:
- Add `CAN_EDIT` on these objects.
- Make that very restricted, but open up `CAN_VIEW`.
- Require `CAN_EDIT` any time we're going to do something authentication/identity related.
This is slightly easier to get wrong (forget CAN_EDIT) than other approaches, but pretty simple, and we always have extra checks in place anyway -- this is just a safety net.
I'm not quite sure how we should identify external accounts, so for now we're just rendering "Email User" or similar -- clearly not a bug, but not identifying. We can figure out what to render in the long term elsewhere.
Test Plan:
- Viewed external accounts.
- Linked an external account.
- Refreshed an external account.
- Edited profile picture.
- Viewed sessions panel.
- Published a bunch of stuff to Asana/JIRA.
- Legalpad signature page now shows external accounts.
{F171595}
Reviewers: chad, btrahan
Reviewed By: btrahan
Subscribers: epriestley
Maniphest Tasks: T3732, T1205, T3116
Differential Revision: https://secure.phabricator.com/D9767
2014-07-10 19:18:10 +02:00
|
|
|
'rsrc/js/core/behavior-toggle-class.js' => 'e566f52c',
|
2014-01-01 16:46:25 +01:00
|
|
|
'rsrc/js/core/behavior-tokenizer.js' => 'b3a4b884',
|
2014-06-26 18:41:07 +02:00
|
|
|
'rsrc/js/core/behavior-tooltip.js' => '3ee3408b',
|
2015-01-28 17:26:10 +01:00
|
|
|
'rsrc/js/core/behavior-watch-anchor.js' => '9f36c42d',
|
Provide a global router for Ajax requests
Summary:
Fixes T430. Fixes T4834. Obsoletes D7641. Currently, we do some things less-well than we could:
- We just let the browser queue and prioritize requests, so if you load a revision with 50 changes and then click "Award Token", the action blocks until the changes load in most/all browsers. It would be better to prioritize this action and queue it immediately.
- Similarly, changes tend to load in order, even if the user has clicked to a specific file. When the user expresses a preference for a specific file, we should prioritize it.
- We show a spinning GIF when waiting on requests. This is appropriate for some types of reuqests, but distracting for others.
To fix this:
- Queue all (or, at least, most) requests into a new queue in JX.Router.
- JX.Router handles prioritizing the requests. Principally:
- You can submit a request with a specific priority (500 = general content loading, 1000 = default, 2000 = explicit user action) and JX.Router will get the higher stuff fired off sooner.
- You can name requests and then adjust their prorities later, if the user expresses an interest in specific results.
- Only use the spinner gif for "workflow" requests, which is bascially when the user clicked something and we're waiting on the server. I think it's useful and not-annoying in this case.
- Don't show any status for draft requests.
- For content requests, show a subtle hipster-style top loading bar.
Test Plan:
- Viewed a diff with 93 changes, and clicked award token.
- Prior to this patch, the action took many many seconds to resolve.
- After this patch, it resolves quickly.
- Viewed a diff with 93 changes and saw a pleasant subtle hipster-style loading bar.
- Viewed a diff with 93 changes and typed some draft text. Previews populated fairly quickly and there was no spinner.
- Viewed a diff with 93 changes and clicked something with workflow, saw a spinner after a moment.
- Viewed a diff with 93 changes and clicked a file in the table of contents near the end of the list.
- Prior to this patch, it took a long time to show up.
- After this patch, it loads directly.
Reviewers: chad, btrahan
Reviewed By: btrahan
Subscribers: epriestley
Maniphest Tasks: T430, T4834
Differential Revision: https://secure.phabricator.com/D8979
2014-05-05 19:57:42 +02:00
|
|
|
'rsrc/js/core/behavior-workflow.js' => '0a3f3021',
|
2014-01-01 16:46:25 +01:00
|
|
|
'rsrc/js/core/phtize.js' => 'd254d646',
|
2014-08-01 21:29:48 +02:00
|
|
|
'rsrc/js/phui/behavior-phui-object-box-tabs.js' => '2bfa2836',
|
2014-05-05 19:57:23 +02:00
|
|
|
'rsrc/js/phui/behavior-phui-timeline-dropdown-menu.js' => '4d94d9c3',
|
|
|
|
'rsrc/js/phuix/PHUIXActionListView.js' => 'b5c256b8',
|
2014-05-19 01:10:54 +02:00
|
|
|
'rsrc/js/phuix/PHUIXActionView.js' => '6e8cefa4',
|
2014-05-05 19:57:23 +02:00
|
|
|
'rsrc/js/phuix/PHUIXDropdownMenu.js' => 'bd4c8dca',
|
2014-01-01 03:04:25 +01:00
|
|
|
),
|
2014-07-14 17:33:33 +02:00
|
|
|
'symbols' => array(
|
2014-12-17 20:10:50 +01:00
|
|
|
'almanac-css' => 'dbb9b3af',
|
2014-01-01 16:46:25 +01:00
|
|
|
'aphront-bars' => '231ac33c',
|
2014-01-06 06:47:21 +01:00
|
|
|
'aphront-dark-console-css' => '6378ef3d',
|
2015-02-19 17:45:37 +01:00
|
|
|
'aphront-dialog-view-css' => 'd2e76b88',
|
2014-05-02 23:25:05 +02:00
|
|
|
'aphront-list-filter-view-css' => '2ae43867',
|
2015-01-12 19:04:01 +01:00
|
|
|
'aphront-multi-column-view-css' => '41a848c0',
|
2014-01-01 16:46:25 +01:00
|
|
|
'aphront-pager-view-css' => '2e3539af',
|
2015-02-21 01:00:39 +01:00
|
|
|
'aphront-panel-view-css' => '7e0c3a56',
|
2014-06-13 20:36:01 +02:00
|
|
|
'aphront-table-view-css' => 'b22b7216',
|
2014-05-29 05:56:20 +02:00
|
|
|
'aphront-tokenizer-control-css' => '82ce2142',
|
2014-11-24 20:57:29 +01:00
|
|
|
'aphront-tooltip-css' => '4099b97e',
|
2014-01-01 16:46:25 +01:00
|
|
|
'aphront-two-column-view-css' => '16ab3ad2',
|
2014-12-30 11:48:53 +01:00
|
|
|
'aphront-typeahead-control-css' => '0e403212',
|
2014-01-01 16:46:25 +01:00
|
|
|
'auth-css' => '1e655982',
|
Make "Show Context" persist rendering, whitespace, encoding, etc
Summary:
Ref T2009. Currently, we do not persist view parameters when making context rendering requests.
The big one is the renderer (1up vs 2up). This makes context on unified diffs come in with too many columns.
However, it impacts other parameters too. For example, at HEAD, if you change highlighting to "rainbow" and then load more context, the context uses the original highlighter instead of the rainbow highlighter.
This moves context loads into ChangesetViewManager, which maintains view parameters and can provide them correctly.
- This removes "ref"; it is no longer required, as the ChangesetViewManager tracks it.
- This removes URI management from `behavior-show-more`; it is no longer required, since the ChangesetViewManager knows how to render.
- This removes "whitespace" since this is handled properly by the view manager.
Test Plan:
- Used "Show Top" / "Show All" / "Show Bottom" in 1-up and 2-up views.
- Changed file highlighting to rainbow, loaded stuff, saw rainbow stick.
- Used "Show Entire File" in 1-up and 2-up views.
- Saw loading chrome.
- No loading chrome normally.
- Made inlines, verified `copyRows()` code runs.
- Poked around Diffusion -- it is missing some parameter handling, but works OK.
Reviewers: btrahan
Reviewed By: btrahan
Subscribers: epriestley
Maniphest Tasks: T2009
Differential Revision: https://secure.phabricator.com/D11977
2015-03-05 23:03:00 +01:00
|
|
|
'changeset-view-manager' => 'fce415a0',
|
2014-01-01 16:46:25 +01:00
|
|
|
'config-options-css' => '7fedf08b',
|
2015-03-03 00:42:25 +01:00
|
|
|
'config-welcome-css' => '6abd79be',
|
Conpherence - make the durable column kind of work and stuff
Summary:
Ref T7014. This hooks up the durable column such that when you open it up it loads your most recent Conpherence. You can then switch amongst the various widgets and stuff and everything works nicely.
Except...
- scroll bar does not work
- also doesn't work at HEAD when I add a ton of text to the UI with no changes? (wrapped $copy in array_fill(0, 1000, $copy))
- "widget selector" does not collapse when you select something else
- this part wasn't really specified so I used the aphlict dropdown stuff. didn't want to keep working on that if this was the wrong UI choice
- can not edit title
- do we still want that to be done by clicking on the title, which pops a dialogue?
- can not add participants or calendar events
- what should this UI be? maybe just a button on the top for "participants" and a button on the bottom for calendar? both on top?
- this is not pixel perfect to the mock or two I've seen around. Aside from generally being bad at that, I definitely didn't get the name + timestamps formatting correctly, because the standard DOM of that has timestamp FIRST which appears second due to a "float right". Seemed like a lot of special-casing for what might not even be that important in the UI so I punted. (And again, there's likely many unknown ways in which this isn't pixel perfect)
There's also code quality issues
- `ConpherenceWidgetConfigConstants` is hopefully temporary or at least gets more sleek as we keep progressing here
- copied some CSS from main Conpherence app
- DOM structure is pretty different
- there's some minor CSS tweaks too given the different width (not to mention the DOM structure being different)
- copied some JS from behavior-pontificate.js to sync threads relative to aphlict updates
- JS in general is like a better version of existing JS; these should collapse I'd hope?
- maybe the aphlict-behavior-dropdown change was badsauce?
...but all that said, this definitely feels really nice and I feel like adding stuff is going to be really easy compared to how normal Conpherence is.
Also includes a bonus bug fix - we now correctly update participation. The user would encounter this issue if they were in a conpherence that got some updates and then they went to a different page; they would have unread status for the messages that were ajax'd in. This patch fixes that by making sure we mark participation up to date with the proper transaction in all cases.
Test Plan: hit "\" to invoke the column and saw nice loading UI and my latest conpherence load. sent messages and verified they received A-OK by looking in DOM console. toggled various widges and verified they rendered correctly. opened up a second browser with a second user on the thread, sent a message, and it was received in a nice asynchronous fashion
Reviewers: chad, epriestley
Reviewed By: epriestley
Subscribers: Korvin, epriestley
Maniphest Tasks: T7014
Differential Revision: https://secure.phabricator.com/D11968
2015-03-05 19:33:39 +01:00
|
|
|
'conpherence-durable-column-view' => '3b836442',
|
2015-01-29 23:27:44 +01:00
|
|
|
'conpherence-menu-css' => '73774137',
|
2015-01-30 23:29:24 +01:00
|
|
|
'conpherence-message-pane-css' => '17a9517f',
|
2014-05-28 00:26:16 +02:00
|
|
|
'conpherence-notification-css' => '04a6e10a',
|
2014-01-01 16:46:25 +01:00
|
|
|
'conpherence-update-css' => '1099a660',
|
2014-12-30 11:48:53 +01:00
|
|
|
'conpherence-widget-pane-css' => '3d575438',
|
2015-03-05 23:11:36 +01:00
|
|
|
'differential-changeset-view-css' => 'bad09138',
|
2014-02-27 20:06:55 +01:00
|
|
|
'differential-core-view-css' => '7ac3cabc',
|
2015-03-05 23:11:51 +01:00
|
|
|
'differential-inline-comment-editor' => '41060c54',
|
2014-09-30 18:47:54 +02:00
|
|
|
'differential-results-table-css' => '181aa9d9',
|
2014-01-01 16:46:25 +01:00
|
|
|
'differential-revision-add-comment-css' => 'c478bcaa',
|
|
|
|
'differential-revision-comment-css' => '48186045',
|
2014-03-12 21:53:04 +01:00
|
|
|
'differential-revision-history-css' => '0e8eb855',
|
2014-01-01 16:46:25 +01:00
|
|
|
'differential-revision-list-css' => 'f3c47d33',
|
2014-10-15 19:33:26 +02:00
|
|
|
'differential-table-of-contents-css' => '63f3ef4a',
|
2014-06-13 20:36:01 +02:00
|
|
|
'diffusion-icons-css' => '9c5828da',
|
2014-01-01 16:46:25 +01:00
|
|
|
'diffusion-source-css' => '66fdf661',
|
2014-03-06 20:28:24 +01:00
|
|
|
'diviner-shared-css' => '38813222',
|
2015-02-09 17:12:47 +01:00
|
|
|
'font-fontawesome' => 'ae9a7b4d',
|
|
|
|
'font-source-sans-pro' => '0d859f60',
|
2014-01-01 16:46:25 +01:00
|
|
|
'global-drag-and-drop-css' => '697324ad',
|
2014-08-06 02:28:13 +02:00
|
|
|
'harbormaster-css' => '49d64eb4',
|
2014-11-17 23:06:05 +01:00
|
|
|
'herald-css' => '826075fa',
|
2015-01-29 23:15:38 +01:00
|
|
|
'herald-rule-editor' => '6e2de6f2',
|
2014-04-27 20:18:48 +02:00
|
|
|
'herald-test-css' => '778b008e',
|
2015-01-28 17:45:23 +01:00
|
|
|
'homepage-panel-css' => 'e34bf140',
|
2015-02-09 17:38:51 +01:00
|
|
|
'inline-comment-summary-css' => 'eb5f8e8c',
|
Multiplex AJAX calls
Summary: Fixes T5344. Essentially, we only make the AJAX request to `/notification/individual/` if we are the leader tab (i.e. only one tab will make this request). Once a response has been received from the server (containing the contents of the notification), we broadcast the message contents back to all other tabs for rendering.
Test Plan:
Opened two tabs on `/notification/status/` and clicked "Send Test Notification".
**Before**
```lang=bash, name=tail -f /var/log/phabricator-access.log | grep /notification/individual/
[Tue, 13 Jan 2015 20:10:37 +1100] 17033 phabricator 10.0.0.1 josh PhabricatorNotificationIndividualController - /notification/individual/-200 236036
[Tue, 13 Jan 2015 20:10:37 +1100] 17657 phabricator 10.0.0.1 josh PhabricatorNotificationIndividualController - /notification/individual/-200 24130
```
**After**
```lang=bash, name=tail -f /var/log/phabricator-access.log | grep /notification/individual/
[Tue, 13 Jan 2015 20:11:15 +1100] 17657 phabricator 10.0.0.1 josh PhabricatorNotificationIndividualController - /notification/individual/-200 180217
```
Reviewers: #blessed_reviewers, epriestley
Reviewed By: #blessed_reviewers, epriestley
Subscribers: Korvin, epriestley
Maniphest Tasks: T5344
Differential Revision: https://secure.phabricator.com/D11360
2015-01-15 21:05:31 +01:00
|
|
|
'javelin-aphlict' => '2be71d56',
|
Introduce CAN_EDIT for ExternalAccount, and make CAN_VIEW more liberal
Summary:
Fixes T3732. Ref T1205. Ref T3116.
External accounts (like emails used as identities, Facebook accounts, LDAP accounts, etc.) are stored in "ExternalAccount" objects.
Currently, we have a very restrictive `CAN_VIEW` policy for ExternalAccounts, to add an extra layer of protection to make sure users can't use them in unintended ways. For example, it would be bad if a user could link their Phabricator account to a Facebook account without proper authentication. All of the controllers which do sensitive things have checks anyway, but a restrictive CAN_VIEW provided an extra layer of protection. Se T3116 for some discussion.
However, this means that when grey/external users take actions (via email, or via applications like Legalpad) other users can't load the account handles and can't see anything about the actor (they just see "Restricted External Account" or similar).
Balancing these concerns is mostly about not making a huge mess while doing it. This seems like a reasonable approach:
- Add `CAN_EDIT` on these objects.
- Make that very restricted, but open up `CAN_VIEW`.
- Require `CAN_EDIT` any time we're going to do something authentication/identity related.
This is slightly easier to get wrong (forget CAN_EDIT) than other approaches, but pretty simple, and we always have extra checks in place anyway -- this is just a safety net.
I'm not quite sure how we should identify external accounts, so for now we're just rendering "Email User" or similar -- clearly not a bug, but not identifying. We can figure out what to render in the long term elsewhere.
Test Plan:
- Viewed external accounts.
- Linked an external account.
- Refreshed an external account.
- Edited profile picture.
- Viewed sessions panel.
- Published a bunch of stuff to Asana/JIRA.
- Legalpad signature page now shows external accounts.
{F171595}
Reviewers: chad, btrahan
Reviewed By: btrahan
Subscribers: epriestley
Maniphest Tasks: T3732, T1205, T3116
Differential Revision: https://secure.phabricator.com/D9767
2014-07-10 19:18:10 +02:00
|
|
|
'javelin-behavior' => '61cbc29a',
|
Conpherence - make the durable column kind of work and stuff
Summary:
Ref T7014. This hooks up the durable column such that when you open it up it loads your most recent Conpherence. You can then switch amongst the various widgets and stuff and everything works nicely.
Except...
- scroll bar does not work
- also doesn't work at HEAD when I add a ton of text to the UI with no changes? (wrapped $copy in array_fill(0, 1000, $copy))
- "widget selector" does not collapse when you select something else
- this part wasn't really specified so I used the aphlict dropdown stuff. didn't want to keep working on that if this was the wrong UI choice
- can not edit title
- do we still want that to be done by clicking on the title, which pops a dialogue?
- can not add participants or calendar events
- what should this UI be? maybe just a button on the top for "participants" and a button on the bottom for calendar? both on top?
- this is not pixel perfect to the mock or two I've seen around. Aside from generally being bad at that, I definitely didn't get the name + timestamps formatting correctly, because the standard DOM of that has timestamp FIRST which appears second due to a "float right". Seemed like a lot of special-casing for what might not even be that important in the UI so I punted. (And again, there's likely many unknown ways in which this isn't pixel perfect)
There's also code quality issues
- `ConpherenceWidgetConfigConstants` is hopefully temporary or at least gets more sleek as we keep progressing here
- copied some CSS from main Conpherence app
- DOM structure is pretty different
- there's some minor CSS tweaks too given the different width (not to mention the DOM structure being different)
- copied some JS from behavior-pontificate.js to sync threads relative to aphlict updates
- JS in general is like a better version of existing JS; these should collapse I'd hope?
- maybe the aphlict-behavior-dropdown change was badsauce?
...but all that said, this definitely feels really nice and I feel like adding stuff is going to be really easy compared to how normal Conpherence is.
Also includes a bonus bug fix - we now correctly update participation. The user would encounter this issue if they were in a conpherence that got some updates and then they went to a different page; they would have unread status for the messages that were ajax'd in. This patch fixes that by making sure we mark participation up to date with the proper transaction in all cases.
Test Plan: hit "\" to invoke the column and saw nice loading UI and my latest conpherence load. sent messages and verified they received A-OK by looking in DOM console. toggled various widges and verified they rendered correctly. opened up a second browser with a second user on the thread, sent a message, and it was received in a nice asynchronous fashion
Reviewers: chad, epriestley
Reviewed By: epriestley
Subscribers: Korvin, epriestley
Maniphest Tasks: T7014
Differential Revision: https://secure.phabricator.com/D11968
2015-03-05 19:33:39 +01:00
|
|
|
'javelin-behavior-aphlict-dropdown' => 'cc2d9c80',
|
Multiplex AJAX calls
Summary: Fixes T5344. Essentially, we only make the AJAX request to `/notification/individual/` if we are the leader tab (i.e. only one tab will make this request). Once a response has been received from the server (containing the contents of the notification), we broadcast the message contents back to all other tabs for rendering.
Test Plan:
Opened two tabs on `/notification/status/` and clicked "Send Test Notification".
**Before**
```lang=bash, name=tail -f /var/log/phabricator-access.log | grep /notification/individual/
[Tue, 13 Jan 2015 20:10:37 +1100] 17033 phabricator 10.0.0.1 josh PhabricatorNotificationIndividualController - /notification/individual/-200 236036
[Tue, 13 Jan 2015 20:10:37 +1100] 17657 phabricator 10.0.0.1 josh PhabricatorNotificationIndividualController - /notification/individual/-200 24130
```
**After**
```lang=bash, name=tail -f /var/log/phabricator-access.log | grep /notification/individual/
[Tue, 13 Jan 2015 20:11:15 +1100] 17657 phabricator 10.0.0.1 josh PhabricatorNotificationIndividualController - /notification/individual/-200 180217
```
Reviewers: #blessed_reviewers, epriestley
Reviewed By: #blessed_reviewers, epriestley
Subscribers: Korvin, epriestley
Maniphest Tasks: T5344
Differential Revision: https://secure.phabricator.com/D11360
2015-01-15 21:05:31 +01:00
|
|
|
'javelin-behavior-aphlict-listen' => '851f167c',
|
2015-01-14 22:08:08 +01:00
|
|
|
'javelin-behavior-aphlict-status' => 'ea681761',
|
2014-01-01 16:46:25 +01:00
|
|
|
'javelin-behavior-aphront-basic-tokenizer' => 'b3a4b884',
|
2014-06-23 19:27:47 +02:00
|
|
|
'javelin-behavior-aphront-crop' => 'fa0f4fc2',
|
2014-06-23 19:35:39 +02:00
|
|
|
'javelin-behavior-aphront-drag-and-drop-textarea' => '92eb531d',
|
2014-08-02 23:44:35 +02:00
|
|
|
'javelin-behavior-aphront-form-disable-on-submit' => '5c54cbf3',
|
2014-06-23 19:27:47 +02:00
|
|
|
'javelin-behavior-aphront-more' => 'a80d0378',
|
2014-01-01 16:46:25 +01:00
|
|
|
'javelin-behavior-audio-source' => '59b251eb',
|
2014-06-23 19:27:47 +02:00
|
|
|
'javelin-behavior-audit-preview' => 'd835b03a',
|
2014-12-30 11:53:27 +01:00
|
|
|
'javelin-behavior-balanced-payment-form' => 'b2c03e60',
|
2014-06-25 21:30:53 +02:00
|
|
|
'javelin-behavior-boards-dropdown' => '0ec56e1d',
|
2014-06-26 18:41:07 +02:00
|
|
|
'javelin-behavior-choose-control' => '6153c708',
|
2014-06-23 19:27:47 +02:00
|
|
|
'javelin-behavior-config-reorder-fields' => '14a827de',
|
2015-02-26 19:27:28 +01:00
|
|
|
'javelin-behavior-conpherence-menu' => '869e3445',
|
2015-02-26 00:14:27 +01:00
|
|
|
'javelin-behavior-conpherence-pontificate' => '86df5915',
|
2014-05-05 19:57:23 +02:00
|
|
|
'javelin-behavior-conpherence-widget-pane' => '40b1ff90',
|
2014-12-30 11:53:27 +01:00
|
|
|
'javelin-behavior-countdown-timer' => 'e4cc26b3',
|
2015-01-03 00:30:00 +01:00
|
|
|
'javelin-behavior-dark-console' => '08883e8b',
|
2014-05-19 23:04:26 +02:00
|
|
|
'javelin-behavior-dashboard-async-panel' => '469c0d9e',
|
2014-06-23 19:27:47 +02:00
|
|
|
'javelin-behavior-dashboard-move-panels' => '82439934',
|
2014-07-13 18:18:50 +02:00
|
|
|
'javelin-behavior-dashboard-query-panel-select' => '453c5375',
|
2014-06-23 19:27:47 +02:00
|
|
|
'javelin-behavior-dashboard-tab-panel' => 'd4eecc63',
|
2014-01-01 16:46:25 +01:00
|
|
|
'javelin-behavior-device' => '03d6ed07',
|
2014-06-23 19:27:47 +02:00
|
|
|
'javelin-behavior-differential-add-reviewers-and-ccs' => 'e10f8e18',
|
2014-07-01 20:04:05 +02:00
|
|
|
'javelin-behavior-differential-comment-jump' => '4fdb476d',
|
2014-01-01 16:46:25 +01:00
|
|
|
'javelin-behavior-differential-diff-radios' => 'e1ff79b1',
|
Make "Show Context" persist rendering, whitespace, encoding, etc
Summary:
Ref T2009. Currently, we do not persist view parameters when making context rendering requests.
The big one is the renderer (1up vs 2up). This makes context on unified diffs come in with too many columns.
However, it impacts other parameters too. For example, at HEAD, if you change highlighting to "rainbow" and then load more context, the context uses the original highlighter instead of the rainbow highlighter.
This moves context loads into ChangesetViewManager, which maintains view parameters and can provide them correctly.
- This removes "ref"; it is no longer required, as the ChangesetViewManager tracks it.
- This removes URI management from `behavior-show-more`; it is no longer required, since the ChangesetViewManager knows how to render.
- This removes "whitespace" since this is handled properly by the view manager.
Test Plan:
- Used "Show Top" / "Show All" / "Show Bottom" in 1-up and 2-up views.
- Changed file highlighting to rainbow, loaded stuff, saw rainbow stick.
- Used "Show Entire File" in 1-up and 2-up views.
- Saw loading chrome.
- No loading chrome normally.
- Made inlines, verified `copyRows()` code runs.
- Poked around Diffusion -- it is missing some parameter handling, but works OK.
Reviewers: btrahan
Reviewed By: btrahan
Subscribers: epriestley
Maniphest Tasks: T2009
Differential Revision: https://secure.phabricator.com/D11977
2015-03-05 23:03:00 +01:00
|
|
|
'javelin-behavior-differential-dropdown-menus' => '2035b9cb',
|
2015-03-05 23:11:51 +01:00
|
|
|
'javelin-behavior-differential-edit-inline-comments' => 'ae8e9b44',
|
2014-08-28 22:08:32 +02:00
|
|
|
'javelin-behavior-differential-feedback-preview' => '6932def3',
|
2014-11-12 21:26:22 +01:00
|
|
|
'javelin-behavior-differential-keyboard-navigation' => '2c426492',
|
2015-03-05 23:03:15 +01:00
|
|
|
'javelin-behavior-differential-populate' => '8694b1df',
|
2014-06-23 19:27:47 +02:00
|
|
|
'javelin-behavior-differential-show-field-details' => 'bba9eedf',
|
2014-01-01 16:46:25 +01:00
|
|
|
'javelin-behavior-differential-toggle-files' => 'ca3f91eb',
|
|
|
|
'javelin-behavior-differential-user-select' => 'a8d8459d',
|
2014-02-27 20:06:55 +01:00
|
|
|
'javelin-behavior-diffusion-commit-branches' => 'bdaf4d04',
|
|
|
|
'javelin-behavior-diffusion-commit-graph' => 'f7f1289f',
|
2015-01-29 19:20:35 +01:00
|
|
|
'javelin-behavior-diffusion-jump-to' => '73d09eef',
|
2014-05-13 23:09:00 +02:00
|
|
|
'javelin-behavior-diffusion-locate-file' => '6d3e1947',
|
2014-05-12 20:53:31 +02:00
|
|
|
'javelin-behavior-diffusion-pull-lastmodified' => '2b228192',
|
2014-02-27 20:06:55 +01:00
|
|
|
'javelin-behavior-doorkeeper-tag' => 'e5822781',
|
2015-03-05 19:43:26 +01:00
|
|
|
'javelin-behavior-durable-column' => 'a88a26cc',
|
2014-12-30 11:51:31 +01:00
|
|
|
'javelin-behavior-error-log' => '6882e80a',
|
2014-08-16 23:55:22 +02:00
|
|
|
'javelin-behavior-fancy-datepicker' => 'c51ae228',
|
Give files uploaded to objects a very restrictive view policy
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
2014-08-02 23:46:13 +02:00
|
|
|
'javelin-behavior-global-drag-and-drop' => '07f199d8',
|
2014-01-01 16:46:25 +01:00
|
|
|
'javelin-behavior-herald-rule-editor' => '7ebaeed3',
|
2014-04-28 02:31:35 +02:00
|
|
|
'javelin-behavior-high-security-warning' => '8fc1c918',
|
2014-01-01 16:46:25 +01:00
|
|
|
'javelin-behavior-history-install' => '7ee2b591',
|
2014-02-27 20:06:55 +01:00
|
|
|
'javelin-behavior-icon-composer' => '8ef9ab58',
|
2014-01-01 16:46:25 +01:00
|
|
|
'javelin-behavior-konami' => '5bc2cb21',
|
2014-02-27 20:06:55 +01:00
|
|
|
'javelin-behavior-launch-icon-composer' => '48086888',
|
2014-12-23 18:28:57 +01:00
|
|
|
'javelin-behavior-lightbox-attachments' => 'f8ba29d7',
|
2015-02-24 18:41:37 +01:00
|
|
|
'javelin-behavior-line-chart' => '88f0c5b3',
|
2014-01-01 16:46:25 +01:00
|
|
|
'javelin-behavior-load-blame' => '42126667',
|
2014-12-30 11:53:27 +01:00
|
|
|
'javelin-behavior-maniphest-batch-editor' => 'f24f3253',
|
2014-06-23 19:27:47 +02:00
|
|
|
'javelin-behavior-maniphest-batch-selector' => '7b98d7c5',
|
|
|
|
'javelin-behavior-maniphest-list-editor' => 'a9f88de2',
|
2014-01-01 16:46:25 +01:00
|
|
|
'javelin-behavior-maniphest-subpriority-editor' => '84845b5b',
|
2014-06-23 19:27:47 +02:00
|
|
|
'javelin-behavior-maniphest-transaction-controls' => '44168bad',
|
|
|
|
'javelin-behavior-maniphest-transaction-expand' => '5fefb143',
|
2014-01-01 16:46:25 +01:00
|
|
|
'javelin-behavior-maniphest-transaction-preview' => 'f8248bc5',
|
|
|
|
'javelin-behavior-owners-path-editor' => '7a68dda3',
|
2015-03-02 22:01:00 +01:00
|
|
|
'javelin-behavior-passphrase-credential-control' => '3cb0b2fc',
|
2014-01-01 16:46:25 +01:00
|
|
|
'javelin-behavior-persona-login' => '9414ff18',
|
2014-06-23 19:27:47 +02:00
|
|
|
'javelin-behavior-phabricator-active-nav' => 'e379b58e',
|
2014-01-01 16:46:25 +01:00
|
|
|
'javelin-behavior-phabricator-autofocus' => '7319e029',
|
2014-06-23 19:27:47 +02:00
|
|
|
'javelin-behavior-phabricator-busy-example' => '60479091',
|
|
|
|
'javelin-behavior-phabricator-file-tree' => '88236f00',
|
|
|
|
'javelin-behavior-phabricator-gesture' => '3ab51e2c',
|
|
|
|
'javelin-behavior-phabricator-gesture-example' => '558829c2',
|
|
|
|
'javelin-behavior-phabricator-hovercards' => 'f36e01af',
|
|
|
|
'javelin-behavior-phabricator-keyboard-pager' => 'a8da01f0',
|
2014-01-01 16:46:25 +01:00
|
|
|
'javelin-behavior-phabricator-keyboard-shortcuts' => 'd75709e6',
|
2014-12-30 11:50:26 +01:00
|
|
|
'javelin-behavior-phabricator-line-linker' => '1499a8cb',
|
2014-06-23 19:27:47 +02:00
|
|
|
'javelin-behavior-phabricator-nav' => '14d7a8b8',
|
2014-12-30 11:54:21 +01:00
|
|
|
'javelin-behavior-phabricator-notification-example' => '8ce821c5',
|
2014-11-03 17:20:15 +01:00
|
|
|
'javelin-behavior-phabricator-object-selector' => '49b73b36',
|
2014-06-23 19:35:39 +02:00
|
|
|
'javelin-behavior-phabricator-oncopy' => '2926fff2',
|
2014-07-01 20:04:05 +02:00
|
|
|
'javelin-behavior-phabricator-remarkup-assist' => 'e32d14ab',
|
2014-06-23 19:27:47 +02:00
|
|
|
'javelin-behavior-phabricator-reveal-content' => '60821bc7',
|
2014-11-18 00:32:37 +01:00
|
|
|
'javelin-behavior-phabricator-search-typeahead' => '724b1247',
|
2015-01-28 17:26:10 +01:00
|
|
|
'javelin-behavior-phabricator-show-older-transactions' => 'dbbf48b6',
|
2014-06-26 18:41:07 +02:00
|
|
|
'javelin-behavior-phabricator-tooltips' => '3ee3408b',
|
2014-06-21 21:50:40 +02:00
|
|
|
'javelin-behavior-phabricator-transaction-comment-form' => '9f7309fb',
|
2014-08-08 00:21:32 +02:00
|
|
|
'javelin-behavior-phabricator-transaction-list' => '13c739ea',
|
2015-01-28 17:26:10 +01:00
|
|
|
'javelin-behavior-phabricator-watch-anchor' => '9f36c42d',
|
2014-06-23 19:27:47 +02:00
|
|
|
'javelin-behavior-phame-post-preview' => 'be807912',
|
|
|
|
'javelin-behavior-pholio-mock-edit' => '9c2623f4',
|
2014-12-30 11:56:42 +01:00
|
|
|
'javelin-behavior-pholio-mock-view' => 'e58bf807',
|
2014-08-01 21:29:48 +02:00
|
|
|
'javelin-behavior-phui-object-box-tabs' => '2bfa2836',
|
2014-05-05 19:57:23 +02:00
|
|
|
'javelin-behavior-phui-timeline-dropdown-menu' => '4d94d9c3',
|
2014-05-29 05:56:20 +02:00
|
|
|
'javelin-behavior-policy-control' => 'f3fef818',
|
2014-07-18 00:56:20 +02:00
|
|
|
'javelin-behavior-policy-rule-editor' => 'fe9a552f',
|
2014-06-23 19:27:47 +02:00
|
|
|
'javelin-behavior-ponder-votebox' => '4e9b766b',
|
2015-01-07 02:50:40 +01:00
|
|
|
'javelin-behavior-project-boards' => '87cb6b51',
|
2014-01-01 16:46:25 +01:00
|
|
|
'javelin-behavior-project-create' => '065227cc',
|
Provide a global router for Ajax requests
Summary:
Fixes T430. Fixes T4834. Obsoletes D7641. Currently, we do some things less-well than we could:
- We just let the browser queue and prioritize requests, so if you load a revision with 50 changes and then click "Award Token", the action blocks until the changes load in most/all browsers. It would be better to prioritize this action and queue it immediately.
- Similarly, changes tend to load in order, even if the user has clicked to a specific file. When the user expresses a preference for a specific file, we should prioritize it.
- We show a spinning GIF when waiting on requests. This is appropriate for some types of reuqests, but distracting for others.
To fix this:
- Queue all (or, at least, most) requests into a new queue in JX.Router.
- JX.Router handles prioritizing the requests. Principally:
- You can submit a request with a specific priority (500 = general content loading, 1000 = default, 2000 = explicit user action) and JX.Router will get the higher stuff fired off sooner.
- You can name requests and then adjust their prorities later, if the user expresses an interest in specific results.
- Only use the spinner gif for "workflow" requests, which is bascially when the user clicked something and we're waiting on the server. I think it's useful and not-annoying in this case.
- Don't show any status for draft requests.
- For content requests, show a subtle hipster-style top loading bar.
Test Plan:
- Viewed a diff with 93 changes, and clicked award token.
- Prior to this patch, the action took many many seconds to resolve.
- After this patch, it resolves quickly.
- Viewed a diff with 93 changes and saw a pleasant subtle hipster-style loading bar.
- Viewed a diff with 93 changes and typed some draft text. Previews populated fairly quickly and there was no spinner.
- Viewed a diff with 93 changes and clicked something with workflow, saw a spinner after a moment.
- Viewed a diff with 93 changes and clicked a file in the table of contents near the end of the list.
- Prior to this patch, it took a long time to show up.
- After this patch, it loads directly.
Reviewers: chad, btrahan
Reviewed By: btrahan
Subscribers: epriestley
Maniphest Tasks: T430, T4834
Differential Revision: https://secure.phabricator.com/D8979
2014-05-05 19:57:42 +02:00
|
|
|
'javelin-behavior-refresh-csrf' => '7814b593',
|
2014-06-23 19:27:47 +02:00
|
|
|
'javelin-behavior-releeph-preview-branch' => 'b2b4fbaf',
|
2015-01-25 17:46:22 +01:00
|
|
|
'javelin-behavior-releeph-request-state-change' => 'a0b57eb8',
|
Introduce CAN_EDIT for ExternalAccount, and make CAN_VIEW more liberal
Summary:
Fixes T3732. Ref T1205. Ref T3116.
External accounts (like emails used as identities, Facebook accounts, LDAP accounts, etc.) are stored in "ExternalAccount" objects.
Currently, we have a very restrictive `CAN_VIEW` policy for ExternalAccounts, to add an extra layer of protection to make sure users can't use them in unintended ways. For example, it would be bad if a user could link their Phabricator account to a Facebook account without proper authentication. All of the controllers which do sensitive things have checks anyway, but a restrictive CAN_VIEW provided an extra layer of protection. Se T3116 for some discussion.
However, this means that when grey/external users take actions (via email, or via applications like Legalpad) other users can't load the account handles and can't see anything about the actor (they just see "Restricted External Account" or similar).
Balancing these concerns is mostly about not making a huge mess while doing it. This seems like a reasonable approach:
- Add `CAN_EDIT` on these objects.
- Make that very restricted, but open up `CAN_VIEW`.
- Require `CAN_EDIT` any time we're going to do something authentication/identity related.
This is slightly easier to get wrong (forget CAN_EDIT) than other approaches, but pretty simple, and we always have extra checks in place anyway -- this is just a safety net.
I'm not quite sure how we should identify external accounts, so for now we're just rendering "Email User" or similar -- clearly not a bug, but not identifying. We can figure out what to render in the long term elsewhere.
Test Plan:
- Viewed external accounts.
- Linked an external account.
- Refreshed an external account.
- Edited profile picture.
- Viewed sessions panel.
- Published a bunch of stuff to Asana/JIRA.
- Legalpad signature page now shows external accounts.
{F171595}
Reviewers: chad, btrahan
Reviewed By: btrahan
Subscribers: epriestley
Maniphest Tasks: T3732, T1205, T3116
Differential Revision: https://secure.phabricator.com/D9767
2014-07-10 19:18:10 +02:00
|
|
|
'javelin-behavior-releeph-request-typeahead' => 'de2e896f',
|
2014-01-01 16:46:25 +01:00
|
|
|
'javelin-behavior-remarkup-preview' => 'f7379f45',
|
2014-06-23 19:27:47 +02:00
|
|
|
'javelin-behavior-reorder-applications' => '76b9fc3e',
|
2014-08-09 17:49:01 +02:00
|
|
|
'javelin-behavior-reorder-columns' => 'e1d25dfb',
|
2014-06-23 19:27:47 +02:00
|
|
|
'javelin-behavior-repository-crossreference' => 'f9539603',
|
2015-01-25 17:46:22 +01:00
|
|
|
'javelin-behavior-scrollbar' => '834a1173',
|
2014-06-23 19:27:47 +02:00
|
|
|
'javelin-behavior-search-reorder-queries' => 'e9581f08',
|
|
|
|
'javelin-behavior-select-on-click' => '4e3e79a6',
|
2015-01-23 22:29:15 +01:00
|
|
|
'javelin-behavior-slowvote-embed' => '887ad43f',
|
2014-12-30 11:53:27 +01:00
|
|
|
'javelin-behavior-stripe-payment-form' => '3f5d6dbf',
|
|
|
|
'javelin-behavior-test-payment-form' => 'fc91ab6c',
|
Introduce CAN_EDIT for ExternalAccount, and make CAN_VIEW more liberal
Summary:
Fixes T3732. Ref T1205. Ref T3116.
External accounts (like emails used as identities, Facebook accounts, LDAP accounts, etc.) are stored in "ExternalAccount" objects.
Currently, we have a very restrictive `CAN_VIEW` policy for ExternalAccounts, to add an extra layer of protection to make sure users can't use them in unintended ways. For example, it would be bad if a user could link their Phabricator account to a Facebook account without proper authentication. All of the controllers which do sensitive things have checks anyway, but a restrictive CAN_VIEW provided an extra layer of protection. Se T3116 for some discussion.
However, this means that when grey/external users take actions (via email, or via applications like Legalpad) other users can't load the account handles and can't see anything about the actor (they just see "Restricted External Account" or similar).
Balancing these concerns is mostly about not making a huge mess while doing it. This seems like a reasonable approach:
- Add `CAN_EDIT` on these objects.
- Make that very restricted, but open up `CAN_VIEW`.
- Require `CAN_EDIT` any time we're going to do something authentication/identity related.
This is slightly easier to get wrong (forget CAN_EDIT) than other approaches, but pretty simple, and we always have extra checks in place anyway -- this is just a safety net.
I'm not quite sure how we should identify external accounts, so for now we're just rendering "Email User" or similar -- clearly not a bug, but not identifying. We can figure out what to render in the long term elsewhere.
Test Plan:
- Viewed external accounts.
- Linked an external account.
- Refreshed an external account.
- Edited profile picture.
- Viewed sessions panel.
- Published a bunch of stuff to Asana/JIRA.
- Legalpad signature page now shows external accounts.
{F171595}
Reviewers: chad, btrahan
Reviewed By: btrahan
Subscribers: epriestley
Maniphest Tasks: T3732, T1205, T3116
Differential Revision: https://secure.phabricator.com/D9767
2014-07-10 19:18:10 +02:00
|
|
|
'javelin-behavior-toggle-class' => 'e566f52c',
|
2015-01-14 01:10:57 +01:00
|
|
|
'javelin-behavior-view-placeholder' => '47830651',
|
Provide a global router for Ajax requests
Summary:
Fixes T430. Fixes T4834. Obsoletes D7641. Currently, we do some things less-well than we could:
- We just let the browser queue and prioritize requests, so if you load a revision with 50 changes and then click "Award Token", the action blocks until the changes load in most/all browsers. It would be better to prioritize this action and queue it immediately.
- Similarly, changes tend to load in order, even if the user has clicked to a specific file. When the user expresses a preference for a specific file, we should prioritize it.
- We show a spinning GIF when waiting on requests. This is appropriate for some types of reuqests, but distracting for others.
To fix this:
- Queue all (or, at least, most) requests into a new queue in JX.Router.
- JX.Router handles prioritizing the requests. Principally:
- You can submit a request with a specific priority (500 = general content loading, 1000 = default, 2000 = explicit user action) and JX.Router will get the higher stuff fired off sooner.
- You can name requests and then adjust their prorities later, if the user expresses an interest in specific results.
- Only use the spinner gif for "workflow" requests, which is bascially when the user clicked something and we're waiting on the server. I think it's useful and not-annoying in this case.
- Don't show any status for draft requests.
- For content requests, show a subtle hipster-style top loading bar.
Test Plan:
- Viewed a diff with 93 changes, and clicked award token.
- Prior to this patch, the action took many many seconds to resolve.
- After this patch, it resolves quickly.
- Viewed a diff with 93 changes and saw a pleasant subtle hipster-style loading bar.
- Viewed a diff with 93 changes and typed some draft text. Previews populated fairly quickly and there was no spinner.
- Viewed a diff with 93 changes and clicked something with workflow, saw a spinner after a moment.
- Viewed a diff with 93 changes and clicked a file in the table of contents near the end of the list.
- Prior to this patch, it took a long time to show up.
- After this patch, it loads directly.
Reviewers: chad, btrahan
Reviewed By: btrahan
Subscribers: epriestley
Maniphest Tasks: T430, T4834
Differential Revision: https://secure.phabricator.com/D8979
2014-05-05 19:57:42 +02:00
|
|
|
'javelin-behavior-workflow' => '0a3f3021',
|
2014-01-01 16:46:25 +01:00
|
|
|
'javelin-color' => '7e41274a',
|
2015-01-20 01:55:08 +01:00
|
|
|
'javelin-cookie' => '62dfea03',
|
2014-06-23 19:35:39 +02:00
|
|
|
'javelin-diffusion-locate-file-source' => 'b42eddc7',
|
2015-01-28 17:26:10 +01:00
|
|
|
'javelin-dom' => '6f7962d5',
|
2014-02-27 20:06:55 +01:00
|
|
|
'javelin-dynval' => 'f6555212',
|
Introduce CAN_EDIT for ExternalAccount, and make CAN_VIEW more liberal
Summary:
Fixes T3732. Ref T1205. Ref T3116.
External accounts (like emails used as identities, Facebook accounts, LDAP accounts, etc.) are stored in "ExternalAccount" objects.
Currently, we have a very restrictive `CAN_VIEW` policy for ExternalAccounts, to add an extra layer of protection to make sure users can't use them in unintended ways. For example, it would be bad if a user could link their Phabricator account to a Facebook account without proper authentication. All of the controllers which do sensitive things have checks anyway, but a restrictive CAN_VIEW provided an extra layer of protection. Se T3116 for some discussion.
However, this means that when grey/external users take actions (via email, or via applications like Legalpad) other users can't load the account handles and can't see anything about the actor (they just see "Restricted External Account" or similar).
Balancing these concerns is mostly about not making a huge mess while doing it. This seems like a reasonable approach:
- Add `CAN_EDIT` on these objects.
- Make that very restricted, but open up `CAN_VIEW`.
- Require `CAN_EDIT` any time we're going to do something authentication/identity related.
This is slightly easier to get wrong (forget CAN_EDIT) than other approaches, but pretty simple, and we always have extra checks in place anyway -- this is just a safety net.
I'm not quite sure how we should identify external accounts, so for now we're just rendering "Email User" or similar -- clearly not a bug, but not identifying. We can figure out what to render in the long term elsewhere.
Test Plan:
- Viewed external accounts.
- Linked an external account.
- Refreshed an external account.
- Edited profile picture.
- Viewed sessions panel.
- Published a bunch of stuff to Asana/JIRA.
- Legalpad signature page now shows external accounts.
{F171595}
Reviewers: chad, btrahan
Reviewed By: btrahan
Subscribers: epriestley
Maniphest Tasks: T3732, T1205, T3116
Differential Revision: https://secure.phabricator.com/D9767
2014-07-10 19:18:10 +02:00
|
|
|
'javelin-event' => '85ea0626',
|
2014-01-01 16:46:25 +01:00
|
|
|
'javelin-fx' => '54b612ba',
|
Quicksand, an ignoble successor to Quickling
Summary:
Ref T2086. Ref T7014. With the persistent column, there is significant value in retaining chrome state through navigation events, because the user may have a lot of state in the chat window (scroll position, text selection, room juggling, partially entered text, etc). We can do this by capturing navigation events and faking them with Javascript.
(This can also improve performance, albeit slightly, and I believe there are better approaches to tackle performance any problems which exist with the chrome in many cases).
At Facebook, this system was "Photostream" in photos and then "Quickling" in general, and the technical cost of the system was //staggering//. I am loathe to pursue it again. However:
- Browsers are less junky now, and we target a smaller set of browsers. A large part of the technical cost of Quickling was the high complexity of emulating nagivation events in IE, where we needed to navigate a hidden iframe to make history entries. All desktop browsers which we might want to use this system on support the History API (although this prototype does not yet implement it).
- Javelin and Phabricator's architecture are much cleaner than Facebook's was. A large part of the technical cost of Quickling was inconsistency, inlined `onclick` handlers, and general lack of coordination and abstraction. We will have //some// of this, but "correctly written" behaviors are mostly immune to it by design, and many of Javelin's architectural decisions were influenced by desire to avoid issues we encountered building this stuff for Facebook.
- Some of the primitives which Quickling required (like loading resources over Ajax) have existed in a stable state in our codebase for a year or more, and adoption of these primitives was trivial and uneventful (vs a huge production at Facebook).
- My hubris is bolstered by recent success with WebSockets and JX.Scrollbar, both of which I would have assessed as infeasibly complex to develop in this project a few years ago.
To these points, the developer cost to prototype Photostream was several weeks; the developer cost to prototype this was a bit less than an hour. It is plausible to me that implementing and maintaining this system really will be hundreds of times less complex than it was at Facebook.
Test Plan:
My plan for this and D11497 is:
- Get them in master.
- Some secret key / relatively-hidden preference activates the column.
- Quicksand activates //only// when the column is open.
- We can use column + quicksand for a long period of time (i.e., over the course of Conpherence v2 development) and hammer out the long tail of issues.
- When it derps up, you just hide the column and you're good to go.
Reviewers: btrahan, chad
Reviewed By: chad
Subscribers: epriestley
Maniphest Tasks: T2086, T7014
Differential Revision: https://secure.phabricator.com/D11507
2015-01-27 23:52:09 +01:00
|
|
|
'javelin-history' => '2e0148bc',
|
2015-01-14 01:10:57 +01:00
|
|
|
'javelin-install' => '05270951',
|
Introduce CAN_EDIT for ExternalAccount, and make CAN_VIEW more liberal
Summary:
Fixes T3732. Ref T1205. Ref T3116.
External accounts (like emails used as identities, Facebook accounts, LDAP accounts, etc.) are stored in "ExternalAccount" objects.
Currently, we have a very restrictive `CAN_VIEW` policy for ExternalAccounts, to add an extra layer of protection to make sure users can't use them in unintended ways. For example, it would be bad if a user could link their Phabricator account to a Facebook account without proper authentication. All of the controllers which do sensitive things have checks anyway, but a restrictive CAN_VIEW provided an extra layer of protection. Se T3116 for some discussion.
However, this means that when grey/external users take actions (via email, or via applications like Legalpad) other users can't load the account handles and can't see anything about the actor (they just see "Restricted External Account" or similar).
Balancing these concerns is mostly about not making a huge mess while doing it. This seems like a reasonable approach:
- Add `CAN_EDIT` on these objects.
- Make that very restricted, but open up `CAN_VIEW`.
- Require `CAN_EDIT` any time we're going to do something authentication/identity related.
This is slightly easier to get wrong (forget CAN_EDIT) than other approaches, but pretty simple, and we always have extra checks in place anyway -- this is just a safety net.
I'm not quite sure how we should identify external accounts, so for now we're just rendering "Email User" or similar -- clearly not a bug, but not identifying. We can figure out what to render in the long term elsewhere.
Test Plan:
- Viewed external accounts.
- Linked an external account.
- Refreshed an external account.
- Edited profile picture.
- Viewed sessions panel.
- Published a bunch of stuff to Asana/JIRA.
- Legalpad signature page now shows external accounts.
{F171595}
Reviewers: chad, btrahan
Reviewed By: btrahan
Subscribers: epriestley
Maniphest Tasks: T3732, T1205, T3116
Differential Revision: https://secure.phabricator.com/D9767
2014-07-10 19:18:10 +02:00
|
|
|
'javelin-json' => '69adf288',
|
2015-01-22 21:22:26 +01:00
|
|
|
'javelin-leader' => '331b1611',
|
2015-01-28 21:42:05 +01:00
|
|
|
'javelin-magical-init' => '2bd3c675',
|
Introduce CAN_EDIT for ExternalAccount, and make CAN_VIEW more liberal
Summary:
Fixes T3732. Ref T1205. Ref T3116.
External accounts (like emails used as identities, Facebook accounts, LDAP accounts, etc.) are stored in "ExternalAccount" objects.
Currently, we have a very restrictive `CAN_VIEW` policy for ExternalAccounts, to add an extra layer of protection to make sure users can't use them in unintended ways. For example, it would be bad if a user could link their Phabricator account to a Facebook account without proper authentication. All of the controllers which do sensitive things have checks anyway, but a restrictive CAN_VIEW provided an extra layer of protection. Se T3116 for some discussion.
However, this means that when grey/external users take actions (via email, or via applications like Legalpad) other users can't load the account handles and can't see anything about the actor (they just see "Restricted External Account" or similar).
Balancing these concerns is mostly about not making a huge mess while doing it. This seems like a reasonable approach:
- Add `CAN_EDIT` on these objects.
- Make that very restricted, but open up `CAN_VIEW`.
- Require `CAN_EDIT` any time we're going to do something authentication/identity related.
This is slightly easier to get wrong (forget CAN_EDIT) than other approaches, but pretty simple, and we always have extra checks in place anyway -- this is just a safety net.
I'm not quite sure how we should identify external accounts, so for now we're just rendering "Email User" or similar -- clearly not a bug, but not identifying. We can figure out what to render in the long term elsewhere.
Test Plan:
- Viewed external accounts.
- Linked an external account.
- Refreshed an external account.
- Edited profile picture.
- Viewed sessions panel.
- Published a bunch of stuff to Asana/JIRA.
- Legalpad signature page now shows external accounts.
{F171595}
Reviewers: chad, btrahan
Reviewed By: btrahan
Subscribers: epriestley
Maniphest Tasks: T3732, T1205, T3116
Differential Revision: https://secure.phabricator.com/D9767
2014-07-10 19:18:10 +02:00
|
|
|
'javelin-mask' => '8a41885b',
|
Quicksand, an ignoble successor to Quickling
Summary:
Ref T2086. Ref T7014. With the persistent column, there is significant value in retaining chrome state through navigation events, because the user may have a lot of state in the chat window (scroll position, text selection, room juggling, partially entered text, etc). We can do this by capturing navigation events and faking them with Javascript.
(This can also improve performance, albeit slightly, and I believe there are better approaches to tackle performance any problems which exist with the chrome in many cases).
At Facebook, this system was "Photostream" in photos and then "Quickling" in general, and the technical cost of the system was //staggering//. I am loathe to pursue it again. However:
- Browsers are less junky now, and we target a smaller set of browsers. A large part of the technical cost of Quickling was the high complexity of emulating nagivation events in IE, where we needed to navigate a hidden iframe to make history entries. All desktop browsers which we might want to use this system on support the History API (although this prototype does not yet implement it).
- Javelin and Phabricator's architecture are much cleaner than Facebook's was. A large part of the technical cost of Quickling was inconsistency, inlined `onclick` handlers, and general lack of coordination and abstraction. We will have //some// of this, but "correctly written" behaviors are mostly immune to it by design, and many of Javelin's architectural decisions were influenced by desire to avoid issues we encountered building this stuff for Facebook.
- Some of the primitives which Quickling required (like loading resources over Ajax) have existed in a stable state in our codebase for a year or more, and adoption of these primitives was trivial and uneventful (vs a huge production at Facebook).
- My hubris is bolstered by recent success with WebSockets and JX.Scrollbar, both of which I would have assessed as infeasibly complex to develop in this project a few years ago.
To these points, the developer cost to prototype Photostream was several weeks; the developer cost to prototype this was a bit less than an hour. It is plausible to me that implementing and maintaining this system really will be hundreds of times less complex than it was at Facebook.
Test Plan:
My plan for this and D11497 is:
- Get them in master.
- Some secret key / relatively-hidden preference activates the column.
- Quicksand activates //only// when the column is open.
- We can use column + quicksand for a long period of time (i.e., over the course of Conpherence v2 development) and hammer out the long tail of issues.
- When it derps up, you just hide the column and you're good to go.
Reviewers: btrahan, chad
Reviewed By: chad
Subscribers: epriestley
Maniphest Tasks: T2086, T7014
Differential Revision: https://secure.phabricator.com/D11507
2015-01-27 23:52:09 +01:00
|
|
|
'javelin-quicksand' => 'f960d43d',
|
2015-01-14 01:10:57 +01:00
|
|
|
'javelin-reactor' => '2b8de964',
|
|
|
|
'javelin-reactor-dom' => 'c90a04fc',
|
2014-02-27 20:06:55 +01:00
|
|
|
'javelin-reactor-node-calmer' => '76f4ebed',
|
2015-01-14 01:10:57 +01:00
|
|
|
'javelin-reactornode' => '1ad0a787',
|
|
|
|
'javelin-request' => '94b750d2',
|
|
|
|
'javelin-resource' => '44959b73',
|
Provide a global router for Ajax requests
Summary:
Fixes T430. Fixes T4834. Obsoletes D7641. Currently, we do some things less-well than we could:
- We just let the browser queue and prioritize requests, so if you load a revision with 50 changes and then click "Award Token", the action blocks until the changes load in most/all browsers. It would be better to prioritize this action and queue it immediately.
- Similarly, changes tend to load in order, even if the user has clicked to a specific file. When the user expresses a preference for a specific file, we should prioritize it.
- We show a spinning GIF when waiting on requests. This is appropriate for some types of reuqests, but distracting for others.
To fix this:
- Queue all (or, at least, most) requests into a new queue in JX.Router.
- JX.Router handles prioritizing the requests. Principally:
- You can submit a request with a specific priority (500 = general content loading, 1000 = default, 2000 = explicit user action) and JX.Router will get the higher stuff fired off sooner.
- You can name requests and then adjust their prorities later, if the user expresses an interest in specific results.
- Only use the spinner gif for "workflow" requests, which is bascially when the user clicked something and we're waiting on the server. I think it's useful and not-annoying in this case.
- Don't show any status for draft requests.
- For content requests, show a subtle hipster-style top loading bar.
Test Plan:
- Viewed a diff with 93 changes, and clicked award token.
- Prior to this patch, the action took many many seconds to resolve.
- After this patch, it resolves quickly.
- Viewed a diff with 93 changes and saw a pleasant subtle hipster-style loading bar.
- Viewed a diff with 93 changes and typed some draft text. Previews populated fairly quickly and there was no spinner.
- Viewed a diff with 93 changes and clicked something with workflow, saw a spinner after a moment.
- Viewed a diff with 93 changes and clicked a file in the table of contents near the end of the list.
- Prior to this patch, it took a long time to show up.
- After this patch, it loads directly.
Reviewers: chad, btrahan
Reviewed By: btrahan
Subscribers: epriestley
Maniphest Tasks: T430, T4834
Differential Revision: https://secure.phabricator.com/D8979
2014-05-05 19:57:42 +02:00
|
|
|
'javelin-routable' => 'b3e7d692',
|
|
|
|
'javelin-router' => '29274e2b',
|
2015-01-29 16:10:35 +01:00
|
|
|
'javelin-scrollbar' => '5b2f5a08',
|
2015-01-28 21:42:05 +01:00
|
|
|
'javelin-stratcom' => '6c53634d',
|
2015-01-14 01:10:57 +01:00
|
|
|
'javelin-tokenizer' => '7644823e',
|
|
|
|
'javelin-typeahead' => '70baed2f',
|
Introduce CAN_EDIT for ExternalAccount, and make CAN_VIEW more liberal
Summary:
Fixes T3732. Ref T1205. Ref T3116.
External accounts (like emails used as identities, Facebook accounts, LDAP accounts, etc.) are stored in "ExternalAccount" objects.
Currently, we have a very restrictive `CAN_VIEW` policy for ExternalAccounts, to add an extra layer of protection to make sure users can't use them in unintended ways. For example, it would be bad if a user could link their Phabricator account to a Facebook account without proper authentication. All of the controllers which do sensitive things have checks anyway, but a restrictive CAN_VIEW provided an extra layer of protection. Se T3116 for some discussion.
However, this means that when grey/external users take actions (via email, or via applications like Legalpad) other users can't load the account handles and can't see anything about the actor (they just see "Restricted External Account" or similar).
Balancing these concerns is mostly about not making a huge mess while doing it. This seems like a reasonable approach:
- Add `CAN_EDIT` on these objects.
- Make that very restricted, but open up `CAN_VIEW`.
- Require `CAN_EDIT` any time we're going to do something authentication/identity related.
This is slightly easier to get wrong (forget CAN_EDIT) than other approaches, but pretty simple, and we always have extra checks in place anyway -- this is just a safety net.
I'm not quite sure how we should identify external accounts, so for now we're just rendering "Email User" or similar -- clearly not a bug, but not identifying. We can figure out what to render in the long term elsewhere.
Test Plan:
- Viewed external accounts.
- Linked an external account.
- Refreshed an external account.
- Edited profile picture.
- Viewed sessions panel.
- Published a bunch of stuff to Asana/JIRA.
- Legalpad signature page now shows external accounts.
{F171595}
Reviewers: chad, btrahan
Reviewed By: btrahan
Subscribers: epriestley
Maniphest Tasks: T3732, T1205, T3116
Differential Revision: https://secure.phabricator.com/D9767
2014-07-10 19:18:10 +02:00
|
|
|
'javelin-typeahead-composite-source' => '503e17fd',
|
2015-01-09 23:09:13 +01:00
|
|
|
'javelin-typeahead-normalizer' => '6f7a9da8',
|
Introduce CAN_EDIT for ExternalAccount, and make CAN_VIEW more liberal
Summary:
Fixes T3732. Ref T1205. Ref T3116.
External accounts (like emails used as identities, Facebook accounts, LDAP accounts, etc.) are stored in "ExternalAccount" objects.
Currently, we have a very restrictive `CAN_VIEW` policy for ExternalAccounts, to add an extra layer of protection to make sure users can't use them in unintended ways. For example, it would be bad if a user could link their Phabricator account to a Facebook account without proper authentication. All of the controllers which do sensitive things have checks anyway, but a restrictive CAN_VIEW provided an extra layer of protection. Se T3116 for some discussion.
However, this means that when grey/external users take actions (via email, or via applications like Legalpad) other users can't load the account handles and can't see anything about the actor (they just see "Restricted External Account" or similar).
Balancing these concerns is mostly about not making a huge mess while doing it. This seems like a reasonable approach:
- Add `CAN_EDIT` on these objects.
- Make that very restricted, but open up `CAN_VIEW`.
- Require `CAN_EDIT` any time we're going to do something authentication/identity related.
This is slightly easier to get wrong (forget CAN_EDIT) than other approaches, but pretty simple, and we always have extra checks in place anyway -- this is just a safety net.
I'm not quite sure how we should identify external accounts, so for now we're just rendering "Email User" or similar -- clearly not a bug, but not identifying. We can figure out what to render in the long term elsewhere.
Test Plan:
- Viewed external accounts.
- Linked an external account.
- Refreshed an external account.
- Edited profile picture.
- Viewed sessions panel.
- Published a bunch of stuff to Asana/JIRA.
- Legalpad signature page now shows external accounts.
{F171595}
Reviewers: chad, btrahan
Reviewed By: btrahan
Subscribers: epriestley
Maniphest Tasks: T3732, T1205, T3116
Differential Revision: https://secure.phabricator.com/D9767
2014-07-10 19:18:10 +02:00
|
|
|
'javelin-typeahead-ondemand-source' => '8b3fd187',
|
|
|
|
'javelin-typeahead-preloaded-source' => '54f314a0',
|
2015-01-20 01:55:08 +01:00
|
|
|
'javelin-typeahead-source' => '2818f5ce',
|
Introduce CAN_EDIT for ExternalAccount, and make CAN_VIEW more liberal
Summary:
Fixes T3732. Ref T1205. Ref T3116.
External accounts (like emails used as identities, Facebook accounts, LDAP accounts, etc.) are stored in "ExternalAccount" objects.
Currently, we have a very restrictive `CAN_VIEW` policy for ExternalAccounts, to add an extra layer of protection to make sure users can't use them in unintended ways. For example, it would be bad if a user could link their Phabricator account to a Facebook account without proper authentication. All of the controllers which do sensitive things have checks anyway, but a restrictive CAN_VIEW provided an extra layer of protection. Se T3116 for some discussion.
However, this means that when grey/external users take actions (via email, or via applications like Legalpad) other users can't load the account handles and can't see anything about the actor (they just see "Restricted External Account" or similar).
Balancing these concerns is mostly about not making a huge mess while doing it. This seems like a reasonable approach:
- Add `CAN_EDIT` on these objects.
- Make that very restricted, but open up `CAN_VIEW`.
- Require `CAN_EDIT` any time we're going to do something authentication/identity related.
This is slightly easier to get wrong (forget CAN_EDIT) than other approaches, but pretty simple, and we always have extra checks in place anyway -- this is just a safety net.
I'm not quite sure how we should identify external accounts, so for now we're just rendering "Email User" or similar -- clearly not a bug, but not identifying. We can figure out what to render in the long term elsewhere.
Test Plan:
- Viewed external accounts.
- Linked an external account.
- Refreshed an external account.
- Edited profile picture.
- Viewed sessions panel.
- Published a bunch of stuff to Asana/JIRA.
- Legalpad signature page now shows external accounts.
{F171595}
Reviewers: chad, btrahan
Reviewed By: btrahan
Subscribers: epriestley
Maniphest Tasks: T3732, T1205, T3116
Differential Revision: https://secure.phabricator.com/D9767
2014-07-10 19:18:10 +02:00
|
|
|
'javelin-typeahead-static-source' => '316b8fa1',
|
|
|
|
'javelin-uri' => '6eff08aa',
|
2015-01-20 01:55:08 +01:00
|
|
|
'javelin-util' => '93cc50d6',
|
2015-01-28 17:26:10 +01:00
|
|
|
'javelin-vector' => '2caa8fb8',
|
2014-02-27 20:06:55 +01:00
|
|
|
'javelin-view' => '0f764c35',
|
2015-01-14 01:10:57 +01:00
|
|
|
'javelin-view-html' => 'fe287620',
|
|
|
|
'javelin-view-interpreter' => 'f829edb3',
|
2014-02-27 20:06:55 +01:00
|
|
|
'javelin-view-renderer' => '6c2b09a2',
|
|
|
|
'javelin-view-visitor' => 'efe49472',
|
Namespace Aphlict clients by request path, plus other fixes
Summary:
Fixes T7130. Fixes T7041. Fixes T7012.
Major change here is partitioning clients. In the Phacility cluster, being able to get a huge pile of instances on a single server -- without needing to run a process per instance -- is desirable.
To accomplish this, just bucket clients by the path they connect with. This will let us set client URIs to `/instancename/` and then route connections to a small set of servers. This degrades cleanly in the common case and has no effect on installs which don't do instancing.
Also fix two unrelated issues:
- Fix the timeouts, which were incorrectly initializing in `open()` (which is called during reconnect, causing them to reset every time). Instead, initialize in the constructor. Cap timeout at 5 minutes.
- Probably fix subscriptions, which were using a property with an object definition. Since this is by-ref, all concrete instances of the object share the same property, so all users would be subscribed to everything. Probably.
Test Plan:
- Hit notification status page, saw version bump and instance/path name.
- Saw instance/path name in client and server logs.
- Stopped server, saw reconnects after 2, 4, 16, ... seconds.
- Sent test notification; received test notification.
- Didn't explicitly test the subscription thing but it should be obvious by looking at `/notification/status/` shortly after a push.
Reviewers: joshuaspence, btrahan
Reviewed By: btrahan
Subscribers: epriestley
Maniphest Tasks: T7041, T7012, T7130
Differential Revision: https://secure.phabricator.com/D11769
2015-02-16 20:31:15 +01:00
|
|
|
'javelin-websocket' => 'e292eaf4',
|
2015-01-29 16:10:14 +01:00
|
|
|
'javelin-workflow' => '84d6aea0',
|
2014-02-27 20:06:55 +01:00
|
|
|
'lightbox-attachment-css' => '7acac05d',
|
|
|
|
'maniphest-batch-editor' => '8f380ebc',
|
2015-02-24 18:41:37 +01:00
|
|
|
'maniphest-report-css' => 'd8ed71ad',
|
2014-01-01 16:46:25 +01:00
|
|
|
'maniphest-task-edit-css' => '8e23031b',
|
2015-01-27 19:24:28 +01:00
|
|
|
'maniphest-task-summary-css' => 'ab2fc691',
|
2014-11-17 23:06:05 +01:00
|
|
|
'multirow-row-manager' => 'b5d57730',
|
2014-06-23 19:35:39 +02:00
|
|
|
'owners-path-editor' => 'aa1733d0',
|
2014-01-01 16:46:25 +01:00
|
|
|
'owners-path-editor-css' => '2f00933b',
|
2015-02-27 21:04:41 +01:00
|
|
|
'paste-css' => 'eb997ddd',
|
2014-01-01 16:46:25 +01:00
|
|
|
'path-typeahead' => 'f7fc67ec',
|
2015-01-12 16:20:20 +01:00
|
|
|
'people-profile-css' => '25970776',
|
2014-06-24 18:39:32 +02:00
|
|
|
'phabricator-action-list-view-css' => '9ee9910a',
|
2015-01-26 17:19:22 +01:00
|
|
|
'phabricator-application-launch-view-css' => '16ca323f',
|
2014-01-01 16:46:25 +01:00
|
|
|
'phabricator-busy' => '6453c869',
|
2014-02-12 18:55:53 +01:00
|
|
|
'phabricator-chatlog-css' => '852140ff',
|
2014-01-01 16:46:25 +01:00
|
|
|
'phabricator-content-source-view-css' => '4b8b05d4',
|
2015-03-05 23:02:06 +01:00
|
|
|
'phabricator-core-css' => '86bfbe8c',
|
2014-01-01 16:46:25 +01:00
|
|
|
'phabricator-countdown-css' => '86b7b0a0',
|
2015-03-01 23:45:56 +01:00
|
|
|
'phabricator-dashboard-css' => '17937d22',
|
2014-08-21 01:21:50 +02:00
|
|
|
'phabricator-drag-and-drop-file-upload' => '8c49f386',
|
2014-09-09 23:20:27 +02:00
|
|
|
'phabricator-draggable-list' => 'a16ec1c6',
|
2015-02-26 18:26:36 +01:00
|
|
|
'phabricator-fatal-config-template-css' => '8e6c6fcd',
|
2014-12-30 11:48:26 +01:00
|
|
|
'phabricator-feed-css' => 'b513b5f4',
|
2014-02-27 20:06:55 +01:00
|
|
|
'phabricator-file-upload' => 'a4ae61bf',
|
2014-05-30 01:04:50 +02:00
|
|
|
'phabricator-filetree-view-css' => 'fccf9f82',
|
2014-01-06 06:47:21 +01:00
|
|
|
'phabricator-flag-css' => '5337623f',
|
2014-06-23 19:35:39 +02:00
|
|
|
'phabricator-hovercard' => '7e8468ae',
|
2014-06-24 18:39:32 +02:00
|
|
|
'phabricator-hovercard-view-css' => '893f4783',
|
2014-01-01 16:46:25 +01:00
|
|
|
'phabricator-keyboard-shortcut' => '1ae869f2',
|
2015-01-25 17:46:22 +01:00
|
|
|
'phabricator-keyboard-shortcut-manager' => 'c1700f6f',
|
2015-02-20 21:57:57 +01:00
|
|
|
'phabricator-main-menu-view' => 'f9f5cd1b',
|
2014-12-30 11:48:26 +01:00
|
|
|
'phabricator-nav-view-css' => '7aeaf435',
|
2014-02-27 20:06:55 +01:00
|
|
|
'phabricator-notification' => '0c6946e7',
|
2014-10-15 19:33:26 +02:00
|
|
|
'phabricator-notification-css' => '9c279160',
|
2014-08-15 02:19:01 +02:00
|
|
|
'phabricator-notification-menu-css' => '6aa0a74b',
|
2014-01-01 16:46:25 +01:00
|
|
|
'phabricator-object-selector-css' => '029a133d',
|
|
|
|
'phabricator-phtize' => 'd254d646',
|
2015-01-09 23:53:56 +01:00
|
|
|
'phabricator-prefab' => '72da38cc',
|
2015-03-01 23:45:56 +01:00
|
|
|
'phabricator-profile-css' => '1a20dcbf',
|
2015-03-01 21:03:02 +01:00
|
|
|
'phabricator-remarkup-css' => '2dbff225',
|
2015-03-03 16:18:40 +01:00
|
|
|
'phabricator-search-results-css' => '559cc554',
|
Provide a global router for Ajax requests
Summary:
Fixes T430. Fixes T4834. Obsoletes D7641. Currently, we do some things less-well than we could:
- We just let the browser queue and prioritize requests, so if you load a revision with 50 changes and then click "Award Token", the action blocks until the changes load in most/all browsers. It would be better to prioritize this action and queue it immediately.
- Similarly, changes tend to load in order, even if the user has clicked to a specific file. When the user expresses a preference for a specific file, we should prioritize it.
- We show a spinning GIF when waiting on requests. This is appropriate for some types of reuqests, but distracting for others.
To fix this:
- Queue all (or, at least, most) requests into a new queue in JX.Router.
- JX.Router handles prioritizing the requests. Principally:
- You can submit a request with a specific priority (500 = general content loading, 1000 = default, 2000 = explicit user action) and JX.Router will get the higher stuff fired off sooner.
- You can name requests and then adjust their prorities later, if the user expresses an interest in specific results.
- Only use the spinner gif for "workflow" requests, which is bascially when the user clicked something and we're waiting on the server. I think it's useful and not-annoying in this case.
- Don't show any status for draft requests.
- For content requests, show a subtle hipster-style top loading bar.
Test Plan:
- Viewed a diff with 93 changes, and clicked award token.
- Prior to this patch, the action took many many seconds to resolve.
- After this patch, it resolves quickly.
- Viewed a diff with 93 changes and saw a pleasant subtle hipster-style loading bar.
- Viewed a diff with 93 changes and typed some draft text. Previews populated fairly quickly and there was no spinner.
- Viewed a diff with 93 changes and clicked something with workflow, saw a spinner after a moment.
- Viewed a diff with 93 changes and clicked a file in the table of contents near the end of the list.
- Prior to this patch, it took a long time to show up.
- After this patch, it loads directly.
Reviewers: chad, btrahan
Reviewed By: btrahan
Subscribers: epriestley
Maniphest Tasks: T430, T4834
Differential Revision: https://secure.phabricator.com/D8979
2014-05-05 19:57:42 +02:00
|
|
|
'phabricator-shaped-request' => '7cbe244b',
|
2015-01-12 19:04:01 +01:00
|
|
|
'phabricator-side-menu-view-css' => '7e8c6341',
|
2014-01-01 16:46:25 +01:00
|
|
|
'phabricator-slowvote-css' => '266df6a1',
|
2015-02-27 21:04:41 +01:00
|
|
|
'phabricator-source-code-view-css' => '2ceee894',
|
|
|
|
'phabricator-standard-page-view' => 'df338a4b',
|
2014-08-19 23:46:37 +02:00
|
|
|
'phabricator-textareautils' => '5c93c52c',
|
2014-09-10 19:17:49 +02:00
|
|
|
'phabricator-title' => '5c1c758c',
|
2015-01-20 01:55:08 +01:00
|
|
|
'phabricator-tooltip' => '1d298e3a',
|
2014-06-22 20:37:52 +02:00
|
|
|
'phabricator-transaction-view-css' => '5d0cae25',
|
2014-04-23 03:29:14 +02:00
|
|
|
'phabricator-ui-example-css' => '528b19de',
|
2014-01-01 16:46:25 +01:00
|
|
|
'phabricator-uiexample-javelin-view' => 'd4a14807',
|
2014-06-23 19:35:39 +02:00
|
|
|
'phabricator-uiexample-reactor-button' => 'd19198c8',
|
2014-06-23 19:27:47 +02:00
|
|
|
'phabricator-uiexample-reactor-checkbox' => '519705ea',
|
|
|
|
'phabricator-uiexample-reactor-focus' => '40a6a403',
|
|
|
|
'phabricator-uiexample-reactor-input' => '886fd850',
|
2014-06-23 19:35:39 +02:00
|
|
|
'phabricator-uiexample-reactor-mouseover' => '47c794d8',
|
2014-06-23 19:27:47 +02:00
|
|
|
'phabricator-uiexample-reactor-radio' => '988040b4',
|
|
|
|
'phabricator-uiexample-reactor-select' => 'a155550f',
|
|
|
|
'phabricator-uiexample-reactor-sendclass' => '1def2711',
|
|
|
|
'phabricator-uiexample-reactor-sendproperties' => 'b1f0ccee',
|
Conpherence - make the durable column kind of work and stuff
Summary:
Ref T7014. This hooks up the durable column such that when you open it up it loads your most recent Conpherence. You can then switch amongst the various widgets and stuff and everything works nicely.
Except...
- scroll bar does not work
- also doesn't work at HEAD when I add a ton of text to the UI with no changes? (wrapped $copy in array_fill(0, 1000, $copy))
- "widget selector" does not collapse when you select something else
- this part wasn't really specified so I used the aphlict dropdown stuff. didn't want to keep working on that if this was the wrong UI choice
- can not edit title
- do we still want that to be done by clicking on the title, which pops a dialogue?
- can not add participants or calendar events
- what should this UI be? maybe just a button on the top for "participants" and a button on the bottom for calendar? both on top?
- this is not pixel perfect to the mock or two I've seen around. Aside from generally being bad at that, I definitely didn't get the name + timestamps formatting correctly, because the standard DOM of that has timestamp FIRST which appears second due to a "float right". Seemed like a lot of special-casing for what might not even be that important in the UI so I punted. (And again, there's likely many unknown ways in which this isn't pixel perfect)
There's also code quality issues
- `ConpherenceWidgetConfigConstants` is hopefully temporary or at least gets more sleek as we keep progressing here
- copied some CSS from main Conpherence app
- DOM structure is pretty different
- there's some minor CSS tweaks too given the different width (not to mention the DOM structure being different)
- copied some JS from behavior-pontificate.js to sync threads relative to aphlict updates
- JS in general is like a better version of existing JS; these should collapse I'd hope?
- maybe the aphlict-behavior-dropdown change was badsauce?
...but all that said, this definitely feels really nice and I feel like adding stuff is going to be really easy compared to how normal Conpherence is.
Also includes a bonus bug fix - we now correctly update participation. The user would encounter this issue if they were in a conpherence that got some updates and then they went to a different page; they would have unread status for the messages that were ajax'd in. This patch fixes that by making sure we mark participation up to date with the proper transaction in all cases.
Test Plan: hit "\" to invoke the column and saw nice loading UI and my latest conpherence load. sent messages and verified they received A-OK by looking in DOM console. toggled various widges and verified they rendered correctly. opened up a second browser with a second user on the thread, sent a message, and it was received in a nice asynchronous fashion
Reviewers: chad, epriestley
Reviewed By: epriestley
Subscribers: Korvin, epriestley
Maniphest Tasks: T7014
Differential Revision: https://secure.phabricator.com/D11968
2015-03-05 19:33:39 +01:00
|
|
|
'phabricator-zindex-css' => '9ec70c03',
|
2015-03-01 23:45:56 +01:00
|
|
|
'phame-css' => '88bd4705',
|
2014-10-21 19:06:10 +02:00
|
|
|
'pholio-css' => '95174bdd',
|
2014-06-16 00:00:43 +02:00
|
|
|
'pholio-edit-css' => '3ad9d1ee',
|
2014-06-25 00:23:57 +02:00
|
|
|
'pholio-inline-comments-css' => '8e545e49',
|
2014-01-01 16:46:25 +01:00
|
|
|
'phortune-credit-card-form' => '2290aeef',
|
2015-03-02 22:01:08 +01:00
|
|
|
'phortune-credit-card-form-css' => '8391eb02',
|
2014-07-23 19:36:37 +02:00
|
|
|
'phortune-css' => '9149f103',
|
2014-01-06 06:47:21 +01:00
|
|
|
'phrequent-css' => 'ffc185ad',
|
2015-02-27 21:04:41 +01:00
|
|
|
'phriction-document-css' => '0d16bc9a',
|
2014-11-04 20:11:15 +01:00
|
|
|
'phui-action-header-view-css' => '89c497e7',
|
2015-02-21 15:38:27 +01:00
|
|
|
'phui-action-panel-css' => '3ee9afd5',
|
2014-04-18 15:44:45 +02:00
|
|
|
'phui-box-css' => '7b3a2eed',
|
2015-02-26 18:26:36 +01:00
|
|
|
'phui-button-css' => '21cb97f9',
|
2014-10-15 19:33:26 +02:00
|
|
|
'phui-calendar-css' => '8675968e',
|
2014-02-24 19:04:23 +01:00
|
|
|
'phui-calendar-day-css' => 'de035c8a',
|
|
|
|
'phui-calendar-list-css' => 'c1d0ca59',
|
Fixing z-index on calendar date badges.
Summary: Fixes T4787, decreased z-index on calendar badges so that they don't sit on top of notification dropdowns when dropdowns are expanded. Not sure why the badges had z-index 10, but please let me know if there was a more substantial reason for this.
Test Plan: If neither notification dropdowns have content, create enough messages to populate at least 5 rows, open calendar, expand messages dropdown, verify that underlying calendar date badges do not appear over the dropdown.
Reviewers: chad, #blessed_reviewers, epriestley
Reviewed By: #blessed_reviewers, epriestley
Subscribers: epriestley, Korvin
Maniphest Tasks: T4787
Differential Revision: https://secure.phabricator.com/D8770
2014-04-13 17:18:16 +02:00
|
|
|
'phui-calendar-month-css' => 'a92e47d2',
|
2015-02-02 19:34:42 +01:00
|
|
|
'phui-crumbs-view-css' => '594d719e',
|
2015-03-03 00:42:25 +01:00
|
|
|
'phui-document-view-css' => '0f83a7df',
|
2015-01-25 23:14:41 +01:00
|
|
|
'phui-feed-story-css' => 'c9f3a0b5',
|
2014-10-15 19:33:26 +02:00
|
|
|
'phui-font-icon-base-css' => '3dad2ae3',
|
2015-03-03 00:42:25 +01:00
|
|
|
'phui-fontkit-css' => 'd30f4fa3',
|
2015-02-26 18:26:36 +01:00
|
|
|
'phui-form-css' => 'f535f938',
|
2015-03-02 22:01:08 +01:00
|
|
|
'phui-form-view-css' => '76f0b086',
|
2015-01-14 01:10:57 +01:00
|
|
|
'phui-header-view-css' => '083669db',
|
2015-01-26 17:19:22 +01:00
|
|
|
'phui-icon-view-css' => 'd35aa857',
|
2014-06-19 20:28:01 +02:00
|
|
|
'phui-image-mask-css' => '5a8b09c8',
|
2014-01-01 16:46:25 +01:00
|
|
|
'phui-info-panel-css' => '27ea50a1',
|
2015-03-02 18:01:04 +01:00
|
|
|
'phui-info-view-css' => '6c6cc4dd',
|
2014-12-30 11:48:53 +01:00
|
|
|
'phui-list-view-css' => '53deb25c',
|
2015-03-01 23:45:56 +01:00
|
|
|
'phui-object-box-css' => 'd68ce5dc',
|
|
|
|
'phui-object-item-list-view-css' => '9db65899',
|
2014-06-27 18:39:13 +02:00
|
|
|
'phui-pinboard-view-css' => '3dd4a269',
|
2014-12-18 23:42:26 +01:00
|
|
|
'phui-property-list-view-css' => '51480060',
|
2014-01-01 16:46:25 +01:00
|
|
|
'phui-remarkup-preview-css' => '19ad512b',
|
|
|
|
'phui-spacing-css' => '042804d6',
|
2014-10-16 22:12:03 +02:00
|
|
|
'phui-status-list-view-css' => '888cedb8',
|
2015-02-18 20:28:11 +01:00
|
|
|
'phui-tag-view-css' => 'ea469f3a',
|
2014-10-15 19:33:26 +02:00
|
|
|
'phui-text-css' => 'cf019f54',
|
2015-02-02 18:40:46 +01:00
|
|
|
'phui-timeline-view-css' => 'b0fbc4d7',
|
2015-01-12 19:04:01 +01:00
|
|
|
'phui-workboard-view-css' => '8896938c',
|
2014-12-30 11:48:53 +01:00
|
|
|
'phui-workpanel-view-css' => 'e495a5cc',
|
2014-05-05 19:57:23 +02:00
|
|
|
'phuix-action-list-view' => 'b5c256b8',
|
2014-05-19 01:10:54 +02:00
|
|
|
'phuix-action-view' => '6e8cefa4',
|
2014-05-05 19:57:23 +02:00
|
|
|
'phuix-dropdown-menu' => 'bd4c8dca',
|
2014-01-01 16:46:25 +01:00
|
|
|
'policy-css' => '957ea14c',
|
2014-11-17 23:06:05 +01:00
|
|
|
'policy-edit-css' => '815c66f7',
|
2014-04-29 19:43:38 +02:00
|
|
|
'policy-transaction-detail-css' => '82100a43',
|
2014-01-01 16:46:25 +01:00
|
|
|
'ponder-comment-table-css' => '6cdccea7',
|
|
|
|
'ponder-feed-view-css' => 'e62615b6',
|
|
|
|
'ponder-post-css' => 'ebab8a70',
|
|
|
|
'ponder-vote-css' => '8ed6ed8b',
|
2014-05-24 06:48:15 +02:00
|
|
|
'project-icon-css' => 'c2ecb7f1',
|
2014-01-01 16:46:25 +01:00
|
|
|
'raphael-core' => '51ee6b43',
|
|
|
|
'raphael-g' => '40dde778',
|
|
|
|
'raphael-g-line' => '40da039e',
|
2014-04-18 15:44:45 +02:00
|
|
|
'releeph-core' => '9b3c5733',
|
2014-04-14 21:06:56 +02:00
|
|
|
'releeph-preview-branch' => 'b7a6f4a5',
|
2014-01-01 16:46:25 +01:00
|
|
|
'releeph-request-differential-create-dialog' => '8d8b92cd',
|
|
|
|
'releeph-request-typeahead-css' => '667a48ae',
|
2015-02-03 18:07:00 +01:00
|
|
|
'setup-issue-css' => '22270af2',
|
2014-06-24 18:39:32 +02:00
|
|
|
'sprite-gradient-css' => '4bdb98a7',
|
2014-10-29 23:06:15 +01:00
|
|
|
'sprite-login-css' => 'a355d921',
|
2015-03-01 21:03:02 +01:00
|
|
|
'sprite-main-header-css' => '28d01b0b',
|
2015-02-19 23:43:33 +01:00
|
|
|
'sprite-menu-css' => '9ef76324',
|
2015-01-14 19:49:36 +01:00
|
|
|
'sprite-projects-css' => 'b0d9e24f',
|
2014-02-17 19:06:16 +01:00
|
|
|
'sprite-tokens-css' => '1706b943',
|
2014-10-31 18:45:11 +01:00
|
|
|
'syntax-highlighting-css' => '56c1ba38',
|
2014-05-05 19:54:34 +02:00
|
|
|
'tokens-css' => '3d0f239e',
|
2015-01-02 22:48:18 +01:00
|
|
|
'unhandled-exception-css' => '37d4f9a2',
|
2014-01-01 03:04:25 +01:00
|
|
|
),
|
2014-07-14 17:33:33 +02:00
|
|
|
'requires' => array(
|
|
|
|
'029a133d' => array(
|
2014-07-23 19:34:08 +02:00
|
|
|
'aphront-dialog-view-css',
|
2014-01-01 16:46:25 +01:00
|
|
|
),
|
2014-07-14 17:33:33 +02:00
|
|
|
'03d6ed07' => array(
|
2014-07-23 19:34:08 +02:00
|
|
|
'javelin-behavior',
|
|
|
|
'javelin-stratcom',
|
|
|
|
'javelin-dom',
|
|
|
|
'javelin-vector',
|
|
|
|
'javelin-install',
|
2014-01-01 03:04:25 +01:00
|
|
|
),
|
2015-01-14 01:10:57 +01:00
|
|
|
'05270951' => array(
|
|
|
|
'javelin-util',
|
|
|
|
'javelin-magical-init',
|
|
|
|
),
|
2014-07-14 17:33:33 +02:00
|
|
|
'065227cc' => array(
|
2014-07-23 19:34:08 +02:00
|
|
|
'javelin-behavior',
|
|
|
|
'javelin-dom',
|
|
|
|
'javelin-stratcom',
|
|
|
|
'javelin-workflow',
|
2014-01-01 03:04:25 +01:00
|
|
|
),
|
Give files uploaded to objects a very restrictive view policy
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
2014-08-02 23:46:13 +02:00
|
|
|
'07f199d8' => array(
|
|
|
|
'javelin-behavior',
|
|
|
|
'javelin-dom',
|
|
|
|
'javelin-uri',
|
|
|
|
'javelin-mask',
|
|
|
|
'phabricator-drag-and-drop-file-upload',
|
|
|
|
),
|
2015-01-03 00:30:00 +01:00
|
|
|
'08883e8b' => array(
|
|
|
|
'javelin-behavior',
|
|
|
|
'javelin-stratcom',
|
|
|
|
'javelin-util',
|
|
|
|
'javelin-dom',
|
|
|
|
'javelin-request',
|
|
|
|
'phabricator-keyboard-shortcut',
|
|
|
|
),
|
2014-07-14 17:33:33 +02:00
|
|
|
'0a3f3021' => array(
|
2014-07-23 19:34:08 +02:00
|
|
|
'javelin-behavior',
|
|
|
|
'javelin-stratcom',
|
|
|
|
'javelin-workflow',
|
|
|
|
'javelin-dom',
|
|
|
|
'javelin-router',
|
Provide a global router for Ajax requests
Summary:
Fixes T430. Fixes T4834. Obsoletes D7641. Currently, we do some things less-well than we could:
- We just let the browser queue and prioritize requests, so if you load a revision with 50 changes and then click "Award Token", the action blocks until the changes load in most/all browsers. It would be better to prioritize this action and queue it immediately.
- Similarly, changes tend to load in order, even if the user has clicked to a specific file. When the user expresses a preference for a specific file, we should prioritize it.
- We show a spinning GIF when waiting on requests. This is appropriate for some types of reuqests, but distracting for others.
To fix this:
- Queue all (or, at least, most) requests into a new queue in JX.Router.
- JX.Router handles prioritizing the requests. Principally:
- You can submit a request with a specific priority (500 = general content loading, 1000 = default, 2000 = explicit user action) and JX.Router will get the higher stuff fired off sooner.
- You can name requests and then adjust their prorities later, if the user expresses an interest in specific results.
- Only use the spinner gif for "workflow" requests, which is bascially when the user clicked something and we're waiting on the server. I think it's useful and not-annoying in this case.
- Don't show any status for draft requests.
- For content requests, show a subtle hipster-style top loading bar.
Test Plan:
- Viewed a diff with 93 changes, and clicked award token.
- Prior to this patch, the action took many many seconds to resolve.
- After this patch, it resolves quickly.
- Viewed a diff with 93 changes and saw a pleasant subtle hipster-style loading bar.
- Viewed a diff with 93 changes and typed some draft text. Previews populated fairly quickly and there was no spinner.
- Viewed a diff with 93 changes and clicked something with workflow, saw a spinner after a moment.
- Viewed a diff with 93 changes and clicked a file in the table of contents near the end of the list.
- Prior to this patch, it took a long time to show up.
- After this patch, it loads directly.
Reviewers: chad, btrahan
Reviewed By: btrahan
Subscribers: epriestley
Maniphest Tasks: T430, T4834
Differential Revision: https://secure.phabricator.com/D8979
2014-05-05 19:57:42 +02:00
|
|
|
),
|
2014-07-14 17:33:33 +02:00
|
|
|
'0c6946e7' => array(
|
2014-07-23 19:34:08 +02:00
|
|
|
'javelin-install',
|
|
|
|
'javelin-dom',
|
|
|
|
'javelin-stratcom',
|
|
|
|
'javelin-util',
|
|
|
|
'phabricator-notification-css',
|
2014-02-27 20:06:55 +01:00
|
|
|
),
|
2014-07-14 17:33:33 +02:00
|
|
|
'0ec56e1d' => array(
|
2014-07-23 19:34:08 +02:00
|
|
|
'javelin-behavior',
|
|
|
|
'javelin-dom',
|
|
|
|
'javelin-stratcom',
|
|
|
|
'phuix-dropdown-menu',
|
2014-06-25 21:30:53 +02:00
|
|
|
),
|
2014-07-14 17:33:33 +02:00
|
|
|
'0f764c35' => array(
|
2014-07-23 19:34:08 +02:00
|
|
|
'javelin-install',
|
|
|
|
'javelin-util',
|
2014-02-27 20:06:55 +01:00
|
|
|
),
|
2014-08-08 00:21:32 +02:00
|
|
|
'13c739ea' => array(
|
|
|
|
'javelin-behavior',
|
|
|
|
'javelin-stratcom',
|
|
|
|
'javelin-workflow',
|
|
|
|
'javelin-dom',
|
|
|
|
'javelin-uri',
|
|
|
|
'phabricator-textareautils',
|
|
|
|
),
|
2014-12-30 11:50:26 +01:00
|
|
|
'1499a8cb' => array(
|
|
|
|
'javelin-behavior',
|
|
|
|
'javelin-stratcom',
|
|
|
|
'javelin-dom',
|
|
|
|
'javelin-history',
|
|
|
|
),
|
2014-07-14 17:33:33 +02:00
|
|
|
'14a827de' => array(
|
2014-07-23 19:34:08 +02:00
|
|
|
'javelin-behavior',
|
|
|
|
'javelin-stratcom',
|
|
|
|
'javelin-dom',
|
|
|
|
'javelin-json',
|
|
|
|
'phabricator-draggable-list',
|
2014-01-01 16:46:25 +01:00
|
|
|
),
|
2014-07-14 17:33:33 +02:00
|
|
|
'14d7a8b8' => array(
|
2014-07-23 19:34:08 +02:00
|
|
|
'javelin-behavior',
|
|
|
|
'javelin-behavior-device',
|
|
|
|
'javelin-stratcom',
|
|
|
|
'javelin-dom',
|
|
|
|
'javelin-magical-init',
|
|
|
|
'javelin-vector',
|
|
|
|
'javelin-request',
|
|
|
|
'javelin-util',
|
2014-02-27 20:06:55 +01:00
|
|
|
),
|
2015-01-14 01:10:57 +01:00
|
|
|
'1ad0a787' => array(
|
2015-01-13 21:03:48 +01:00
|
|
|
'javelin-install',
|
2015-01-14 01:10:57 +01:00
|
|
|
'javelin-reactor',
|
|
|
|
'javelin-util',
|
|
|
|
'javelin-reactor-node-calmer',
|
2015-01-13 21:03:48 +01:00
|
|
|
),
|
2014-07-14 17:33:33 +02:00
|
|
|
'1ae869f2' => array(
|
2014-07-23 19:34:08 +02:00
|
|
|
'javelin-install',
|
|
|
|
'javelin-util',
|
|
|
|
'phabricator-keyboard-shortcut-manager',
|
2014-01-01 03:04:25 +01:00
|
|
|
),
|
2015-01-20 01:55:08 +01:00
|
|
|
'1d298e3a' => array(
|
|
|
|
'javelin-install',
|
|
|
|
'javelin-util',
|
|
|
|
'javelin-dom',
|
|
|
|
'javelin-vector',
|
|
|
|
),
|
2014-07-14 17:33:33 +02:00
|
|
|
'1def2711' => array(
|
2014-07-23 19:34:08 +02:00
|
|
|
'javelin-install',
|
|
|
|
'javelin-dom',
|
|
|
|
'javelin-reactor-dom',
|
2014-06-20 20:49:41 +02:00
|
|
|
),
|
Make "Show Context" persist rendering, whitespace, encoding, etc
Summary:
Ref T2009. Currently, we do not persist view parameters when making context rendering requests.
The big one is the renderer (1up vs 2up). This makes context on unified diffs come in with too many columns.
However, it impacts other parameters too. For example, at HEAD, if you change highlighting to "rainbow" and then load more context, the context uses the original highlighter instead of the rainbow highlighter.
This moves context loads into ChangesetViewManager, which maintains view parameters and can provide them correctly.
- This removes "ref"; it is no longer required, as the ChangesetViewManager tracks it.
- This removes URI management from `behavior-show-more`; it is no longer required, since the ChangesetViewManager knows how to render.
- This removes "whitespace" since this is handled properly by the view manager.
Test Plan:
- Used "Show Top" / "Show All" / "Show Bottom" in 1-up and 2-up views.
- Changed file highlighting to rainbow, loaded stuff, saw rainbow stick.
- Used "Show Entire File" in 1-up and 2-up views.
- Saw loading chrome.
- No loading chrome normally.
- Made inlines, verified `copyRows()` code runs.
- Poked around Diffusion -- it is missing some parameter handling, but works OK.
Reviewers: btrahan
Reviewed By: btrahan
Subscribers: epriestley
Maniphest Tasks: T2009
Differential Revision: https://secure.phabricator.com/D11977
2015-03-05 23:03:00 +01:00
|
|
|
'2035b9cb' => array(
|
|
|
|
'javelin-behavior',
|
|
|
|
'javelin-dom',
|
|
|
|
'javelin-util',
|
|
|
|
'javelin-stratcom',
|
|
|
|
'javelin-workflow',
|
|
|
|
'phuix-dropdown-menu',
|
|
|
|
'phuix-action-list-view',
|
|
|
|
'phuix-action-view',
|
|
|
|
'phabricator-phtize',
|
|
|
|
'changeset-view-manager',
|
|
|
|
),
|
2014-07-14 17:33:33 +02:00
|
|
|
'2290aeef' => array(
|
2014-07-23 19:34:08 +02:00
|
|
|
'javelin-install',
|
|
|
|
'javelin-dom',
|
|
|
|
'javelin-json',
|
|
|
|
'javelin-workflow',
|
|
|
|
'javelin-util',
|
2014-01-01 03:04:25 +01:00
|
|
|
),
|
2015-01-20 01:55:08 +01:00
|
|
|
'2818f5ce' => array(
|
|
|
|
'javelin-install',
|
|
|
|
'javelin-util',
|
|
|
|
'javelin-dom',
|
|
|
|
'javelin-typeahead-normalizer',
|
|
|
|
),
|
2014-07-14 17:33:33 +02:00
|
|
|
'2926fff2' => array(
|
2014-07-23 19:34:08 +02:00
|
|
|
'javelin-behavior',
|
|
|
|
'javelin-dom',
|
2014-01-01 03:04:25 +01:00
|
|
|
),
|
2014-07-14 17:33:33 +02:00
|
|
|
'29274e2b' => array(
|
2014-07-23 19:34:08 +02:00
|
|
|
'javelin-install',
|
|
|
|
'javelin-util',
|
Provide a global router for Ajax requests
Summary:
Fixes T430. Fixes T4834. Obsoletes D7641. Currently, we do some things less-well than we could:
- We just let the browser queue and prioritize requests, so if you load a revision with 50 changes and then click "Award Token", the action blocks until the changes load in most/all browsers. It would be better to prioritize this action and queue it immediately.
- Similarly, changes tend to load in order, even if the user has clicked to a specific file. When the user expresses a preference for a specific file, we should prioritize it.
- We show a spinning GIF when waiting on requests. This is appropriate for some types of reuqests, but distracting for others.
To fix this:
- Queue all (or, at least, most) requests into a new queue in JX.Router.
- JX.Router handles prioritizing the requests. Principally:
- You can submit a request with a specific priority (500 = general content loading, 1000 = default, 2000 = explicit user action) and JX.Router will get the higher stuff fired off sooner.
- You can name requests and then adjust their prorities later, if the user expresses an interest in specific results.
- Only use the spinner gif for "workflow" requests, which is bascially when the user clicked something and we're waiting on the server. I think it's useful and not-annoying in this case.
- Don't show any status for draft requests.
- For content requests, show a subtle hipster-style top loading bar.
Test Plan:
- Viewed a diff with 93 changes, and clicked award token.
- Prior to this patch, the action took many many seconds to resolve.
- After this patch, it resolves quickly.
- Viewed a diff with 93 changes and saw a pleasant subtle hipster-style loading bar.
- Viewed a diff with 93 changes and typed some draft text. Previews populated fairly quickly and there was no spinner.
- Viewed a diff with 93 changes and clicked something with workflow, saw a spinner after a moment.
- Viewed a diff with 93 changes and clicked a file in the table of contents near the end of the list.
- Prior to this patch, it took a long time to show up.
- After this patch, it loads directly.
Reviewers: chad, btrahan
Reviewed By: btrahan
Subscribers: epriestley
Maniphest Tasks: T430, T4834
Differential Revision: https://secure.phabricator.com/D8979
2014-05-05 19:57:42 +02:00
|
|
|
),
|
2014-07-14 17:33:33 +02:00
|
|
|
'2b228192' => array(
|
2014-07-23 19:34:08 +02:00
|
|
|
'javelin-behavior',
|
|
|
|
'javelin-dom',
|
|
|
|
'javelin-util',
|
|
|
|
'javelin-workflow',
|
|
|
|
'javelin-json',
|
2014-05-12 20:53:31 +02:00
|
|
|
),
|
2015-01-14 01:10:57 +01:00
|
|
|
'2b8de964' => array(
|
|
|
|
'javelin-install',
|
|
|
|
'javelin-util',
|
|
|
|
),
|
Multiplex AJAX calls
Summary: Fixes T5344. Essentially, we only make the AJAX request to `/notification/individual/` if we are the leader tab (i.e. only one tab will make this request). Once a response has been received from the server (containing the contents of the notification), we broadcast the message contents back to all other tabs for rendering.
Test Plan:
Opened two tabs on `/notification/status/` and clicked "Send Test Notification".
**Before**
```lang=bash, name=tail -f /var/log/phabricator-access.log | grep /notification/individual/
[Tue, 13 Jan 2015 20:10:37 +1100] 17033 phabricator 10.0.0.1 josh PhabricatorNotificationIndividualController - /notification/individual/-200 236036
[Tue, 13 Jan 2015 20:10:37 +1100] 17657 phabricator 10.0.0.1 josh PhabricatorNotificationIndividualController - /notification/individual/-200 24130
```
**After**
```lang=bash, name=tail -f /var/log/phabricator-access.log | grep /notification/individual/
[Tue, 13 Jan 2015 20:11:15 +1100] 17657 phabricator 10.0.0.1 josh PhabricatorNotificationIndividualController - /notification/individual/-200 180217
```
Reviewers: #blessed_reviewers, epriestley
Reviewed By: #blessed_reviewers, epriestley
Subscribers: Korvin, epriestley
Maniphest Tasks: T5344
Differential Revision: https://secure.phabricator.com/D11360
2015-01-15 21:05:31 +01:00
|
|
|
'2be71d56' => array(
|
|
|
|
'javelin-install',
|
|
|
|
'javelin-util',
|
|
|
|
'javelin-websocket',
|
|
|
|
'javelin-leader',
|
|
|
|
'javelin-json',
|
|
|
|
),
|
2014-08-01 21:29:48 +02:00
|
|
|
'2bfa2836' => array(
|
|
|
|
'javelin-behavior',
|
|
|
|
'javelin-stratcom',
|
|
|
|
'javelin-dom',
|
|
|
|
),
|
2014-11-12 21:26:22 +01:00
|
|
|
'2c426492' => array(
|
|
|
|
'javelin-behavior',
|
|
|
|
'javelin-dom',
|
|
|
|
'javelin-stratcom',
|
|
|
|
'phabricator-keyboard-shortcut',
|
|
|
|
),
|
2015-01-28 17:26:10 +01:00
|
|
|
'2caa8fb8' => array(
|
2015-01-26 18:34:57 +01:00
|
|
|
'javelin-install',
|
2015-01-28 17:26:10 +01:00
|
|
|
'javelin-event',
|
2015-01-26 18:34:57 +01:00
|
|
|
),
|
Quicksand, an ignoble successor to Quickling
Summary:
Ref T2086. Ref T7014. With the persistent column, there is significant value in retaining chrome state through navigation events, because the user may have a lot of state in the chat window (scroll position, text selection, room juggling, partially entered text, etc). We can do this by capturing navigation events and faking them with Javascript.
(This can also improve performance, albeit slightly, and I believe there are better approaches to tackle performance any problems which exist with the chrome in many cases).
At Facebook, this system was "Photostream" in photos and then "Quickling" in general, and the technical cost of the system was //staggering//. I am loathe to pursue it again. However:
- Browsers are less junky now, and we target a smaller set of browsers. A large part of the technical cost of Quickling was the high complexity of emulating nagivation events in IE, where we needed to navigate a hidden iframe to make history entries. All desktop browsers which we might want to use this system on support the History API (although this prototype does not yet implement it).
- Javelin and Phabricator's architecture are much cleaner than Facebook's was. A large part of the technical cost of Quickling was inconsistency, inlined `onclick` handlers, and general lack of coordination and abstraction. We will have //some// of this, but "correctly written" behaviors are mostly immune to it by design, and many of Javelin's architectural decisions were influenced by desire to avoid issues we encountered building this stuff for Facebook.
- Some of the primitives which Quickling required (like loading resources over Ajax) have existed in a stable state in our codebase for a year or more, and adoption of these primitives was trivial and uneventful (vs a huge production at Facebook).
- My hubris is bolstered by recent success with WebSockets and JX.Scrollbar, both of which I would have assessed as infeasibly complex to develop in this project a few years ago.
To these points, the developer cost to prototype Photostream was several weeks; the developer cost to prototype this was a bit less than an hour. It is plausible to me that implementing and maintaining this system really will be hundreds of times less complex than it was at Facebook.
Test Plan:
My plan for this and D11497 is:
- Get them in master.
- Some secret key / relatively-hidden preference activates the column.
- Quicksand activates //only// when the column is open.
- We can use column + quicksand for a long period of time (i.e., over the course of Conpherence v2 development) and hammer out the long tail of issues.
- When it derps up, you just hide the column and you're good to go.
Reviewers: btrahan, chad
Reviewed By: chad
Subscribers: epriestley
Maniphest Tasks: T2086, T7014
Differential Revision: https://secure.phabricator.com/D11507
2015-01-27 23:52:09 +01:00
|
|
|
'2e0148bc' => array(
|
|
|
|
'javelin-stratcom',
|
|
|
|
'javelin-install',
|
|
|
|
'javelin-uri',
|
|
|
|
'javelin-util',
|
|
|
|
),
|
2014-07-14 17:33:33 +02:00
|
|
|
'316b8fa1' => array(
|
2014-07-23 19:34:08 +02:00
|
|
|
'javelin-install',
|
|
|
|
'javelin-typeahead-source',
|
Introduce CAN_EDIT for ExternalAccount, and make CAN_VIEW more liberal
Summary:
Fixes T3732. Ref T1205. Ref T3116.
External accounts (like emails used as identities, Facebook accounts, LDAP accounts, etc.) are stored in "ExternalAccount" objects.
Currently, we have a very restrictive `CAN_VIEW` policy for ExternalAccounts, to add an extra layer of protection to make sure users can't use them in unintended ways. For example, it would be bad if a user could link their Phabricator account to a Facebook account without proper authentication. All of the controllers which do sensitive things have checks anyway, but a restrictive CAN_VIEW provided an extra layer of protection. Se T3116 for some discussion.
However, this means that when grey/external users take actions (via email, or via applications like Legalpad) other users can't load the account handles and can't see anything about the actor (they just see "Restricted External Account" or similar).
Balancing these concerns is mostly about not making a huge mess while doing it. This seems like a reasonable approach:
- Add `CAN_EDIT` on these objects.
- Make that very restricted, but open up `CAN_VIEW`.
- Require `CAN_EDIT` any time we're going to do something authentication/identity related.
This is slightly easier to get wrong (forget CAN_EDIT) than other approaches, but pretty simple, and we always have extra checks in place anyway -- this is just a safety net.
I'm not quite sure how we should identify external accounts, so for now we're just rendering "Email User" or similar -- clearly not a bug, but not identifying. We can figure out what to render in the long term elsewhere.
Test Plan:
- Viewed external accounts.
- Linked an external account.
- Refreshed an external account.
- Edited profile picture.
- Viewed sessions panel.
- Published a bunch of stuff to Asana/JIRA.
- Legalpad signature page now shows external accounts.
{F171595}
Reviewers: chad, btrahan
Reviewed By: btrahan
Subscribers: epriestley
Maniphest Tasks: T3732, T1205, T3116
Differential Revision: https://secure.phabricator.com/D9767
2014-07-10 19:18:10 +02:00
|
|
|
),
|
2015-01-22 21:22:26 +01:00
|
|
|
'331b1611' => array(
|
|
|
|
'javelin-install',
|
|
|
|
),
|
2014-07-14 17:33:33 +02:00
|
|
|
'3ab51e2c' => array(
|
2014-07-23 19:34:08 +02:00
|
|
|
'javelin-behavior',
|
|
|
|
'javelin-behavior-device',
|
|
|
|
'javelin-stratcom',
|
|
|
|
'javelin-vector',
|
|
|
|
'javelin-dom',
|
|
|
|
'javelin-magical-init',
|
2014-06-23 19:27:47 +02:00
|
|
|
),
|
2015-03-02 22:01:00 +01:00
|
|
|
'3cb0b2fc' => array(
|
2014-07-23 19:34:08 +02:00
|
|
|
'javelin-behavior',
|
|
|
|
'javelin-dom',
|
|
|
|
'javelin-stratcom',
|
|
|
|
'javelin-workflow',
|
|
|
|
'javelin-util',
|
|
|
|
'javelin-uri',
|
2014-06-23 19:27:47 +02:00
|
|
|
),
|
2014-07-14 17:33:33 +02:00
|
|
|
'3ee3408b' => array(
|
2014-07-23 19:34:08 +02:00
|
|
|
'javelin-behavior',
|
|
|
|
'javelin-behavior-device',
|
|
|
|
'javelin-stratcom',
|
|
|
|
'phabricator-tooltip',
|
2014-06-26 18:41:07 +02:00
|
|
|
),
|
2014-12-30 11:53:27 +01:00
|
|
|
'3f5d6dbf' => array(
|
|
|
|
'javelin-behavior',
|
|
|
|
'javelin-dom',
|
|
|
|
'phortune-credit-card-form',
|
|
|
|
),
|
2014-07-14 17:33:33 +02:00
|
|
|
'40a6a403' => array(
|
2014-07-23 19:34:08 +02:00
|
|
|
'javelin-install',
|
|
|
|
'javelin-dom',
|
|
|
|
'javelin-reactor-dom',
|
2014-06-16 21:27:12 +02:00
|
|
|
),
|
2014-07-14 17:33:33 +02:00
|
|
|
'40b1ff90' => array(
|
2014-07-23 19:34:08 +02:00
|
|
|
'javelin-behavior',
|
|
|
|
'javelin-dom',
|
|
|
|
'javelin-stratcom',
|
|
|
|
'javelin-workflow',
|
|
|
|
'javelin-util',
|
|
|
|
'phabricator-notification',
|
|
|
|
'javelin-behavior-device',
|
|
|
|
'phuix-dropdown-menu',
|
|
|
|
'phuix-action-list-view',
|
|
|
|
'phuix-action-view',
|
2014-05-05 19:57:23 +02:00
|
|
|
),
|
2015-03-05 23:11:51 +01:00
|
|
|
'41060c54' => array(
|
|
|
|
'javelin-dom',
|
|
|
|
'javelin-util',
|
|
|
|
'javelin-stratcom',
|
|
|
|
'javelin-install',
|
|
|
|
'javelin-request',
|
|
|
|
'javelin-workflow',
|
|
|
|
),
|
2015-01-04 22:23:22 +01:00
|
|
|
42126667 => array(
|
|
|
|
'javelin-behavior',
|
|
|
|
'javelin-dom',
|
|
|
|
'javelin-request',
|
|
|
|
),
|
2014-07-14 17:33:33 +02:00
|
|
|
'44168bad' => array(
|
2014-07-23 19:34:08 +02:00
|
|
|
'javelin-behavior',
|
|
|
|
'javelin-dom',
|
|
|
|
'phabricator-prefab',
|
2014-03-12 19:29:48 +01:00
|
|
|
),
|
2015-01-14 01:10:57 +01:00
|
|
|
'44959b73' => array(
|
|
|
|
'javelin-util',
|
|
|
|
'javelin-uri',
|
|
|
|
'javelin-install',
|
|
|
|
),
|
2014-07-14 17:33:33 +02:00
|
|
|
'453c5375' => array(
|
2014-07-23 19:34:08 +02:00
|
|
|
'javelin-behavior',
|
|
|
|
'javelin-dom',
|
2014-07-13 18:18:50 +02:00
|
|
|
),
|
2014-07-14 17:33:33 +02:00
|
|
|
'469c0d9e' => array(
|
2014-07-23 19:34:08 +02:00
|
|
|
'javelin-behavior',
|
|
|
|
'javelin-dom',
|
|
|
|
'javelin-workflow',
|
2014-01-01 03:04:25 +01:00
|
|
|
),
|
2015-01-14 01:10:57 +01:00
|
|
|
47830651 => array(
|
|
|
|
'javelin-behavior',
|
|
|
|
'javelin-dom',
|
|
|
|
'javelin-view-renderer',
|
|
|
|
'javelin-install',
|
|
|
|
),
|
2014-07-14 17:33:33 +02:00
|
|
|
'47c794d8' => array(
|
2014-07-23 19:34:08 +02:00
|
|
|
'javelin-install',
|
|
|
|
'javelin-dom',
|
|
|
|
'javelin-reactor-dom',
|
2014-06-23 19:35:39 +02:00
|
|
|
),
|
2015-01-04 22:23:22 +01:00
|
|
|
48086888 => array(
|
|
|
|
'javelin-behavior',
|
|
|
|
'javelin-dom',
|
|
|
|
'javelin-workflow',
|
|
|
|
),
|
2014-11-03 17:20:15 +01:00
|
|
|
'49b73b36' => array(
|
|
|
|
'javelin-behavior',
|
|
|
|
'javelin-dom',
|
|
|
|
'javelin-request',
|
|
|
|
'javelin-util',
|
|
|
|
),
|
2014-07-14 17:33:33 +02:00
|
|
|
'4d94d9c3' => array(
|
2014-07-23 19:34:08 +02:00
|
|
|
'javelin-behavior',
|
|
|
|
'javelin-stratcom',
|
|
|
|
'javelin-dom',
|
|
|
|
'phuix-dropdown-menu',
|
2014-05-05 19:57:23 +02:00
|
|
|
),
|
2014-07-14 17:33:33 +02:00
|
|
|
'4e3e79a6' => array(
|
2014-07-23 19:34:08 +02:00
|
|
|
'javelin-behavior',
|
|
|
|
'javelin-stratcom',
|
|
|
|
'javelin-dom',
|
2014-06-23 19:27:47 +02:00
|
|
|
),
|
2014-07-14 17:33:33 +02:00
|
|
|
'4e9b766b' => array(
|
2014-07-23 19:34:08 +02:00
|
|
|
'javelin-behavior',
|
|
|
|
'javelin-dom',
|
|
|
|
'javelin-util',
|
|
|
|
'javelin-stratcom',
|
|
|
|
'javelin-request',
|
2014-01-01 03:04:25 +01:00
|
|
|
),
|
2014-07-14 17:33:33 +02:00
|
|
|
'4fdb476d' => array(
|
2014-07-23 19:34:08 +02:00
|
|
|
'javelin-behavior',
|
|
|
|
'javelin-stratcom',
|
|
|
|
'javelin-dom',
|
2014-07-01 20:04:05 +02:00
|
|
|
),
|
2014-07-14 17:33:33 +02:00
|
|
|
'503e17fd' => array(
|
2014-07-23 19:34:08 +02:00
|
|
|
'javelin-install',
|
|
|
|
'javelin-typeahead-source',
|
|
|
|
'javelin-util',
|
Introduce CAN_EDIT for ExternalAccount, and make CAN_VIEW more liberal
Summary:
Fixes T3732. Ref T1205. Ref T3116.
External accounts (like emails used as identities, Facebook accounts, LDAP accounts, etc.) are stored in "ExternalAccount" objects.
Currently, we have a very restrictive `CAN_VIEW` policy for ExternalAccounts, to add an extra layer of protection to make sure users can't use them in unintended ways. For example, it would be bad if a user could link their Phabricator account to a Facebook account without proper authentication. All of the controllers which do sensitive things have checks anyway, but a restrictive CAN_VIEW provided an extra layer of protection. Se T3116 for some discussion.
However, this means that when grey/external users take actions (via email, or via applications like Legalpad) other users can't load the account handles and can't see anything about the actor (they just see "Restricted External Account" or similar).
Balancing these concerns is mostly about not making a huge mess while doing it. This seems like a reasonable approach:
- Add `CAN_EDIT` on these objects.
- Make that very restricted, but open up `CAN_VIEW`.
- Require `CAN_EDIT` any time we're going to do something authentication/identity related.
This is slightly easier to get wrong (forget CAN_EDIT) than other approaches, but pretty simple, and we always have extra checks in place anyway -- this is just a safety net.
I'm not quite sure how we should identify external accounts, so for now we're just rendering "Email User" or similar -- clearly not a bug, but not identifying. We can figure out what to render in the long term elsewhere.
Test Plan:
- Viewed external accounts.
- Linked an external account.
- Refreshed an external account.
- Edited profile picture.
- Viewed sessions panel.
- Published a bunch of stuff to Asana/JIRA.
- Legalpad signature page now shows external accounts.
{F171595}
Reviewers: chad, btrahan
Reviewed By: btrahan
Subscribers: epriestley
Maniphest Tasks: T3732, T1205, T3116
Differential Revision: https://secure.phabricator.com/D9767
2014-07-10 19:18:10 +02:00
|
|
|
),
|
2014-07-14 17:33:33 +02:00
|
|
|
'519705ea' => array(
|
2014-07-23 19:34:08 +02:00
|
|
|
'javelin-install',
|
|
|
|
'javelin-dom',
|
|
|
|
'javelin-reactor-dom',
|
2014-02-27 20:06:55 +01:00
|
|
|
),
|
2014-07-14 17:33:33 +02:00
|
|
|
'54b612ba' => array(
|
2014-07-23 19:34:08 +02:00
|
|
|
'javelin-color',
|
|
|
|
'javelin-install',
|
|
|
|
'javelin-util',
|
2014-01-01 03:04:25 +01:00
|
|
|
),
|
2014-07-14 17:33:33 +02:00
|
|
|
'54f314a0' => array(
|
2014-07-23 19:34:08 +02:00
|
|
|
'javelin-install',
|
|
|
|
'javelin-util',
|
|
|
|
'javelin-request',
|
|
|
|
'javelin-typeahead-source',
|
Introduce CAN_EDIT for ExternalAccount, and make CAN_VIEW more liberal
Summary:
Fixes T3732. Ref T1205. Ref T3116.
External accounts (like emails used as identities, Facebook accounts, LDAP accounts, etc.) are stored in "ExternalAccount" objects.
Currently, we have a very restrictive `CAN_VIEW` policy for ExternalAccounts, to add an extra layer of protection to make sure users can't use them in unintended ways. For example, it would be bad if a user could link their Phabricator account to a Facebook account without proper authentication. All of the controllers which do sensitive things have checks anyway, but a restrictive CAN_VIEW provided an extra layer of protection. Se T3116 for some discussion.
However, this means that when grey/external users take actions (via email, or via applications like Legalpad) other users can't load the account handles and can't see anything about the actor (they just see "Restricted External Account" or similar).
Balancing these concerns is mostly about not making a huge mess while doing it. This seems like a reasonable approach:
- Add `CAN_EDIT` on these objects.
- Make that very restricted, but open up `CAN_VIEW`.
- Require `CAN_EDIT` any time we're going to do something authentication/identity related.
This is slightly easier to get wrong (forget CAN_EDIT) than other approaches, but pretty simple, and we always have extra checks in place anyway -- this is just a safety net.
I'm not quite sure how we should identify external accounts, so for now we're just rendering "Email User" or similar -- clearly not a bug, but not identifying. We can figure out what to render in the long term elsewhere.
Test Plan:
- Viewed external accounts.
- Linked an external account.
- Refreshed an external account.
- Edited profile picture.
- Viewed sessions panel.
- Published a bunch of stuff to Asana/JIRA.
- Legalpad signature page now shows external accounts.
{F171595}
Reviewers: chad, btrahan
Reviewed By: btrahan
Subscribers: epriestley
Maniphest Tasks: T3732, T1205, T3116
Differential Revision: https://secure.phabricator.com/D9767
2014-07-10 19:18:10 +02:00
|
|
|
),
|
2014-07-14 17:33:33 +02:00
|
|
|
'558829c2' => array(
|
2014-07-23 19:34:08 +02:00
|
|
|
'javelin-stratcom',
|
|
|
|
'javelin-behavior',
|
|
|
|
'javelin-vector',
|
|
|
|
'javelin-dom',
|
2014-06-23 19:27:47 +02:00
|
|
|
),
|
2014-07-14 17:33:33 +02:00
|
|
|
'59b251eb' => array(
|
2014-07-23 19:34:08 +02:00
|
|
|
'javelin-behavior',
|
|
|
|
'javelin-stratcom',
|
|
|
|
'javelin-vector',
|
|
|
|
'javelin-dom',
|
2014-01-01 03:04:25 +01:00
|
|
|
),
|
2015-01-29 16:10:35 +01:00
|
|
|
'5b2f5a08' => array(
|
|
|
|
'javelin-install',
|
|
|
|
'javelin-dom',
|
|
|
|
'javelin-stratcom',
|
|
|
|
'javelin-vector',
|
|
|
|
),
|
2014-07-14 17:33:33 +02:00
|
|
|
'5bc2cb21' => array(
|
2014-07-23 19:34:08 +02:00
|
|
|
'javelin-behavior',
|
|
|
|
'javelin-stratcom',
|
2014-01-01 03:04:25 +01:00
|
|
|
),
|
2014-09-10 19:17:49 +02:00
|
|
|
'5c1c758c' => array(
|
|
|
|
'javelin-install',
|
|
|
|
),
|
2014-08-02 23:44:35 +02:00
|
|
|
'5c54cbf3' => array(
|
|
|
|
'javelin-behavior',
|
|
|
|
'javelin-stratcom',
|
|
|
|
'javelin-dom',
|
|
|
|
),
|
2014-08-19 23:46:37 +02:00
|
|
|
'5c93c52c' => array(
|
|
|
|
'javelin-install',
|
|
|
|
'javelin-dom',
|
|
|
|
'javelin-vector',
|
|
|
|
),
|
2014-07-14 17:33:33 +02:00
|
|
|
'5fefb143' => array(
|
2014-07-23 19:34:08 +02:00
|
|
|
'javelin-behavior',
|
|
|
|
'javelin-dom',
|
|
|
|
'javelin-workflow',
|
|
|
|
'javelin-stratcom',
|
2014-06-23 19:27:47 +02:00
|
|
|
),
|
2015-01-04 22:23:22 +01:00
|
|
|
60479091 => array(
|
|
|
|
'phabricator-busy',
|
|
|
|
'javelin-behavior',
|
|
|
|
),
|
2014-07-14 17:33:33 +02:00
|
|
|
'60821bc7' => array(
|
2014-07-23 19:34:08 +02:00
|
|
|
'javelin-behavior',
|
|
|
|
'javelin-stratcom',
|
|
|
|
'javelin-dom',
|
2014-01-01 03:04:25 +01:00
|
|
|
),
|
2014-07-14 17:33:33 +02:00
|
|
|
'6153c708' => array(
|
2014-07-23 19:34:08 +02:00
|
|
|
'javelin-behavior',
|
|
|
|
'javelin-stratcom',
|
|
|
|
'javelin-dom',
|
|
|
|
'javelin-workflow',
|
2014-06-26 18:41:07 +02:00
|
|
|
),
|
2014-07-14 17:33:33 +02:00
|
|
|
'61cbc29a' => array(
|
2014-07-23 19:34:08 +02:00
|
|
|
'javelin-magical-init',
|
|
|
|
'javelin-util',
|
2014-06-24 00:19:34 +02:00
|
|
|
),
|
2015-01-20 01:55:08 +01:00
|
|
|
'62dfea03' => array(
|
|
|
|
'javelin-install',
|
|
|
|
'javelin-util',
|
|
|
|
),
|
2014-07-14 17:33:33 +02:00
|
|
|
'6453c869' => array(
|
2014-07-23 19:34:08 +02:00
|
|
|
'javelin-install',
|
|
|
|
'javelin-dom',
|
|
|
|
'javelin-fx',
|
2014-05-13 23:09:00 +02:00
|
|
|
),
|
2014-12-30 11:51:31 +01:00
|
|
|
'6882e80a' => array(
|
|
|
|
'javelin-dom',
|
|
|
|
),
|
2014-08-28 22:08:32 +02:00
|
|
|
'6932def3' => array(
|
|
|
|
'javelin-behavior',
|
|
|
|
'javelin-stratcom',
|
|
|
|
'javelin-dom',
|
|
|
|
'javelin-request',
|
|
|
|
'javelin-util',
|
|
|
|
'phabricator-shaped-request',
|
|
|
|
),
|
2014-07-14 17:33:33 +02:00
|
|
|
'69adf288' => array(
|
2014-07-23 19:34:08 +02:00
|
|
|
'javelin-install',
|
2014-05-14 17:53:11 +02:00
|
|
|
),
|
2014-07-14 17:33:33 +02:00
|
|
|
'6c2b09a2' => array(
|
2014-07-23 19:34:08 +02:00
|
|
|
'javelin-install',
|
|
|
|
'javelin-util',
|
2014-01-01 03:04:25 +01:00
|
|
|
),
|
2015-01-28 21:42:05 +01:00
|
|
|
'6c53634d' => array(
|
|
|
|
'javelin-install',
|
|
|
|
'javelin-event',
|
|
|
|
'javelin-util',
|
|
|
|
'javelin-magical-init',
|
|
|
|
),
|
2014-07-14 17:33:33 +02:00
|
|
|
'6d3e1947' => array(
|
2014-07-23 19:34:08 +02:00
|
|
|
'javelin-behavior',
|
|
|
|
'javelin-diffusion-locate-file-source',
|
|
|
|
'javelin-dom',
|
|
|
|
'javelin-typeahead',
|
|
|
|
'javelin-uri',
|
2014-01-01 03:04:25 +01:00
|
|
|
),
|
2015-01-29 23:15:38 +01:00
|
|
|
'6e2de6f2' => array(
|
|
|
|
'multirow-row-manager',
|
|
|
|
'javelin-install',
|
|
|
|
'javelin-util',
|
|
|
|
'javelin-dom',
|
|
|
|
'javelin-stratcom',
|
|
|
|
'javelin-json',
|
|
|
|
'phabricator-prefab',
|
|
|
|
),
|
2014-07-14 17:33:33 +02:00
|
|
|
'6e8cefa4' => array(
|
2014-07-23 19:34:08 +02:00
|
|
|
'javelin-install',
|
|
|
|
'javelin-dom',
|
|
|
|
'javelin-util',
|
2014-05-19 01:10:54 +02:00
|
|
|
),
|
2014-07-14 17:33:33 +02:00
|
|
|
'6eff08aa' => array(
|
2014-07-23 19:34:08 +02:00
|
|
|
'javelin-install',
|
|
|
|
'javelin-util',
|
|
|
|
'javelin-stratcom',
|
Introduce CAN_EDIT for ExternalAccount, and make CAN_VIEW more liberal
Summary:
Fixes T3732. Ref T1205. Ref T3116.
External accounts (like emails used as identities, Facebook accounts, LDAP accounts, etc.) are stored in "ExternalAccount" objects.
Currently, we have a very restrictive `CAN_VIEW` policy for ExternalAccounts, to add an extra layer of protection to make sure users can't use them in unintended ways. For example, it would be bad if a user could link their Phabricator account to a Facebook account without proper authentication. All of the controllers which do sensitive things have checks anyway, but a restrictive CAN_VIEW provided an extra layer of protection. Se T3116 for some discussion.
However, this means that when grey/external users take actions (via email, or via applications like Legalpad) other users can't load the account handles and can't see anything about the actor (they just see "Restricted External Account" or similar).
Balancing these concerns is mostly about not making a huge mess while doing it. This seems like a reasonable approach:
- Add `CAN_EDIT` on these objects.
- Make that very restricted, but open up `CAN_VIEW`.
- Require `CAN_EDIT` any time we're going to do something authentication/identity related.
This is slightly easier to get wrong (forget CAN_EDIT) than other approaches, but pretty simple, and we always have extra checks in place anyway -- this is just a safety net.
I'm not quite sure how we should identify external accounts, so for now we're just rendering "Email User" or similar -- clearly not a bug, but not identifying. We can figure out what to render in the long term elsewhere.
Test Plan:
- Viewed external accounts.
- Linked an external account.
- Refreshed an external account.
- Edited profile picture.
- Viewed sessions panel.
- Published a bunch of stuff to Asana/JIRA.
- Legalpad signature page now shows external accounts.
{F171595}
Reviewers: chad, btrahan
Reviewed By: btrahan
Subscribers: epriestley
Maniphest Tasks: T3732, T1205, T3116
Differential Revision: https://secure.phabricator.com/D9767
2014-07-10 19:18:10 +02:00
|
|
|
),
|
2015-01-28 17:26:10 +01:00
|
|
|
'6f7962d5' => array(
|
|
|
|
'javelin-magical-init',
|
|
|
|
'javelin-install',
|
|
|
|
'javelin-util',
|
|
|
|
'javelin-vector',
|
|
|
|
'javelin-stratcom',
|
|
|
|
),
|
2015-01-09 23:09:13 +01:00
|
|
|
'6f7a9da8' => array(
|
|
|
|
'javelin-install',
|
|
|
|
),
|
2015-01-14 01:10:57 +01:00
|
|
|
'70baed2f' => array(
|
|
|
|
'javelin-install',
|
|
|
|
'javelin-dom',
|
|
|
|
'javelin-vector',
|
|
|
|
'javelin-util',
|
|
|
|
),
|
2014-11-18 00:32:37 +01:00
|
|
|
'724b1247' => array(
|
|
|
|
'javelin-behavior',
|
|
|
|
'javelin-typeahead-ondemand-source',
|
|
|
|
'javelin-typeahead',
|
|
|
|
'javelin-dom',
|
|
|
|
'javelin-uri',
|
|
|
|
'javelin-util',
|
|
|
|
'javelin-stratcom',
|
|
|
|
'phabricator-prefab',
|
|
|
|
),
|
2015-01-09 23:53:56 +01:00
|
|
|
'72da38cc' => array(
|
|
|
|
'javelin-install',
|
|
|
|
'javelin-util',
|
|
|
|
'javelin-dom',
|
|
|
|
'javelin-typeahead',
|
|
|
|
'javelin-tokenizer',
|
|
|
|
'javelin-typeahead-preloaded-source',
|
|
|
|
'javelin-typeahead-ondemand-source',
|
|
|
|
'javelin-dom',
|
|
|
|
'javelin-stratcom',
|
|
|
|
'javelin-util',
|
|
|
|
),
|
2015-01-04 22:23:22 +01:00
|
|
|
'7319e029' => array(
|
|
|
|
'javelin-behavior',
|
|
|
|
'javelin-dom',
|
|
|
|
),
|
2015-01-29 19:20:35 +01:00
|
|
|
'73d09eef' => array(
|
|
|
|
'javelin-behavior',
|
|
|
|
'javelin-vector',
|
|
|
|
'javelin-dom',
|
|
|
|
),
|
2015-01-14 01:10:57 +01:00
|
|
|
'7644823e' => array(
|
|
|
|
'javelin-dom',
|
|
|
|
'javelin-util',
|
|
|
|
'javelin-stratcom',
|
|
|
|
'javelin-install',
|
|
|
|
),
|
2014-07-14 17:33:33 +02:00
|
|
|
'76b9fc3e' => array(
|
2014-07-23 19:34:08 +02:00
|
|
|
'javelin-behavior',
|
|
|
|
'javelin-stratcom',
|
|
|
|
'javelin-workflow',
|
|
|
|
'javelin-dom',
|
|
|
|
'phabricator-draggable-list',
|
2014-06-23 19:27:47 +02:00
|
|
|
),
|
2014-07-14 17:33:33 +02:00
|
|
|
'76f4ebed' => array(
|
2014-07-23 19:34:08 +02:00
|
|
|
'javelin-install',
|
|
|
|
'javelin-reactor',
|
|
|
|
'javelin-util',
|
2014-01-01 03:04:25 +01:00
|
|
|
),
|
2014-07-14 17:33:33 +02:00
|
|
|
'7814b593' => array(
|
2014-07-23 19:34:08 +02:00
|
|
|
'javelin-request',
|
|
|
|
'javelin-behavior',
|
|
|
|
'javelin-dom',
|
|
|
|
'javelin-router',
|
|
|
|
'javelin-util',
|
|
|
|
'phabricator-busy',
|
Provide a global router for Ajax requests
Summary:
Fixes T430. Fixes T4834. Obsoletes D7641. Currently, we do some things less-well than we could:
- We just let the browser queue and prioritize requests, so if you load a revision with 50 changes and then click "Award Token", the action blocks until the changes load in most/all browsers. It would be better to prioritize this action and queue it immediately.
- Similarly, changes tend to load in order, even if the user has clicked to a specific file. When the user expresses a preference for a specific file, we should prioritize it.
- We show a spinning GIF when waiting on requests. This is appropriate for some types of reuqests, but distracting for others.
To fix this:
- Queue all (or, at least, most) requests into a new queue in JX.Router.
- JX.Router handles prioritizing the requests. Principally:
- You can submit a request with a specific priority (500 = general content loading, 1000 = default, 2000 = explicit user action) and JX.Router will get the higher stuff fired off sooner.
- You can name requests and then adjust their prorities later, if the user expresses an interest in specific results.
- Only use the spinner gif for "workflow" requests, which is bascially when the user clicked something and we're waiting on the server. I think it's useful and not-annoying in this case.
- Don't show any status for draft requests.
- For content requests, show a subtle hipster-style top loading bar.
Test Plan:
- Viewed a diff with 93 changes, and clicked award token.
- Prior to this patch, the action took many many seconds to resolve.
- After this patch, it resolves quickly.
- Viewed a diff with 93 changes and saw a pleasant subtle hipster-style loading bar.
- Viewed a diff with 93 changes and typed some draft text. Previews populated fairly quickly and there was no spinner.
- Viewed a diff with 93 changes and clicked something with workflow, saw a spinner after a moment.
- Viewed a diff with 93 changes and clicked a file in the table of contents near the end of the list.
- Prior to this patch, it took a long time to show up.
- After this patch, it loads directly.
Reviewers: chad, btrahan
Reviewed By: btrahan
Subscribers: epriestley
Maniphest Tasks: T430, T4834
Differential Revision: https://secure.phabricator.com/D8979
2014-05-05 19:57:42 +02:00
|
|
|
),
|
2014-07-14 17:33:33 +02:00
|
|
|
'7a68dda3' => array(
|
2014-07-23 19:34:08 +02:00
|
|
|
'owners-path-editor',
|
|
|
|
'javelin-behavior',
|
2014-01-01 03:04:25 +01:00
|
|
|
),
|
2014-07-14 17:33:33 +02:00
|
|
|
'7b98d7c5' => array(
|
2014-07-23 19:34:08 +02:00
|
|
|
'javelin-behavior',
|
|
|
|
'javelin-dom',
|
|
|
|
'javelin-stratcom',
|
|
|
|
'javelin-util',
|
2014-01-01 03:04:25 +01:00
|
|
|
),
|
2014-07-14 17:33:33 +02:00
|
|
|
'7cbe244b' => array(
|
2014-07-23 19:34:08 +02:00
|
|
|
'javelin-install',
|
|
|
|
'javelin-util',
|
|
|
|
'javelin-request',
|
|
|
|
'javelin-router',
|
Provide a global router for Ajax requests
Summary:
Fixes T430. Fixes T4834. Obsoletes D7641. Currently, we do some things less-well than we could:
- We just let the browser queue and prioritize requests, so if you load a revision with 50 changes and then click "Award Token", the action blocks until the changes load in most/all browsers. It would be better to prioritize this action and queue it immediately.
- Similarly, changes tend to load in order, even if the user has clicked to a specific file. When the user expresses a preference for a specific file, we should prioritize it.
- We show a spinning GIF when waiting on requests. This is appropriate for some types of reuqests, but distracting for others.
To fix this:
- Queue all (or, at least, most) requests into a new queue in JX.Router.
- JX.Router handles prioritizing the requests. Principally:
- You can submit a request with a specific priority (500 = general content loading, 1000 = default, 2000 = explicit user action) and JX.Router will get the higher stuff fired off sooner.
- You can name requests and then adjust their prorities later, if the user expresses an interest in specific results.
- Only use the spinner gif for "workflow" requests, which is bascially when the user clicked something and we're waiting on the server. I think it's useful and not-annoying in this case.
- Don't show any status for draft requests.
- For content requests, show a subtle hipster-style top loading bar.
Test Plan:
- Viewed a diff with 93 changes, and clicked award token.
- Prior to this patch, the action took many many seconds to resolve.
- After this patch, it resolves quickly.
- Viewed a diff with 93 changes and saw a pleasant subtle hipster-style loading bar.
- Viewed a diff with 93 changes and typed some draft text. Previews populated fairly quickly and there was no spinner.
- Viewed a diff with 93 changes and clicked something with workflow, saw a spinner after a moment.
- Viewed a diff with 93 changes and clicked a file in the table of contents near the end of the list.
- Prior to this patch, it took a long time to show up.
- After this patch, it loads directly.
Reviewers: chad, btrahan
Reviewed By: btrahan
Subscribers: epriestley
Maniphest Tasks: T430, T4834
Differential Revision: https://secure.phabricator.com/D8979
2014-05-05 19:57:42 +02:00
|
|
|
),
|
2014-07-14 17:33:33 +02:00
|
|
|
'7e41274a' => array(
|
2014-07-23 19:34:08 +02:00
|
|
|
'javelin-install',
|
2014-01-01 03:04:25 +01:00
|
|
|
),
|
2014-07-14 17:33:33 +02:00
|
|
|
'7e8468ae' => array(
|
2014-07-23 19:34:08 +02:00
|
|
|
'javelin-install',
|
|
|
|
'javelin-dom',
|
|
|
|
'javelin-vector',
|
|
|
|
'javelin-request',
|
|
|
|
'javelin-uri',
|
2014-06-23 19:35:39 +02:00
|
|
|
),
|
2014-07-14 17:33:33 +02:00
|
|
|
'7ebaeed3' => array(
|
2014-07-23 19:34:08 +02:00
|
|
|
'herald-rule-editor',
|
|
|
|
'javelin-behavior',
|
2014-01-01 03:04:25 +01:00
|
|
|
),
|
2014-07-14 17:33:33 +02:00
|
|
|
'7ee2b591' => array(
|
2014-07-23 19:34:08 +02:00
|
|
|
'javelin-behavior',
|
|
|
|
'javelin-history',
|
Fix some issues where Conpherence would make to many draft requests
Summary:
A few minor fixes:
- When we build a tag with `"meta" => null`, strip the attribute like we do for all other attributes. Previously, we would actually set the metadata to `null`. This happened with the Conpherence form.
- Just respond to the draft request with an empty (but valid) response, instead of building a dialog.
- `PhabricatorShapedRequest` is confusingly named and I should have caught this in review, but the basic shape of it is:
- You make one object.
- You call `trigger()` when stuff changes (e.g., a keystroke).
- It manages making a small number of requests (e.g., one request after the user stops typing for a moment).
- The way it was being used previously would incorrectly send a request for every keystroke.
I think I'm going to simplify `ShapedRequest` and merge it into some larger queue for T430.
Test Plan: Typed some text, no longer saw a flurry of requests. Reloaded page, still saw draft text.
Reviewers: btrahan, chad
Reviewed By: chad
CC: aran, chad
Differential Revision: https://secure.phabricator.com/D8380
2014-03-01 20:23:08 +01:00
|
|
|
),
|
2015-01-04 22:23:22 +01:00
|
|
|
82439934 => array(
|
|
|
|
'javelin-behavior',
|
|
|
|
'javelin-dom',
|
|
|
|
'javelin-util',
|
|
|
|
'javelin-stratcom',
|
|
|
|
'javelin-workflow',
|
|
|
|
'phabricator-draggable-list',
|
|
|
|
),
|
2014-07-14 17:33:33 +02:00
|
|
|
'82ce2142' => array(
|
2014-07-23 19:34:08 +02:00
|
|
|
'aphront-typeahead-control-css',
|
2014-05-29 05:56:20 +02:00
|
|
|
),
|
2015-01-25 17:46:22 +01:00
|
|
|
'834a1173' => array(
|
|
|
|
'javelin-behavior',
|
|
|
|
'javelin-scrollbar',
|
|
|
|
),
|
2014-07-14 17:33:33 +02:00
|
|
|
'84845b5b' => array(
|
2014-07-23 19:34:08 +02:00
|
|
|
'javelin-behavior',
|
|
|
|
'javelin-dom',
|
|
|
|
'javelin-stratcom',
|
|
|
|
'javelin-workflow',
|
|
|
|
'phabricator-draggable-list',
|
2014-01-01 16:46:25 +01:00
|
|
|
),
|
2015-01-29 16:10:14 +01:00
|
|
|
'84d6aea0' => array(
|
|
|
|
'javelin-stratcom',
|
|
|
|
'javelin-request',
|
|
|
|
'javelin-dom',
|
|
|
|
'javelin-vector',
|
|
|
|
'javelin-install',
|
|
|
|
'javelin-util',
|
|
|
|
'javelin-mask',
|
|
|
|
'javelin-uri',
|
|
|
|
'javelin-routable',
|
|
|
|
),
|
Multiplex AJAX calls
Summary: Fixes T5344. Essentially, we only make the AJAX request to `/notification/individual/` if we are the leader tab (i.e. only one tab will make this request). Once a response has been received from the server (containing the contents of the notification), we broadcast the message contents back to all other tabs for rendering.
Test Plan:
Opened two tabs on `/notification/status/` and clicked "Send Test Notification".
**Before**
```lang=bash, name=tail -f /var/log/phabricator-access.log | grep /notification/individual/
[Tue, 13 Jan 2015 20:10:37 +1100] 17033 phabricator 10.0.0.1 josh PhabricatorNotificationIndividualController - /notification/individual/-200 236036
[Tue, 13 Jan 2015 20:10:37 +1100] 17657 phabricator 10.0.0.1 josh PhabricatorNotificationIndividualController - /notification/individual/-200 24130
```
**After**
```lang=bash, name=tail -f /var/log/phabricator-access.log | grep /notification/individual/
[Tue, 13 Jan 2015 20:11:15 +1100] 17657 phabricator 10.0.0.1 josh PhabricatorNotificationIndividualController - /notification/individual/-200 180217
```
Reviewers: #blessed_reviewers, epriestley
Reviewed By: #blessed_reviewers, epriestley
Subscribers: Korvin, epriestley
Maniphest Tasks: T5344
Differential Revision: https://secure.phabricator.com/D11360
2015-01-15 21:05:31 +01:00
|
|
|
'851f167c' => array(
|
|
|
|
'javelin-behavior',
|
|
|
|
'javelin-aphlict',
|
|
|
|
'javelin-stratcom',
|
|
|
|
'javelin-request',
|
|
|
|
'javelin-uri',
|
|
|
|
'javelin-dom',
|
|
|
|
'javelin-json',
|
|
|
|
'javelin-router',
|
|
|
|
'javelin-util',
|
|
|
|
'javelin-leader',
|
|
|
|
'phabricator-notification',
|
|
|
|
),
|
2014-07-14 17:33:33 +02:00
|
|
|
'85ea0626' => array(
|
2014-07-23 19:34:08 +02:00
|
|
|
'javelin-install',
|
Introduce CAN_EDIT for ExternalAccount, and make CAN_VIEW more liberal
Summary:
Fixes T3732. Ref T1205. Ref T3116.
External accounts (like emails used as identities, Facebook accounts, LDAP accounts, etc.) are stored in "ExternalAccount" objects.
Currently, we have a very restrictive `CAN_VIEW` policy for ExternalAccounts, to add an extra layer of protection to make sure users can't use them in unintended ways. For example, it would be bad if a user could link their Phabricator account to a Facebook account without proper authentication. All of the controllers which do sensitive things have checks anyway, but a restrictive CAN_VIEW provided an extra layer of protection. Se T3116 for some discussion.
However, this means that when grey/external users take actions (via email, or via applications like Legalpad) other users can't load the account handles and can't see anything about the actor (they just see "Restricted External Account" or similar).
Balancing these concerns is mostly about not making a huge mess while doing it. This seems like a reasonable approach:
- Add `CAN_EDIT` on these objects.
- Make that very restricted, but open up `CAN_VIEW`.
- Require `CAN_EDIT` any time we're going to do something authentication/identity related.
This is slightly easier to get wrong (forget CAN_EDIT) than other approaches, but pretty simple, and we always have extra checks in place anyway -- this is just a safety net.
I'm not quite sure how we should identify external accounts, so for now we're just rendering "Email User" or similar -- clearly not a bug, but not identifying. We can figure out what to render in the long term elsewhere.
Test Plan:
- Viewed external accounts.
- Linked an external account.
- Refreshed an external account.
- Edited profile picture.
- Viewed sessions panel.
- Published a bunch of stuff to Asana/JIRA.
- Legalpad signature page now shows external accounts.
{F171595}
Reviewers: chad, btrahan
Reviewed By: btrahan
Subscribers: epriestley
Maniphest Tasks: T3732, T1205, T3116
Differential Revision: https://secure.phabricator.com/D9767
2014-07-10 19:18:10 +02:00
|
|
|
),
|
2015-03-05 23:03:15 +01:00
|
|
|
'8694b1df' => array(
|
|
|
|
'javelin-behavior',
|
|
|
|
'javelin-dom',
|
|
|
|
'javelin-stratcom',
|
|
|
|
'phabricator-tooltip',
|
|
|
|
'changeset-view-manager',
|
|
|
|
),
|
2015-02-26 19:27:28 +01:00
|
|
|
'869e3445' => array(
|
|
|
|
'javelin-behavior',
|
|
|
|
'javelin-dom',
|
|
|
|
'javelin-util',
|
|
|
|
'javelin-stratcom',
|
|
|
|
'javelin-workflow',
|
|
|
|
'javelin-behavior-device',
|
|
|
|
'javelin-history',
|
|
|
|
'javelin-vector',
|
|
|
|
'phabricator-shaped-request',
|
|
|
|
),
|
2015-02-26 00:14:27 +01:00
|
|
|
'86df5915' => array(
|
|
|
|
'javelin-behavior',
|
|
|
|
'javelin-dom',
|
|
|
|
'javelin-util',
|
|
|
|
'javelin-workflow',
|
|
|
|
'javelin-stratcom',
|
|
|
|
),
|
2015-01-07 02:50:40 +01:00
|
|
|
'87cb6b51' => array(
|
|
|
|
'javelin-behavior',
|
|
|
|
'javelin-dom',
|
|
|
|
'javelin-util',
|
|
|
|
'javelin-vector',
|
|
|
|
'javelin-stratcom',
|
|
|
|
'javelin-workflow',
|
|
|
|
'phabricator-draggable-list',
|
|
|
|
),
|
2014-07-14 17:33:33 +02:00
|
|
|
'88236f00' => array(
|
2014-07-23 19:34:08 +02:00
|
|
|
'javelin-behavior',
|
|
|
|
'phabricator-keyboard-shortcut',
|
|
|
|
'javelin-stratcom',
|
2014-01-01 03:04:25 +01:00
|
|
|
),
|
2014-07-14 17:33:33 +02:00
|
|
|
'886fd850' => array(
|
2014-07-23 19:34:08 +02:00
|
|
|
'javelin-install',
|
|
|
|
'javelin-reactor-dom',
|
|
|
|
'javelin-view-html',
|
|
|
|
'javelin-view-interpreter',
|
|
|
|
'javelin-view-renderer',
|
2014-06-23 19:27:47 +02:00
|
|
|
),
|
2015-01-23 22:29:15 +01:00
|
|
|
'887ad43f' => array(
|
|
|
|
'javelin-behavior',
|
|
|
|
'javelin-request',
|
|
|
|
'javelin-stratcom',
|
|
|
|
'javelin-dom',
|
|
|
|
),
|
2015-02-24 18:41:37 +01:00
|
|
|
'88f0c5b3' => array(
|
|
|
|
'javelin-behavior',
|
|
|
|
'javelin-dom',
|
|
|
|
'javelin-vector',
|
|
|
|
),
|
2014-07-14 17:33:33 +02:00
|
|
|
'8a41885b' => array(
|
2014-07-23 19:34:08 +02:00
|
|
|
'javelin-install',
|
|
|
|
'javelin-dom',
|
Introduce CAN_EDIT for ExternalAccount, and make CAN_VIEW more liberal
Summary:
Fixes T3732. Ref T1205. Ref T3116.
External accounts (like emails used as identities, Facebook accounts, LDAP accounts, etc.) are stored in "ExternalAccount" objects.
Currently, we have a very restrictive `CAN_VIEW` policy for ExternalAccounts, to add an extra layer of protection to make sure users can't use them in unintended ways. For example, it would be bad if a user could link their Phabricator account to a Facebook account without proper authentication. All of the controllers which do sensitive things have checks anyway, but a restrictive CAN_VIEW provided an extra layer of protection. Se T3116 for some discussion.
However, this means that when grey/external users take actions (via email, or via applications like Legalpad) other users can't load the account handles and can't see anything about the actor (they just see "Restricted External Account" or similar).
Balancing these concerns is mostly about not making a huge mess while doing it. This seems like a reasonable approach:
- Add `CAN_EDIT` on these objects.
- Make that very restricted, but open up `CAN_VIEW`.
- Require `CAN_EDIT` any time we're going to do something authentication/identity related.
This is slightly easier to get wrong (forget CAN_EDIT) than other approaches, but pretty simple, and we always have extra checks in place anyway -- this is just a safety net.
I'm not quite sure how we should identify external accounts, so for now we're just rendering "Email User" or similar -- clearly not a bug, but not identifying. We can figure out what to render in the long term elsewhere.
Test Plan:
- Viewed external accounts.
- Linked an external account.
- Refreshed an external account.
- Edited profile picture.
- Viewed sessions panel.
- Published a bunch of stuff to Asana/JIRA.
- Legalpad signature page now shows external accounts.
{F171595}
Reviewers: chad, btrahan
Reviewed By: btrahan
Subscribers: epriestley
Maniphest Tasks: T3732, T1205, T3116
Differential Revision: https://secure.phabricator.com/D9767
2014-07-10 19:18:10 +02:00
|
|
|
),
|
2014-07-14 17:33:33 +02:00
|
|
|
'8b3fd187' => array(
|
2014-07-23 19:34:08 +02:00
|
|
|
'javelin-install',
|
|
|
|
'javelin-util',
|
|
|
|
'javelin-request',
|
|
|
|
'javelin-typeahead-source',
|
2014-01-01 03:04:25 +01:00
|
|
|
),
|
2014-08-21 01:21:50 +02:00
|
|
|
'8c49f386' => array(
|
|
|
|
'javelin-install',
|
|
|
|
'javelin-util',
|
|
|
|
'javelin-request',
|
|
|
|
'javelin-dom',
|
|
|
|
'javelin-uri',
|
|
|
|
'phabricator-file-upload',
|
|
|
|
),
|
2014-12-30 11:54:21 +01:00
|
|
|
'8ce821c5' => array(
|
|
|
|
'phabricator-notification',
|
|
|
|
'javelin-stratcom',
|
|
|
|
'javelin-behavior',
|
|
|
|
),
|
2014-07-14 17:33:33 +02:00
|
|
|
'8ef9ab58' => array(
|
2014-07-23 19:34:08 +02:00
|
|
|
'javelin-behavior',
|
|
|
|
'javelin-dom',
|
|
|
|
'javelin-stratcom',
|
2014-06-19 20:28:01 +02:00
|
|
|
),
|
2014-07-14 17:33:33 +02:00
|
|
|
'8fc1c918' => array(
|
2014-07-23 19:34:08 +02:00
|
|
|
'javelin-behavior',
|
|
|
|
'javelin-uri',
|
|
|
|
'phabricator-notification',
|
2014-01-01 03:04:25 +01:00
|
|
|
),
|
2014-07-14 17:33:33 +02:00
|
|
|
'92eb531d' => array(
|
2014-07-23 19:34:08 +02:00
|
|
|
'javelin-behavior',
|
|
|
|
'javelin-dom',
|
|
|
|
'phabricator-drag-and-drop-file-upload',
|
|
|
|
'phabricator-textareautils',
|
2014-06-23 19:35:39 +02:00
|
|
|
),
|
2014-07-14 17:33:33 +02:00
|
|
|
'9414ff18' => array(
|
2014-07-23 19:34:08 +02:00
|
|
|
'javelin-behavior',
|
|
|
|
'javelin-resource',
|
|
|
|
'javelin-stratcom',
|
|
|
|
'javelin-workflow',
|
|
|
|
'javelin-util',
|
2014-01-01 03:04:25 +01:00
|
|
|
),
|
2015-01-14 01:10:57 +01:00
|
|
|
'94b750d2' => array(
|
2015-01-04 22:23:22 +01:00
|
|
|
'javelin-install',
|
|
|
|
'javelin-stratcom',
|
|
|
|
'javelin-util',
|
|
|
|
'javelin-behavior',
|
|
|
|
'javelin-json',
|
|
|
|
'javelin-dom',
|
|
|
|
'javelin-resource',
|
|
|
|
'javelin-routable',
|
|
|
|
),
|
2014-12-30 11:56:42 +01:00
|
|
|
'988040b4' => array(
|
|
|
|
'javelin-install',
|
2014-12-30 11:53:27 +01:00
|
|
|
'javelin-dom',
|
2014-12-30 11:56:42 +01:00
|
|
|
'javelin-reactor-dom',
|
2014-12-30 11:53:27 +01:00
|
|
|
),
|
2014-07-14 17:33:33 +02:00
|
|
|
'9c2623f4' => array(
|
2014-07-23 19:34:08 +02:00
|
|
|
'javelin-behavior',
|
|
|
|
'javelin-stratcom',
|
|
|
|
'javelin-dom',
|
|
|
|
'javelin-workflow',
|
|
|
|
'phabricator-phtize',
|
|
|
|
'phabricator-drag-and-drop-file-upload',
|
|
|
|
'phabricator-draggable-list',
|
2014-01-01 03:04:25 +01:00
|
|
|
),
|
2015-01-28 17:26:10 +01:00
|
|
|
'9f36c42d' => array(
|
|
|
|
'javelin-behavior',
|
|
|
|
'javelin-stratcom',
|
|
|
|
'javelin-dom',
|
|
|
|
'javelin-vector',
|
|
|
|
),
|
2014-07-14 17:33:33 +02:00
|
|
|
'9f7309fb' => array(
|
2014-07-23 19:34:08 +02:00
|
|
|
'javelin-behavior',
|
|
|
|
'javelin-dom',
|
|
|
|
'javelin-util',
|
|
|
|
'javelin-request',
|
|
|
|
'phabricator-shaped-request',
|
2014-06-21 21:50:40 +02:00
|
|
|
),
|
2015-01-25 17:46:22 +01:00
|
|
|
'a0b57eb8' => array(
|
|
|
|
'javelin-behavior',
|
|
|
|
'javelin-dom',
|
|
|
|
'javelin-stratcom',
|
|
|
|
'javelin-workflow',
|
|
|
|
'javelin-util',
|
|
|
|
'phabricator-keyboard-shortcut',
|
|
|
|
),
|
2014-07-14 17:33:33 +02:00
|
|
|
'a155550f' => array(
|
2014-07-23 19:34:08 +02:00
|
|
|
'javelin-install',
|
|
|
|
'javelin-dom',
|
|
|
|
'javelin-reactor-dom',
|
2014-06-23 19:27:47 +02:00
|
|
|
),
|
2014-09-09 23:20:27 +02:00
|
|
|
'a16ec1c6' => array(
|
|
|
|
'javelin-install',
|
|
|
|
'javelin-dom',
|
|
|
|
'javelin-stratcom',
|
|
|
|
'javelin-util',
|
|
|
|
'javelin-vector',
|
|
|
|
'javelin-magical-init',
|
|
|
|
),
|
2014-07-14 17:33:33 +02:00
|
|
|
'a4ae61bf' => array(
|
2014-07-23 19:34:08 +02:00
|
|
|
'javelin-install',
|
|
|
|
'javelin-dom',
|
|
|
|
'phabricator-notification',
|
2014-02-27 20:06:55 +01:00
|
|
|
),
|
2014-07-14 17:33:33 +02:00
|
|
|
'a80d0378' => array(
|
2014-07-23 19:34:08 +02:00
|
|
|
'javelin-behavior',
|
|
|
|
'javelin-stratcom',
|
|
|
|
'javelin-dom',
|
2014-06-23 19:27:47 +02:00
|
|
|
),
|
2015-03-05 19:43:26 +01:00
|
|
|
'a88a26cc' => array(
|
|
|
|
'javelin-behavior',
|
|
|
|
'javelin-dom',
|
|
|
|
'javelin-stratcom',
|
|
|
|
'javelin-scrollbar',
|
|
|
|
'javelin-quicksand',
|
|
|
|
'phabricator-keyboard-shortcut',
|
|
|
|
'javelin-behavior-conpherence-widget-pane',
|
|
|
|
),
|
2014-07-14 17:33:33 +02:00
|
|
|
'a8d8459d' => array(
|
2014-07-23 19:34:08 +02:00
|
|
|
'javelin-behavior',
|
|
|
|
'javelin-dom',
|
|
|
|
'javelin-stratcom',
|
2014-01-01 03:04:25 +01:00
|
|
|
),
|
2014-07-14 17:33:33 +02:00
|
|
|
'a8da01f0' => array(
|
2014-07-23 19:34:08 +02:00
|
|
|
'javelin-behavior',
|
|
|
|
'javelin-uri',
|
|
|
|
'phabricator-keyboard-shortcut',
|
2014-05-29 23:20:16 +02:00
|
|
|
),
|
2014-07-14 17:33:33 +02:00
|
|
|
'a9f88de2' => array(
|
2014-07-23 19:34:08 +02:00
|
|
|
'javelin-behavior',
|
|
|
|
'javelin-dom',
|
|
|
|
'javelin-stratcom',
|
|
|
|
'javelin-workflow',
|
|
|
|
'javelin-fx',
|
|
|
|
'javelin-util',
|
2014-06-23 19:27:47 +02:00
|
|
|
),
|
2014-07-14 17:33:33 +02:00
|
|
|
'aa1733d0' => array(
|
2014-07-23 19:34:08 +02:00
|
|
|
'multirow-row-manager',
|
|
|
|
'javelin-install',
|
|
|
|
'path-typeahead',
|
|
|
|
'javelin-dom',
|
|
|
|
'javelin-util',
|
|
|
|
'phabricator-prefab',
|
2014-06-23 19:35:39 +02:00
|
|
|
),
|
2015-03-05 23:11:51 +01:00
|
|
|
'ae8e9b44' => array(
|
|
|
|
'javelin-behavior',
|
|
|
|
'javelin-stratcom',
|
|
|
|
'javelin-dom',
|
|
|
|
'javelin-util',
|
|
|
|
'javelin-vector',
|
|
|
|
'differential-inline-comment-editor',
|
|
|
|
),
|
2014-07-14 17:33:33 +02:00
|
|
|
'b1f0ccee' => array(
|
2014-07-23 19:34:08 +02:00
|
|
|
'javelin-install',
|
|
|
|
'javelin-dom',
|
|
|
|
'javelin-reactor-dom',
|
2014-01-01 03:04:25 +01:00
|
|
|
),
|
2014-07-14 17:33:33 +02:00
|
|
|
'b2b4fbaf' => array(
|
2014-07-23 19:34:08 +02:00
|
|
|
'javelin-behavior',
|
|
|
|
'javelin-dom',
|
|
|
|
'javelin-uri',
|
|
|
|
'javelin-request',
|
2014-06-23 19:27:47 +02:00
|
|
|
),
|
2014-12-30 11:53:27 +01:00
|
|
|
'b2c03e60' => array(
|
|
|
|
'javelin-behavior',
|
|
|
|
'javelin-dom',
|
|
|
|
'phortune-credit-card-form',
|
|
|
|
),
|
2014-07-14 17:33:33 +02:00
|
|
|
'b3a4b884' => array(
|
2014-07-23 19:34:08 +02:00
|
|
|
'javelin-behavior',
|
|
|
|
'phabricator-prefab',
|
2014-01-01 03:04:25 +01:00
|
|
|
),
|
2014-07-14 17:33:33 +02:00
|
|
|
'b3e7d692' => array(
|
2014-07-23 19:34:08 +02:00
|
|
|
'javelin-install',
|
Provide a global router for Ajax requests
Summary:
Fixes T430. Fixes T4834. Obsoletes D7641. Currently, we do some things less-well than we could:
- We just let the browser queue and prioritize requests, so if you load a revision with 50 changes and then click "Award Token", the action blocks until the changes load in most/all browsers. It would be better to prioritize this action and queue it immediately.
- Similarly, changes tend to load in order, even if the user has clicked to a specific file. When the user expresses a preference for a specific file, we should prioritize it.
- We show a spinning GIF when waiting on requests. This is appropriate for some types of reuqests, but distracting for others.
To fix this:
- Queue all (or, at least, most) requests into a new queue in JX.Router.
- JX.Router handles prioritizing the requests. Principally:
- You can submit a request with a specific priority (500 = general content loading, 1000 = default, 2000 = explicit user action) and JX.Router will get the higher stuff fired off sooner.
- You can name requests and then adjust their prorities later, if the user expresses an interest in specific results.
- Only use the spinner gif for "workflow" requests, which is bascially when the user clicked something and we're waiting on the server. I think it's useful and not-annoying in this case.
- Don't show any status for draft requests.
- For content requests, show a subtle hipster-style top loading bar.
Test Plan:
- Viewed a diff with 93 changes, and clicked award token.
- Prior to this patch, the action took many many seconds to resolve.
- After this patch, it resolves quickly.
- Viewed a diff with 93 changes and saw a pleasant subtle hipster-style loading bar.
- Viewed a diff with 93 changes and typed some draft text. Previews populated fairly quickly and there was no spinner.
- Viewed a diff with 93 changes and clicked something with workflow, saw a spinner after a moment.
- Viewed a diff with 93 changes and clicked a file in the table of contents near the end of the list.
- Prior to this patch, it took a long time to show up.
- After this patch, it loads directly.
Reviewers: chad, btrahan
Reviewed By: btrahan
Subscribers: epriestley
Maniphest Tasks: T430, T4834
Differential Revision: https://secure.phabricator.com/D8979
2014-05-05 19:57:42 +02:00
|
|
|
),
|
2014-07-14 17:33:33 +02:00
|
|
|
'b42eddc7' => array(
|
2014-07-23 19:34:08 +02:00
|
|
|
'javelin-install',
|
|
|
|
'javelin-dom',
|
|
|
|
'javelin-typeahead-preloaded-source',
|
|
|
|
'javelin-util',
|
2014-06-23 19:35:39 +02:00
|
|
|
),
|
2014-07-14 17:33:33 +02:00
|
|
|
'b5c256b8' => array(
|
2014-07-23 19:34:08 +02:00
|
|
|
'javelin-install',
|
|
|
|
'javelin-dom',
|
2014-05-05 19:57:23 +02:00
|
|
|
),
|
2014-11-17 23:06:05 +01:00
|
|
|
'b5d57730' => array(
|
|
|
|
'javelin-install',
|
|
|
|
'javelin-stratcom',
|
|
|
|
'javelin-dom',
|
|
|
|
'javelin-util',
|
|
|
|
),
|
2014-07-14 17:33:33 +02:00
|
|
|
'bba9eedf' => array(
|
2014-07-23 19:34:08 +02:00
|
|
|
'javelin-behavior',
|
|
|
|
'javelin-stratcom',
|
|
|
|
'javelin-dom',
|
2014-06-23 19:27:47 +02:00
|
|
|
),
|
2014-07-14 17:33:33 +02:00
|
|
|
'bd4c8dca' => array(
|
2014-07-23 19:34:08 +02:00
|
|
|
'javelin-install',
|
|
|
|
'javelin-util',
|
|
|
|
'javelin-dom',
|
|
|
|
'javelin-vector',
|
|
|
|
'javelin-stratcom',
|
2014-05-05 19:57:23 +02:00
|
|
|
),
|
2014-07-14 17:33:33 +02:00
|
|
|
'bdaf4d04' => array(
|
2014-07-23 19:34:08 +02:00
|
|
|
'javelin-behavior',
|
|
|
|
'javelin-dom',
|
|
|
|
'javelin-util',
|
|
|
|
'javelin-request',
|
2014-01-01 03:04:25 +01:00
|
|
|
),
|
2014-07-14 17:33:33 +02:00
|
|
|
'be807912' => array(
|
2014-07-23 19:34:08 +02:00
|
|
|
'javelin-behavior',
|
|
|
|
'javelin-dom',
|
|
|
|
'javelin-util',
|
|
|
|
'phabricator-shaped-request',
|
2014-01-01 03:04:25 +01:00
|
|
|
),
|
2015-01-25 17:46:22 +01:00
|
|
|
'c1700f6f' => array(
|
|
|
|
'javelin-install',
|
|
|
|
'javelin-util',
|
|
|
|
'javelin-stratcom',
|
|
|
|
'javelin-dom',
|
|
|
|
'javelin-vector',
|
|
|
|
),
|
2014-08-16 23:55:22 +02:00
|
|
|
'c51ae228' => array(
|
|
|
|
'javelin-behavior',
|
|
|
|
'javelin-util',
|
|
|
|
'javelin-dom',
|
|
|
|
'javelin-stratcom',
|
|
|
|
'javelin-vector',
|
|
|
|
),
|
2015-01-14 01:10:57 +01:00
|
|
|
'c90a04fc' => array(
|
|
|
|
'javelin-dom',
|
|
|
|
'javelin-dynval',
|
|
|
|
'javelin-reactor',
|
|
|
|
'javelin-reactornode',
|
|
|
|
'javelin-install',
|
|
|
|
'javelin-util',
|
|
|
|
),
|
2014-07-14 17:33:33 +02:00
|
|
|
'ca3f91eb' => array(
|
2014-07-23 19:34:08 +02:00
|
|
|
'javelin-behavior',
|
|
|
|
'javelin-dom',
|
|
|
|
'javelin-stratcom',
|
|
|
|
'phabricator-phtize',
|
2014-01-01 03:04:25 +01:00
|
|
|
),
|
Conpherence - make the durable column kind of work and stuff
Summary:
Ref T7014. This hooks up the durable column such that when you open it up it loads your most recent Conpherence. You can then switch amongst the various widgets and stuff and everything works nicely.
Except...
- scroll bar does not work
- also doesn't work at HEAD when I add a ton of text to the UI with no changes? (wrapped $copy in array_fill(0, 1000, $copy))
- "widget selector" does not collapse when you select something else
- this part wasn't really specified so I used the aphlict dropdown stuff. didn't want to keep working on that if this was the wrong UI choice
- can not edit title
- do we still want that to be done by clicking on the title, which pops a dialogue?
- can not add participants or calendar events
- what should this UI be? maybe just a button on the top for "participants" and a button on the bottom for calendar? both on top?
- this is not pixel perfect to the mock or two I've seen around. Aside from generally being bad at that, I definitely didn't get the name + timestamps formatting correctly, because the standard DOM of that has timestamp FIRST which appears second due to a "float right". Seemed like a lot of special-casing for what might not even be that important in the UI so I punted. (And again, there's likely many unknown ways in which this isn't pixel perfect)
There's also code quality issues
- `ConpherenceWidgetConfigConstants` is hopefully temporary or at least gets more sleek as we keep progressing here
- copied some CSS from main Conpherence app
- DOM structure is pretty different
- there's some minor CSS tweaks too given the different width (not to mention the DOM structure being different)
- copied some JS from behavior-pontificate.js to sync threads relative to aphlict updates
- JS in general is like a better version of existing JS; these should collapse I'd hope?
- maybe the aphlict-behavior-dropdown change was badsauce?
...but all that said, this definitely feels really nice and I feel like adding stuff is going to be really easy compared to how normal Conpherence is.
Also includes a bonus bug fix - we now correctly update participation. The user would encounter this issue if they were in a conpherence that got some updates and then they went to a different page; they would have unread status for the messages that were ajax'd in. This patch fixes that by making sure we mark participation up to date with the proper transaction in all cases.
Test Plan: hit "\" to invoke the column and saw nice loading UI and my latest conpherence load. sent messages and verified they received A-OK by looking in DOM console. toggled various widges and verified they rendered correctly. opened up a second browser with a second user on the thread, sent a message, and it was received in a nice asynchronous fashion
Reviewers: chad, epriestley
Reviewed By: epriestley
Subscribers: Korvin, epriestley
Maniphest Tasks: T7014
Differential Revision: https://secure.phabricator.com/D11968
2015-03-05 19:33:39 +01:00
|
|
|
'cc2d9c80' => array(
|
|
|
|
'javelin-behavior',
|
|
|
|
'javelin-request',
|
|
|
|
'javelin-stratcom',
|
|
|
|
'javelin-vector',
|
|
|
|
'javelin-dom',
|
|
|
|
'javelin-uri',
|
|
|
|
'javelin-behavior-device',
|
|
|
|
'phabricator-title',
|
|
|
|
),
|
2014-07-14 17:33:33 +02:00
|
|
|
'd19198c8' => array(
|
2014-07-23 19:34:08 +02:00
|
|
|
'javelin-install',
|
|
|
|
'javelin-dom',
|
|
|
|
'javelin-util',
|
|
|
|
'javelin-dynval',
|
|
|
|
'javelin-reactor-dom',
|
2014-01-01 16:46:25 +01:00
|
|
|
),
|
2014-07-14 17:33:33 +02:00
|
|
|
'd254d646' => array(
|
2014-07-23 19:34:08 +02:00
|
|
|
'javelin-util',
|
2014-01-01 16:46:25 +01:00
|
|
|
),
|
2014-07-14 17:33:33 +02:00
|
|
|
'd4a14807' => array(
|
2014-07-23 19:34:08 +02:00
|
|
|
'javelin-install',
|
|
|
|
'javelin-dom',
|
|
|
|
'javelin-view',
|
2014-01-01 03:04:25 +01:00
|
|
|
),
|
2014-07-14 17:33:33 +02:00
|
|
|
'd4eecc63' => array(
|
2014-07-23 19:34:08 +02:00
|
|
|
'javelin-behavior',
|
|
|
|
'javelin-dom',
|
|
|
|
'javelin-stratcom',
|
2014-06-23 19:27:47 +02:00
|
|
|
),
|
2014-07-14 17:33:33 +02:00
|
|
|
'd75709e6' => array(
|
2014-07-23 19:34:08 +02:00
|
|
|
'javelin-behavior',
|
|
|
|
'javelin-workflow',
|
|
|
|
'javelin-json',
|
|
|
|
'javelin-dom',
|
|
|
|
'phabricator-keyboard-shortcut',
|
2014-01-01 16:46:25 +01:00
|
|
|
),
|
2014-07-14 17:33:33 +02:00
|
|
|
'd835b03a' => array(
|
2014-07-23 19:34:08 +02:00
|
|
|
'javelin-behavior',
|
|
|
|
'javelin-dom',
|
|
|
|
'javelin-util',
|
|
|
|
'phabricator-shaped-request',
|
2014-03-27 18:50:54 +01:00
|
|
|
),
|
2015-01-28 17:26:10 +01:00
|
|
|
'dbbf48b6' => array(
|
|
|
|
'javelin-behavior',
|
|
|
|
'javelin-stratcom',
|
|
|
|
'javelin-dom',
|
|
|
|
'phabricator-busy',
|
|
|
|
),
|
2014-07-14 17:33:33 +02:00
|
|
|
'de2e896f' => array(
|
2014-07-23 19:34:08 +02:00
|
|
|
'javelin-behavior',
|
|
|
|
'javelin-dom',
|
|
|
|
'javelin-typeahead',
|
|
|
|
'javelin-typeahead-ondemand-source',
|
|
|
|
'javelin-dom',
|
Introduce CAN_EDIT for ExternalAccount, and make CAN_VIEW more liberal
Summary:
Fixes T3732. Ref T1205. Ref T3116.
External accounts (like emails used as identities, Facebook accounts, LDAP accounts, etc.) are stored in "ExternalAccount" objects.
Currently, we have a very restrictive `CAN_VIEW` policy for ExternalAccounts, to add an extra layer of protection to make sure users can't use them in unintended ways. For example, it would be bad if a user could link their Phabricator account to a Facebook account without proper authentication. All of the controllers which do sensitive things have checks anyway, but a restrictive CAN_VIEW provided an extra layer of protection. Se T3116 for some discussion.
However, this means that when grey/external users take actions (via email, or via applications like Legalpad) other users can't load the account handles and can't see anything about the actor (they just see "Restricted External Account" or similar).
Balancing these concerns is mostly about not making a huge mess while doing it. This seems like a reasonable approach:
- Add `CAN_EDIT` on these objects.
- Make that very restricted, but open up `CAN_VIEW`.
- Require `CAN_EDIT` any time we're going to do something authentication/identity related.
This is slightly easier to get wrong (forget CAN_EDIT) than other approaches, but pretty simple, and we always have extra checks in place anyway -- this is just a safety net.
I'm not quite sure how we should identify external accounts, so for now we're just rendering "Email User" or similar -- clearly not a bug, but not identifying. We can figure out what to render in the long term elsewhere.
Test Plan:
- Viewed external accounts.
- Linked an external account.
- Refreshed an external account.
- Edited profile picture.
- Viewed sessions panel.
- Published a bunch of stuff to Asana/JIRA.
- Legalpad signature page now shows external accounts.
{F171595}
Reviewers: chad, btrahan
Reviewed By: btrahan
Subscribers: epriestley
Maniphest Tasks: T3732, T1205, T3116
Differential Revision: https://secure.phabricator.com/D9767
2014-07-10 19:18:10 +02:00
|
|
|
),
|
2014-07-14 17:33:33 +02:00
|
|
|
'e10f8e18' => array(
|
2014-07-23 19:34:08 +02:00
|
|
|
'javelin-behavior',
|
|
|
|
'javelin-dom',
|
|
|
|
'phabricator-prefab',
|
2014-02-27 20:06:55 +01:00
|
|
|
),
|
2014-08-09 17:49:01 +02:00
|
|
|
'e1d25dfb' => array(
|
|
|
|
'javelin-behavior',
|
|
|
|
'javelin-stratcom',
|
|
|
|
'javelin-workflow',
|
|
|
|
'javelin-dom',
|
|
|
|
'phabricator-draggable-list',
|
|
|
|
),
|
2014-07-14 17:33:33 +02:00
|
|
|
'e1ff79b1' => array(
|
2014-07-23 19:34:08 +02:00
|
|
|
'javelin-behavior',
|
|
|
|
'javelin-stratcom',
|
|
|
|
'javelin-dom',
|
2014-01-01 03:04:25 +01:00
|
|
|
),
|
Namespace Aphlict clients by request path, plus other fixes
Summary:
Fixes T7130. Fixes T7041. Fixes T7012.
Major change here is partitioning clients. In the Phacility cluster, being able to get a huge pile of instances on a single server -- without needing to run a process per instance -- is desirable.
To accomplish this, just bucket clients by the path they connect with. This will let us set client URIs to `/instancename/` and then route connections to a small set of servers. This degrades cleanly in the common case and has no effect on installs which don't do instancing.
Also fix two unrelated issues:
- Fix the timeouts, which were incorrectly initializing in `open()` (which is called during reconnect, causing them to reset every time). Instead, initialize in the constructor. Cap timeout at 5 minutes.
- Probably fix subscriptions, which were using a property with an object definition. Since this is by-ref, all concrete instances of the object share the same property, so all users would be subscribed to everything. Probably.
Test Plan:
- Hit notification status page, saw version bump and instance/path name.
- Saw instance/path name in client and server logs.
- Stopped server, saw reconnects after 2, 4, 16, ... seconds.
- Sent test notification; received test notification.
- Didn't explicitly test the subscription thing but it should be obvious by looking at `/notification/status/` shortly after a push.
Reviewers: joshuaspence, btrahan
Reviewed By: btrahan
Subscribers: epriestley
Maniphest Tasks: T7041, T7012, T7130
Differential Revision: https://secure.phabricator.com/D11769
2015-02-16 20:31:15 +01:00
|
|
|
'e292eaf4' => array(
|
|
|
|
'javelin-install',
|
|
|
|
),
|
2014-07-14 17:33:33 +02:00
|
|
|
'e32d14ab' => array(
|
2014-07-23 19:34:08 +02:00
|
|
|
'javelin-behavior',
|
|
|
|
'javelin-stratcom',
|
|
|
|
'javelin-dom',
|
|
|
|
'phabricator-phtize',
|
|
|
|
'phabricator-textareautils',
|
|
|
|
'javelin-workflow',
|
|
|
|
'javelin-vector',
|
2014-07-01 20:04:05 +02:00
|
|
|
),
|
2014-07-14 17:33:33 +02:00
|
|
|
'e379b58e' => array(
|
2014-07-23 19:34:08 +02:00
|
|
|
'javelin-behavior',
|
|
|
|
'javelin-stratcom',
|
|
|
|
'javelin-vector',
|
|
|
|
'javelin-dom',
|
|
|
|
'javelin-uri',
|
2014-06-23 19:27:47 +02:00
|
|
|
),
|
2014-12-30 11:53:27 +01:00
|
|
|
'e4cc26b3' => array(
|
|
|
|
'javelin-behavior',
|
|
|
|
'javelin-dom',
|
|
|
|
),
|
2014-07-14 17:33:33 +02:00
|
|
|
'e566f52c' => array(
|
2014-07-23 19:34:08 +02:00
|
|
|
'javelin-behavior',
|
|
|
|
'javelin-stratcom',
|
|
|
|
'javelin-dom',
|
Introduce CAN_EDIT for ExternalAccount, and make CAN_VIEW more liberal
Summary:
Fixes T3732. Ref T1205. Ref T3116.
External accounts (like emails used as identities, Facebook accounts, LDAP accounts, etc.) are stored in "ExternalAccount" objects.
Currently, we have a very restrictive `CAN_VIEW` policy for ExternalAccounts, to add an extra layer of protection to make sure users can't use them in unintended ways. For example, it would be bad if a user could link their Phabricator account to a Facebook account without proper authentication. All of the controllers which do sensitive things have checks anyway, but a restrictive CAN_VIEW provided an extra layer of protection. Se T3116 for some discussion.
However, this means that when grey/external users take actions (via email, or via applications like Legalpad) other users can't load the account handles and can't see anything about the actor (they just see "Restricted External Account" or similar).
Balancing these concerns is mostly about not making a huge mess while doing it. This seems like a reasonable approach:
- Add `CAN_EDIT` on these objects.
- Make that very restricted, but open up `CAN_VIEW`.
- Require `CAN_EDIT` any time we're going to do something authentication/identity related.
This is slightly easier to get wrong (forget CAN_EDIT) than other approaches, but pretty simple, and we always have extra checks in place anyway -- this is just a safety net.
I'm not quite sure how we should identify external accounts, so for now we're just rendering "Email User" or similar -- clearly not a bug, but not identifying. We can figure out what to render in the long term elsewhere.
Test Plan:
- Viewed external accounts.
- Linked an external account.
- Refreshed an external account.
- Edited profile picture.
- Viewed sessions panel.
- Published a bunch of stuff to Asana/JIRA.
- Legalpad signature page now shows external accounts.
{F171595}
Reviewers: chad, btrahan
Reviewed By: btrahan
Subscribers: epriestley
Maniphest Tasks: T3732, T1205, T3116
Differential Revision: https://secure.phabricator.com/D9767
2014-07-10 19:18:10 +02:00
|
|
|
),
|
2014-07-14 17:33:33 +02:00
|
|
|
'e5822781' => array(
|
2014-07-23 19:34:08 +02:00
|
|
|
'javelin-behavior',
|
|
|
|
'javelin-dom',
|
|
|
|
'javelin-json',
|
|
|
|
'javelin-workflow',
|
|
|
|
'javelin-magical-init',
|
2014-01-01 03:04:25 +01:00
|
|
|
),
|
2014-12-30 11:56:42 +01:00
|
|
|
'e58bf807' => array(
|
|
|
|
'javelin-behavior',
|
|
|
|
'javelin-util',
|
|
|
|
'javelin-stratcom',
|
|
|
|
'javelin-dom',
|
|
|
|
'javelin-vector',
|
|
|
|
'javelin-magical-init',
|
|
|
|
'javelin-request',
|
|
|
|
'javelin-history',
|
|
|
|
'javelin-workflow',
|
|
|
|
'javelin-mask',
|
|
|
|
'javelin-behavior-device',
|
|
|
|
'phabricator-keyboard-shortcut',
|
|
|
|
),
|
2014-07-14 17:33:33 +02:00
|
|
|
'e9581f08' => array(
|
2014-07-23 19:34:08 +02:00
|
|
|
'javelin-behavior',
|
|
|
|
'javelin-stratcom',
|
|
|
|
'javelin-workflow',
|
|
|
|
'javelin-dom',
|
|
|
|
'phabricator-draggable-list',
|
2014-06-23 19:27:47 +02:00
|
|
|
),
|
2015-01-14 22:08:08 +01:00
|
|
|
'ea681761' => array(
|
|
|
|
'javelin-behavior',
|
|
|
|
'javelin-aphlict',
|
|
|
|
'phabricator-phtize',
|
|
|
|
'javelin-dom',
|
|
|
|
),
|
2014-07-14 17:33:33 +02:00
|
|
|
'efe49472' => array(
|
2014-07-23 19:34:08 +02:00
|
|
|
'javelin-install',
|
|
|
|
'javelin-util',
|
2014-01-01 03:04:25 +01:00
|
|
|
),
|
2014-12-30 11:53:27 +01:00
|
|
|
'f24f3253' => array(
|
|
|
|
'javelin-behavior',
|
|
|
|
'javelin-dom',
|
|
|
|
'javelin-util',
|
|
|
|
'phabricator-prefab',
|
|
|
|
'multirow-row-manager',
|
|
|
|
'javelin-json',
|
|
|
|
),
|
2014-07-14 17:33:33 +02:00
|
|
|
'f36e01af' => array(
|
2014-07-23 19:34:08 +02:00
|
|
|
'javelin-behavior',
|
|
|
|
'javelin-behavior-device',
|
|
|
|
'javelin-stratcom',
|
|
|
|
'javelin-vector',
|
|
|
|
'phabricator-hovercard',
|
2014-06-23 19:27:47 +02:00
|
|
|
),
|
2014-07-14 17:33:33 +02:00
|
|
|
'f3fef818' => array(
|
2014-07-23 19:34:08 +02:00
|
|
|
'javelin-behavior',
|
|
|
|
'javelin-dom',
|
|
|
|
'javelin-util',
|
|
|
|
'phuix-dropdown-menu',
|
|
|
|
'phuix-action-list-view',
|
|
|
|
'phuix-action-view',
|
|
|
|
'javelin-workflow',
|
2014-05-29 05:56:20 +02:00
|
|
|
),
|
2014-07-14 17:33:33 +02:00
|
|
|
'f6555212' => array(
|
2014-07-23 19:34:08 +02:00
|
|
|
'javelin-install',
|
|
|
|
'javelin-reactornode',
|
|
|
|
'javelin-util',
|
|
|
|
'javelin-reactor',
|
2014-02-27 20:06:55 +01:00
|
|
|
),
|
2014-07-14 17:33:33 +02:00
|
|
|
'f7379f45' => array(
|
2014-07-23 19:34:08 +02:00
|
|
|
'javelin-behavior',
|
|
|
|
'javelin-dom',
|
|
|
|
'javelin-util',
|
|
|
|
'phabricator-shaped-request',
|
2014-01-01 03:04:25 +01:00
|
|
|
),
|
2014-07-14 17:33:33 +02:00
|
|
|
'f7f1289f' => array(
|
2014-07-23 19:34:08 +02:00
|
|
|
'javelin-behavior',
|
|
|
|
'javelin-dom',
|
|
|
|
'javelin-stratcom',
|
2014-02-27 20:06:55 +01:00
|
|
|
),
|
2014-07-14 17:33:33 +02:00
|
|
|
'f7fc67ec' => array(
|
2014-07-23 19:34:08 +02:00
|
|
|
'javelin-install',
|
|
|
|
'javelin-typeahead',
|
|
|
|
'javelin-dom',
|
|
|
|
'javelin-request',
|
|
|
|
'javelin-typeahead-ondemand-source',
|
|
|
|
'javelin-util',
|
2014-01-01 03:04:25 +01:00
|
|
|
),
|
2014-07-14 17:33:33 +02:00
|
|
|
'f8248bc5' => array(
|
2014-07-23 19:34:08 +02:00
|
|
|
'javelin-behavior',
|
|
|
|
'javelin-dom',
|
|
|
|
'javelin-util',
|
|
|
|
'javelin-json',
|
|
|
|
'javelin-stratcom',
|
|
|
|
'phabricator-shaped-request',
|
2014-01-01 03:04:25 +01:00
|
|
|
),
|
2015-01-14 01:10:57 +01:00
|
|
|
'f829edb3' => array(
|
|
|
|
'javelin-view',
|
|
|
|
'javelin-install',
|
|
|
|
'javelin-dom',
|
|
|
|
),
|
2014-12-23 18:28:57 +01:00
|
|
|
'f8ba29d7' => array(
|
|
|
|
'javelin-behavior',
|
|
|
|
'javelin-stratcom',
|
|
|
|
'javelin-dom',
|
|
|
|
'javelin-mask',
|
|
|
|
'javelin-util',
|
|
|
|
'phabricator-busy',
|
|
|
|
),
|
2014-07-14 17:33:33 +02:00
|
|
|
'f9539603' => array(
|
2014-07-23 19:34:08 +02:00
|
|
|
'javelin-behavior',
|
|
|
|
'javelin-dom',
|
|
|
|
'javelin-stratcom',
|
|
|
|
'javelin-uri',
|
2014-01-01 03:04:25 +01:00
|
|
|
),
|
Quicksand, an ignoble successor to Quickling
Summary:
Ref T2086. Ref T7014. With the persistent column, there is significant value in retaining chrome state through navigation events, because the user may have a lot of state in the chat window (scroll position, text selection, room juggling, partially entered text, etc). We can do this by capturing navigation events and faking them with Javascript.
(This can also improve performance, albeit slightly, and I believe there are better approaches to tackle performance any problems which exist with the chrome in many cases).
At Facebook, this system was "Photostream" in photos and then "Quickling" in general, and the technical cost of the system was //staggering//. I am loathe to pursue it again. However:
- Browsers are less junky now, and we target a smaller set of browsers. A large part of the technical cost of Quickling was the high complexity of emulating nagivation events in IE, where we needed to navigate a hidden iframe to make history entries. All desktop browsers which we might want to use this system on support the History API (although this prototype does not yet implement it).
- Javelin and Phabricator's architecture are much cleaner than Facebook's was. A large part of the technical cost of Quickling was inconsistency, inlined `onclick` handlers, and general lack of coordination and abstraction. We will have //some// of this, but "correctly written" behaviors are mostly immune to it by design, and many of Javelin's architectural decisions were influenced by desire to avoid issues we encountered building this stuff for Facebook.
- Some of the primitives which Quickling required (like loading resources over Ajax) have existed in a stable state in our codebase for a year or more, and adoption of these primitives was trivial and uneventful (vs a huge production at Facebook).
- My hubris is bolstered by recent success with WebSockets and JX.Scrollbar, both of which I would have assessed as infeasibly complex to develop in this project a few years ago.
To these points, the developer cost to prototype Photostream was several weeks; the developer cost to prototype this was a bit less than an hour. It is plausible to me that implementing and maintaining this system really will be hundreds of times less complex than it was at Facebook.
Test Plan:
My plan for this and D11497 is:
- Get them in master.
- Some secret key / relatively-hidden preference activates the column.
- Quicksand activates //only// when the column is open.
- We can use column + quicksand for a long period of time (i.e., over the course of Conpherence v2 development) and hammer out the long tail of issues.
- When it derps up, you just hide the column and you're good to go.
Reviewers: btrahan, chad
Reviewed By: chad
Subscribers: epriestley
Maniphest Tasks: T2086, T7014
Differential Revision: https://secure.phabricator.com/D11507
2015-01-27 23:52:09 +01:00
|
|
|
'f960d43d' => array(
|
|
|
|
'javelin-install',
|
|
|
|
),
|
2014-07-14 17:33:33 +02:00
|
|
|
'fa0f4fc2' => array(
|
2014-07-23 19:34:08 +02:00
|
|
|
'javelin-behavior',
|
|
|
|
'javelin-dom',
|
|
|
|
'javelin-vector',
|
|
|
|
'javelin-magical-init',
|
2014-03-25 21:49:33 +01:00
|
|
|
),
|
2014-12-30 11:53:27 +01:00
|
|
|
'fc91ab6c' => array(
|
|
|
|
'javelin-behavior',
|
|
|
|
'javelin-dom',
|
|
|
|
'phortune-credit-card-form',
|
|
|
|
),
|
Make "Show Context" persist rendering, whitespace, encoding, etc
Summary:
Ref T2009. Currently, we do not persist view parameters when making context rendering requests.
The big one is the renderer (1up vs 2up). This makes context on unified diffs come in with too many columns.
However, it impacts other parameters too. For example, at HEAD, if you change highlighting to "rainbow" and then load more context, the context uses the original highlighter instead of the rainbow highlighter.
This moves context loads into ChangesetViewManager, which maintains view parameters and can provide them correctly.
- This removes "ref"; it is no longer required, as the ChangesetViewManager tracks it.
- This removes URI management from `behavior-show-more`; it is no longer required, since the ChangesetViewManager knows how to render.
- This removes "whitespace" since this is handled properly by the view manager.
Test Plan:
- Used "Show Top" / "Show All" / "Show Bottom" in 1-up and 2-up views.
- Changed file highlighting to rainbow, loaded stuff, saw rainbow stick.
- Used "Show Entire File" in 1-up and 2-up views.
- Saw loading chrome.
- No loading chrome normally.
- Made inlines, verified `copyRows()` code runs.
- Poked around Diffusion -- it is missing some parameter handling, but works OK.
Reviewers: btrahan
Reviewed By: btrahan
Subscribers: epriestley
Maniphest Tasks: T2009
Differential Revision: https://secure.phabricator.com/D11977
2015-03-05 23:03:00 +01:00
|
|
|
'fce415a0' => array(
|
|
|
|
'javelin-dom',
|
|
|
|
'javelin-util',
|
|
|
|
'javelin-stratcom',
|
|
|
|
'javelin-install',
|
|
|
|
'javelin-workflow',
|
|
|
|
'javelin-router',
|
|
|
|
'javelin-behavior-device',
|
|
|
|
'javelin-vector',
|
|
|
|
),
|
2015-01-14 01:10:57 +01:00
|
|
|
'fe287620' => array(
|
2014-07-23 19:34:08 +02:00
|
|
|
'javelin-install',
|
|
|
|
'javelin-dom',
|
2015-01-14 01:10:57 +01:00
|
|
|
'javelin-view-visitor',
|
|
|
|
'javelin-util',
|
2014-07-13 18:18:50 +02:00
|
|
|
),
|
2014-07-18 00:56:20 +02:00
|
|
|
'fe9a552f' => array(
|
2014-07-23 19:34:08 +02:00
|
|
|
'javelin-behavior',
|
|
|
|
'multirow-row-manager',
|
|
|
|
'javelin-dom',
|
|
|
|
'javelin-util',
|
|
|
|
'phabricator-prefab',
|
|
|
|
'javelin-json',
|
2014-07-18 00:56:20 +02:00
|
|
|
),
|
2014-01-01 03:04:25 +01:00
|
|
|
),
|
2014-07-14 17:33:33 +02:00
|
|
|
'packages' => array(
|
|
|
|
'core.pkg.css' => array(
|
2014-07-23 19:34:08 +02:00
|
|
|
'phabricator-core-css',
|
|
|
|
'phabricator-zindex-css',
|
|
|
|
'phui-button-css',
|
|
|
|
'phabricator-standard-page-view',
|
|
|
|
'aphront-dialog-view-css',
|
|
|
|
'phui-form-view-css',
|
|
|
|
'aphront-panel-view-css',
|
|
|
|
'aphront-table-view-css',
|
|
|
|
'aphront-tokenizer-control-css',
|
|
|
|
'aphront-typeahead-control-css',
|
|
|
|
'aphront-list-filter-view-css',
|
|
|
|
'phabricator-remarkup-css',
|
|
|
|
'syntax-highlighting-css',
|
|
|
|
'aphront-pager-view-css',
|
|
|
|
'phabricator-transaction-view-css',
|
|
|
|
'aphront-tooltip-css',
|
|
|
|
'phabricator-flag-css',
|
2015-03-01 23:45:56 +01:00
|
|
|
'phui-info-view-css',
|
2014-07-23 19:34:08 +02:00
|
|
|
'sprite-gradient-css',
|
|
|
|
'sprite-menu-css',
|
|
|
|
'phabricator-main-menu-view',
|
|
|
|
'phabricator-notification-css',
|
|
|
|
'phabricator-notification-menu-css',
|
|
|
|
'lightbox-attachment-css',
|
|
|
|
'phui-header-view-css',
|
|
|
|
'phabricator-filetree-view-css',
|
|
|
|
'phabricator-nav-view-css',
|
|
|
|
'phabricator-side-menu-view-css',
|
2015-01-23 22:30:00 +01:00
|
|
|
'phui-crumbs-view-css',
|
2014-07-23 19:34:08 +02:00
|
|
|
'phui-object-item-list-view-css',
|
|
|
|
'global-drag-and-drop-css',
|
|
|
|
'phui-spacing-css',
|
|
|
|
'phui-form-css',
|
|
|
|
'phui-icon-view-css',
|
|
|
|
'phabricator-application-launch-view-css',
|
|
|
|
'phabricator-action-list-view-css',
|
|
|
|
'phui-property-list-view-css',
|
|
|
|
'phui-tag-view-css',
|
|
|
|
'phui-list-view-css',
|
|
|
|
'font-fontawesome',
|
|
|
|
'phui-font-icon-base-css',
|
|
|
|
'sprite-main-header-css',
|
|
|
|
'phui-box-css',
|
|
|
|
'phui-object-box-css',
|
|
|
|
'phui-timeline-view-css',
|
|
|
|
'sprite-tokens-css',
|
|
|
|
'tokens-css',
|
|
|
|
'phui-status-list-view-css',
|
Rewrite Aphlict to use Websockets
Summary:
Fixes T6559. No more flash, use Websockets. This is less aggressive than the earlier version, and retains more server logic.
- Support "wss".
- Make the client work.
- Remove "notification.user" entirely.
- Seems ok?
Test Plan:
In Safari, Firefox and Chrome, saw the browsers connect. Made a bunch of comments/updates and saw notifications.
Notable holes in the test plan:
- Haven't tested "wss" yet. I'll do this on secure.
- Notifications are //too fast// now, locally. I get them after I hit submit but before the page reloads.
- There are probably some other rough edges, this is a fairly big patch.
Reviewers: joshuaspence, btrahan
Reviewed By: joshuaspence, btrahan
Subscribers: fabe, btrahan, epriestley
Maniphest Tasks: T6713, T6559
Differential Revision: https://secure.phabricator.com/D11143
2015-01-08 19:03:00 +01:00
|
|
|
'phui-feed-story-css',
|
|
|
|
'phabricator-feed-css',
|
|
|
|
'phabricator-dashboard-css',
|
|
|
|
'aphront-multi-column-view-css',
|
|
|
|
'phui-action-header-view-css',
|
2014-01-01 03:04:25 +01:00
|
|
|
),
|
2014-07-14 17:33:33 +02:00
|
|
|
'core.pkg.js' => array(
|
2014-07-23 19:34:08 +02:00
|
|
|
'javelin-util',
|
|
|
|
'javelin-install',
|
|
|
|
'javelin-event',
|
|
|
|
'javelin-stratcom',
|
|
|
|
'javelin-behavior',
|
|
|
|
'javelin-resource',
|
|
|
|
'javelin-request',
|
|
|
|
'javelin-vector',
|
|
|
|
'javelin-dom',
|
|
|
|
'javelin-json',
|
|
|
|
'javelin-uri',
|
|
|
|
'javelin-workflow',
|
|
|
|
'javelin-mask',
|
|
|
|
'javelin-typeahead',
|
|
|
|
'javelin-typeahead-normalizer',
|
|
|
|
'javelin-typeahead-source',
|
|
|
|
'javelin-typeahead-preloaded-source',
|
|
|
|
'javelin-typeahead-ondemand-source',
|
|
|
|
'javelin-tokenizer',
|
|
|
|
'javelin-history',
|
|
|
|
'javelin-router',
|
|
|
|
'javelin-routable',
|
|
|
|
'javelin-behavior-aphront-basic-tokenizer',
|
|
|
|
'javelin-behavior-workflow',
|
|
|
|
'javelin-behavior-aphront-form-disable-on-submit',
|
|
|
|
'phabricator-keyboard-shortcut-manager',
|
|
|
|
'phabricator-keyboard-shortcut',
|
|
|
|
'javelin-behavior-phabricator-keyboard-shortcuts',
|
|
|
|
'javelin-behavior-refresh-csrf',
|
|
|
|
'javelin-behavior-phabricator-watch-anchor',
|
|
|
|
'javelin-behavior-phabricator-autofocus',
|
|
|
|
'phuix-dropdown-menu',
|
|
|
|
'phuix-action-list-view',
|
|
|
|
'phuix-action-view',
|
|
|
|
'phabricator-phtize',
|
|
|
|
'javelin-behavior-phabricator-oncopy',
|
|
|
|
'phabricator-tooltip',
|
|
|
|
'javelin-behavior-phabricator-tooltips',
|
|
|
|
'phabricator-prefab',
|
|
|
|
'javelin-behavior-device',
|
|
|
|
'javelin-behavior-toggle-class',
|
|
|
|
'javelin-behavior-lightbox-attachments',
|
|
|
|
'phabricator-busy',
|
|
|
|
'javelin-aphlict',
|
|
|
|
'phabricator-notification',
|
|
|
|
'javelin-behavior-aphlict-listen',
|
|
|
|
'javelin-behavior-phabricator-search-typeahead',
|
|
|
|
'javelin-behavior-konami',
|
|
|
|
'javelin-behavior-aphlict-dropdown',
|
|
|
|
'javelin-behavior-history-install',
|
|
|
|
'javelin-behavior-phabricator-gesture',
|
|
|
|
'javelin-behavior-phabricator-active-nav',
|
|
|
|
'javelin-behavior-phabricator-nav',
|
|
|
|
'javelin-behavior-phabricator-remarkup-assist',
|
|
|
|
'phabricator-textareautils',
|
|
|
|
'phabricator-file-upload',
|
|
|
|
'javelin-behavior-global-drag-and-drop',
|
|
|
|
'javelin-behavior-phabricator-reveal-content',
|
|
|
|
'phabricator-hovercard',
|
|
|
|
'javelin-behavior-phabricator-hovercards',
|
|
|
|
'javelin-color',
|
|
|
|
'javelin-fx',
|
|
|
|
'phabricator-draggable-list',
|
|
|
|
'javelin-behavior-phabricator-transaction-list',
|
2014-12-04 23:55:18 +01:00
|
|
|
'javelin-behavior-phabricator-show-older-transactions',
|
2014-07-23 19:34:08 +02:00
|
|
|
'javelin-behavior-phui-timeline-dropdown-menu',
|
|
|
|
'javelin-behavior-doorkeeper-tag',
|
Rewrite Aphlict to use Websockets
Summary:
Fixes T6559. No more flash, use Websockets. This is less aggressive than the earlier version, and retains more server logic.
- Support "wss".
- Make the client work.
- Remove "notification.user" entirely.
- Seems ok?
Test Plan:
In Safari, Firefox and Chrome, saw the browsers connect. Made a bunch of comments/updates and saw notifications.
Notable holes in the test plan:
- Haven't tested "wss" yet. I'll do this on secure.
- Notifications are //too fast// now, locally. I get them after I hit submit but before the page reloads.
- There are probably some other rough edges, this is a fairly big patch.
Reviewers: joshuaspence, btrahan
Reviewed By: joshuaspence, btrahan
Subscribers: fabe, btrahan, epriestley
Maniphest Tasks: T6713, T6559
Differential Revision: https://secure.phabricator.com/D11143
2015-01-08 19:03:00 +01:00
|
|
|
'phabricator-title',
|
|
|
|
'javelin-leader',
|
|
|
|
'javelin-websocket',
|
|
|
|
'javelin-behavior-dashboard-async-panel',
|
|
|
|
'javelin-behavior-dashboard-tab-panel',
|
2014-01-01 03:04:25 +01:00
|
|
|
),
|
2014-07-14 17:33:33 +02:00
|
|
|
'darkconsole.pkg.js' => array(
|
2014-07-23 19:34:08 +02:00
|
|
|
'javelin-behavior-dark-console',
|
|
|
|
'javelin-behavior-error-log',
|
2014-01-01 03:04:25 +01:00
|
|
|
),
|
2014-07-14 17:33:33 +02:00
|
|
|
'differential.pkg.css' => array(
|
2014-07-23 19:34:08 +02:00
|
|
|
'differential-core-view-css',
|
|
|
|
'differential-changeset-view-css',
|
|
|
|
'differential-results-table-css',
|
|
|
|
'differential-revision-history-css',
|
|
|
|
'differential-revision-list-css',
|
|
|
|
'differential-table-of-contents-css',
|
|
|
|
'differential-revision-comment-css',
|
|
|
|
'differential-revision-add-comment-css',
|
|
|
|
'phabricator-object-selector-css',
|
|
|
|
'phabricator-content-source-view-css',
|
|
|
|
'inline-comment-summary-css',
|
2014-01-01 03:04:25 +01:00
|
|
|
),
|
2014-07-14 17:33:33 +02:00
|
|
|
'differential.pkg.js' => array(
|
2014-07-23 19:34:08 +02:00
|
|
|
'phabricator-drag-and-drop-file-upload',
|
|
|
|
'phabricator-shaped-request',
|
|
|
|
'javelin-behavior-differential-feedback-preview',
|
|
|
|
'javelin-behavior-differential-edit-inline-comments',
|
|
|
|
'javelin-behavior-differential-populate',
|
|
|
|
'javelin-behavior-differential-diff-radios',
|
|
|
|
'javelin-behavior-differential-comment-jump',
|
|
|
|
'javelin-behavior-differential-add-reviewers-and-ccs',
|
|
|
|
'javelin-behavior-differential-keyboard-navigation',
|
|
|
|
'javelin-behavior-aphront-drag-and-drop-textarea',
|
|
|
|
'javelin-behavior-phabricator-object-selector',
|
|
|
|
'javelin-behavior-repository-crossreference',
|
|
|
|
'javelin-behavior-load-blame',
|
|
|
|
'differential-inline-comment-editor',
|
|
|
|
'javelin-behavior-differential-dropdown-menus',
|
|
|
|
'javelin-behavior-differential-toggle-files',
|
|
|
|
'javelin-behavior-differential-user-select',
|
|
|
|
'javelin-behavior-aphront-more',
|
2014-01-01 03:04:25 +01:00
|
|
|
),
|
2014-07-14 17:33:33 +02:00
|
|
|
'diffusion.pkg.css' => array(
|
2014-07-23 19:34:08 +02:00
|
|
|
'diffusion-icons-css',
|
2014-01-01 03:04:25 +01:00
|
|
|
),
|
2014-07-14 17:33:33 +02:00
|
|
|
'diffusion.pkg.js' => array(
|
2014-07-23 19:34:08 +02:00
|
|
|
'javelin-behavior-diffusion-pull-lastmodified',
|
|
|
|
'javelin-behavior-diffusion-commit-graph',
|
|
|
|
'javelin-behavior-audit-preview',
|
2014-01-01 03:04:25 +01:00
|
|
|
),
|
2014-07-14 17:33:33 +02:00
|
|
|
'maniphest.pkg.css' => array(
|
2014-07-23 19:34:08 +02:00
|
|
|
'maniphest-task-summary-css',
|
2014-01-01 03:04:25 +01:00
|
|
|
),
|
2014-07-14 17:33:33 +02:00
|
|
|
'maniphest.pkg.js' => array(
|
2014-07-23 19:34:08 +02:00
|
|
|
'javelin-behavior-maniphest-batch-selector',
|
|
|
|
'javelin-behavior-maniphest-transaction-controls',
|
|
|
|
'javelin-behavior-maniphest-transaction-preview',
|
|
|
|
'javelin-behavior-maniphest-transaction-expand',
|
|
|
|
'javelin-behavior-maniphest-subpriority-editor',
|
|
|
|
'javelin-behavior-maniphest-list-editor',
|
2014-01-01 03:04:25 +01:00
|
|
|
),
|
|
|
|
),
|
|
|
|
);
|