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(
|
2017-07-17 20:08:17 +02:00
|
|
|
'conpherence.pkg.css' => 'e68cf1fa',
|
2017-10-09 19:52:27 +02:00
|
|
|
'conpherence.pkg.js' => '15191c65',
|
2018-12-18 21:37:00 +01:00
|
|
|
'core.pkg.css' => '47535fd5',
|
Remove "willRenderTimeline()" from ApplicationTransactionInterface
Summary:
Depends on D19914. Ref T11351. Some of the Phoilo rabbit holes go very deep.
`PhabricatorApplicationTransactionInterface` currently requires you to implement `willRenderTimeline()`. Almost every object just implements this as `return $timeline`; only Pholio, Diffusion, and Differential specialize it. In all cases, they are specializing it mostly to render inline comments.
The actual implementations are a bit of a weird mess and the way the data is threaded through the call stack is weird and not very modern.
Try to clean this up:
- Stop requiring `willRenderTimeline()` to be implemented.
- Stop requiring `getApplicationTransactionViewObject()` to be implemented (only the three above, plus Legalpad, implement this, and Legalpad's implementation is a no-op). These two methods are inherently pretty coupled for almost any reasonable thing you might want to do with the timeline.
- Simplify the handling of "renderdata" and call it "View Data". This is additional information about the current view of the transaction timeline that is required to render it correctly. This is only used in Differential, to decide if we can link an inline comment to an anchor on the same page or should link it to another page. We could perhaps do this on the client instead, but having this data doesn't seem inherently bad to me.
- If objects want to customize timeline rendering, they now implement `PhabricatorTimelineInterface` and provide a `TimelineEngine` which gets a nice formal stack.
This leaves a lot of empty `willRenderTimeline()` implementations hanging around. I'll remove these in the next change, it's just going to be deleting a couple dozen copies of an identical empty method implementation.
Test Plan:
- Viewed audits, revisions, and mocks with inline comments.
- Used "Show Older" to page a revision back in history (this is relevant for "View Data").
- Grepped for symbols: willRenderTimeline, getApplicationTransactionViewObject, Legalpad classes.
Reviewers: amckinley
Reviewed By: amckinley
Maniphest Tasks: T11351
Differential Revision: https://secure.phabricator.com/D19918
2018-12-19 20:52:53 +01:00
|
|
|
'core.pkg.js' => 'bd89cb1d',
|
2018-04-08 20:38:19 +02:00
|
|
|
'differential.pkg.css' => '06dc617c',
|
Pass timeline view data to comment previews, restoring Differential comment previews
Summary:
Ref T13222. In D19918, I refactored how timelines get "view data". Today, this is always additional data about which images/changesets/diffs are visible on the current revision/commit/mock, so we can tell if inline comments should be linked to a `#anchor` on the same page (if the inline is rendered there somewhere) or to a `/D123?id=1&vs=2` full link on a different page (if it isn't), but in general this could be any sort of state information about the current page that affects how the timeline should render.
Previously, comment previews did not use any specialized object code and always rendered a "generic" timeline story. This was actually a bug, but none of the code we have today cares about this (since it's all inline related, and inlines render separately) so it never impacted anything.
After the `TimelineEngine` change, the preview renders with Differential-specific code. This is more correct, but we were not passing the preview the "view data" so it broke.
This preview doesn't actually need the view data and we could just make it bail out if it isn't present, but pass it through for consistency and so this works like we'd expect if we do something fancier with view data in the future.
Test Plan: Viewed comment and inline comment previews in Differential, saw old behavior restored.
Reviewers: amckinley
Reviewed By: amckinley
Maniphest Tasks: T13222
Differential Revision: https://secure.phabricator.com/D19943
2019-01-03 01:48:53 +01:00
|
|
|
'differential.pkg.js' => '853c3461',
|
2017-07-09 04:54:23 +02:00
|
|
|
'diffusion.pkg.css' => 'a2d17c7d',
|
2017-06-07 00:47:47 +02:00
|
|
|
'diffusion.pkg.js' => '6134c5a1',
|
[Redesign] Put all ApplicationSearch results in an ObjectBox
Summary:
Ref T8099. In most cases we return either an ObjectList or AphrontTable, and can pretty up the UI in ApplicationSearch. There are a few edge cases, like PeopleUserLog, that can be cleanup up individually in the future, but look fine for now.
Also added 'setNotice' for AphrontTable for a few cases where we want to convey addtional information.
TODO: Seems we always pass a Pager Object, which tries to get displayed, I'll redesign that interaction in the future, probably by passing the Pager to the ObjectBox
Test Plan: Went throught most/all ApplicationSearch panels I could find, even edge cases look better.
Reviewers: btrahan, epriestley
Reviewed By: epriestley
Subscribers: Korvin, epriestley
Maniphest Tasks: T8099
Differential Revision: https://secure.phabricator.com/D12989
2015-05-24 18:13:58 +02:00
|
|
|
'maniphest.pkg.css' => '4845691a',
|
2017-11-30 14:57:39 +01:00
|
|
|
'maniphest.pkg.js' => '4d7e79c8',
|
2017-04-19 22:35:56 +02:00
|
|
|
'rsrc/audio/basic/alert.mp3' => '98461568',
|
|
|
|
'rsrc/audio/basic/bing.mp3' => 'ab8603a5',
|
|
|
|
'rsrc/audio/basic/pock.mp3' => '0cc772f5',
|
2017-04-18 18:26:21 +02:00
|
|
|
'rsrc/audio/basic/tap.mp3' => 'fc2fd796',
|
2017-04-19 22:35:56 +02:00
|
|
|
'rsrc/audio/basic/ting.mp3' => '17660001',
|
2014-01-01 16:46:25 +01:00
|
|
|
'rsrc/css/aphront/aphront-bars.css' => '231ac33c',
|
2018-03-14 18:55:08 +01:00
|
|
|
'rsrc/css/aphront/dark-console.css' => '0e14e8f6',
|
2017-08-10 05:01:31 +02:00
|
|
|
'rsrc/css/aphront/dialog-view.css' => '6bfc244b',
|
2015-09-08 02:18:35 +02:00
|
|
|
'rsrc/css/aphront/list-filter-view.css' => '5d6f0526',
|
2016-09-29 07:27:19 +02:00
|
|
|
'rsrc/css/aphront/multi-column.css' => '84cc6640',
|
2017-08-28 23:51:00 +02:00
|
|
|
'rsrc/css/aphront/notification.css' => '457861ec',
|
2015-03-07 01:44:18 +01:00
|
|
|
'rsrc/css/aphront/panel-view.css' => '8427b78d',
|
2018-04-11 18:40:05 +02:00
|
|
|
'rsrc/css/aphront/phabricator-nav-view.css' => '694d7723',
|
Mobile layouts for Diffusion
Summary: Implements a new mobile view thats more fullscreen, not boxed, so more space. Fixes issues with mobile tables when scrolling overflowed content.
Test Plan: Test home, branch, tags, code, file browse, graph, compare, history, readme, open revisions, owners.
Reviewers: epriestley
Reviewed By: epriestley
Spies: Korvin
Differential Revision: https://secure.phabricator.com/D18505
2017-08-30 21:00:07 +02:00
|
|
|
'rsrc/css/aphront/table-view.css' => '8c9bbafe',
|
2017-06-01 22:30:00 +02:00
|
|
|
'rsrc/css/aphront/tokenizer.css' => '15d5ff71',
|
2018-11-15 13:03:47 +01:00
|
|
|
'rsrc/css/aphront/tooltip.css' => 'cb1397a4',
|
2017-07-17 20:08:17 +02:00
|
|
|
'rsrc/css/aphront/typeahead-browse.css' => 'f2818435',
|
2017-08-14 20:18:29 +02:00
|
|
|
'rsrc/css/aphront/typeahead.css' => 'a4a21016',
|
2014-12-17 20:10:50 +01:00
|
|
|
'rsrc/css/application/almanac/almanac.css' => 'dbb9b3af',
|
2015-07-18 17:51:25 +02:00
|
|
|
'rsrc/css/application/auth/auth.css' => '0877ed6e',
|
2017-08-25 18:34:51 +02:00
|
|
|
'rsrc/css/application/base/main-menu-view.css' => '1802a242',
|
Fix the most significant "phantom notification" badness
Summary:
Ref T13124. Ref T13131. Fixes T8953. See PHI512.
When you receieve a notification about an object and then someone hides that object from you (or deletes it), you get a phantom notification which is very difficult to clear.
For now, test that notifications are visible when you open the menu and clear any that are not.
This could be a little more elegant than it is, but the current behavior is very clearly broken. This unbreaks it, at least.
Test Plan:
- As Alice, configured task stuff to notify me (instead of sending email).
- As Bailey, added Alice as a subscriber to a task, then commented on it.
- As Alice, loaded home and saw a notification count. Didn't click it yet.
- As Bailey, set the task to private.
- As Alice, clicked the notification bell menu icon.
- Before change: no unread notifications, bell menu is semi-stuck in a phantom state which you can't clear.
- After change: bad notifications automatically cleared.
{F5530005}
Reviewers: amckinley
Reviewed By: amckinley
Maniphest Tasks: T13131, T13124, T8953
Differential Revision: https://secure.phabricator.com/D19384
2018-04-19 19:49:30 +02:00
|
|
|
'rsrc/css/application/base/notification-menu.css' => 'ef480927',
|
2017-01-31 17:58:33 +01:00
|
|
|
'rsrc/css/application/base/phui-theme.css' => '9f261c6b',
|
2017-08-17 18:02:43 +02:00
|
|
|
'rsrc/css/application/base/standard-page-view.css' => '34ee718b',
|
2015-06-26 18:33:03 +02:00
|
|
|
'rsrc/css/application/chatlog/chatlog.css' => 'd295b020',
|
2015-05-08 21:19:52 +02:00
|
|
|
'rsrc/css/application/conduit/conduit-api.css' => '7bc725c4',
|
2017-09-06 00:21:12 +02:00
|
|
|
'rsrc/css/application/config/config-options.css' => '4615667b',
|
2016-09-06 22:48:22 +02:00
|
|
|
'rsrc/css/application/config/config-template.css' => '8f18fa41',
|
2018-03-13 20:14:36 +01:00
|
|
|
'rsrc/css/application/config/setup-issue.css' => '30ee0173',
|
2015-05-20 04:38:34 +02:00
|
|
|
'rsrc/css/application/config/unhandled-exception.css' => '4c96257a',
|
2017-04-20 23:23:23 +02:00
|
|
|
'rsrc/css/application/conpherence/color.css' => 'abb4c358',
|
2017-04-13 20:20:51 +02:00
|
|
|
'rsrc/css/application/conpherence/durable-column.css' => '89ea6bef',
|
2017-04-20 23:23:23 +02:00
|
|
|
'rsrc/css/application/conpherence/header-pane.css' => 'cb6f4e19',
|
2017-07-17 20:08:17 +02:00
|
|
|
'rsrc/css/application/conpherence/menu.css' => '69368e97',
|
2017-04-18 22:37:52 +02:00
|
|
|
'rsrc/css/application/conpherence/message-pane.css' => 'b0f55ecc',
|
2017-04-13 05:44:32 +02:00
|
|
|
'rsrc/css/application/conpherence/notification.css' => 'cef0a3fc',
|
2017-04-17 19:59:11 +02:00
|
|
|
'rsrc/css/application/conpherence/participant-pane.css' => '26a3ce56',
|
2016-10-15 15:58:46 +02:00
|
|
|
'rsrc/css/application/conpherence/transaction.css' => '85129c68',
|
2014-01-01 16:46:25 +01:00
|
|
|
'rsrc/css/application/contentsource/content-source-view.css' => '4b8b05d4',
|
2016-04-09 19:07:02 +02:00
|
|
|
'rsrc/css/application/countdown/timer.css' => '16c52f5c',
|
2015-06-23 22:43:47 +02:00
|
|
|
'rsrc/css/application/daemon/bulk-job.css' => 'df9c1d4a',
|
2017-03-02 06:56:57 +01:00
|
|
|
'rsrc/css/application/dashboard/dashboard.css' => 'fe5b1869',
|
2017-07-17 20:08:17 +02:00
|
|
|
'rsrc/css/application/diff/inline-comment-summary.css' => 'f23d4e8f',
|
2015-03-28 00:00:09 +01:00
|
|
|
'rsrc/css/application/differential/add-comment.css' => 'c47f8c40',
|
2018-04-08 20:38:19 +02:00
|
|
|
'rsrc/css/application/differential/changeset-view.css' => 'db34a142',
|
2016-03-12 22:02:32 +01:00
|
|
|
'rsrc/css/application/differential/core.css' => '5b7b8ff4',
|
2017-07-19 23:38:55 +02:00
|
|
|
'rsrc/css/application/differential/phui-inline-comment.css' => '65ae3bc2',
|
2015-05-04 21:21:21 +02:00
|
|
|
'rsrc/css/application/differential/revision-comment.css' => '14b8565a',
|
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',
|
2015-06-23 22:43:47 +02:00
|
|
|
'rsrc/css/application/differential/table-of-contents.css' => 'ae4b7a55',
|
2017-07-09 04:54:23 +02:00
|
|
|
'rsrc/css/application/diffusion/diffusion-icons.css' => '0c15255e',
|
2017-06-07 00:29:57 +02:00
|
|
|
'rsrc/css/application/diffusion/diffusion-readme.css' => '419dd5b6',
|
Move Diffusion Browse to a single column layout
Summary: The main change here is moving (compare, search, history) into buttons in the header bar on all browse views. This allows Directory Browsing to be full width, since there is no other curtain information. File, Image, LFS, Binary all stay in TwoColumn layouts with the same buttons in the header.
Test Plan: Test viewing a directory, file, image, binary file, readme, and fake a gitlfs.
Reviewers: epriestley
Reviewed By: epriestley
Subscribers: Korvin
Differential Revision: https://secure.phabricator.com/D17766
2017-07-01 17:38:17 +02:00
|
|
|
'rsrc/css/application/diffusion/diffusion-repository.css' => 'ee6f20ec',
|
2017-08-30 21:56:47 +02:00
|
|
|
'rsrc/css/application/diffusion/diffusion.css' => '45727264',
|
2015-05-28 20:47:06 +02:00
|
|
|
'rsrc/css/application/feed/feed.css' => 'ecd4ec57',
|
2017-07-17 20:08:17 +02:00
|
|
|
'rsrc/css/application/files/global-drag-and-drop.css' => 'b556a948',
|
2016-12-14 20:35:51 +01:00
|
|
|
'rsrc/css/application/flag/flag.css' => 'bba8f811',
|
2018-08-28 22:02:17 +02:00
|
|
|
'rsrc/css/application/harbormaster/harbormaster.css' => '7446ce72',
|
2015-07-18 14:54:26 +02:00
|
|
|
'rsrc/css/application/herald/herald-test.css' => 'a52e323e',
|
2017-12-11 20:33:15 +01:00
|
|
|
'rsrc/css/application/herald/herald.css' => 'cd8d0134',
|
2016-01-28 05:56:36 +01:00
|
|
|
'rsrc/css/application/maniphest/report.css' => '9b9580b7',
|
2015-06-26 18:33:03 +02:00
|
|
|
'rsrc/css/application/maniphest/task-edit.css' => 'fda62a9b',
|
[Redesign] Put all ApplicationSearch results in an ObjectBox
Summary:
Ref T8099. In most cases we return either an ObjectList or AphrontTable, and can pretty up the UI in ApplicationSearch. There are a few edge cases, like PeopleUserLog, that can be cleanup up individually in the future, but look fine for now.
Also added 'setNotice' for AphrontTable for a few cases where we want to convey addtional information.
TODO: Seems we always pass a Pager Object, which tries to get displayed, I'll redesign that interaction in the future, probably by passing the Pager to the ObjectBox
Test Plan: Went throught most/all ApplicationSearch panels I could find, even edge cases look better.
Reviewers: btrahan, epriestley
Reviewed By: epriestley
Subscribers: Korvin, epriestley
Maniphest Tasks: T8099
Differential Revision: https://secure.phabricator.com/D12989
2015-05-24 18:13:58 +02:00
|
|
|
'rsrc/css/application/maniphest/task-summary.css' => '11cc5344',
|
2015-07-02 23:39:43 +02:00
|
|
|
'rsrc/css/application/objectselector/object-selector.css' => '85ee8ce6',
|
Use a tokenizer, not a gigantic poorly-ordered "<select />", to choose repositories in Owners
Summary: Depends on D19190. Fixes T12590. Ref T13099. Replaces the barely-usable, gigantic, poorly ordered "<select />" control with a tokenizer. Attempts to fix various minor issues.
Test Plan:
- Edited paths: include/exclude paths, from different repositories, different actual paths.
- Used "Add New Path" to add rows, got repository selector prepopulated with last value.
- Used "remove".
- Used validation typeahead, got reasonable behaviors?
The error behavior if you delete the repository for a path is a little sketchy still, but roughly okay.
Maniphest Tasks: T13099, T12590
Differential Revision: https://secure.phabricator.com/D19191
2018-03-08 02:29:06 +01:00
|
|
|
'rsrc/css/application/owners/owners-path-editor.css' => '9c136c29',
|
2017-07-17 20:08:17 +02:00
|
|
|
'rsrc/css/application/paste/paste.css' => '9fcc9773',
|
2017-02-05 21:45:27 +01:00
|
|
|
'rsrc/css/application/people/people-picture-menu-item.css' => 'a06f7f34',
|
2017-02-09 15:45:47 +01:00
|
|
|
'rsrc/css/application/people/people-profile.css' => '4df76faf',
|
2017-07-17 20:08:17 +02:00
|
|
|
'rsrc/css/application/phame/phame.css' => '8cb3afcd',
|
2016-06-09 17:34:00 +02:00
|
|
|
'rsrc/css/application/pholio/pholio-edit.css' => '07676f51',
|
2014-06-25 00:23:57 +02:00
|
|
|
'rsrc/css/application/pholio/pholio-inline-comments.css' => '8e545e49',
|
2016-02-15 06:29:56 +01:00
|
|
|
'rsrc/css/application/pholio/pholio.css' => 'ca89d380',
|
2015-03-02 22:01:08 +01:00
|
|
|
'rsrc/css/application/phortune/phortune-credit-card-form.css' => '8391eb02',
|
2016-10-30 02:45:10 +02:00
|
|
|
'rsrc/css/application/phortune/phortune-invoice.css' => '476055e2',
|
2016-06-08 05:55:18 +02:00
|
|
|
'rsrc/css/application/phortune/phortune.css' => '5b99dae0',
|
2014-01-06 06:47:21 +01:00
|
|
|
'rsrc/css/application/phrequent/phrequent.css' => 'ffc185ad',
|
2016-04-20 15:00:10 +02:00
|
|
|
'rsrc/css/application/phriction/phriction-document-css.css' => '4282e4ad',
|
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',
|
2016-03-04 00:18:41 +01:00
|
|
|
'rsrc/css/application/ponder/ponder-view.css' => 'fbd45f96',
|
2017-07-17 20:08:17 +02:00
|
|
|
'rsrc/css/application/project/project-card-view.css' => '0010bb52',
|
2017-02-24 22:15:30 +01:00
|
|
|
'rsrc/css/application/project/project-view.css' => '792c9057',
|
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',
|
Mobile layouts for Diffusion
Summary: Implements a new mobile view thats more fullscreen, not boxed, so more space. Fixes issues with mobile tables when scrolling overflowed content.
Test Plan: Test home, branch, tags, code, file browse, graph, compare, history, readme, open revisions, owners.
Reviewers: epriestley
Reviewed By: epriestley
Spies: Korvin
Differential Revision: https://secure.phabricator.com/D18505
2017-08-30 21:00:07 +02:00
|
|
|
'rsrc/css/application/search/application-search-view.css' => '787f5b76',
|
2017-08-15 05:50:06 +02:00
|
|
|
'rsrc/css/application/search/search-results.css' => '505dd8cf',
|
2016-02-26 23:34:51 +01:00
|
|
|
'rsrc/css/application/slowvote/slowvote.css' => 'a94b7230',
|
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',
|
2017-09-25 21:56:22 +02:00
|
|
|
'rsrc/css/core/core.css' => '62fa3ace',
|
2018-06-07 21:22:53 +02:00
|
|
|
'rsrc/css/core/remarkup.css' => 'b182076e',
|
2018-04-08 18:10:03 +02:00
|
|
|
'rsrc/css/core/syntax.css' => 'e9c95dd4',
|
2017-05-30 22:23:54 +02:00
|
|
|
'rsrc/css/core/z-index.css' => '9d8f7c4b',
|
2017-02-14 06:06:01 +01:00
|
|
|
'rsrc/css/diviner/diviner-shared.css' => '896f1d43',
|
2017-02-02 00:25:20 +01:00
|
|
|
'rsrc/css/font/font-awesome.css' => 'e838e088',
|
2015-11-22 22:03:58 +01:00
|
|
|
'rsrc/css/font/font-lato.css' => 'c7ccd872',
|
Redesign Config Application
Summary: Ref T11132, significantly cleans up the Config app, new layout, icons, spacing, etc. Some minor todos around re-designing "issues", mobile support, and maybe another pass at actual Group pages.
Test Plan: Visit and test every page in the config app, set new items, resolve setup issues, etc.
Reviewers: epriestley
Reviewed By: epriestley
Subscribers: PHID-OPKG-gm6ozazyms6q6i22gyam, Korvin
Maniphest Tasks: T11132
Differential Revision: https://secure.phabricator.com/D16468
2016-08-30 00:36:13 +02:00
|
|
|
'rsrc/css/font/phui-font-icon-base.css' => '870a7360',
|
2018-02-09 01:55:54 +01:00
|
|
|
'rsrc/css/layout/phabricator-filetree-view.css' => 'b912ad97',
|
2018-04-20 22:14:44 +02:00
|
|
|
'rsrc/css/layout/phabricator-source-code-view.css' => '2ab25dfa',
|
2017-07-19 23:38:55 +02:00
|
|
|
'rsrc/css/phui/button/phui-button-bar.css' => 'f1ff5494',
|
2017-06-05 22:14:34 +02:00
|
|
|
'rsrc/css/phui/button/phui-button-simple.css' => '8e1baf68',
|
2018-09-11 18:04:44 +02:00
|
|
|
'rsrc/css/phui/button/phui-button.css' => '6ccb303c',
|
2016-07-27 18:07:29 +02:00
|
|
|
'rsrc/css/phui/calendar/phui-calendar-day.css' => '572b1893',
|
2017-02-06 19:50:09 +01:00
|
|
|
'rsrc/css/phui/calendar/phui-calendar-list.css' => '576be600',
|
2017-07-17 20:08:17 +02:00
|
|
|
'rsrc/css/phui/calendar/phui-calendar-month.css' => '21154caf',
|
|
|
|
'rsrc/css/phui/calendar/phui-calendar.css' => 'f1ddf11c',
|
Replace the "Choose Subtype" radio buttons dialog with a simpler "big stuff you click" sort of UI
Summary:
Ref T13222. Fixes T12588. See PHI683. In several cases, we present the user with a choice between multiple major options: Alamnac service types, Drydock blueprint types, Repository VCS types, Herald rule types, etc.
Today, we generally do this with radio buttons and a "Submit" button. This isn't terrible, but often it means users have to click twice (once on the radio; once on submit) when a single click would be sufficient. The radio click target can also be small.
In other cases, we have a container with a link and we'd like to link the entire container: notifications, the `/drydock/` console, etc. We'd like to just link the entire container, but this causes some problems:
- It's not legal to link block eleements like `<a><div> ... </div></a>` and some browsers actually get upset about it.
- We can `<a><span> ... </span></a>` instead, then turn the `<span>` into a block element with CSS -- and this sometimes works, but also has some drawbacks:
- It's not great to do that for screenreaders, since the readable text in the link isn't necessarily very meaningful.
- We can't have any other links inside the element (e.g., details or documentation).
- We can `<form><button> ... </button></form>` instead, but this has its own set of problems:
- You can't right-click to interact with a button in the same way you can with a link.
- Also not great for screenreaders.
Instead, try adding a `linked-container` behavior which just means "when users click this element, pretend they clicked the first link inside it".
This gives us natural HTML (real, legal HTML with actual `<a>` tags) and good screenreader behavior, but allows the effective link target to be visually larger than just the link.
If no issues crop up with this, I'd plan to eventually use this technique in more places (Repositories, Herald, Almanac, Drydock, Notifications menu, etc).
Test Plan:
{F6053035}
- Left-clicked and command-left-clicked the new JS fanciness, got sensible behaviors.
Reviewers: amckinley
Reviewed By: amckinley
Subscribers: PHID-OPKG-gm6ozazyms6q6i22gyam
Maniphest Tasks: T13222, T12588
Differential Revision: https://secure.phabricator.com/D19855
2018-12-07 15:04:07 +01:00
|
|
|
'rsrc/css/phui/object-item/phui-oi-big-ui.css' => '7a7c22af',
|
2016-12-14 20:35:51 +01:00
|
|
|
'rsrc/css/phui/object-item/phui-oi-color.css' => 'cd2b9b77',
|
2017-05-16 06:41:47 +02:00
|
|
|
'rsrc/css/phui/object-item/phui-oi-drag-ui.css' => '08f4ccc3',
|
2016-12-14 20:35:51 +01:00
|
|
|
'rsrc/css/phui/object-item/phui-oi-flush-ui.css' => '9d9685d6',
|
2018-04-19 20:28:24 +02:00
|
|
|
'rsrc/css/phui/object-item/phui-oi-list-view.css' => '7c5c1291',
|
2016-12-14 20:35:51 +01:00
|
|
|
'rsrc/css/phui/object-item/phui-oi-simple-ui.css' => 'a8beebea',
|
2018-02-08 19:37:47 +01:00
|
|
|
'rsrc/css/phui/phui-action-list.css' => '0bcd9a45',
|
2017-07-30 21:21:36 +02:00
|
|
|
'rsrc/css/phui/phui-action-panel.css' => 'b4798122',
|
2017-02-24 22:15:30 +01:00
|
|
|
'rsrc/css/phui/phui-badge.css' => '22c0cf4f',
|
2017-08-29 01:07:22 +02:00
|
|
|
'rsrc/css/phui/phui-basic-nav-view.css' => '98c11ab3',
|
2017-08-04 02:18:30 +02:00
|
|
|
'rsrc/css/phui/phui-big-info-view.css' => 'acc3492c',
|
2017-11-30 14:14:05 +01:00
|
|
|
'rsrc/css/phui/phui-box.css' => '4bd6cdb9',
|
Restore bulk edit support for remarkup fields (description, add comment)
Summary:
Depends on D18866. Ref T13025. Fixes T12415. This makes the old "Add Comment" action work, and adds support for a new "Set description to" action (possibly, I could imagine "append description" being useful some day, maybe).
The implementation is just a `<textarea />`, not a whole fancy remarkup box with `[Bold] [Italic] ...` buttons, preview, typeaheads, etc. It would be nice to enrich this eventually but doing the rendering in pure JS is currently very involved.
This requires a little bit of gymnastics to get the transaction populated properly, and adds some extra validation since we need some code there anyway.
Test Plan:
- Changed the description of a task via bulk editor.
- Added a comment to a task via bulk editor.
Reviewers: amckinley
Reviewed By: amckinley
Maniphest Tasks: T13025, T12415
Differential Revision: https://secure.phabricator.com/D18867
2018-01-11 18:48:33 +01:00
|
|
|
'rsrc/css/phui/phui-bulk-editor.css' => '9a81e5d5',
|
2016-01-28 22:29:27 +01:00
|
|
|
'rsrc/css/phui/phui-chart.css' => '6bf6f78e',
|
2017-02-05 21:45:27 +01:00
|
|
|
'rsrc/css/phui/phui-cms.css' => '504b4b23',
|
2017-07-19 23:38:55 +02:00
|
|
|
'rsrc/css/phui/phui-comment-form.css' => 'ac68149f',
|
2016-12-02 20:00:37 +01:00
|
|
|
'rsrc/css/phui/phui-comment-panel.css' => 'f50152ad',
|
2018-05-09 20:25:08 +02:00
|
|
|
'rsrc/css/phui/phui-crumbs-view.css' => '10728aaa',
|
2017-09-25 21:56:22 +02:00
|
|
|
'rsrc/css/phui/phui-curtain-view.css' => '2bdaf026',
|
2018-10-01 20:06:00 +02:00
|
|
|
'rsrc/css/phui/phui-document-pro.css' => 'dd79b5df',
|
2015-12-19 21:28:18 +01:00
|
|
|
'rsrc/css/phui/phui-document-summary.css' => '9ca48bdf',
|
2018-08-29 18:31:32 +02:00
|
|
|
'rsrc/css/phui/phui-document.css' => 'c4ac41f9',
|
2016-10-11 19:02:22 +02:00
|
|
|
'rsrc/css/phui/phui-feed-story.css' => '44a9c8e9',
|
2017-03-22 17:48:10 +01:00
|
|
|
'rsrc/css/phui/phui-fontkit.css' => '1320ed01',
|
2018-12-18 21:37:00 +01:00
|
|
|
'rsrc/css/phui/phui-form-view.css' => 'b04e08d9',
|
2017-07-28 00:12:48 +02:00
|
|
|
'rsrc/css/phui/phui-form.css' => '7aaa04e3',
|
2016-03-17 20:01:22 +01:00
|
|
|
'rsrc/css/phui/phui-head-thing.css' => 'fd311e5f',
|
Allow DocumentView to render with a curtain, and make Phriction use a curtain
Summary:
Depends on D19616. Ref T13077. Fixes T8172. In the last round of design updates, a lot of actions got stuffed into "Actions" menus.
I never really got used to these and think they're a net usability loss, and broadly agree with the feedback in T8172. I'd generally like to move back toward a state where actions are available on the page, not hidden in a menu.
For now, just put a curtain view on these pages. This could be refined later (e.g., stick this menu to the right hand side of the screen) depending on where other Phriction changes go.
(Broadly, I'm also not satisfied with where we ended up on the fixed-width pages like Diffusion > Manage, Config, and Instances. In contrast, I //do// like where we ended up with Phortune in terms of overall design. I anticipate revisiting some of this stuff eventually.)
Test Plan:
- Looked at Phriction pages on desktop/tablet/mobile/printable -- actions are now available on the page.
- Looked at other DocumentView pages (like Phame blogs) -- no changes for now.
Reviewers: amckinley
Maniphest Tasks: T13077, T8172
Differential Revision: https://secure.phabricator.com/D19617
2018-08-28 23:37:19 +02:00
|
|
|
'rsrc/css/phui/phui-header-view.css' => '1ba8b707',
|
2018-11-15 13:15:43 +01:00
|
|
|
'rsrc/css/phui/phui-hovercard.css' => '4a484541',
|
2017-02-04 18:41:03 +01:00
|
|
|
'rsrc/css/phui/phui-icon-set-selector.css' => '87db8fee',
|
2018-04-03 21:26:35 +02:00
|
|
|
'rsrc/css/phui/phui-icon.css' => 'cf24ceec',
|
2016-02-15 06:29:56 +01:00
|
|
|
'rsrc/css/phui/phui-image-mask.css' => 'a8498f9c',
|
2017-09-07 22:15:07 +02:00
|
|
|
'rsrc/css/phui/phui-info-view.css' => 'e929f98c',
|
2016-09-12 14:53:54 +02:00
|
|
|
'rsrc/css/phui/phui-invisible-character-view.css' => '6993d9f0',
|
2017-08-21 22:07:38 +02:00
|
|
|
'rsrc/css/phui/phui-left-right.css' => '75227a4d',
|
2016-12-02 18:59:46 +01:00
|
|
|
'rsrc/css/phui/phui-lightbox.css' => '0a035e40',
|
2017-07-17 20:08:17 +02:00
|
|
|
'rsrc/css/phui/phui-list.css' => '38f8c9bd',
|
2017-04-21 20:22:06 +02:00
|
|
|
'rsrc/css/phui/phui-object-box.css' => '9cff003c',
|
2017-06-07 01:53:14 +02:00
|
|
|
'rsrc/css/phui/phui-pager.css' => 'edcbc226',
|
2015-05-31 23:28:16 +02:00
|
|
|
'rsrc/css/phui/phui-pinboard-view.css' => '2495140e',
|
2018-06-01 22:12:13 +02:00
|
|
|
'rsrc/css/phui/phui-property-list-view.css' => '546a04ae',
|
2017-04-18 00:11:08 +02:00
|
|
|
'rsrc/css/phui/phui-remarkup-preview.css' => '54a34863',
|
2017-01-31 17:58:33 +01:00
|
|
|
'rsrc/css/phui/phui-segment-bar-view.css' => 'b1d1b892',
|
2014-01-01 16:46:25 +01:00
|
|
|
'rsrc/css/phui/phui-spacing.css' => '042804d6',
|
2016-05-01 21:48:56 +02:00
|
|
|
'rsrc/css/phui/phui-status.css' => 'd5263e49',
|
2017-07-17 20:08:17 +02:00
|
|
|
'rsrc/css/phui/phui-tag-view.css' => 'b4719c50',
|
2018-01-29 21:54:04 +01:00
|
|
|
'rsrc/css/phui/phui-timeline-view.css' => '6ddf8126',
|
2017-09-25 21:56:22 +02:00
|
|
|
'rsrc/css/phui/phui-two-column-view.css' => '44ec4951',
|
2017-02-05 21:45:27 +01:00
|
|
|
'rsrc/css/phui/workboards/phui-workboard-color.css' => '783cdff5',
|
2017-01-31 17:58:33 +01:00
|
|
|
'rsrc/css/phui/workboards/phui-workboard.css' => '3bc85455',
|
2017-01-17 21:04:28 +01:00
|
|
|
'rsrc/css/phui/workboards/phui-workcard.css' => 'cca5fa92',
|
2016-12-14 20:35:51 +01:00
|
|
|
'rsrc/css/phui/workboards/phui-workpanel.css' => 'a3a63478',
|
2017-08-11 22:37:15 +02:00
|
|
|
'rsrc/css/sprite-login.css' => '396f3c3a',
|
2016-07-04 03:32:31 +02:00
|
|
|
'rsrc/css/sprite-tokens.css' => '9cdfd599',
|
2016-05-05 03:24:59 +02:00
|
|
|
'rsrc/css/syntax/syntax-default.css' => '9923583c',
|
2016-01-28 22:29:27 +01:00
|
|
|
'rsrc/externals/d3/d3.min.js' => 'a11a5ff2',
|
2017-02-02 00:25:20 +01:00
|
|
|
'rsrc/externals/font/fontawesome/fontawesome-webfont.eot' => '24a7064f',
|
|
|
|
'rsrc/externals/font/fontawesome/fontawesome-webfont.ttf' => '0039fe26',
|
|
|
|
'rsrc/externals/font/fontawesome/fontawesome-webfont.woff' => 'de978a43',
|
|
|
|
'rsrc/externals/font/fontawesome/fontawesome-webfont.woff2' => '2a832057',
|
Smaller Lato font footprint
Summary:
About 1/3 the size. The "Full" Lato set is over 3000 Glyphs, this was a handbuilt set of Latin, Latin-A, and Latin-B. Specific Unicode set:
```U+0100-024F, U+1E00-1EFF, U+20A0-20AB, U+20AD-20CF, U+2C60-2C7F, U+A720-A7FF, U+0000-00FF, U+0131, U+0152-0153, U+02C6, U+02DA, U+02DC, U+2000-206F, U+2074, U+20AC, U+2212, U+2215, U+E0FF, U+EFFD, U+F000```
This unicode set is what Google Fonts uses as "Latin,Latin-Ext"
Test Plan: Built test pages in Phriction for Latin-A, Latin-B. Checked Chrome, Firefox, Mac and PC. If issues get reported, can default back to larger font pack.
Reviewers: btrahan, epriestley
Reviewed By: epriestley
Subscribers: epriestley, Korvin
Maniphest Tasks: T8755
Differential Revision: https://secure.phabricator.com/D13558
2015-07-06 16:17:11 +02:00
|
|
|
'rsrc/externals/font/lato/lato-bold.eot' => '99fbcf8c',
|
2015-11-22 22:03:58 +01:00
|
|
|
'rsrc/externals/font/lato/lato-bold.svg' => '2aa83045',
|
Smaller Lato font footprint
Summary:
About 1/3 the size. The "Full" Lato set is over 3000 Glyphs, this was a handbuilt set of Latin, Latin-A, and Latin-B. Specific Unicode set:
```U+0100-024F, U+1E00-1EFF, U+20A0-20AB, U+20AD-20CF, U+2C60-2C7F, U+A720-A7FF, U+0000-00FF, U+0131, U+0152-0153, U+02C6, U+02DA, U+02DC, U+2000-206F, U+2074, U+20AC, U+2212, U+2215, U+E0FF, U+EFFD, U+F000```
This unicode set is what Google Fonts uses as "Latin,Latin-Ext"
Test Plan: Built test pages in Phriction for Latin-A, Latin-B. Checked Chrome, Firefox, Mac and PC. If issues get reported, can default back to larger font pack.
Reviewers: btrahan, epriestley
Reviewed By: epriestley
Subscribers: epriestley, Korvin
Maniphest Tasks: T8755
Differential Revision: https://secure.phabricator.com/D13558
2015-07-06 16:17:11 +02:00
|
|
|
'rsrc/externals/font/lato/lato-bold.ttf' => '0a7141f7',
|
|
|
|
'rsrc/externals/font/lato/lato-bold.woff' => 'f5db2061',
|
|
|
|
'rsrc/externals/font/lato/lato-bold.woff2' => '37a94ecd',
|
|
|
|
'rsrc/externals/font/lato/lato-bolditalic.eot' => 'b93389d0',
|
2015-11-22 22:03:58 +01:00
|
|
|
'rsrc/externals/font/lato/lato-bolditalic.svg' => '5442e1ef',
|
Smaller Lato font footprint
Summary:
About 1/3 the size. The "Full" Lato set is over 3000 Glyphs, this was a handbuilt set of Latin, Latin-A, and Latin-B. Specific Unicode set:
```U+0100-024F, U+1E00-1EFF, U+20A0-20AB, U+20AD-20CF, U+2C60-2C7F, U+A720-A7FF, U+0000-00FF, U+0131, U+0152-0153, U+02C6, U+02DA, U+02DC, U+2000-206F, U+2074, U+20AC, U+2212, U+2215, U+E0FF, U+EFFD, U+F000```
This unicode set is what Google Fonts uses as "Latin,Latin-Ext"
Test Plan: Built test pages in Phriction for Latin-A, Latin-B. Checked Chrome, Firefox, Mac and PC. If issues get reported, can default back to larger font pack.
Reviewers: btrahan, epriestley
Reviewed By: epriestley
Subscribers: epriestley, Korvin
Maniphest Tasks: T8755
Differential Revision: https://secure.phabricator.com/D13558
2015-07-06 16:17:11 +02:00
|
|
|
'rsrc/externals/font/lato/lato-bolditalic.ttf' => 'dad31252',
|
|
|
|
'rsrc/externals/font/lato/lato-bolditalic.woff' => 'e53bcf47',
|
|
|
|
'rsrc/externals/font/lato/lato-bolditalic.woff2' => 'd035007f',
|
|
|
|
'rsrc/externals/font/lato/lato-italic.eot' => '6a903f5d',
|
2015-11-22 22:03:58 +01:00
|
|
|
'rsrc/externals/font/lato/lato-italic.svg' => '0dc7cf2f',
|
Smaller Lato font footprint
Summary:
About 1/3 the size. The "Full" Lato set is over 3000 Glyphs, this was a handbuilt set of Latin, Latin-A, and Latin-B. Specific Unicode set:
```U+0100-024F, U+1E00-1EFF, U+20A0-20AB, U+20AD-20CF, U+2C60-2C7F, U+A720-A7FF, U+0000-00FF, U+0131, U+0152-0153, U+02C6, U+02DA, U+02DC, U+2000-206F, U+2074, U+20AC, U+2212, U+2215, U+E0FF, U+EFFD, U+F000```
This unicode set is what Google Fonts uses as "Latin,Latin-Ext"
Test Plan: Built test pages in Phriction for Latin-A, Latin-B. Checked Chrome, Firefox, Mac and PC. If issues get reported, can default back to larger font pack.
Reviewers: btrahan, epriestley
Reviewed By: epriestley
Subscribers: epriestley, Korvin
Maniphest Tasks: T8755
Differential Revision: https://secure.phabricator.com/D13558
2015-07-06 16:17:11 +02:00
|
|
|
'rsrc/externals/font/lato/lato-italic.ttf' => '629f64f0',
|
|
|
|
'rsrc/externals/font/lato/lato-italic.woff' => '678dc4bb',
|
|
|
|
'rsrc/externals/font/lato/lato-italic.woff2' => '7c8dd650',
|
|
|
|
'rsrc/externals/font/lato/lato-regular.eot' => '848dfb1e',
|
2015-11-22 22:03:58 +01:00
|
|
|
'rsrc/externals/font/lato/lato-regular.svg' => 'cbd5fd6b',
|
Smaller Lato font footprint
Summary:
About 1/3 the size. The "Full" Lato set is over 3000 Glyphs, this was a handbuilt set of Latin, Latin-A, and Latin-B. Specific Unicode set:
```U+0100-024F, U+1E00-1EFF, U+20A0-20AB, U+20AD-20CF, U+2C60-2C7F, U+A720-A7FF, U+0000-00FF, U+0131, U+0152-0153, U+02C6, U+02DA, U+02DC, U+2000-206F, U+2074, U+20AC, U+2212, U+2215, U+E0FF, U+EFFD, U+F000```
This unicode set is what Google Fonts uses as "Latin,Latin-Ext"
Test Plan: Built test pages in Phriction for Latin-A, Latin-B. Checked Chrome, Firefox, Mac and PC. If issues get reported, can default back to larger font pack.
Reviewers: btrahan, epriestley
Reviewed By: epriestley
Subscribers: epriestley, Korvin
Maniphest Tasks: T8755
Differential Revision: https://secure.phabricator.com/D13558
2015-07-06 16:17:11 +02:00
|
|
|
'rsrc/externals/font/lato/lato-regular.ttf' => 'e270165b',
|
|
|
|
'rsrc/externals/font/lato/lato-regular.woff' => '13d39fe2',
|
|
|
|
'rsrc/externals/font/lato/lato-regular.woff2' => '57a9f742',
|
2018-11-24 15:59:19 +01:00
|
|
|
'rsrc/externals/javelin/core/Event.js' => 'ef7e057f',
|
Emit a "Content-Security-Policy" HTTP header
Summary:
See PHI399. Ref T4340. This header provides an additional layer of protection against various attacks, including XSS attacks which embed inline `<script ...>` or `onhover="..."` content into the document.
**style-src**: The "unsafe-inline" directive affects both `style="..."` and `<style>`. We use a lot of `style="..."`, some very legitimately, so we can't realistically get away from this any time soon. We only use one `<style>` (for monospaced font preferences) but can't disable `<style>` without disabling `style="..."`.
**img-src**: We use "data:" URIs to inline small images into CSS, and there's a significant performance benefit from doing this. There doesn't seem to be a way to allow "data" URIs in CSS without allowing them in the document itself.
**script-src** and **frame-src**: For a small number of flows (Recaptcha, Stripe) we embed external javascript, some of which embeds child elements (or additional resources) into the document. We now whitelist these narrowly on the respective pages.
This won't work with Quicksand, so I've blacklisted it for now.
**connect-src**: We need to include `'self'` for AJAX to work, and any websocket URIs.
**Clickjacking**: We now have three layers of protection:
- X-Frame-Options: works in older browsers.
- `frame-ancestors 'none'`: does the same thing.
- Explicit framebust in JX.Stratcom after initialization: works in ancient IE.
We could probably drop the explicit framebust but it wasn't difficult to retain.
**script tags**: We previously used an inline `<script>` tag to start Javelin. I've moved this to `<data data-javelin-init ...>` tags, which seems to work properly.
**`__DEV__`**: We previously used an inline `<script>` tag to set the `__DEV__` mode flag. I tried using the "initialization" tags for this, but they fire too late. I moved it to `<html data-developer-mode="1">`, which seems OK everywhere.
**CSP Scope**: Only the CSP header on the original request appears to matter -- you can't refine the scope by emitting headers on CSS/JS. To reduce confusion, I disabled the headers on those response types. More headers could be disabled, although we're likely already deep in the land of diminishing returns.
**Initialization**: The initialization sequence has changed slightly. Previously, we waited for the <script> in bottom of the document to evaluate. Now, we go fishing for tags when domcontentready fires.
Test Plan:
- Browsed around in Firefox, Safari and Chrome looking for console warnings. Interacted with various Javascript behaviors. Enabled Quicksand.
- Disabled all the framebusting, launched a clickjacking attack, verified that each layer of protection is individually effective.
- Verified that the XHProf iframe in Darkconsole and the PHPAST frame layout work properly.
- Enabled notifications, verified no complaints about connecting to Aphlict.
- Hit `__DEV__` mode warnings based on the new data attribute.
- Tried to do sketchy stuff with `data:` URIs and SVGs. This works but doesn't seem to be able to do anything dangerous.
- Went through the Stripe and Recaptcha workflows.
- Dumped and examined the CSP headers with `curl`, etc.
- Added a raw <script> tag to a page (as though I'd found an XSS attack), verified it was no longer executed.
Maniphest Tasks: T4340
Differential Revision: https://secure.phabricator.com/D19143
2018-02-27 15:56:15 +01:00
|
|
|
'rsrc/externals/javelin/core/Stratcom.js' => '327f418a',
|
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',
|
2018-11-24 15:20:04 +01:00
|
|
|
'rsrc/externals/javelin/core/init.js' => '8d83d2a1',
|
2018-12-10 20:39:43 +01:00
|
|
|
'rsrc/externals/javelin/core/init_node.js' => 'f7732951',
|
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',
|
2017-05-17 16:00:42 +02:00
|
|
|
'rsrc/externals/javelin/lib/DOM.js' => '4976858c',
|
2015-03-28 15:38:14 +01:00
|
|
|
'rsrc/externals/javelin/lib/History.js' => 'd4505101',
|
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',
|
2017-04-17 21:10:29 +02:00
|
|
|
'rsrc/externals/javelin/lib/Leader.js' => '7f243deb',
|
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',
|
When logged-out users hit a "Login Required" dialog, try to choose a better "next" URI
Summary:
Ref T10004. After a user logs in, we send them to the "next" URI cookie if there is one, but currently don't always do a very good job of selecting a "next" URI, especially if they tried to do something with a dialog before being asked to log in.
In particular, if a logged-out user clicks an action like "Edit Blocking Tasks" on a Maniphest task, the default behavior is to send them to the standalone page for that dialog after they log in. This can be pretty confusing.
See T2691 and D6416 for earlier efforts here. At that time, we added a mechanism to //manually// override the default behavior, and fixed the most common links. This worked, but I'd like to fix the //default// beahvior so we don't need to remember to `setObjectURI()` correctly all over the place.
ApplicationEditor has also introduced new cases which are more difficult to get right. While we could get them right by using the override and being careful about things, this also motivates fixing the default behavior.
Finally, we have better tools for fixing the default behavior now than we did in 2013.
Instead of using manual overrides, have JS include an "X-Phabricator-Via" header in Ajax requests. This is basically like a referrer header, and will contain the page the user's browser is on.
In essentially every case, this should be a very good place (and often the best place) to send them after login. For all pages currently using `setObjectURI()`, it should produce the same behavior by default.
I'll remove the `setObjectURI()` mechanism in the next diff.
Test Plan: Clicked various workflow actions while logged out, saw "next" get set to a reasonable value, was redirected to a sensible, non-confusing page after login (the page with whatever button I clicked on it).
Reviewers: chad
Reviewed By: chad
Maniphest Tasks: T10004
Differential Revision: https://secure.phabricator.com/D14804
2015-12-17 15:10:04 +01:00
|
|
|
'rsrc/externals/javelin/lib/Quicksand.js' => '6b8ef10b',
|
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',
|
2017-05-20 13:10:32 +02:00
|
|
|
'rsrc/externals/javelin/lib/Scrollbar.js' => '9065f639',
|
2015-03-10 23:30:49 +01:00
|
|
|
'rsrc/externals/javelin/lib/Sound.js' => '949c0fe5',
|
When logged-out users hit a "Login Required" dialog, try to choose a better "next" URI
Summary:
Ref T10004. After a user logs in, we send them to the "next" URI cookie if there is one, but currently don't always do a very good job of selecting a "next" URI, especially if they tried to do something with a dialog before being asked to log in.
In particular, if a logged-out user clicks an action like "Edit Blocking Tasks" on a Maniphest task, the default behavior is to send them to the standalone page for that dialog after they log in. This can be pretty confusing.
See T2691 and D6416 for earlier efforts here. At that time, we added a mechanism to //manually// override the default behavior, and fixed the most common links. This worked, but I'd like to fix the //default// beahvior so we don't need to remember to `setObjectURI()` correctly all over the place.
ApplicationEditor has also introduced new cases which are more difficult to get right. While we could get them right by using the override and being careful about things, this also motivates fixing the default behavior.
Finally, we have better tools for fixing the default behavior now than we did in 2013.
Instead of using manual overrides, have JS include an "X-Phabricator-Via" header in Ajax requests. This is basically like a referrer header, and will contain the page the user's browser is on.
In essentially every case, this should be a very good place (and often the best place) to send them after login. For all pages currently using `setObjectURI()`, it should produce the same behavior by default.
I'll remove the `setObjectURI()` mechanism in the next diff.
Test Plan: Clicked various workflow actions while logged out, saw "next" get set to a reasonable value, was redirected to a sensible, non-confusing page after login (the page with whatever button I clicked on it).
Reviewers: chad
Reviewed By: chad
Maniphest Tasks: T10004
Differential Revision: https://secure.phabricator.com/D14804
2015-12-17 15:10:04 +01:00
|
|
|
'rsrc/externals/javelin/lib/URI.js' => 'c989ade3',
|
2015-01-28 17:26:10 +01:00
|
|
|
'rsrc/externals/javelin/lib/Vector.js' => '2caa8fb8',
|
When disconnected from Aphlict after a successful connection, retry the first reconnect right away
Summary:
Fixes T12567. We currently retry after 2s, 4s, 8s, 16s, ...
If we connected cleanly once, retry the first time right away. There are a bunch of reasonable cases where this will work fine and we don't need to wait. Then we fall back: 0s, 2s, 4s, 8s, ...
Test Plan: {F4911905}
Reviewers: chad
Reviewed By: chad
Maniphest Tasks: T12567
Differential Revision: https://secure.phabricator.com/D17706
2017-04-17 22:20:48 +02:00
|
|
|
'rsrc/externals/javelin/lib/WebSocket.js' => '3ffe32d6',
|
2018-03-22 18:58:56 +01:00
|
|
|
'rsrc/externals/javelin/lib/Workflow.js' => '6a726c55',
|
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',
|
2018-06-01 22:05:46 +02:00
|
|
|
'rsrc/externals/javelin/lib/control/tokenizer/Tokenizer.js' => 'bb6e5c16',
|
2015-01-14 01:10:57 +01:00
|
|
|
'rsrc/externals/javelin/lib/control/typeahead/Typeahead.js' => '70baed2f',
|
2016-11-17 13:13:39 +01:00
|
|
|
'rsrc/externals/javelin/lib/control/typeahead/normalizer/TypeaheadNormalizer.js' => '185bbd53',
|
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',
|
2016-01-16 23:33:03 +01:00
|
|
|
'rsrc/externals/javelin/lib/control/typeahead/source/TypeaheadOnDemandSource.js' => '013ffff9',
|
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/TypeaheadPreloadedSource.js' => '54f314a0',
|
Use a tokenizer, not a gigantic poorly-ordered "<select />", to choose repositories in Owners
Summary: Depends on D19190. Fixes T12590. Ref T13099. Replaces the barely-usable, gigantic, poorly ordered "<select />" control with a tokenizer. Attempts to fix various minor issues.
Test Plan:
- Edited paths: include/exclude paths, from different repositories, different actual paths.
- Used "Add New Path" to add rows, got repository selector prepopulated with last value.
- Used "remove".
- Used validation typeahead, got reasonable behaviors?
The error behavior if you delete the repository for a path is a little sketchy still, but roughly okay.
Maniphest Tasks: T13099, T12590
Differential Revision: https://secure.phabricator.com/D19191
2018-03-08 02:29:06 +01:00
|
|
|
'rsrc/externals/javelin/lib/control/typeahead/source/TypeaheadSource.js' => 'ab9e0a82',
|
Time control typeaheads.
Summary: Ref T8031, Time control typeaheads
Test Plan: Edit an event, type '3', typeahead should suggest, '3:00 AM', '3:30 AM', '3:00 PM', '3:30 PM'.
Reviewers: chad, epriestley, #blessed_reviewers
Reviewed By: epriestley, #blessed_reviewers
Subscribers: Korvin, epriestley
Maniphest Tasks: T8031
Differential Revision: https://secure.phabricator.com/D12953
2015-05-20 18:51:26 +02:00
|
|
|
'rsrc/externals/javelin/lib/control/typeahead/source/TypeaheadStaticSource.js' => '6c0e62fa',
|
2016-09-12 01:09:56 +02:00
|
|
|
'rsrc/favicons/favicon-16x16.png' => 'fc6275ba',
|
2016-09-09 18:35:54 +02:00
|
|
|
'rsrc/favicons/mask-icon.svg' => 'e132a80f',
|
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',
|
2017-02-26 18:36:21 +01:00
|
|
|
'rsrc/image/avatar.png' => '17d346a4',
|
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',
|
2017-06-06 16:04:09 +02:00
|
|
|
'rsrc/image/controls/checkbox-checked.png' => 'ad6441ea',
|
|
|
|
'rsrc/image/controls/checkbox-unchecked.png' => '8eb1f0ae',
|
2016-03-09 02:50:01 +01:00
|
|
|
'rsrc/image/d5d8e1.png' => '0c2a1497',
|
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/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/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_put.png' => '08c95a0c',
|
|
|
|
'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',
|
|
|
|
'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',
|
2016-08-08 22:21:18 +02:00
|
|
|
'rsrc/image/logo/light-eye.png' => '1a576ddd',
|
2014-01-01 16:46:25 +01:00
|
|
|
'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',
|
2015-12-04 21:30:38 +01:00
|
|
|
'rsrc/image/people/user0.png' => '03dacaea',
|
|
|
|
'rsrc/image/people/user1.png' => '4a4e7702',
|
|
|
|
'rsrc/image/people/user2.png' => '47a0ee40',
|
|
|
|
'rsrc/image/people/user3.png' => '835ff627',
|
|
|
|
'rsrc/image/people/user4.png' => 'b0e830f1',
|
|
|
|
'rsrc/image/people/user5.png' => '9c95b369',
|
|
|
|
'rsrc/image/people/user6.png' => 'ba3fbfb0',
|
|
|
|
'rsrc/image/people/user7.png' => 'da613924',
|
|
|
|
'rsrc/image/people/user8.png' => 'f1035edf',
|
|
|
|
'rsrc/image/people/user9.png' => '66730be3',
|
2014-01-01 16:46:25 +01:00
|
|
|
'rsrc/image/people/washington.png' => '40dd301c',
|
|
|
|
'rsrc/image/phrequent_active.png' => 'a466a8ed',
|
|
|
|
'rsrc/image/phrequent_inactive.png' => 'bfc15a69',
|
2016-06-21 02:29:56 +02:00
|
|
|
'rsrc/image/resize.png' => 'fd476de4',
|
2017-08-11 22:37:15 +02:00
|
|
|
'rsrc/image/sprite-login-X2.png' => '308c92c4',
|
|
|
|
'rsrc/image/sprite-login.png' => '9ec54245',
|
2016-07-04 03:32:31 +02:00
|
|
|
'rsrc/image/sprite-tokens-X2.png' => '804a5232',
|
|
|
|
'rsrc/image/sprite-tokens.png' => 'b41d03da',
|
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',
|
Fix several duplication/replay behaviors in Aphlict
Summary:
Ref T12566. Ref T12563. This fixes three bugs with Aphlict replay stuff:
First, Conphernece would try to repaint the UI even if no thread was open. Only repaint when a thread is open.
Second, although we deduplicate JX.Leader messages, we didn't deduplicate actual notification messages. If you browsed the leader window, then it re-elected itelf as a leader and replayed history, it could rebroadcast notifications and other windows could show doubles. Deduplicate notifications to prevent this.
Third, we always replayed the last 60 seconds of history. When you browsed the leader window, whichever window became the new leader (possibly the one you just browsed) could replay messages from before it had opened, leading to duplicate messages. Particularly, after receiving a message and then browsing you could see that message again. Instead, only replay history as far back as when the window first opened.
Test Plan:
- Clicked "Repaint" with a thread open, saw a repaint. Clicked "Repaint" with Conpherence open but no thread, no repaint and no 404 request to `/update/null/`.
- In browser A, opened three windows. In browser B, sent a notification. In browser A, browsed the leader window away twice in a row. Observed that the window which never became a leader doesn't duplicate notifications.
- In browser A, opened three windows. In browser B, sent a notification. In browser A, browsed the leader window away over and over again. Observed that replay requests issued with appropriate history windows.
Reviewers: chad
Reviewed By: chad
Maniphest Tasks: T12566, T12563
Differential Revision: https://secure.phabricator.com/D17722
2017-04-18 20:14:37 +02:00
|
|
|
'rsrc/js/application/aphlict/Aphlict.js' => 'e1d4b11a',
|
2017-01-17 22:59:56 +01:00
|
|
|
'rsrc/js/application/aphlict/behavior-aphlict-dropdown.js' => 'caade6f2',
|
2018-03-16 23:10:26 +01:00
|
|
|
'rsrc/js/application/aphlict/behavior-aphlict-listen.js' => '599a8f5f',
|
2016-10-02 05:37:28 +02:00
|
|
|
'rsrc/js/application/aphlict/behavior-aphlict-status.js' => '5e2634b9',
|
2017-08-23 23:35:02 +02:00
|
|
|
'rsrc/js/application/aphlict/behavior-desktop-notifications-control.js' => '27ca6289',
|
2016-07-15 23:02:24 +02:00
|
|
|
'rsrc/js/application/calendar/behavior-day-view.js' => '4b3c4443',
|
2016-10-31 19:38:35 +01:00
|
|
|
'rsrc/js/application/calendar/behavior-event-all-day.js' => 'b41537c9',
|
2016-07-27 15:44:42 +02:00
|
|
|
'rsrc/js/application/calendar/behavior-month-view.js' => 'fe33e256',
|
2015-05-25 14:34:23 +02:00
|
|
|
'rsrc/js/application/config/behavior-reorder-fields.js' => 'b6993408',
|
Fix several duplication/replay behaviors in Aphlict
Summary:
Ref T12566. Ref T12563. This fixes three bugs with Aphlict replay stuff:
First, Conphernece would try to repaint the UI even if no thread was open. Only repaint when a thread is open.
Second, although we deduplicate JX.Leader messages, we didn't deduplicate actual notification messages. If you browsed the leader window, then it re-elected itelf as a leader and replayed history, it could rebroadcast notifications and other windows could show doubles. Deduplicate notifications to prevent this.
Third, we always replayed the last 60 seconds of history. When you browsed the leader window, whichever window became the new leader (possibly the one you just browsed) could replay messages from before it had opened, leading to duplicate messages. Particularly, after receiving a message and then browsing you could see that message again. Instead, only replay history as far back as when the window first opened.
Test Plan:
- Clicked "Repaint" with a thread open, saw a repaint. Clicked "Repaint" with Conpherence open but no thread, no repaint and no 404 request to `/update/null/`.
- In browser A, opened three windows. In browser B, sent a notification. In browser A, browsed the leader window away twice in a row. Observed that the window which never became a leader doesn't duplicate notifications.
- In browser A, opened three windows. In browser B, sent a notification. In browser A, browsed the leader window away over and over again. Observed that replay requests issued with appropriate history windows.
Reviewers: chad
Reviewed By: chad
Maniphest Tasks: T12566, T12563
Differential Revision: https://secure.phabricator.com/D17722
2017-04-18 20:14:37 +02:00
|
|
|
'rsrc/js/application/conpherence/ConpherenceThreadManager.js' => '4d863052',
|
Remove 'full-display' setting from Conpherence, spruce up search results
Summary: This removes 'full-display', 'minimal-display' from Conpherence, which I recall was because we had 2 UIs for column and regular chat. I'm also tossing in slightly nicer search results, with a link to the actual message and the full date shown for context.
Test Plan: Post a message in mobile, tablet, full conpherence, and in durable column. Clean up UI in durable column. Do a search in Full UI, click on result date, get taken to the message... usually. My test data is a little wonky, but I think this works most of the time.
Reviewers: epriestley
Reviewed By: epriestley
Subscribers: Korvin
Differential Revision: https://secure.phabricator.com/D16710
2016-10-16 05:26:15 +02:00
|
|
|
'rsrc/js/application/conpherence/behavior-conpherence-search.js' => '9bbf3762',
|
2017-04-26 19:48:50 +02:00
|
|
|
'rsrc/js/application/conpherence/behavior-durable-column.js' => '2ae077e1',
|
2017-10-09 19:52:27 +02:00
|
|
|
'rsrc/js/application/conpherence/behavior-menu.js' => '4047cd35',
|
|
|
|
'rsrc/js/application/conpherence/behavior-participant-pane.js' => 'd057e45a',
|
2017-04-10 23:39:36 +02:00
|
|
|
'rsrc/js/application/conpherence/behavior-pontificate.js' => '55616e04',
|
2015-03-10 23:32:15 +01:00
|
|
|
'rsrc/js/application/conpherence/behavior-quicksand-blacklist.js' => '7927a7d3',
|
2016-10-19 06:49:02 +02:00
|
|
|
'rsrc/js/application/conpherence/behavior-toggle-widget.js' => '3dbf94d5',
|
2014-12-30 11:53:27 +01:00
|
|
|
'rsrc/js/application/countdown/timer.js' => 'e4cc26b3',
|
2015-06-23 22:43:47 +02:00
|
|
|
'rsrc/js/application/daemon/behavior-bulk-job-reload.js' => 'edf8a145',
|
2014-05-19 23:04:26 +02:00
|
|
|
'rsrc/js/application/dashboard/behavior-dashboard-async-panel.js' => '469c0d9e',
|
2017-02-14 23:08:56 +01:00
|
|
|
'rsrc/js/application/dashboard/behavior-dashboard-move-panels.js' => '408bf173',
|
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',
|
2018-02-09 01:55:54 +01:00
|
|
|
'rsrc/js/application/diff/DiffChangeset.js' => 'b49b59d6',
|
2018-11-24 15:59:19 +01:00
|
|
|
'rsrc/js/application/diff/DiffChangesetList.js' => '0a84bcc1',
|
2017-07-21 17:08:24 +02:00
|
|
|
'rsrc/js/application/diff/DiffInline.js' => 'e83d28f3',
|
Make some Differential comment actions (like "Accept" and "Reject") conflict with one another
Summary:
Ref T11114. When a user selects "Accept", and then selects "Reject", remove the "Accept". It does not make sense to both accept and reject a revision.
For now, every one of the "actions" conflicts: accept, reject, resign, claim, close, commandeer, etc, etc. I couldn't come up with any combinations that it seems like users are reasonably likely to want to try, and we haven't received combo-action requests in the past that I can recall.
Test Plan:
- Selected "Accept", then selected "Reject". One replaced the other.
- Selected "Accept", then selected "Change Subscribers". Both co-existed happily.
Reviewers: chad
Reviewed By: chad
Maniphest Tasks: T11114
Differential Revision: https://secure.phabricator.com/D17132
2017-01-02 20:17:27 +01:00
|
|
|
'rsrc/js/application/diff/behavior-preview-link.js' => '051c7832',
|
2014-01-01 16:46:25 +01:00
|
|
|
'rsrc/js/application/differential/behavior-diff-radios.js' => 'e1ff79b1',
|
In Differential standalone views, disable some keyboard shortcuts which don't work
Summary:
Ref T13164. See PHI693. In Differential, you can {nav View Options > View Standalone} to get a standalone view of a single changeset. You can also arrive here via the big changeset list for revisions affecting a huge number of files.
We currently suggest that all the keyboard shortcuts work, but some do not. In particular, the "Next File" and "Previous File" keyboard shortcuts (and some similar shortcuts) do not work. In the main view, the next/previous files are on the same page. In the standalone view, we'd need to actually change the URI.
Ideally, we should do this (and, e.g., put prev/next links on the page). As a first step toward that, hide the nonfunctional shortcuts to stop users from being misled.
Test Plan:
- Viewed a revision in normal and standalone views.
- No changes in normal view, and all keys still work ("N", "P", etc).
- In standalone view, "?" no longer shows nonfunctional key commands.
Reviewers: amckinley
Reviewed By: amckinley
Maniphest Tasks: T13164
Differential Revision: https://secure.phabricator.com/D19571
2018-08-13 17:21:16 +02:00
|
|
|
'rsrc/js/application/differential/behavior-populate.js' => 'f0eb6708',
|
2014-01-01 16:46:25 +01:00
|
|
|
'rsrc/js/application/differential/behavior-user-select.js' => 'a8d8459d',
|
2017-10-09 19:52:27 +02:00
|
|
|
'rsrc/js/application/diffusion/DiffusionLocateFileSource.js' => '00676f00',
|
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',
|
2017-06-07 00:47:47 +02:00
|
|
|
'rsrc/js/application/diffusion/behavior-commit-graph.js' => '75b83cbb',
|
2014-05-13 23:09:00 +02:00
|
|
|
'rsrc/js/application/diffusion/behavior-locate-file.js' => '6d3e1947',
|
2015-10-07 16:32:27 +02:00
|
|
|
'rsrc/js/application/diffusion/behavior-pull-lastmodified.js' => 'f01586dc',
|
Allow Doorkeeper references to have multiple display variations (full, short, etc.)
Summary:
Ref T13102. An install has a custom rule for bridging JIRA references via Doorkeeper and would like to be able to render them as `JIRA-123` instead of `JIRA JIRA-123 Full JIRA title`.
I think it's reasonable to imagine future support upstream for `JIRA-123`, `{JIRA-123}`, and so on, although we do not support these today. We can take a small step toward eventual support by letting the rendering pipeline understand different view modes.
This adds an optional `name` (the default text rendered before we do the OAuth sync) and an optional `view`, which can be `short` or `full`.
Test Plan:
I tested this primarily with Asana, since it's less of a pain to set up than JIRA. The logic should be similar, hopefully.
I changed `DoorkeeperAsanaRemarkupRule` to specify `name` and `view`, e.g `'view' => (mt_rand(0, 1) ? 'short' : 'full')`. Then I made a bunch of Asana references in a comment and saw them randomly go short or long.
Maniphest Tasks: T13102
Differential Revision: https://secure.phabricator.com/D19215
2018-03-13 19:09:22 +01:00
|
|
|
'rsrc/js/application/doorkeeper/behavior-doorkeeper-tag.js' => '1db13e70',
|
2015-10-21 20:28:26 +02:00
|
|
|
'rsrc/js/application/drydock/drydock-live-operation-status.js' => '901935ef',
|
2018-04-28 15:43:09 +02:00
|
|
|
'rsrc/js/application/files/behavior-document-engine.js' => '3935d8c4',
|
2016-01-19 17:43:31 +01:00
|
|
|
'rsrc/js/application/files/behavior-icon-composer.js' => '8499b6ab',
|
2014-02-27 20:06:55 +01:00
|
|
|
'rsrc/js/application/files/behavior-launch-icon-composer.js' => '48086888',
|
2018-04-27 19:58:28 +02:00
|
|
|
'rsrc/js/application/harbormaster/behavior-harbormaster-log.js' => '549459b8',
|
2018-01-19 23:43:20 +01:00
|
|
|
'rsrc/js/application/herald/HeraldRuleEditor.js' => 'dca75c0e',
|
2018-08-13 20:35:02 +02:00
|
|
|
'rsrc/js/application/herald/PathTypeahead.js' => '6d8c7912',
|
2014-01-01 16:46:25 +01:00
|
|
|
'rsrc/js/application/herald/herald-rule-editor.js' => '7ebaeed3',
|
2017-11-30 14:57:39 +01:00
|
|
|
'rsrc/js/application/maniphest/behavior-batch-selector.js' => 'ad54037e',
|
2016-01-28 22:29:27 +01:00
|
|
|
'rsrc/js/application/maniphest/behavior-line-chart.js' => 'e4232876',
|
2014-06-23 19:27:47 +02:00
|
|
|
'rsrc/js/application/maniphest/behavior-list-edit.js' => 'a9f88de2',
|
2015-06-30 18:37:12 +02:00
|
|
|
'rsrc/js/application/maniphest/behavior-subpriorityeditor.js' => '71237763',
|
Use a tokenizer, not a gigantic poorly-ordered "<select />", to choose repositories in Owners
Summary: Depends on D19190. Fixes T12590. Ref T13099. Replaces the barely-usable, gigantic, poorly ordered "<select />" control with a tokenizer. Attempts to fix various minor issues.
Test Plan:
- Edited paths: include/exclude paths, from different repositories, different actual paths.
- Used "Add New Path" to add rows, got repository selector prepopulated with last value.
- Used "remove".
- Used validation typeahead, got reasonable behaviors?
The error behavior if you delete the repository for a path is a little sketchy still, but roughly okay.
Maniphest Tasks: T13099, T12590
Differential Revision: https://secure.phabricator.com/D19191
2018-03-08 02:29:06 +01:00
|
|
|
'rsrc/js/application/owners/OwnersPathEditor.js' => 'c96502cf',
|
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',
|
2016-06-09 17:34:00 +02:00
|
|
|
'rsrc/js/application/pholio/behavior-pholio-mock-edit.js' => 'bee502c8',
|
2017-10-09 19:52:27 +02:00
|
|
|
'rsrc/js/application/pholio/behavior-pholio-mock-view.js' => 'ec1f3669',
|
2017-02-10 17:34:12 +01:00
|
|
|
'rsrc/js/application/phortune/behavior-stripe-payment-form.js' => 'a6b98425',
|
2014-12-30 11:53:27 +01:00
|
|
|
'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',
|
2016-02-05 19:30:20 +01:00
|
|
|
'rsrc/js/application/policy/behavior-policy-control.js' => 'd0c516d5',
|
2015-04-17 16:55:17 +02:00
|
|
|
'rsrc/js/application/policy/behavior-policy-rule-editor.js' => '5e9f347c',
|
2017-01-24 16:25:57 +01:00
|
|
|
'rsrc/js/application/projects/WorkboardBoard.js' => '8935deef',
|
2016-02-11 00:06:20 +01:00
|
|
|
'rsrc/js/application/projects/WorkboardCard.js' => 'c587b80f',
|
2017-05-22 19:47:19 +02:00
|
|
|
'rsrc/js/application/projects/WorkboardColumn.js' => '758b4758',
|
2017-03-02 02:13:36 +01:00
|
|
|
'rsrc/js/application/projects/WorkboardController.js' => '26167537',
|
|
|
|
'rsrc/js/application/projects/behavior-project-boards.js' => '4250a34e',
|
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',
|
2018-04-08 18:10:03 +02:00
|
|
|
'rsrc/js/application/repository/repository-crossreference.js' => '9a860428',
|
2016-01-13 18:40:27 +01:00
|
|
|
'rsrc/js/application/search/behavior-reorder-profile-menu-items.js' => 'e2e0a072',
|
2014-06-23 19:27:47 +02:00
|
|
|
'rsrc/js/application/search/behavior-reorder-queries.js' => 'e9581f08',
|
Pass timeline view data to comment previews, restoring Differential comment previews
Summary:
Ref T13222. In D19918, I refactored how timelines get "view data". Today, this is always additional data about which images/changesets/diffs are visible on the current revision/commit/mock, so we can tell if inline comments should be linked to a `#anchor` on the same page (if the inline is rendered there somewhere) or to a `/D123?id=1&vs=2` full link on a different page (if it isn't), but in general this could be any sort of state information about the current page that affects how the timeline should render.
Previously, comment previews did not use any specialized object code and always rendered a "generic" timeline story. This was actually a bug, but none of the code we have today cares about this (since it's all inline related, and inlines render separately) so it never impacted anything.
After the `TimelineEngine` change, the preview renders with Differential-specific code. This is more correct, but we were not passing the preview the "view data" so it broke.
This preview doesn't actually need the view data and we could just make it bail out if it isn't present, but pass it through for consistency and so this works like we'd expect if we do something fancier with view data in the future.
Test Plan: Viewed comment and inline comment previews in Differential, saw old behavior restored.
Reviewers: amckinley
Reviewed By: amckinley
Maniphest Tasks: T13222
Differential Revision: https://secure.phabricator.com/D19943
2019-01-03 01:48:53 +01:00
|
|
|
'rsrc/js/application/transactions/behavior-comment-actions.js' => 'd848ec84',
|
2015-12-08 15:14:47 +01:00
|
|
|
'rsrc/js/application/transactions/behavior-reorder-configs.js' => 'd7a74243',
|
2015-11-17 18:33:06 +01:00
|
|
|
'rsrc/js/application/transactions/behavior-reorder-fields.js' => 'b59e1e96',
|
Remove "willRenderTimeline()" from ApplicationTransactionInterface
Summary:
Depends on D19914. Ref T11351. Some of the Phoilo rabbit holes go very deep.
`PhabricatorApplicationTransactionInterface` currently requires you to implement `willRenderTimeline()`. Almost every object just implements this as `return $timeline`; only Pholio, Diffusion, and Differential specialize it. In all cases, they are specializing it mostly to render inline comments.
The actual implementations are a bit of a weird mess and the way the data is threaded through the call stack is weird and not very modern.
Try to clean this up:
- Stop requiring `willRenderTimeline()` to be implemented.
- Stop requiring `getApplicationTransactionViewObject()` to be implemented (only the three above, plus Legalpad, implement this, and Legalpad's implementation is a no-op). These two methods are inherently pretty coupled for almost any reasonable thing you might want to do with the timeline.
- Simplify the handling of "renderdata" and call it "View Data". This is additional information about the current view of the transaction timeline that is required to render it correctly. This is only used in Differential, to decide if we can link an inline comment to an anchor on the same page or should link it to another page. We could perhaps do this on the client instead, but having this data doesn't seem inherently bad to me.
- If objects want to customize timeline rendering, they now implement `PhabricatorTimelineInterface` and provide a `TimelineEngine` which gets a nice formal stack.
This leaves a lot of empty `willRenderTimeline()` implementations hanging around. I'll remove these in the next change, it's just going to be deleting a couple dozen copies of an identical empty method implementation.
Test Plan:
- Viewed audits, revisions, and mocks with inline comments.
- Used "Show Older" to page a revision back in history (this is relevant for "View Data").
- Grepped for symbols: willRenderTimeline, getApplicationTransactionViewObject, Legalpad classes.
Reviewers: amckinley
Reviewed By: amckinley
Maniphest Tasks: T11351
Differential Revision: https://secure.phabricator.com/D19918
2018-12-19 20:52:53 +01:00
|
|
|
'rsrc/js/application/transactions/behavior-show-older-transactions.js' => '0e1eca96',
|
2015-05-18 21:18:10 +02:00
|
|
|
'rsrc/js/application/transactions/behavior-transaction-comment-form.js' => 'b23b49e6',
|
2017-04-18 18:05:00 +02:00
|
|
|
'rsrc/js/application/transactions/behavior-transaction-list.js' => '1f6794f6',
|
2015-04-17 16:55:17 +02:00
|
|
|
'rsrc/js/application/typeahead/behavior-typeahead-browse.js' => '635de1ec',
|
|
|
|
'rsrc/js/application/typeahead/behavior-typeahead-search.js' => '93d0c9e3',
|
2014-06-23 19:27:47 +02:00
|
|
|
'rsrc/js/application/uiexample/gesture-example.js' => '558829c2',
|
2014-12-30 11:54:21 +01:00
|
|
|
'rsrc/js/application/uiexample/notification-example.js' => '8ce821c5',
|
2015-04-02 05:10:32 +02:00
|
|
|
'rsrc/js/core/Busy.js' => '59a7976a',
|
2016-05-21 01:26:11 +02:00
|
|
|
'rsrc/js/core/DragAndDropFileUpload.js' => '58dea2fa',
|
2016-11-17 13:01:35 +01:00
|
|
|
'rsrc/js/core/DraggableList.js' => 'bea6e7f4',
|
2016-10-20 20:41:57 +02:00
|
|
|
'rsrc/js/core/Favicon.js' => '1fe2510c',
|
2016-02-06 23:05:15 +01:00
|
|
|
'rsrc/js/core/FileUpload.js' => '680ea2c8',
|
2016-02-03 17:26:30 +01:00
|
|
|
'rsrc/js/core/Hovercard.js' => '1bd28176',
|
2014-01-01 16:46:25 +01:00
|
|
|
'rsrc/js/core/KeyboardShortcut.js' => '1ae869f2',
|
2017-05-16 15:40:50 +02:00
|
|
|
'rsrc/js/core/KeyboardShortcutManager.js' => 'c19dd9b9',
|
2014-11-17 23:06:05 +01:00
|
|
|
'rsrc/js/core/MultirowRowManager.js' => 'b5d57730',
|
2018-03-16 23:10:26 +01:00
|
|
|
'rsrc/js/core/Notification.js' => '4f774dac',
|
2017-10-09 19:52:27 +02:00
|
|
|
'rsrc/js/core/Prefab.js' => '77b0ae28',
|
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',
|
2016-05-21 01:26:11 +02:00
|
|
|
'rsrc/js/core/TextAreaUtils.js' => '320810c8',
|
2016-10-20 20:41:57 +02:00
|
|
|
'rsrc/js/core/Title.js' => '485aaa6c',
|
2017-05-20 13:58:09 +02:00
|
|
|
'rsrc/js/core/ToolTip.js' => '358b8c04',
|
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',
|
2016-04-13 18:20:15 +02:00
|
|
|
'rsrc/js/core/behavior-badge-view.js' => '8ff5e24c',
|
2018-01-19 16:32:28 +01:00
|
|
|
'rsrc/js/core/behavior-bulk-editor.js' => '66a6def1',
|
Allow installs to customize project icons
Summary:
Ref T10010. Ref T5819. General alignment of the stars:
- There were some hacks in Conduit around stripping `fa-...` off icons when reading and writing that I wanted to get rid of.
- We probably have room for a subtitle in the new heavy nav, and using the icon name is a good starting point (and maybe good enough on its own?)
- The project list was real bad looking with redundant tag/names, now it is very slightly less bad looking with non-redundant types?
- Some installs will want to call Milestones something else, and this gets us a big part of the way there.
- This may slightly help to reinforce "tag" vs "policy" vs "group" stuff?
---
I'm letting installs have enough rope to shoot themselves in the foot (e.g., define 100 icons). It isn't the end of the world if they reuse icons, and is clearly their fault.
I think the cases where 100 icons will break down are:
- Icon selector dialog may get very unwieldy.
- Query UI will be pretty iffy/huge with 100 icons.
We could improve these fairly easily if an install comes up with a reasonable use case for having 100 icons.
---
The UI on the icon itself in the list views is a little iffy -- mostly, it's too saturated/bold.
I'd ideally like to try either:
- rendering a "shade" version (i.e. lighter, less-saturated color); or
- rendering a "shade" tag with just the icon in it.
However, there didn't seem to be a way to do the first one right now (`fa-example sh-blue` doesn't work) and the second one had weird margins/padding, so I left it like this for now. I figure we can clean it up once we build the thick nav, since that will probably also want an identical element.
(I don't want to render a full tag with the icon + name since I think that's confusing -- it looks like a project/object tag, but is not.)
Test Plan:
{F1049905}
{F1049906}
Reviewers: chad
Reviewed By: chad
Subscribers: 20after4, Luke081515.2
Maniphest Tasks: T5819, T10010
Differential Revision: https://secure.phabricator.com/D14918
2015-12-30 13:36:48 +01:00
|
|
|
'rsrc/js/core/behavior-choose-control.js' => '327a00d1',
|
2017-05-31 05:00:15 +02:00
|
|
|
'rsrc/js/core/behavior-copy.js' => 'b0b8f86d',
|
2016-05-22 15:50:12 +02:00
|
|
|
'rsrc/js/core/behavior-detect-timezone.js' => '4c193c96',
|
2017-10-09 19:52:27 +02:00
|
|
|
'rsrc/js/core/behavior-device.js' => 'a3714c76',
|
2016-05-21 01:26:11 +02:00
|
|
|
'rsrc/js/core/behavior-drag-and-drop-textarea.js' => '484a6e22',
|
Fix a hang in fancy date picker for Ye Olde Time Years
Summary:
Fixes T12960. When the user enters a date like "1917", we currently loop ~20 million times.
Instead:
- Be a little more careful about parsing.
- Javascript's default behavior of interpreting "2001-02-31" as "2001-03-03" ("February 31" -> "March 3") already seems reasonable, so just let it do that.
Test Plan:
Verified these behaviors:
- `2017-08-08` - Valid, recent.
- `17-08-08` - Valid, recent.
- `1917-08-08` - Valid, a century ago, no loop.
- `2017-02-31` - "February 31", interpreted as "March 3" by Javascsript, seems reasonable.
- `Quack` - Default, current time.
- `0/0/0`, `0/99/0` - Default, current time.
Reviewers: avivey, chad
Reviewed By: chad
Maniphest Tasks: T12960
Differential Revision: https://secure.phabricator.com/D18383
2017-08-10 12:31:20 +02:00
|
|
|
'rsrc/js/core/behavior-fancy-datepicker.js' => 'ecf4e799',
|
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',
|
2016-10-18 23:24:17 +02:00
|
|
|
'rsrc/js/core/behavior-global-drag-and-drop.js' => '960f6a39',
|
2015-04-24 01:37:56 +02:00
|
|
|
'rsrc/js/core/behavior-high-security-warning.js' => 'a464fe03',
|
2014-01-01 16:46:25 +01:00
|
|
|
'rsrc/js/core/behavior-history-install.js' => '7ee2b591',
|
2016-02-03 17:26:30 +01:00
|
|
|
'rsrc/js/core/behavior-hovercard.js' => 'bcaccd64',
|
2014-06-23 19:27:47 +02:00
|
|
|
'rsrc/js/core/behavior-keyboard-pager.js' => 'a8da01f0',
|
Make "/" focus the search input again
Summary:
See D1902, T989, T11263, D15984, T4103 , D15976, https://secure.phabricator.com/w/changelog/2016.22/, T2527, T11231, T8286, T11264 for discussion!
When we get another copy of T989, I will rename it to "Build a complicated keybinding settings page like a cool video game" and leave it open forever.
Test Plan: Pressed "/" in Firefox, had my pristine browsing experience inexplicably hijacked by this horrible application.
Reviewers: avivey, chad
Reviewed By: avivey
Subscribers: Korvin
Differential Revision: https://secure.phabricator.com/D15984
2016-07-08 22:57:33 +02:00
|
|
|
'rsrc/js/core/behavior-keyboard-shortcuts.js' => '01fca1f0',
|
2018-03-08 17:22:16 +01:00
|
|
|
'rsrc/js/core/behavior-lightbox-attachments.js' => '6b31879a',
|
2018-04-11 23:44:06 +02:00
|
|
|
'rsrc/js/core/behavior-line-linker.js' => '66a62306',
|
Replace the "Choose Subtype" radio buttons dialog with a simpler "big stuff you click" sort of UI
Summary:
Ref T13222. Fixes T12588. See PHI683. In several cases, we present the user with a choice between multiple major options: Alamnac service types, Drydock blueprint types, Repository VCS types, Herald rule types, etc.
Today, we generally do this with radio buttons and a "Submit" button. This isn't terrible, but often it means users have to click twice (once on the radio; once on submit) when a single click would be sufficient. The radio click target can also be small.
In other cases, we have a container with a link and we'd like to link the entire container: notifications, the `/drydock/` console, etc. We'd like to just link the entire container, but this causes some problems:
- It's not legal to link block eleements like `<a><div> ... </div></a>` and some browsers actually get upset about it.
- We can `<a><span> ... </span></a>` instead, then turn the `<span>` into a block element with CSS -- and this sometimes works, but also has some drawbacks:
- It's not great to do that for screenreaders, since the readable text in the link isn't necessarily very meaningful.
- We can't have any other links inside the element (e.g., details or documentation).
- We can `<form><button> ... </button></form>` instead, but this has its own set of problems:
- You can't right-click to interact with a button in the same way you can with a link.
- Also not great for screenreaders.
Instead, try adding a `linked-container` behavior which just means "when users click this element, pretend they clicked the first link inside it".
This gives us natural HTML (real, legal HTML with actual `<a>` tags) and good screenreader behavior, but allows the effective link target to be visually larger than just the link.
If no issues crop up with this, I'd plan to eventually use this technique in more places (Repositories, Herald, Almanac, Drydock, Notifications menu, etc).
Test Plan:
{F6053035}
- Left-clicked and command-left-clicked the new JS fanciness, got sensible behaviors.
Reviewers: amckinley
Reviewed By: amckinley
Subscribers: PHID-OPKG-gm6ozazyms6q6i22gyam
Maniphest Tasks: T13222, T12588
Differential Revision: https://secure.phabricator.com/D19855
2018-12-07 15:04:07 +01:00
|
|
|
'rsrc/js/core/behavior-linked-container.js' => '291da458',
|
2014-06-23 19:27:47 +02:00
|
|
|
'rsrc/js/core/behavior-more.js' => 'a80d0378',
|
2017-06-07 22:48:19 +02:00
|
|
|
'rsrc/js/core/behavior-object-selector.js' => '77c1f0b0',
|
2014-06-23 19:35:39 +02:00
|
|
|
'rsrc/js/core/behavior-oncopy.js' => '2926fff2',
|
2018-08-27 19:09:13 +02:00
|
|
|
'rsrc/js/core/behavior-phabricator-nav.js' => '9d32bc88',
|
2017-04-26 17:49:53 +02:00
|
|
|
'rsrc/js/core/behavior-phabricator-remarkup-assist.js' => 'acd29eee',
|
2016-04-10 13:26:53 +02:00
|
|
|
'rsrc/js/core/behavior-read-only-warning.js' => 'ba158207',
|
2018-03-06 19:25:05 +01:00
|
|
|
'rsrc/js/core/behavior-redirect.js' => '0213259f',
|
When logged-out users hit a "Login Required" dialog, try to choose a better "next" URI
Summary:
Ref T10004. After a user logs in, we send them to the "next" URI cookie if there is one, but currently don't always do a very good job of selecting a "next" URI, especially if they tried to do something with a dialog before being asked to log in.
In particular, if a logged-out user clicks an action like "Edit Blocking Tasks" on a Maniphest task, the default behavior is to send them to the standalone page for that dialog after they log in. This can be pretty confusing.
See T2691 and D6416 for earlier efforts here. At that time, we added a mechanism to //manually// override the default behavior, and fixed the most common links. This worked, but I'd like to fix the //default// beahvior so we don't need to remember to `setObjectURI()` correctly all over the place.
ApplicationEditor has also introduced new cases which are more difficult to get right. While we could get them right by using the override and being careful about things, this also motivates fixing the default behavior.
Finally, we have better tools for fixing the default behavior now than we did in 2013.
Instead of using manual overrides, have JS include an "X-Phabricator-Via" header in Ajax requests. This is basically like a referrer header, and will contain the page the user's browser is on.
In essentially every case, this should be a very good place (and often the best place) to send them after login. For all pages currently using `setObjectURI()`, it should produce the same behavior by default.
I'll remove the `setObjectURI()` mechanism in the next diff.
Test Plan: Clicked various workflow actions while logged out, saw "next" get set to a reasonable value, was redirected to a sensible, non-confusing page after login (the page with whatever button I clicked on it).
Reviewers: chad
Reviewed By: chad
Maniphest Tasks: T10004
Differential Revision: https://secure.phabricator.com/D14804
2015-12-17 15:10:04 +01:00
|
|
|
'rsrc/js/core/behavior-refresh-csrf.js' => 'ab2f381b',
|
2018-03-08 14:29:24 +01:00
|
|
|
'rsrc/js/core/behavior-remarkup-load-image.js' => '040fce04',
|
2015-12-26 22:00:01 +01:00
|
|
|
'rsrc/js/core/behavior-remarkup-preview.js' => '4b700e9e',
|
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',
|
2018-02-16 16:09:17 +01:00
|
|
|
'rsrc/js/core/behavior-search-typeahead.js' => 'c3e917d9',
|
2016-05-11 19:17:33 +02:00
|
|
|
'rsrc/js/core/behavior-select-content.js' => 'bf5374ef',
|
2014-06-23 19:27:47 +02:00
|
|
|
'rsrc/js/core/behavior-select-on-click.js' => '4e3e79a6',
|
2016-06-07 00:01:18 +02:00
|
|
|
'rsrc/js/core/behavior-setup-check-https.js' => '491416b3',
|
2016-04-15 21:06:53 +02:00
|
|
|
'rsrc/js/core/behavior-time-typeahead.js' => '522431f7',
|
2016-04-13 18:20:15 +02:00
|
|
|
'rsrc/js/core/behavior-toggle-class.js' => '92b9ec77',
|
2014-01-01 16:46:25 +01:00
|
|
|
'rsrc/js/core/behavior-tokenizer.js' => 'b3a4b884',
|
2017-01-31 17:58:33 +01:00
|
|
|
'rsrc/js/core/behavior-tooltip.js' => 'c420b0b9',
|
2017-01-17 22:59:56 +01:00
|
|
|
'rsrc/js/core/behavior-user-menu.js' => '31420f77',
|
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',
|
2017-04-17 21:10:29 +02:00
|
|
|
'rsrc/js/core/darkconsole/DarkLog.js' => 'c8e1ffe3',
|
|
|
|
'rsrc/js/core/darkconsole/DarkMessage.js' => 'c48cccdd',
|
2018-03-14 00:26:01 +01:00
|
|
|
'rsrc/js/core/darkconsole/behavior-dark-console.js' => '66888767',
|
2014-01-01 16:46:25 +01:00
|
|
|
'rsrc/js/core/phtize.js' => 'd254d646',
|
2017-01-18 20:17:11 +01:00
|
|
|
'rsrc/js/phui/behavior-phui-dropdown-menu.js' => 'b95d6f7d',
|
2016-05-21 01:26:11 +02:00
|
|
|
'rsrc/js/phui/behavior-phui-file-upload.js' => 'b003d4fb',
|
2017-11-30 14:14:05 +01:00
|
|
|
'rsrc/js/phui/behavior-phui-selectable-list.js' => '464259a2',
|
2016-06-21 02:49:38 +02:00
|
|
|
'rsrc/js/phui/behavior-phui-submenu.js' => 'a6f7a73b',
|
2016-07-01 01:55:28 +02:00
|
|
|
'rsrc/js/phui/behavior-phui-tab-group.js' => '0a0b10e9',
|
2014-05-05 19:57:23 +02:00
|
|
|
'rsrc/js/phuix/PHUIXActionListView.js' => 'b5c256b8',
|
2018-03-30 20:02:01 +02:00
|
|
|
'rsrc/js/phuix/PHUIXActionView.js' => '8d4a8c72',
|
2018-03-30 17:42:18 +02:00
|
|
|
'rsrc/js/phuix/PHUIXAutocomplete.js' => 'df1bbd34',
|
2018-08-17 19:53:28 +02:00
|
|
|
'rsrc/js/phuix/PHUIXButtonView.js' => '85ac9772',
|
2017-10-09 19:52:27 +02:00
|
|
|
'rsrc/js/phuix/PHUIXDropdownMenu.js' => '04b2ae03',
|
2017-05-30 23:47:50 +02:00
|
|
|
'rsrc/js/phuix/PHUIXExample.js' => '68af71ca',
|
Use a tokenizer, not a gigantic poorly-ordered "<select />", to choose repositories in Owners
Summary: Depends on D19190. Fixes T12590. Ref T13099. Replaces the barely-usable, gigantic, poorly ordered "<select />" control with a tokenizer. Attempts to fix various minor issues.
Test Plan:
- Edited paths: include/exclude paths, from different repositories, different actual paths.
- Used "Add New Path" to add rows, got repository selector prepopulated with last value.
- Used "remove".
- Used validation typeahead, got reasonable behaviors?
The error behavior if you delete the repository for a path is a little sketchy still, but roughly okay.
Maniphest Tasks: T13099, T12590
Differential Revision: https://secure.phabricator.com/D19191
2018-03-08 02:29:06 +01:00
|
|
|
'rsrc/js/phuix/PHUIXFormControl.js' => '210a16c1',
|
2015-12-02 23:38:11 +01:00
|
|
|
'rsrc/js/phuix/PHUIXIconView.js' => 'bff6884b',
|
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',
|
2018-03-14 18:55:08 +01:00
|
|
|
'aphront-dark-console-css' => '0e14e8f6',
|
2017-08-10 05:01:31 +02:00
|
|
|
'aphront-dialog-view-css' => '6bfc244b',
|
2015-09-08 02:18:35 +02:00
|
|
|
'aphront-list-filter-view-css' => '5d6f0526',
|
2016-09-29 07:27:19 +02:00
|
|
|
'aphront-multi-column-view-css' => '84cc6640',
|
2015-03-07 01:44:18 +01:00
|
|
|
'aphront-panel-view-css' => '8427b78d',
|
Mobile layouts for Diffusion
Summary: Implements a new mobile view thats more fullscreen, not boxed, so more space. Fixes issues with mobile tables when scrolling overflowed content.
Test Plan: Test home, branch, tags, code, file browse, graph, compare, history, readme, open revisions, owners.
Reviewers: epriestley
Reviewed By: epriestley
Spies: Korvin
Differential Revision: https://secure.phabricator.com/D18505
2017-08-30 21:00:07 +02:00
|
|
|
'aphront-table-view-css' => '8c9bbafe',
|
2017-06-01 22:30:00 +02:00
|
|
|
'aphront-tokenizer-control-css' => '15d5ff71',
|
2018-11-15 13:03:47 +01:00
|
|
|
'aphront-tooltip-css' => 'cb1397a4',
|
2017-08-14 20:18:29 +02:00
|
|
|
'aphront-typeahead-control-css' => 'a4a21016',
|
Mobile layouts for Diffusion
Summary: Implements a new mobile view thats more fullscreen, not boxed, so more space. Fixes issues with mobile tables when scrolling overflowed content.
Test Plan: Test home, branch, tags, code, file browse, graph, compare, history, readme, open revisions, owners.
Reviewers: epriestley
Reviewed By: epriestley
Spies: Korvin
Differential Revision: https://secure.phabricator.com/D18505
2017-08-30 21:00:07 +02:00
|
|
|
'application-search-view-css' => '787f5b76',
|
2015-07-18 17:51:25 +02:00
|
|
|
'auth-css' => '0877ed6e',
|
2015-06-23 22:43:47 +02:00
|
|
|
'bulk-job-css' => 'df9c1d4a',
|
2015-05-08 21:19:52 +02:00
|
|
|
'conduit-api-css' => '7bc725c4',
|
2017-09-06 00:21:12 +02:00
|
|
|
'config-options-css' => '4615667b',
|
2017-04-20 23:23:23 +02:00
|
|
|
'conpherence-color-css' => 'abb4c358',
|
2017-04-13 20:20:51 +02:00
|
|
|
'conpherence-durable-column-view' => '89ea6bef',
|
2017-04-20 23:23:23 +02:00
|
|
|
'conpherence-header-pane-css' => 'cb6f4e19',
|
2017-07-17 20:08:17 +02:00
|
|
|
'conpherence-menu-css' => '69368e97',
|
2017-04-18 22:37:52 +02:00
|
|
|
'conpherence-message-pane-css' => 'b0f55ecc',
|
2017-04-13 05:44:32 +02:00
|
|
|
'conpherence-notification-css' => 'cef0a3fc',
|
2017-04-17 19:59:11 +02:00
|
|
|
'conpherence-participant-pane-css' => '26a3ce56',
|
Fix several duplication/replay behaviors in Aphlict
Summary:
Ref T12566. Ref T12563. This fixes three bugs with Aphlict replay stuff:
First, Conphernece would try to repaint the UI even if no thread was open. Only repaint when a thread is open.
Second, although we deduplicate JX.Leader messages, we didn't deduplicate actual notification messages. If you browsed the leader window, then it re-elected itelf as a leader and replayed history, it could rebroadcast notifications and other windows could show doubles. Deduplicate notifications to prevent this.
Third, we always replayed the last 60 seconds of history. When you browsed the leader window, whichever window became the new leader (possibly the one you just browsed) could replay messages from before it had opened, leading to duplicate messages. Particularly, after receiving a message and then browsing you could see that message again. Instead, only replay history as far back as when the window first opened.
Test Plan:
- Clicked "Repaint" with a thread open, saw a repaint. Clicked "Repaint" with Conpherence open but no thread, no repaint and no 404 request to `/update/null/`.
- In browser A, opened three windows. In browser B, sent a notification. In browser A, browsed the leader window away twice in a row. Observed that the window which never became a leader doesn't duplicate notifications.
- In browser A, opened three windows. In browser B, sent a notification. In browser A, browsed the leader window away over and over again. Observed that replay requests issued with appropriate history windows.
Reviewers: chad
Reviewed By: chad
Maniphest Tasks: T12566, T12563
Differential Revision: https://secure.phabricator.com/D17722
2017-04-18 20:14:37 +02:00
|
|
|
'conpherence-thread-manager' => '4d863052',
|
2016-10-15 15:58:46 +02:00
|
|
|
'conpherence-transaction-css' => '85129c68',
|
2016-01-28 22:29:27 +01:00
|
|
|
'd3' => 'a11a5ff2',
|
2018-04-08 20:38:19 +02:00
|
|
|
'differential-changeset-view-css' => 'db34a142',
|
2016-03-12 22:02:32 +01:00
|
|
|
'differential-core-view-css' => '5b7b8ff4',
|
2015-03-28 00:00:09 +01:00
|
|
|
'differential-revision-add-comment-css' => 'c47f8c40',
|
2015-05-04 21:21:21 +02:00
|
|
|
'differential-revision-comment-css' => '14b8565a',
|
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',
|
2015-06-23 22:43:47 +02:00
|
|
|
'differential-table-of-contents-css' => 'ae4b7a55',
|
2017-08-30 21:56:47 +02:00
|
|
|
'diffusion-css' => '45727264',
|
2017-07-09 04:54:23 +02:00
|
|
|
'diffusion-icons-css' => '0c15255e',
|
2017-06-07 00:29:57 +02:00
|
|
|
'diffusion-readme-css' => '419dd5b6',
|
Move Diffusion Browse to a single column layout
Summary: The main change here is moving (compare, search, history) into buttons in the header bar on all browse views. This allows Directory Browsing to be full width, since there is no other curtain information. File, Image, LFS, Binary all stay in TwoColumn layouts with the same buttons in the header.
Test Plan: Test viewing a directory, file, image, binary file, readme, and fake a gitlfs.
Reviewers: epriestley
Reviewed By: epriestley
Subscribers: Korvin
Differential Revision: https://secure.phabricator.com/D17766
2017-07-01 17:38:17 +02:00
|
|
|
'diffusion-repository-css' => 'ee6f20ec',
|
2017-02-14 06:06:01 +01:00
|
|
|
'diviner-shared-css' => '896f1d43',
|
2017-02-02 00:25:20 +01:00
|
|
|
'font-fontawesome' => 'e838e088',
|
2015-11-22 22:03:58 +01:00
|
|
|
'font-lato' => 'c7ccd872',
|
2017-07-17 20:08:17 +02:00
|
|
|
'global-drag-and-drop-css' => 'b556a948',
|
2018-08-28 22:02:17 +02:00
|
|
|
'harbormaster-css' => '7446ce72',
|
2017-12-11 20:33:15 +01:00
|
|
|
'herald-css' => 'cd8d0134',
|
2018-01-19 23:43:20 +01:00
|
|
|
'herald-rule-editor' => 'dca75c0e',
|
2015-07-18 14:54:26 +02:00
|
|
|
'herald-test-css' => 'a52e323e',
|
2017-07-17 20:08:17 +02:00
|
|
|
'inline-comment-summary-css' => 'f23d4e8f',
|
Fix several duplication/replay behaviors in Aphlict
Summary:
Ref T12566. Ref T12563. This fixes three bugs with Aphlict replay stuff:
First, Conphernece would try to repaint the UI even if no thread was open. Only repaint when a thread is open.
Second, although we deduplicate JX.Leader messages, we didn't deduplicate actual notification messages. If you browsed the leader window, then it re-elected itelf as a leader and replayed history, it could rebroadcast notifications and other windows could show doubles. Deduplicate notifications to prevent this.
Third, we always replayed the last 60 seconds of history. When you browsed the leader window, whichever window became the new leader (possibly the one you just browsed) could replay messages from before it had opened, leading to duplicate messages. Particularly, after receiving a message and then browsing you could see that message again. Instead, only replay history as far back as when the window first opened.
Test Plan:
- Clicked "Repaint" with a thread open, saw a repaint. Clicked "Repaint" with Conpherence open but no thread, no repaint and no 404 request to `/update/null/`.
- In browser A, opened three windows. In browser B, sent a notification. In browser A, browsed the leader window away twice in a row. Observed that the window which never became a leader doesn't duplicate notifications.
- In browser A, opened three windows. In browser B, sent a notification. In browser A, browsed the leader window away over and over again. Observed that replay requests issued with appropriate history windows.
Reviewers: chad
Reviewed By: chad
Maniphest Tasks: T12566, T12563
Differential Revision: https://secure.phabricator.com/D17722
2017-04-18 20:14:37 +02:00
|
|
|
'javelin-aphlict' => 'e1d4b11a',
|
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',
|
2017-01-17 22:59:56 +01:00
|
|
|
'javelin-behavior-aphlict-dropdown' => 'caade6f2',
|
2018-03-16 23:10:26 +01:00
|
|
|
'javelin-behavior-aphlict-listen' => '599a8f5f',
|
2016-10-02 05:37:28 +02:00
|
|
|
'javelin-behavior-aphlict-status' => '5e2634b9',
|
2014-01-01 16:46:25 +01:00
|
|
|
'javelin-behavior-aphront-basic-tokenizer' => 'b3a4b884',
|
2016-05-21 01:26:11 +02:00
|
|
|
'javelin-behavior-aphront-drag-and-drop-textarea' => '484a6e22',
|
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',
|
2016-04-13 18:20:15 +02:00
|
|
|
'javelin-behavior-badge-view' => '8ff5e24c',
|
2018-01-19 16:32:28 +01:00
|
|
|
'javelin-behavior-bulk-editor' => '66a6def1',
|
2015-06-23 22:43:47 +02:00
|
|
|
'javelin-behavior-bulk-job-reload' => 'edf8a145',
|
2016-07-27 15:44:42 +02:00
|
|
|
'javelin-behavior-calendar-month-view' => 'fe33e256',
|
Allow installs to customize project icons
Summary:
Ref T10010. Ref T5819. General alignment of the stars:
- There were some hacks in Conduit around stripping `fa-...` off icons when reading and writing that I wanted to get rid of.
- We probably have room for a subtitle in the new heavy nav, and using the icon name is a good starting point (and maybe good enough on its own?)
- The project list was real bad looking with redundant tag/names, now it is very slightly less bad looking with non-redundant types?
- Some installs will want to call Milestones something else, and this gets us a big part of the way there.
- This may slightly help to reinforce "tag" vs "policy" vs "group" stuff?
---
I'm letting installs have enough rope to shoot themselves in the foot (e.g., define 100 icons). It isn't the end of the world if they reuse icons, and is clearly their fault.
I think the cases where 100 icons will break down are:
- Icon selector dialog may get very unwieldy.
- Query UI will be pretty iffy/huge with 100 icons.
We could improve these fairly easily if an install comes up with a reasonable use case for having 100 icons.
---
The UI on the icon itself in the list views is a little iffy -- mostly, it's too saturated/bold.
I'd ideally like to try either:
- rendering a "shade" version (i.e. lighter, less-saturated color); or
- rendering a "shade" tag with just the icon in it.
However, there didn't seem to be a way to do the first one right now (`fa-example sh-blue` doesn't work) and the second one had weird margins/padding, so I left it like this for now. I figure we can clean it up once we build the thick nav, since that will probably also want an identical element.
(I don't want to render a full tag with the icon + name since I think that's confusing -- it looks like a project/object tag, but is not.)
Test Plan:
{F1049905}
{F1049906}
Reviewers: chad
Reviewed By: chad
Subscribers: 20after4, Luke081515.2
Maniphest Tasks: T5819, T10010
Differential Revision: https://secure.phabricator.com/D14918
2015-12-30 13:36:48 +01:00
|
|
|
'javelin-behavior-choose-control' => '327a00d1',
|
Pass timeline view data to comment previews, restoring Differential comment previews
Summary:
Ref T13222. In D19918, I refactored how timelines get "view data". Today, this is always additional data about which images/changesets/diffs are visible on the current revision/commit/mock, so we can tell if inline comments should be linked to a `#anchor` on the same page (if the inline is rendered there somewhere) or to a `/D123?id=1&vs=2` full link on a different page (if it isn't), but in general this could be any sort of state information about the current page that affects how the timeline should render.
Previously, comment previews did not use any specialized object code and always rendered a "generic" timeline story. This was actually a bug, but none of the code we have today cares about this (since it's all inline related, and inlines render separately) so it never impacted anything.
After the `TimelineEngine` change, the preview renders with Differential-specific code. This is more correct, but we were not passing the preview the "view data" so it broke.
This preview doesn't actually need the view data and we could just make it bail out if it isn't present, but pass it through for consistency and so this works like we'd expect if we do something fancier with view data in the future.
Test Plan: Viewed comment and inline comment previews in Differential, saw old behavior restored.
Reviewers: amckinley
Reviewed By: amckinley
Maniphest Tasks: T13222
Differential Revision: https://secure.phabricator.com/D19943
2019-01-03 01:48:53 +01:00
|
|
|
'javelin-behavior-comment-actions' => 'd848ec84',
|
2015-05-25 14:34:23 +02:00
|
|
|
'javelin-behavior-config-reorder-fields' => 'b6993408',
|
2017-10-09 19:52:27 +02:00
|
|
|
'javelin-behavior-conpherence-menu' => '4047cd35',
|
|
|
|
'javelin-behavior-conpherence-participant-pane' => 'd057e45a',
|
2017-04-10 23:39:36 +02:00
|
|
|
'javelin-behavior-conpherence-pontificate' => '55616e04',
|
Remove 'full-display' setting from Conpherence, spruce up search results
Summary: This removes 'full-display', 'minimal-display' from Conpherence, which I recall was because we had 2 UIs for column and regular chat. I'm also tossing in slightly nicer search results, with a link to the actual message and the full date shown for context.
Test Plan: Post a message in mobile, tablet, full conpherence, and in durable column. Clean up UI in durable column. Do a search in Full UI, click on result date, get taken to the message... usually. My test data is a little wonky, but I think this works most of the time.
Reviewers: epriestley
Reviewed By: epriestley
Subscribers: Korvin
Differential Revision: https://secure.phabricator.com/D16710
2016-10-16 05:26:15 +02:00
|
|
|
'javelin-behavior-conpherence-search' => '9bbf3762',
|
2014-12-30 11:53:27 +01:00
|
|
|
'javelin-behavior-countdown-timer' => 'e4cc26b3',
|
2018-03-14 00:26:01 +01:00
|
|
|
'javelin-behavior-dark-console' => '66888767',
|
2014-05-19 23:04:26 +02:00
|
|
|
'javelin-behavior-dashboard-async-panel' => '469c0d9e',
|
2017-02-14 23:08:56 +01:00
|
|
|
'javelin-behavior-dashboard-move-panels' => '408bf173',
|
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',
|
2016-07-15 23:02:24 +02:00
|
|
|
'javelin-behavior-day-view' => '4b3c4443',
|
2017-08-23 23:35:02 +02:00
|
|
|
'javelin-behavior-desktop-notifications-control' => '27ca6289',
|
2016-05-22 15:50:12 +02:00
|
|
|
'javelin-behavior-detect-timezone' => '4c193c96',
|
2017-10-09 19:52:27 +02:00
|
|
|
'javelin-behavior-device' => 'a3714c76',
|
Make some Differential comment actions (like "Accept" and "Reject") conflict with one another
Summary:
Ref T11114. When a user selects "Accept", and then selects "Reject", remove the "Accept". It does not make sense to both accept and reject a revision.
For now, every one of the "actions" conflicts: accept, reject, resign, claim, close, commandeer, etc, etc. I couldn't come up with any combinations that it seems like users are reasonably likely to want to try, and we haven't received combo-action requests in the past that I can recall.
Test Plan:
- Selected "Accept", then selected "Reject". One replaced the other.
- Selected "Accept", then selected "Change Subscribers". Both co-existed happily.
Reviewers: chad
Reviewed By: chad
Maniphest Tasks: T11114
Differential Revision: https://secure.phabricator.com/D17132
2017-01-02 20:17:27 +01:00
|
|
|
'javelin-behavior-diff-preview-link' => '051c7832',
|
2014-01-01 16:46:25 +01:00
|
|
|
'javelin-behavior-differential-diff-radios' => 'e1ff79b1',
|
In Differential standalone views, disable some keyboard shortcuts which don't work
Summary:
Ref T13164. See PHI693. In Differential, you can {nav View Options > View Standalone} to get a standalone view of a single changeset. You can also arrive here via the big changeset list for revisions affecting a huge number of files.
We currently suggest that all the keyboard shortcuts work, but some do not. In particular, the "Next File" and "Previous File" keyboard shortcuts (and some similar shortcuts) do not work. In the main view, the next/previous files are on the same page. In the standalone view, we'd need to actually change the URI.
Ideally, we should do this (and, e.g., put prev/next links on the page). As a first step toward that, hide the nonfunctional shortcuts to stop users from being misled.
Test Plan:
- Viewed a revision in normal and standalone views.
- No changes in normal view, and all keys still work ("N", "P", etc).
- In standalone view, "?" no longer shows nonfunctional key commands.
Reviewers: amckinley
Reviewed By: amckinley
Maniphest Tasks: T13164
Differential Revision: https://secure.phabricator.com/D19571
2018-08-13 17:21:16 +02:00
|
|
|
'javelin-behavior-differential-populate' => 'f0eb6708',
|
2014-01-01 16:46:25 +01:00
|
|
|
'javelin-behavior-differential-user-select' => 'a8d8459d',
|
2014-02-27 20:06:55 +01:00
|
|
|
'javelin-behavior-diffusion-commit-branches' => 'bdaf4d04',
|
2017-06-07 00:47:47 +02:00
|
|
|
'javelin-behavior-diffusion-commit-graph' => '75b83cbb',
|
2014-05-13 23:09:00 +02:00
|
|
|
'javelin-behavior-diffusion-locate-file' => '6d3e1947',
|
2015-10-07 16:32:27 +02:00
|
|
|
'javelin-behavior-diffusion-pull-lastmodified' => 'f01586dc',
|
2018-04-28 15:43:09 +02:00
|
|
|
'javelin-behavior-document-engine' => '3935d8c4',
|
Allow Doorkeeper references to have multiple display variations (full, short, etc.)
Summary:
Ref T13102. An install has a custom rule for bridging JIRA references via Doorkeeper and would like to be able to render them as `JIRA-123` instead of `JIRA JIRA-123 Full JIRA title`.
I think it's reasonable to imagine future support upstream for `JIRA-123`, `{JIRA-123}`, and so on, although we do not support these today. We can take a small step toward eventual support by letting the rendering pipeline understand different view modes.
This adds an optional `name` (the default text rendered before we do the OAuth sync) and an optional `view`, which can be `short` or `full`.
Test Plan:
I tested this primarily with Asana, since it's less of a pain to set up than JIRA. The logic should be similar, hopefully.
I changed `DoorkeeperAsanaRemarkupRule` to specify `name` and `view`, e.g `'view' => (mt_rand(0, 1) ? 'short' : 'full')`. Then I made a bunch of Asana references in a comment and saw them randomly go short or long.
Maniphest Tasks: T13102
Differential Revision: https://secure.phabricator.com/D19215
2018-03-13 19:09:22 +01:00
|
|
|
'javelin-behavior-doorkeeper-tag' => '1db13e70',
|
2015-10-21 20:28:26 +02:00
|
|
|
'javelin-behavior-drydock-live-operation-status' => '901935ef',
|
2017-04-26 19:48:50 +02:00
|
|
|
'javelin-behavior-durable-column' => '2ae077e1',
|
2015-12-08 15:14:47 +01:00
|
|
|
'javelin-behavior-editengine-reorder-configs' => 'd7a74243',
|
2015-11-17 18:33:06 +01:00
|
|
|
'javelin-behavior-editengine-reorder-fields' => 'b59e1e96',
|
2016-10-31 19:38:35 +01:00
|
|
|
'javelin-behavior-event-all-day' => 'b41537c9',
|
Fix a hang in fancy date picker for Ye Olde Time Years
Summary:
Fixes T12960. When the user enters a date like "1917", we currently loop ~20 million times.
Instead:
- Be a little more careful about parsing.
- Javascript's default behavior of interpreting "2001-02-31" as "2001-03-03" ("February 31" -> "March 3") already seems reasonable, so just let it do that.
Test Plan:
Verified these behaviors:
- `2017-08-08` - Valid, recent.
- `17-08-08` - Valid, recent.
- `1917-08-08` - Valid, a century ago, no loop.
- `2017-02-31` - "February 31", interpreted as "March 3" by Javascsript, seems reasonable.
- `Quack` - Default, current time.
- `0/0/0`, `0/99/0` - Default, current time.
Reviewers: avivey, chad
Reviewed By: chad
Maniphest Tasks: T12960
Differential Revision: https://secure.phabricator.com/D18383
2017-08-10 12:31:20 +02:00
|
|
|
'javelin-behavior-fancy-datepicker' => 'ecf4e799',
|
2016-10-18 23:24:17 +02:00
|
|
|
'javelin-behavior-global-drag-and-drop' => '960f6a39',
|
2018-04-27 19:58:28 +02:00
|
|
|
'javelin-behavior-harbormaster-log' => '549459b8',
|
2014-01-01 16:46:25 +01:00
|
|
|
'javelin-behavior-herald-rule-editor' => '7ebaeed3',
|
2015-04-24 01:37:56 +02:00
|
|
|
'javelin-behavior-high-security-warning' => 'a464fe03',
|
2014-01-01 16:46:25 +01:00
|
|
|
'javelin-behavior-history-install' => '7ee2b591',
|
2016-01-19 17:43:31 +01:00
|
|
|
'javelin-behavior-icon-composer' => '8499b6ab',
|
2014-02-27 20:06:55 +01:00
|
|
|
'javelin-behavior-launch-icon-composer' => '48086888',
|
2018-03-08 17:22:16 +01:00
|
|
|
'javelin-behavior-lightbox-attachments' => '6b31879a',
|
2016-01-28 22:29:27 +01:00
|
|
|
'javelin-behavior-line-chart' => 'e4232876',
|
Replace the "Choose Subtype" radio buttons dialog with a simpler "big stuff you click" sort of UI
Summary:
Ref T13222. Fixes T12588. See PHI683. In several cases, we present the user with a choice between multiple major options: Alamnac service types, Drydock blueprint types, Repository VCS types, Herald rule types, etc.
Today, we generally do this with radio buttons and a "Submit" button. This isn't terrible, but often it means users have to click twice (once on the radio; once on submit) when a single click would be sufficient. The radio click target can also be small.
In other cases, we have a container with a link and we'd like to link the entire container: notifications, the `/drydock/` console, etc. We'd like to just link the entire container, but this causes some problems:
- It's not legal to link block eleements like `<a><div> ... </div></a>` and some browsers actually get upset about it.
- We can `<a><span> ... </span></a>` instead, then turn the `<span>` into a block element with CSS -- and this sometimes works, but also has some drawbacks:
- It's not great to do that for screenreaders, since the readable text in the link isn't necessarily very meaningful.
- We can't have any other links inside the element (e.g., details or documentation).
- We can `<form><button> ... </button></form>` instead, but this has its own set of problems:
- You can't right-click to interact with a button in the same way you can with a link.
- Also not great for screenreaders.
Instead, try adding a `linked-container` behavior which just means "when users click this element, pretend they clicked the first link inside it".
This gives us natural HTML (real, legal HTML with actual `<a>` tags) and good screenreader behavior, but allows the effective link target to be visually larger than just the link.
If no issues crop up with this, I'd plan to eventually use this technique in more places (Repositories, Herald, Almanac, Drydock, Notifications menu, etc).
Test Plan:
{F6053035}
- Left-clicked and command-left-clicked the new JS fanciness, got sensible behaviors.
Reviewers: amckinley
Reviewed By: amckinley
Subscribers: PHID-OPKG-gm6ozazyms6q6i22gyam
Maniphest Tasks: T13222, T12588
Differential Revision: https://secure.phabricator.com/D19855
2018-12-07 15:04:07 +01:00
|
|
|
'javelin-behavior-linked-container' => '291da458',
|
2017-11-30 14:57:39 +01:00
|
|
|
'javelin-behavior-maniphest-batch-selector' => 'ad54037e',
|
2014-06-23 19:27:47 +02:00
|
|
|
'javelin-behavior-maniphest-list-editor' => 'a9f88de2',
|
2015-06-30 18:37:12 +02:00
|
|
|
'javelin-behavior-maniphest-subpriority-editor' => '71237763',
|
2014-01-01 16:46:25 +01:00
|
|
|
'javelin-behavior-owners-path-editor' => '7a68dda3',
|
2015-03-02 22:01:00 +01:00
|
|
|
'javelin-behavior-passphrase-credential-control' => '3cb0b2fc',
|
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',
|
2017-05-31 05:00:15 +02:00
|
|
|
'javelin-behavior-phabricator-clipboard-copy' => 'b0b8f86d',
|
2014-06-23 19:27:47 +02:00
|
|
|
'javelin-behavior-phabricator-file-tree' => '88236f00',
|
|
|
|
'javelin-behavior-phabricator-gesture' => '3ab51e2c',
|
|
|
|
'javelin-behavior-phabricator-gesture-example' => '558829c2',
|
|
|
|
'javelin-behavior-phabricator-keyboard-pager' => 'a8da01f0',
|
Make "/" focus the search input again
Summary:
See D1902, T989, T11263, D15984, T4103 , D15976, https://secure.phabricator.com/w/changelog/2016.22/, T2527, T11231, T8286, T11264 for discussion!
When we get another copy of T989, I will rename it to "Build a complicated keybinding settings page like a cool video game" and leave it open forever.
Test Plan: Pressed "/" in Firefox, had my pristine browsing experience inexplicably hijacked by this horrible application.
Reviewers: avivey, chad
Reviewed By: avivey
Subscribers: Korvin
Differential Revision: https://secure.phabricator.com/D15984
2016-07-08 22:57:33 +02:00
|
|
|
'javelin-behavior-phabricator-keyboard-shortcuts' => '01fca1f0',
|
2018-04-11 23:44:06 +02:00
|
|
|
'javelin-behavior-phabricator-line-linker' => '66a62306',
|
2018-08-27 19:09:13 +02:00
|
|
|
'javelin-behavior-phabricator-nav' => '9d32bc88',
|
2014-12-30 11:54:21 +01:00
|
|
|
'javelin-behavior-phabricator-notification-example' => '8ce821c5',
|
2017-06-07 22:48:19 +02:00
|
|
|
'javelin-behavior-phabricator-object-selector' => '77c1f0b0',
|
2014-06-23 19:35:39 +02:00
|
|
|
'javelin-behavior-phabricator-oncopy' => '2926fff2',
|
2017-04-26 17:49:53 +02:00
|
|
|
'javelin-behavior-phabricator-remarkup-assist' => 'acd29eee',
|
2014-06-23 19:27:47 +02:00
|
|
|
'javelin-behavior-phabricator-reveal-content' => '60821bc7',
|
2018-02-16 16:09:17 +01:00
|
|
|
'javelin-behavior-phabricator-search-typeahead' => 'c3e917d9',
|
Remove "willRenderTimeline()" from ApplicationTransactionInterface
Summary:
Depends on D19914. Ref T11351. Some of the Phoilo rabbit holes go very deep.
`PhabricatorApplicationTransactionInterface` currently requires you to implement `willRenderTimeline()`. Almost every object just implements this as `return $timeline`; only Pholio, Diffusion, and Differential specialize it. In all cases, they are specializing it mostly to render inline comments.
The actual implementations are a bit of a weird mess and the way the data is threaded through the call stack is weird and not very modern.
Try to clean this up:
- Stop requiring `willRenderTimeline()` to be implemented.
- Stop requiring `getApplicationTransactionViewObject()` to be implemented (only the three above, plus Legalpad, implement this, and Legalpad's implementation is a no-op). These two methods are inherently pretty coupled for almost any reasonable thing you might want to do with the timeline.
- Simplify the handling of "renderdata" and call it "View Data". This is additional information about the current view of the transaction timeline that is required to render it correctly. This is only used in Differential, to decide if we can link an inline comment to an anchor on the same page or should link it to another page. We could perhaps do this on the client instead, but having this data doesn't seem inherently bad to me.
- If objects want to customize timeline rendering, they now implement `PhabricatorTimelineInterface` and provide a `TimelineEngine` which gets a nice formal stack.
This leaves a lot of empty `willRenderTimeline()` implementations hanging around. I'll remove these in the next change, it's just going to be deleting a couple dozen copies of an identical empty method implementation.
Test Plan:
- Viewed audits, revisions, and mocks with inline comments.
- Used "Show Older" to page a revision back in history (this is relevant for "View Data").
- Grepped for symbols: willRenderTimeline, getApplicationTransactionViewObject, Legalpad classes.
Reviewers: amckinley
Reviewed By: amckinley
Maniphest Tasks: T11351
Differential Revision: https://secure.phabricator.com/D19918
2018-12-19 20:52:53 +01:00
|
|
|
'javelin-behavior-phabricator-show-older-transactions' => '0e1eca96',
|
2017-01-31 17:58:33 +01:00
|
|
|
'javelin-behavior-phabricator-tooltips' => 'c420b0b9',
|
2015-05-18 21:18:10 +02:00
|
|
|
'javelin-behavior-phabricator-transaction-comment-form' => 'b23b49e6',
|
2017-04-18 18:05:00 +02:00
|
|
|
'javelin-behavior-phabricator-transaction-list' => '1f6794f6',
|
2015-01-28 17:26:10 +01:00
|
|
|
'javelin-behavior-phabricator-watch-anchor' => '9f36c42d',
|
2016-06-09 17:34:00 +02:00
|
|
|
'javelin-behavior-pholio-mock-edit' => 'bee502c8',
|
2017-10-09 19:52:27 +02:00
|
|
|
'javelin-behavior-pholio-mock-view' => 'ec1f3669',
|
2017-01-18 20:17:11 +01:00
|
|
|
'javelin-behavior-phui-dropdown-menu' => 'b95d6f7d',
|
2016-05-21 01:26:11 +02:00
|
|
|
'javelin-behavior-phui-file-upload' => 'b003d4fb',
|
2016-02-03 17:26:30 +01:00
|
|
|
'javelin-behavior-phui-hovercards' => 'bcaccd64',
|
2017-11-30 14:14:05 +01:00
|
|
|
'javelin-behavior-phui-selectable-list' => '464259a2',
|
2016-06-21 02:49:38 +02:00
|
|
|
'javelin-behavior-phui-submenu' => 'a6f7a73b',
|
2016-07-01 01:55:28 +02:00
|
|
|
'javelin-behavior-phui-tab-group' => '0a0b10e9',
|
2017-05-30 23:47:50 +02:00
|
|
|
'javelin-behavior-phuix-example' => '68af71ca',
|
2016-02-05 19:30:20 +01:00
|
|
|
'javelin-behavior-policy-control' => 'd0c516d5',
|
2015-04-17 16:55:17 +02:00
|
|
|
'javelin-behavior-policy-rule-editor' => '5e9f347c',
|
2017-03-02 02:13:36 +01:00
|
|
|
'javelin-behavior-project-boards' => '4250a34e',
|
2014-01-01 16:46:25 +01:00
|
|
|
'javelin-behavior-project-create' => '065227cc',
|
2015-03-10 23:32:15 +01:00
|
|
|
'javelin-behavior-quicksand-blacklist' => '7927a7d3',
|
2016-04-10 13:26:53 +02:00
|
|
|
'javelin-behavior-read-only-warning' => 'ba158207',
|
2018-03-06 19:25:05 +01:00
|
|
|
'javelin-behavior-redirect' => '0213259f',
|
When logged-out users hit a "Login Required" dialog, try to choose a better "next" URI
Summary:
Ref T10004. After a user logs in, we send them to the "next" URI cookie if there is one, but currently don't always do a very good job of selecting a "next" URI, especially if they tried to do something with a dialog before being asked to log in.
In particular, if a logged-out user clicks an action like "Edit Blocking Tasks" on a Maniphest task, the default behavior is to send them to the standalone page for that dialog after they log in. This can be pretty confusing.
See T2691 and D6416 for earlier efforts here. At that time, we added a mechanism to //manually// override the default behavior, and fixed the most common links. This worked, but I'd like to fix the //default// beahvior so we don't need to remember to `setObjectURI()` correctly all over the place.
ApplicationEditor has also introduced new cases which are more difficult to get right. While we could get them right by using the override and being careful about things, this also motivates fixing the default behavior.
Finally, we have better tools for fixing the default behavior now than we did in 2013.
Instead of using manual overrides, have JS include an "X-Phabricator-Via" header in Ajax requests. This is basically like a referrer header, and will contain the page the user's browser is on.
In essentially every case, this should be a very good place (and often the best place) to send them after login. For all pages currently using `setObjectURI()`, it should produce the same behavior by default.
I'll remove the `setObjectURI()` mechanism in the next diff.
Test Plan: Clicked various workflow actions while logged out, saw "next" get set to a reasonable value, was redirected to a sensible, non-confusing page after login (the page with whatever button I clicked on it).
Reviewers: chad
Reviewed By: chad
Maniphest Tasks: T10004
Differential Revision: https://secure.phabricator.com/D14804
2015-12-17 15:10:04 +01:00
|
|
|
'javelin-behavior-refresh-csrf' => 'ab2f381b',
|
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',
|
2018-03-08 14:29:24 +01:00
|
|
|
'javelin-behavior-remarkup-load-image' => '040fce04',
|
2015-12-26 22:00:01 +01:00
|
|
|
'javelin-behavior-remarkup-preview' => '4b700e9e',
|
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',
|
2016-01-13 18:40:27 +01:00
|
|
|
'javelin-behavior-reorder-profile-menu-items' => 'e2e0a072',
|
2018-04-08 18:10:03 +02:00
|
|
|
'javelin-behavior-repository-crossreference' => '9a860428',
|
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',
|
2016-05-11 19:17:33 +02:00
|
|
|
'javelin-behavior-select-content' => 'bf5374ef',
|
2014-06-23 19:27:47 +02:00
|
|
|
'javelin-behavior-select-on-click' => '4e3e79a6',
|
2016-06-07 00:01:18 +02:00
|
|
|
'javelin-behavior-setup-check-https' => '491416b3',
|
2017-02-10 17:34:12 +01:00
|
|
|
'javelin-behavior-stripe-payment-form' => 'a6b98425',
|
2014-12-30 11:53:27 +01:00
|
|
|
'javelin-behavior-test-payment-form' => 'fc91ab6c',
|
2016-04-15 21:06:53 +02:00
|
|
|
'javelin-behavior-time-typeahead' => '522431f7',
|
2016-04-13 18:20:15 +02:00
|
|
|
'javelin-behavior-toggle-class' => '92b9ec77',
|
2016-10-19 06:49:02 +02:00
|
|
|
'javelin-behavior-toggle-widget' => '3dbf94d5',
|
2015-04-17 16:55:17 +02:00
|
|
|
'javelin-behavior-typeahead-browse' => '635de1ec',
|
|
|
|
'javelin-behavior-typeahead-search' => '93d0c9e3',
|
2017-01-17 22:59:56 +01:00
|
|
|
'javelin-behavior-user-menu' => '31420f77',
|
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',
|
2017-10-09 19:52:27 +02:00
|
|
|
'javelin-diffusion-locate-file-source' => '00676f00',
|
2017-05-17 16:00:42 +02:00
|
|
|
'javelin-dom' => '4976858c',
|
2014-02-27 20:06:55 +01:00
|
|
|
'javelin-dynval' => 'f6555212',
|
2018-11-24 15:59:19 +01:00
|
|
|
'javelin-event' => 'ef7e057f',
|
2014-01-01 16:46:25 +01:00
|
|
|
'javelin-fx' => '54b612ba',
|
2015-03-28 15:38:14 +01:00
|
|
|
'javelin-history' => 'd4505101',
|
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',
|
2017-04-17 21:10:29 +02:00
|
|
|
'javelin-leader' => '7f243deb',
|
2018-11-24 15:20:04 +01:00
|
|
|
'javelin-magical-init' => '8d83d2a1',
|
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',
|
When logged-out users hit a "Login Required" dialog, try to choose a better "next" URI
Summary:
Ref T10004. After a user logs in, we send them to the "next" URI cookie if there is one, but currently don't always do a very good job of selecting a "next" URI, especially if they tried to do something with a dialog before being asked to log in.
In particular, if a logged-out user clicks an action like "Edit Blocking Tasks" on a Maniphest task, the default behavior is to send them to the standalone page for that dialog after they log in. This can be pretty confusing.
See T2691 and D6416 for earlier efforts here. At that time, we added a mechanism to //manually// override the default behavior, and fixed the most common links. This worked, but I'd like to fix the //default// beahvior so we don't need to remember to `setObjectURI()` correctly all over the place.
ApplicationEditor has also introduced new cases which are more difficult to get right. While we could get them right by using the override and being careful about things, this also motivates fixing the default behavior.
Finally, we have better tools for fixing the default behavior now than we did in 2013.
Instead of using manual overrides, have JS include an "X-Phabricator-Via" header in Ajax requests. This is basically like a referrer header, and will contain the page the user's browser is on.
In essentially every case, this should be a very good place (and often the best place) to send them after login. For all pages currently using `setObjectURI()`, it should produce the same behavior by default.
I'll remove the `setObjectURI()` mechanism in the next diff.
Test Plan: Clicked various workflow actions while logged out, saw "next" get set to a reasonable value, was redirected to a sensible, non-confusing page after login (the page with whatever button I clicked on it).
Reviewers: chad
Reviewed By: chad
Maniphest Tasks: T10004
Differential Revision: https://secure.phabricator.com/D14804
2015-12-17 15:10:04 +01:00
|
|
|
'javelin-quicksand' => '6b8ef10b',
|
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',
|
2017-05-20 13:10:32 +02:00
|
|
|
'javelin-scrollbar' => '9065f639',
|
2015-03-10 23:30:49 +01:00
|
|
|
'javelin-sound' => '949c0fe5',
|
Emit a "Content-Security-Policy" HTTP header
Summary:
See PHI399. Ref T4340. This header provides an additional layer of protection against various attacks, including XSS attacks which embed inline `<script ...>` or `onhover="..."` content into the document.
**style-src**: The "unsafe-inline" directive affects both `style="..."` and `<style>`. We use a lot of `style="..."`, some very legitimately, so we can't realistically get away from this any time soon. We only use one `<style>` (for monospaced font preferences) but can't disable `<style>` without disabling `style="..."`.
**img-src**: We use "data:" URIs to inline small images into CSS, and there's a significant performance benefit from doing this. There doesn't seem to be a way to allow "data" URIs in CSS without allowing them in the document itself.
**script-src** and **frame-src**: For a small number of flows (Recaptcha, Stripe) we embed external javascript, some of which embeds child elements (or additional resources) into the document. We now whitelist these narrowly on the respective pages.
This won't work with Quicksand, so I've blacklisted it for now.
**connect-src**: We need to include `'self'` for AJAX to work, and any websocket URIs.
**Clickjacking**: We now have three layers of protection:
- X-Frame-Options: works in older browsers.
- `frame-ancestors 'none'`: does the same thing.
- Explicit framebust in JX.Stratcom after initialization: works in ancient IE.
We could probably drop the explicit framebust but it wasn't difficult to retain.
**script tags**: We previously used an inline `<script>` tag to start Javelin. I've moved this to `<data data-javelin-init ...>` tags, which seems to work properly.
**`__DEV__`**: We previously used an inline `<script>` tag to set the `__DEV__` mode flag. I tried using the "initialization" tags for this, but they fire too late. I moved it to `<html data-developer-mode="1">`, which seems OK everywhere.
**CSP Scope**: Only the CSP header on the original request appears to matter -- you can't refine the scope by emitting headers on CSS/JS. To reduce confusion, I disabled the headers on those response types. More headers could be disabled, although we're likely already deep in the land of diminishing returns.
**Initialization**: The initialization sequence has changed slightly. Previously, we waited for the <script> in bottom of the document to evaluate. Now, we go fishing for tags when domcontentready fires.
Test Plan:
- Browsed around in Firefox, Safari and Chrome looking for console warnings. Interacted with various Javascript behaviors. Enabled Quicksand.
- Disabled all the framebusting, launched a clickjacking attack, verified that each layer of protection is individually effective.
- Verified that the XHProf iframe in Darkconsole and the PHPAST frame layout work properly.
- Enabled notifications, verified no complaints about connecting to Aphlict.
- Hit `__DEV__` mode warnings based on the new data attribute.
- Tried to do sketchy stuff with `data:` URIs and SVGs. This works but doesn't seem to be able to do anything dangerous.
- Went through the Stripe and Recaptcha workflows.
- Dumped and examined the CSP headers with `curl`, etc.
- Added a raw <script> tag to a page (as though I'd found an XSS attack), verified it was no longer executed.
Maniphest Tasks: T4340
Differential Revision: https://secure.phabricator.com/D19143
2018-02-27 15:56:15 +01:00
|
|
|
'javelin-stratcom' => '327f418a',
|
2018-06-01 22:05:46 +02:00
|
|
|
'javelin-tokenizer' => 'bb6e5c16',
|
2015-01-14 01:10:57 +01:00
|
|
|
'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',
|
2016-11-17 13:13:39 +01:00
|
|
|
'javelin-typeahead-normalizer' => '185bbd53',
|
2016-01-16 23:33:03 +01:00
|
|
|
'javelin-typeahead-ondemand-source' => '013ffff9',
|
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-preloaded-source' => '54f314a0',
|
Use a tokenizer, not a gigantic poorly-ordered "<select />", to choose repositories in Owners
Summary: Depends on D19190. Fixes T12590. Ref T13099. Replaces the barely-usable, gigantic, poorly ordered "<select />" control with a tokenizer. Attempts to fix various minor issues.
Test Plan:
- Edited paths: include/exclude paths, from different repositories, different actual paths.
- Used "Add New Path" to add rows, got repository selector prepopulated with last value.
- Used "remove".
- Used validation typeahead, got reasonable behaviors?
The error behavior if you delete the repository for a path is a little sketchy still, but roughly okay.
Maniphest Tasks: T13099, T12590
Differential Revision: https://secure.phabricator.com/D19191
2018-03-08 02:29:06 +01:00
|
|
|
'javelin-typeahead-source' => 'ab9e0a82',
|
Time control typeaheads.
Summary: Ref T8031, Time control typeaheads
Test Plan: Edit an event, type '3', typeahead should suggest, '3:00 AM', '3:30 AM', '3:00 PM', '3:30 PM'.
Reviewers: chad, epriestley, #blessed_reviewers
Reviewed By: epriestley, #blessed_reviewers
Subscribers: Korvin, epriestley
Maniphest Tasks: T8031
Differential Revision: https://secure.phabricator.com/D12953
2015-05-20 18:51:26 +02:00
|
|
|
'javelin-typeahead-static-source' => '6c0e62fa',
|
When logged-out users hit a "Login Required" dialog, try to choose a better "next" URI
Summary:
Ref T10004. After a user logs in, we send them to the "next" URI cookie if there is one, but currently don't always do a very good job of selecting a "next" URI, especially if they tried to do something with a dialog before being asked to log in.
In particular, if a logged-out user clicks an action like "Edit Blocking Tasks" on a Maniphest task, the default behavior is to send them to the standalone page for that dialog after they log in. This can be pretty confusing.
See T2691 and D6416 for earlier efforts here. At that time, we added a mechanism to //manually// override the default behavior, and fixed the most common links. This worked, but I'd like to fix the //default// beahvior so we don't need to remember to `setObjectURI()` correctly all over the place.
ApplicationEditor has also introduced new cases which are more difficult to get right. While we could get them right by using the override and being careful about things, this also motivates fixing the default behavior.
Finally, we have better tools for fixing the default behavior now than we did in 2013.
Instead of using manual overrides, have JS include an "X-Phabricator-Via" header in Ajax requests. This is basically like a referrer header, and will contain the page the user's browser is on.
In essentially every case, this should be a very good place (and often the best place) to send them after login. For all pages currently using `setObjectURI()`, it should produce the same behavior by default.
I'll remove the `setObjectURI()` mechanism in the next diff.
Test Plan: Clicked various workflow actions while logged out, saw "next" get set to a reasonable value, was redirected to a sensible, non-confusing page after login (the page with whatever button I clicked on it).
Reviewers: chad
Reviewed By: chad
Maniphest Tasks: T10004
Differential Revision: https://secure.phabricator.com/D14804
2015-12-17 15:10:04 +01:00
|
|
|
'javelin-uri' => 'c989ade3',
|
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',
|
When disconnected from Aphlict after a successful connection, retry the first reconnect right away
Summary:
Fixes T12567. We currently retry after 2s, 4s, 8s, 16s, ...
If we connected cleanly once, retry the first time right away. There are a bunch of reasonable cases where this will work fine and we don't need to wait. Then we fall back: 0s, 2s, 4s, 8s, ...
Test Plan: {F4911905}
Reviewers: chad
Reviewed By: chad
Maniphest Tasks: T12567
Differential Revision: https://secure.phabricator.com/D17706
2017-04-17 22:20:48 +02:00
|
|
|
'javelin-websocket' => '3ffe32d6',
|
2017-01-24 16:25:57 +01:00
|
|
|
'javelin-workboard-board' => '8935deef',
|
2016-02-11 00:06:20 +01:00
|
|
|
'javelin-workboard-card' => 'c587b80f',
|
2017-05-22 19:47:19 +02:00
|
|
|
'javelin-workboard-column' => '758b4758',
|
2017-03-02 02:13:36 +01:00
|
|
|
'javelin-workboard-controller' => '26167537',
|
2018-03-22 18:58:56 +01:00
|
|
|
'javelin-workflow' => '6a726c55',
|
2016-01-28 05:56:36 +01:00
|
|
|
'maniphest-report-css' => '9b9580b7',
|
2015-06-26 18:33:03 +02:00
|
|
|
'maniphest-task-edit-css' => 'fda62a9b',
|
[Redesign] Put all ApplicationSearch results in an ObjectBox
Summary:
Ref T8099. In most cases we return either an ObjectList or AphrontTable, and can pretty up the UI in ApplicationSearch. There are a few edge cases, like PeopleUserLog, that can be cleanup up individually in the future, but look fine for now.
Also added 'setNotice' for AphrontTable for a few cases where we want to convey addtional information.
TODO: Seems we always pass a Pager Object, which tries to get displayed, I'll redesign that interaction in the future, probably by passing the Pager to the ObjectBox
Test Plan: Went throught most/all ApplicationSearch panels I could find, even edge cases look better.
Reviewers: btrahan, epriestley
Reviewed By: epriestley
Subscribers: Korvin, epriestley
Maniphest Tasks: T8099
Differential Revision: https://secure.phabricator.com/D12989
2015-05-24 18:13:58 +02:00
|
|
|
'maniphest-task-summary-css' => '11cc5344',
|
2014-11-17 23:06:05 +01:00
|
|
|
'multirow-row-manager' => 'b5d57730',
|
Use a tokenizer, not a gigantic poorly-ordered "<select />", to choose repositories in Owners
Summary: Depends on D19190. Fixes T12590. Ref T13099. Replaces the barely-usable, gigantic, poorly ordered "<select />" control with a tokenizer. Attempts to fix various minor issues.
Test Plan:
- Edited paths: include/exclude paths, from different repositories, different actual paths.
- Used "Add New Path" to add rows, got repository selector prepopulated with last value.
- Used "remove".
- Used validation typeahead, got reasonable behaviors?
The error behavior if you delete the repository for a path is a little sketchy still, but roughly okay.
Maniphest Tasks: T13099, T12590
Differential Revision: https://secure.phabricator.com/D19191
2018-03-08 02:29:06 +01:00
|
|
|
'owners-path-editor' => 'c96502cf',
|
|
|
|
'owners-path-editor-css' => '9c136c29',
|
2017-07-17 20:08:17 +02:00
|
|
|
'paste-css' => '9fcc9773',
|
2018-08-13 20:35:02 +02:00
|
|
|
'path-typeahead' => '6d8c7912',
|
2017-02-05 21:45:27 +01:00
|
|
|
'people-picture-menu-item-css' => 'a06f7f34',
|
2017-02-09 15:45:47 +01:00
|
|
|
'people-profile-css' => '4df76faf',
|
2018-02-08 19:37:47 +01:00
|
|
|
'phabricator-action-list-view-css' => '0bcd9a45',
|
2015-04-02 05:10:32 +02:00
|
|
|
'phabricator-busy' => '59a7976a',
|
2015-06-26 18:33:03 +02:00
|
|
|
'phabricator-chatlog-css' => 'd295b020',
|
2014-01-01 16:46:25 +01:00
|
|
|
'phabricator-content-source-view-css' => '4b8b05d4',
|
2017-09-25 21:56:22 +02:00
|
|
|
'phabricator-core-css' => '62fa3ace',
|
2016-04-09 19:07:02 +02:00
|
|
|
'phabricator-countdown-css' => '16c52f5c',
|
2017-04-17 21:10:29 +02:00
|
|
|
'phabricator-darklog' => 'c8e1ffe3',
|
|
|
|
'phabricator-darkmessage' => 'c48cccdd',
|
2017-03-02 06:56:57 +01:00
|
|
|
'phabricator-dashboard-css' => 'fe5b1869',
|
2018-02-09 01:55:54 +01:00
|
|
|
'phabricator-diff-changeset' => 'b49b59d6',
|
2018-11-24 15:59:19 +01:00
|
|
|
'phabricator-diff-changeset-list' => '0a84bcc1',
|
2017-07-21 17:08:24 +02:00
|
|
|
'phabricator-diff-inline' => 'e83d28f3',
|
2016-05-21 01:26:11 +02:00
|
|
|
'phabricator-drag-and-drop-file-upload' => '58dea2fa',
|
2016-11-17 13:01:35 +01:00
|
|
|
'phabricator-draggable-list' => 'bea6e7f4',
|
2016-09-06 22:48:22 +02:00
|
|
|
'phabricator-fatal-config-template-css' => '8f18fa41',
|
2016-10-20 20:41:57 +02:00
|
|
|
'phabricator-favicon' => '1fe2510c',
|
2015-05-28 20:47:06 +02:00
|
|
|
'phabricator-feed-css' => 'ecd4ec57',
|
2016-02-06 23:05:15 +01:00
|
|
|
'phabricator-file-upload' => '680ea2c8',
|
2018-02-09 01:55:54 +01:00
|
|
|
'phabricator-filetree-view-css' => 'b912ad97',
|
2016-12-14 20:35:51 +01:00
|
|
|
'phabricator-flag-css' => 'bba8f811',
|
2014-01-01 16:46:25 +01:00
|
|
|
'phabricator-keyboard-shortcut' => '1ae869f2',
|
2017-05-16 15:40:50 +02:00
|
|
|
'phabricator-keyboard-shortcut-manager' => 'c19dd9b9',
|
2017-08-25 18:34:51 +02:00
|
|
|
'phabricator-main-menu-view' => '1802a242',
|
2018-04-11 18:40:05 +02:00
|
|
|
'phabricator-nav-view-css' => '694d7723',
|
2018-03-16 23:10:26 +01:00
|
|
|
'phabricator-notification' => '4f774dac',
|
2017-08-28 23:51:00 +02:00
|
|
|
'phabricator-notification-css' => '457861ec',
|
Fix the most significant "phantom notification" badness
Summary:
Ref T13124. Ref T13131. Fixes T8953. See PHI512.
When you receieve a notification about an object and then someone hides that object from you (or deletes it), you get a phantom notification which is very difficult to clear.
For now, test that notifications are visible when you open the menu and clear any that are not.
This could be a little more elegant than it is, but the current behavior is very clearly broken. This unbreaks it, at least.
Test Plan:
- As Alice, configured task stuff to notify me (instead of sending email).
- As Bailey, added Alice as a subscriber to a task, then commented on it.
- As Alice, loaded home and saw a notification count. Didn't click it yet.
- As Bailey, set the task to private.
- As Alice, clicked the notification bell menu icon.
- Before change: no unread notifications, bell menu is semi-stuck in a phantom state which you can't clear.
- After change: bad notifications automatically cleared.
{F5530005}
Reviewers: amckinley
Reviewed By: amckinley
Maniphest Tasks: T13131, T13124, T8953
Differential Revision: https://secure.phabricator.com/D19384
2018-04-19 19:49:30 +02:00
|
|
|
'phabricator-notification-menu-css' => 'ef480927',
|
2015-07-02 23:39:43 +02:00
|
|
|
'phabricator-object-selector-css' => '85ee8ce6',
|
2014-01-01 16:46:25 +01:00
|
|
|
'phabricator-phtize' => 'd254d646',
|
2017-10-09 19:52:27 +02:00
|
|
|
'phabricator-prefab' => '77b0ae28',
|
2018-06-07 21:22:53 +02:00
|
|
|
'phabricator-remarkup-css' => 'b182076e',
|
2017-08-15 05:50:06 +02:00
|
|
|
'phabricator-search-results-css' => '505dd8cf',
|
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',
|
2016-02-26 23:34:51 +01:00
|
|
|
'phabricator-slowvote-css' => 'a94b7230',
|
2018-04-20 22:14:44 +02:00
|
|
|
'phabricator-source-code-view-css' => '2ab25dfa',
|
2017-08-17 18:02:43 +02:00
|
|
|
'phabricator-standard-page-view' => '34ee718b',
|
2016-05-21 01:26:11 +02:00
|
|
|
'phabricator-textareautils' => '320810c8',
|
2016-10-20 20:41:57 +02:00
|
|
|
'phabricator-title' => '485aaa6c',
|
2017-05-20 13:58:09 +02:00
|
|
|
'phabricator-tooltip' => '358b8c04',
|
2014-04-23 03:29:14 +02:00
|
|
|
'phabricator-ui-example-css' => '528b19de',
|
2017-05-30 22:23:54 +02:00
|
|
|
'phabricator-zindex-css' => '9d8f7c4b',
|
2017-07-17 20:08:17 +02:00
|
|
|
'phame-css' => '8cb3afcd',
|
2016-02-15 06:29:56 +01:00
|
|
|
'pholio-css' => 'ca89d380',
|
2016-06-09 17:34:00 +02:00
|
|
|
'pholio-edit-css' => '07676f51',
|
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',
|
2016-06-08 05:55:18 +02:00
|
|
|
'phortune-css' => '5b99dae0',
|
2016-10-30 02:45:10 +02:00
|
|
|
'phortune-invoice-css' => '476055e2',
|
2014-01-06 06:47:21 +01:00
|
|
|
'phrequent-css' => 'ffc185ad',
|
2016-04-20 15:00:10 +02:00
|
|
|
'phriction-document-css' => '4282e4ad',
|
2017-07-30 21:21:36 +02:00
|
|
|
'phui-action-panel-css' => 'b4798122',
|
2017-02-24 22:15:30 +01:00
|
|
|
'phui-badge-view-css' => '22c0cf4f',
|
2017-08-29 01:07:22 +02:00
|
|
|
'phui-basic-nav-view-css' => '98c11ab3',
|
2017-08-04 02:18:30 +02:00
|
|
|
'phui-big-info-view-css' => 'acc3492c',
|
2017-11-30 14:14:05 +01:00
|
|
|
'phui-box-css' => '4bd6cdb9',
|
Restore bulk edit support for remarkup fields (description, add comment)
Summary:
Depends on D18866. Ref T13025. Fixes T12415. This makes the old "Add Comment" action work, and adds support for a new "Set description to" action (possibly, I could imagine "append description" being useful some day, maybe).
The implementation is just a `<textarea />`, not a whole fancy remarkup box with `[Bold] [Italic] ...` buttons, preview, typeaheads, etc. It would be nice to enrich this eventually but doing the rendering in pure JS is currently very involved.
This requires a little bit of gymnastics to get the transaction populated properly, and adds some extra validation since we need some code there anyway.
Test Plan:
- Changed the description of a task via bulk editor.
- Added a comment to a task via bulk editor.
Reviewers: amckinley
Reviewed By: amckinley
Maniphest Tasks: T13025, T12415
Differential Revision: https://secure.phabricator.com/D18867
2018-01-11 18:48:33 +01:00
|
|
|
'phui-bulk-editor-css' => '9a81e5d5',
|
2017-07-19 23:38:55 +02:00
|
|
|
'phui-button-bar-css' => 'f1ff5494',
|
2018-09-11 18:04:44 +02:00
|
|
|
'phui-button-css' => '6ccb303c',
|
2017-06-05 22:14:34 +02:00
|
|
|
'phui-button-simple-css' => '8e1baf68',
|
2017-07-17 20:08:17 +02:00
|
|
|
'phui-calendar-css' => 'f1ddf11c',
|
2016-07-27 18:07:29 +02:00
|
|
|
'phui-calendar-day-css' => '572b1893',
|
2017-02-06 19:50:09 +01:00
|
|
|
'phui-calendar-list-css' => '576be600',
|
2017-07-17 20:08:17 +02:00
|
|
|
'phui-calendar-month-css' => '21154caf',
|
2016-01-28 22:29:27 +01:00
|
|
|
'phui-chart-css' => '6bf6f78e',
|
2017-02-05 21:45:27 +01:00
|
|
|
'phui-cms-css' => '504b4b23',
|
2017-07-19 23:38:55 +02:00
|
|
|
'phui-comment-form-css' => 'ac68149f',
|
2016-12-02 20:00:37 +01:00
|
|
|
'phui-comment-panel-css' => 'f50152ad',
|
2018-05-09 20:25:08 +02:00
|
|
|
'phui-crumbs-view-css' => '10728aaa',
|
2017-09-25 21:56:22 +02:00
|
|
|
'phui-curtain-view-css' => '2bdaf026',
|
2015-12-19 21:28:18 +01:00
|
|
|
'phui-document-summary-view-css' => '9ca48bdf',
|
2018-08-29 18:31:32 +02:00
|
|
|
'phui-document-view-css' => 'c4ac41f9',
|
2018-10-01 20:06:00 +02:00
|
|
|
'phui-document-view-pro-css' => 'dd79b5df',
|
2016-10-11 19:02:22 +02:00
|
|
|
'phui-feed-story-css' => '44a9c8e9',
|
Redesign Config Application
Summary: Ref T11132, significantly cleans up the Config app, new layout, icons, spacing, etc. Some minor todos around re-designing "issues", mobile support, and maybe another pass at actual Group pages.
Test Plan: Visit and test every page in the config app, set new items, resolve setup issues, etc.
Reviewers: epriestley
Reviewed By: epriestley
Subscribers: PHID-OPKG-gm6ozazyms6q6i22gyam, Korvin
Maniphest Tasks: T11132
Differential Revision: https://secure.phabricator.com/D16468
2016-08-30 00:36:13 +02:00
|
|
|
'phui-font-icon-base-css' => '870a7360',
|
2017-03-22 17:48:10 +01:00
|
|
|
'phui-fontkit-css' => '1320ed01',
|
2017-07-28 00:12:48 +02:00
|
|
|
'phui-form-css' => '7aaa04e3',
|
2018-12-18 21:37:00 +01:00
|
|
|
'phui-form-view-css' => 'b04e08d9',
|
2016-03-17 20:01:22 +01:00
|
|
|
'phui-head-thing-view-css' => 'fd311e5f',
|
Allow DocumentView to render with a curtain, and make Phriction use a curtain
Summary:
Depends on D19616. Ref T13077. Fixes T8172. In the last round of design updates, a lot of actions got stuffed into "Actions" menus.
I never really got used to these and think they're a net usability loss, and broadly agree with the feedback in T8172. I'd generally like to move back toward a state where actions are available on the page, not hidden in a menu.
For now, just put a curtain view on these pages. This could be refined later (e.g., stick this menu to the right hand side of the screen) depending on where other Phriction changes go.
(Broadly, I'm also not satisfied with where we ended up on the fixed-width pages like Diffusion > Manage, Config, and Instances. In contrast, I //do// like where we ended up with Phortune in terms of overall design. I anticipate revisiting some of this stuff eventually.)
Test Plan:
- Looked at Phriction pages on desktop/tablet/mobile/printable -- actions are now available on the page.
- Looked at other DocumentView pages (like Phame blogs) -- no changes for now.
Reviewers: amckinley
Maniphest Tasks: T13077, T8172
Differential Revision: https://secure.phabricator.com/D19617
2018-08-28 23:37:19 +02:00
|
|
|
'phui-header-view-css' => '1ba8b707',
|
2016-02-03 17:26:30 +01:00
|
|
|
'phui-hovercard' => '1bd28176',
|
2018-11-15 13:15:43 +01:00
|
|
|
'phui-hovercard-view-css' => '4a484541',
|
2017-02-04 18:41:03 +01:00
|
|
|
'phui-icon-set-selector-css' => '87db8fee',
|
2018-04-03 21:26:35 +02:00
|
|
|
'phui-icon-view-css' => 'cf24ceec',
|
2016-02-15 06:29:56 +01:00
|
|
|
'phui-image-mask-css' => 'a8498f9c',
|
2017-09-07 22:15:07 +02:00
|
|
|
'phui-info-view-css' => 'e929f98c',
|
2017-07-19 23:38:55 +02:00
|
|
|
'phui-inline-comment-view-css' => '65ae3bc2',
|
2016-09-12 14:53:54 +02:00
|
|
|
'phui-invisible-character-view-css' => '6993d9f0',
|
2017-08-21 22:07:38 +02:00
|
|
|
'phui-left-right-css' => '75227a4d',
|
2016-12-02 18:59:46 +01:00
|
|
|
'phui-lightbox-css' => '0a035e40',
|
2017-07-17 20:08:17 +02:00
|
|
|
'phui-list-view-css' => '38f8c9bd',
|
2017-04-21 20:22:06 +02:00
|
|
|
'phui-object-box-css' => '9cff003c',
|
Replace the "Choose Subtype" radio buttons dialog with a simpler "big stuff you click" sort of UI
Summary:
Ref T13222. Fixes T12588. See PHI683. In several cases, we present the user with a choice between multiple major options: Alamnac service types, Drydock blueprint types, Repository VCS types, Herald rule types, etc.
Today, we generally do this with radio buttons and a "Submit" button. This isn't terrible, but often it means users have to click twice (once on the radio; once on submit) when a single click would be sufficient. The radio click target can also be small.
In other cases, we have a container with a link and we'd like to link the entire container: notifications, the `/drydock/` console, etc. We'd like to just link the entire container, but this causes some problems:
- It's not legal to link block eleements like `<a><div> ... </div></a>` and some browsers actually get upset about it.
- We can `<a><span> ... </span></a>` instead, then turn the `<span>` into a block element with CSS -- and this sometimes works, but also has some drawbacks:
- It's not great to do that for screenreaders, since the readable text in the link isn't necessarily very meaningful.
- We can't have any other links inside the element (e.g., details or documentation).
- We can `<form><button> ... </button></form>` instead, but this has its own set of problems:
- You can't right-click to interact with a button in the same way you can with a link.
- Also not great for screenreaders.
Instead, try adding a `linked-container` behavior which just means "when users click this element, pretend they clicked the first link inside it".
This gives us natural HTML (real, legal HTML with actual `<a>` tags) and good screenreader behavior, but allows the effective link target to be visually larger than just the link.
If no issues crop up with this, I'd plan to eventually use this technique in more places (Repositories, Herald, Almanac, Drydock, Notifications menu, etc).
Test Plan:
{F6053035}
- Left-clicked and command-left-clicked the new JS fanciness, got sensible behaviors.
Reviewers: amckinley
Reviewed By: amckinley
Subscribers: PHID-OPKG-gm6ozazyms6q6i22gyam
Maniphest Tasks: T13222, T12588
Differential Revision: https://secure.phabricator.com/D19855
2018-12-07 15:04:07 +01:00
|
|
|
'phui-oi-big-ui-css' => '7a7c22af',
|
2016-12-14 20:35:51 +01:00
|
|
|
'phui-oi-color-css' => 'cd2b9b77',
|
2017-05-16 06:41:47 +02:00
|
|
|
'phui-oi-drag-ui-css' => '08f4ccc3',
|
2016-12-14 20:35:51 +01:00
|
|
|
'phui-oi-flush-ui-css' => '9d9685d6',
|
2018-04-19 20:28:24 +02:00
|
|
|
'phui-oi-list-view-css' => '7c5c1291',
|
2016-12-14 20:35:51 +01:00
|
|
|
'phui-oi-simple-ui-css' => 'a8beebea',
|
2017-06-07 01:53:14 +02:00
|
|
|
'phui-pager-css' => 'edcbc226',
|
2015-05-31 23:28:16 +02:00
|
|
|
'phui-pinboard-view-css' => '2495140e',
|
2018-06-01 22:12:13 +02:00
|
|
|
'phui-property-list-view-css' => '546a04ae',
|
2017-04-18 00:11:08 +02:00
|
|
|
'phui-remarkup-preview-css' => '54a34863',
|
2017-01-31 17:58:33 +01:00
|
|
|
'phui-segment-bar-view-css' => 'b1d1b892',
|
2014-01-01 16:46:25 +01:00
|
|
|
'phui-spacing-css' => '042804d6',
|
2016-05-01 21:48:56 +02:00
|
|
|
'phui-status-list-view-css' => 'd5263e49',
|
2017-07-17 20:08:17 +02:00
|
|
|
'phui-tag-view-css' => 'b4719c50',
|
2017-01-31 17:58:33 +01:00
|
|
|
'phui-theme-css' => '9f261c6b',
|
2018-01-29 21:54:04 +01:00
|
|
|
'phui-timeline-view-css' => '6ddf8126',
|
2017-09-25 21:56:22 +02:00
|
|
|
'phui-two-column-view-css' => '44ec4951',
|
2017-02-05 21:45:27 +01:00
|
|
|
'phui-workboard-color-css' => '783cdff5',
|
2017-01-31 17:58:33 +01:00
|
|
|
'phui-workboard-view-css' => '3bc85455',
|
2017-01-17 21:04:28 +01:00
|
|
|
'phui-workcard-view-css' => 'cca5fa92',
|
2016-12-14 20:35:51 +01:00
|
|
|
'phui-workpanel-view-css' => 'a3a63478',
|
2014-05-05 19:57:23 +02:00
|
|
|
'phuix-action-list-view' => 'b5c256b8',
|
2018-03-30 20:02:01 +02:00
|
|
|
'phuix-action-view' => '8d4a8c72',
|
2018-03-30 17:42:18 +02:00
|
|
|
'phuix-autocomplete' => 'df1bbd34',
|
2018-08-17 19:53:28 +02:00
|
|
|
'phuix-button-view' => '85ac9772',
|
2017-10-09 19:52:27 +02:00
|
|
|
'phuix-dropdown-menu' => '04b2ae03',
|
Use a tokenizer, not a gigantic poorly-ordered "<select />", to choose repositories in Owners
Summary: Depends on D19190. Fixes T12590. Ref T13099. Replaces the barely-usable, gigantic, poorly ordered "<select />" control with a tokenizer. Attempts to fix various minor issues.
Test Plan:
- Edited paths: include/exclude paths, from different repositories, different actual paths.
- Used "Add New Path" to add rows, got repository selector prepopulated with last value.
- Used "remove".
- Used validation typeahead, got reasonable behaviors?
The error behavior if you delete the repository for a path is a little sketchy still, but roughly okay.
Maniphest Tasks: T13099, T12590
Differential Revision: https://secure.phabricator.com/D19191
2018-03-08 02:29:06 +01:00
|
|
|
'phuix-form-control-view' => '210a16c1',
|
2015-12-02 23:38:11 +01:00
|
|
|
'phuix-icon-view' => 'bff6884b',
|
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',
|
2016-03-04 00:18:41 +01:00
|
|
|
'ponder-view-css' => 'fbd45f96',
|
2017-07-17 20:08:17 +02:00
|
|
|
'project-card-view-css' => '0010bb52',
|
2017-02-24 22:15:30 +01:00
|
|
|
'project-view-css' => '792c9057',
|
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',
|
2018-03-13 20:14:36 +01:00
|
|
|
'setup-issue-css' => '30ee0173',
|
2017-08-11 22:37:15 +02:00
|
|
|
'sprite-login-css' => '396f3c3a',
|
2016-07-04 03:32:31 +02:00
|
|
|
'sprite-tokens-css' => '9cdfd599',
|
2016-05-05 03:24:59 +02:00
|
|
|
'syntax-default-css' => '9923583c',
|
2018-04-08 18:10:03 +02:00
|
|
|
'syntax-highlighting-css' => 'e9c95dd4',
|
2014-05-05 19:54:34 +02:00
|
|
|
'tokens-css' => '3d0f239e',
|
2017-07-17 20:08:17 +02:00
|
|
|
'typeahead-browse-css' => 'f2818435',
|
2015-05-20 04:38:34 +02:00
|
|
|
'unhandled-exception-css' => '4c96257a',
|
2014-01-01 03:04:25 +01:00
|
|
|
),
|
2014-07-14 17:33:33 +02:00
|
|
|
'requires' => array(
|
2017-10-09 19:52:27 +02:00
|
|
|
'00676f00' => array(
|
|
|
|
'javelin-install',
|
|
|
|
'javelin-dom',
|
|
|
|
'javelin-typeahead-preloaded-source',
|
|
|
|
'javelin-util',
|
|
|
|
),
|
2016-01-16 23:33:03 +01:00
|
|
|
'013ffff9' => array(
|
|
|
|
'javelin-install',
|
|
|
|
'javelin-util',
|
|
|
|
'javelin-request',
|
|
|
|
'javelin-typeahead-source',
|
|
|
|
),
|
Make "/" focus the search input again
Summary:
See D1902, T989, T11263, D15984, T4103 , D15976, https://secure.phabricator.com/w/changelog/2016.22/, T2527, T11231, T8286, T11264 for discussion!
When we get another copy of T989, I will rename it to "Build a complicated keybinding settings page like a cool video game" and leave it open forever.
Test Plan: Pressed "/" in Firefox, had my pristine browsing experience inexplicably hijacked by this horrible application.
Reviewers: avivey, chad
Reviewed By: avivey
Subscribers: Korvin
Differential Revision: https://secure.phabricator.com/D15984
2016-07-08 22:57:33 +02:00
|
|
|
'01fca1f0' => array(
|
|
|
|
'javelin-behavior',
|
|
|
|
'javelin-workflow',
|
|
|
|
'javelin-json',
|
|
|
|
'javelin-dom',
|
|
|
|
'phabricator-keyboard-shortcut',
|
|
|
|
),
|
2018-03-06 19:25:05 +01:00
|
|
|
'0213259f' => array(
|
|
|
|
'javelin-behavior',
|
|
|
|
'javelin-uri',
|
|
|
|
),
|
2018-03-08 14:29:24 +01:00
|
|
|
'040fce04' => array(
|
|
|
|
'javelin-behavior',
|
|
|
|
'javelin-request',
|
|
|
|
),
|
2017-10-09 19:52:27 +02:00
|
|
|
'04b2ae03' => array(
|
|
|
|
'javelin-install',
|
|
|
|
'javelin-util',
|
|
|
|
'javelin-dom',
|
|
|
|
'javelin-vector',
|
|
|
|
'javelin-stratcom',
|
|
|
|
),
|
Make some Differential comment actions (like "Accept" and "Reject") conflict with one another
Summary:
Ref T11114. When a user selects "Accept", and then selects "Reject", remove the "Accept". It does not make sense to both accept and reject a revision.
For now, every one of the "actions" conflicts: accept, reject, resign, claim, close, commandeer, etc, etc. I couldn't come up with any combinations that it seems like users are reasonably likely to want to try, and we haven't received combo-action requests in the past that I can recall.
Test Plan:
- Selected "Accept", then selected "Reject". One replaced the other.
- Selected "Accept", then selected "Change Subscribers". Both co-existed happily.
Reviewers: chad
Reviewed By: chad
Maniphest Tasks: T11114
Differential Revision: https://secure.phabricator.com/D17132
2017-01-02 20:17:27 +01:00
|
|
|
'051c7832' => array(
|
|
|
|
'javelin-behavior',
|
|
|
|
'javelin-stratcom',
|
|
|
|
'javelin-dom',
|
|
|
|
),
|
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
|
|
|
),
|
2017-05-16 06:41:47 +02:00
|
|
|
'08f4ccc3' => array(
|
|
|
|
'phui-oi-list-view-css',
|
|
|
|
),
|
2016-07-01 01:55:28 +02:00
|
|
|
'0a0b10e9' => array(
|
|
|
|
'javelin-behavior',
|
|
|
|
'javelin-stratcom',
|
|
|
|
'javelin-dom',
|
|
|
|
),
|
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
|
|
|
),
|
2018-11-24 15:59:19 +01:00
|
|
|
'0a84bcc1' => array(
|
|
|
|
'javelin-install',
|
|
|
|
'phuix-button-view',
|
|
|
|
),
|
Remove "willRenderTimeline()" from ApplicationTransactionInterface
Summary:
Depends on D19914. Ref T11351. Some of the Phoilo rabbit holes go very deep.
`PhabricatorApplicationTransactionInterface` currently requires you to implement `willRenderTimeline()`. Almost every object just implements this as `return $timeline`; only Pholio, Diffusion, and Differential specialize it. In all cases, they are specializing it mostly to render inline comments.
The actual implementations are a bit of a weird mess and the way the data is threaded through the call stack is weird and not very modern.
Try to clean this up:
- Stop requiring `willRenderTimeline()` to be implemented.
- Stop requiring `getApplicationTransactionViewObject()` to be implemented (only the three above, plus Legalpad, implement this, and Legalpad's implementation is a no-op). These two methods are inherently pretty coupled for almost any reasonable thing you might want to do with the timeline.
- Simplify the handling of "renderdata" and call it "View Data". This is additional information about the current view of the transaction timeline that is required to render it correctly. This is only used in Differential, to decide if we can link an inline comment to an anchor on the same page or should link it to another page. We could perhaps do this on the client instead, but having this data doesn't seem inherently bad to me.
- If objects want to customize timeline rendering, they now implement `PhabricatorTimelineInterface` and provide a `TimelineEngine` which gets a nice formal stack.
This leaves a lot of empty `willRenderTimeline()` implementations hanging around. I'll remove these in the next change, it's just going to be deleting a couple dozen copies of an identical empty method implementation.
Test Plan:
- Viewed audits, revisions, and mocks with inline comments.
- Used "Show Older" to page a revision back in history (this is relevant for "View Data").
- Grepped for symbols: willRenderTimeline, getApplicationTransactionViewObject, Legalpad classes.
Reviewers: amckinley
Reviewed By: amckinley
Maniphest Tasks: T11351
Differential Revision: https://secure.phabricator.com/D19918
2018-12-19 20:52:53 +01:00
|
|
|
'0e1eca96' => array(
|
|
|
|
'javelin-behavior',
|
|
|
|
'javelin-stratcom',
|
|
|
|
'javelin-dom',
|
|
|
|
'phabricator-busy',
|
|
|
|
),
|
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
|
|
|
),
|
2017-06-01 22:30:00 +02:00
|
|
|
'15d5ff71' => array(
|
|
|
|
'aphront-typeahead-control-css',
|
|
|
|
'phui-tag-view-css',
|
|
|
|
),
|
2017-08-25 18:34:51 +02:00
|
|
|
'1802a242' => array(
|
|
|
|
'phui-theme-css',
|
|
|
|
),
|
2016-11-17 13:13:39 +01:00
|
|
|
'185bbd53' => array(
|
|
|
|
'javelin-install',
|
|
|
|
),
|
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
|
|
|
),
|
2016-02-03 17:26:30 +01:00
|
|
|
'1bd28176' => array(
|
|
|
|
'javelin-install',
|
|
|
|
'javelin-dom',
|
|
|
|
'javelin-vector',
|
|
|
|
'javelin-request',
|
|
|
|
'javelin-uri',
|
|
|
|
),
|
Allow Doorkeeper references to have multiple display variations (full, short, etc.)
Summary:
Ref T13102. An install has a custom rule for bridging JIRA references via Doorkeeper and would like to be able to render them as `JIRA-123` instead of `JIRA JIRA-123 Full JIRA title`.
I think it's reasonable to imagine future support upstream for `JIRA-123`, `{JIRA-123}`, and so on, although we do not support these today. We can take a small step toward eventual support by letting the rendering pipeline understand different view modes.
This adds an optional `name` (the default text rendered before we do the OAuth sync) and an optional `view`, which can be `short` or `full`.
Test Plan:
I tested this primarily with Asana, since it's less of a pain to set up than JIRA. The logic should be similar, hopefully.
I changed `DoorkeeperAsanaRemarkupRule` to specify `name` and `view`, e.g `'view' => (mt_rand(0, 1) ? 'short' : 'full')`. Then I made a bunch of Asana references in a comment and saw them randomly go short or long.
Maniphest Tasks: T13102
Differential Revision: https://secure.phabricator.com/D19215
2018-03-13 19:09:22 +01:00
|
|
|
'1db13e70' => array(
|
|
|
|
'javelin-behavior',
|
|
|
|
'javelin-dom',
|
|
|
|
'javelin-json',
|
|
|
|
'javelin-workflow',
|
|
|
|
'javelin-magical-init',
|
|
|
|
),
|
2017-04-18 18:05:00 +02:00
|
|
|
'1f6794f6' => array(
|
|
|
|
'javelin-behavior',
|
|
|
|
'javelin-stratcom',
|
|
|
|
'javelin-workflow',
|
|
|
|
'javelin-dom',
|
|
|
|
'javelin-uri',
|
|
|
|
'phabricator-textareautils',
|
|
|
|
),
|
2016-10-20 20:41:57 +02:00
|
|
|
'1fe2510c' => array(
|
|
|
|
'javelin-install',
|
|
|
|
'javelin-dom',
|
|
|
|
),
|
Use a tokenizer, not a gigantic poorly-ordered "<select />", to choose repositories in Owners
Summary: Depends on D19190. Fixes T12590. Ref T13099. Replaces the barely-usable, gigantic, poorly ordered "<select />" control with a tokenizer. Attempts to fix various minor issues.
Test Plan:
- Edited paths: include/exclude paths, from different repositories, different actual paths.
- Used "Add New Path" to add rows, got repository selector prepopulated with last value.
- Used "remove".
- Used validation typeahead, got reasonable behaviors?
The error behavior if you delete the repository for a path is a little sketchy still, but roughly okay.
Maniphest Tasks: T13099, T12590
Differential Revision: https://secure.phabricator.com/D19191
2018-03-08 02:29:06 +01:00
|
|
|
'210a16c1' => array(
|
|
|
|
'javelin-install',
|
|
|
|
'javelin-dom',
|
|
|
|
),
|
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
|
|
|
),
|
2017-03-02 02:13:36 +01:00
|
|
|
26167537 => array(
|
|
|
|
'javelin-install',
|
|
|
|
'javelin-dom',
|
|
|
|
'javelin-util',
|
|
|
|
'javelin-vector',
|
|
|
|
'javelin-stratcom',
|
|
|
|
'javelin-workflow',
|
|
|
|
'phabricator-drag-and-drop-file-upload',
|
|
|
|
'javelin-workboard-board',
|
|
|
|
),
|
2017-08-23 23:35:02 +02:00
|
|
|
'27ca6289' => array(
|
|
|
|
'javelin-behavior',
|
|
|
|
'javelin-stratcom',
|
|
|
|
'javelin-dom',
|
|
|
|
'javelin-uri',
|
|
|
|
'phabricator-notification',
|
|
|
|
),
|
Replace the "Choose Subtype" radio buttons dialog with a simpler "big stuff you click" sort of UI
Summary:
Ref T13222. Fixes T12588. See PHI683. In several cases, we present the user with a choice between multiple major options: Alamnac service types, Drydock blueprint types, Repository VCS types, Herald rule types, etc.
Today, we generally do this with radio buttons and a "Submit" button. This isn't terrible, but often it means users have to click twice (once on the radio; once on submit) when a single click would be sufficient. The radio click target can also be small.
In other cases, we have a container with a link and we'd like to link the entire container: notifications, the `/drydock/` console, etc. We'd like to just link the entire container, but this causes some problems:
- It's not legal to link block eleements like `<a><div> ... </div></a>` and some browsers actually get upset about it.
- We can `<a><span> ... </span></a>` instead, then turn the `<span>` into a block element with CSS -- and this sometimes works, but also has some drawbacks:
- It's not great to do that for screenreaders, since the readable text in the link isn't necessarily very meaningful.
- We can't have any other links inside the element (e.g., details or documentation).
- We can `<form><button> ... </button></form>` instead, but this has its own set of problems:
- You can't right-click to interact with a button in the same way you can with a link.
- Also not great for screenreaders.
Instead, try adding a `linked-container` behavior which just means "when users click this element, pretend they clicked the first link inside it".
This gives us natural HTML (real, legal HTML with actual `<a>` tags) and good screenreader behavior, but allows the effective link target to be visually larger than just the link.
If no issues crop up with this, I'd plan to eventually use this technique in more places (Repositories, Herald, Almanac, Drydock, Notifications menu, etc).
Test Plan:
{F6053035}
- Left-clicked and command-left-clicked the new JS fanciness, got sensible behaviors.
Reviewers: amckinley
Reviewed By: amckinley
Subscribers: PHID-OPKG-gm6ozazyms6q6i22gyam
Maniphest Tasks: T13222, T12588
Differential Revision: https://secure.phabricator.com/D19855
2018-12-07 15:04:07 +01:00
|
|
|
'291da458' => array(
|
|
|
|
'javelin-behavior',
|
|
|
|
'javelin-dom',
|
|
|
|
),
|
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
|
|
|
),
|
2017-04-26 19:48:50 +02:00
|
|
|
'2ae077e1' => array(
|
|
|
|
'javelin-behavior',
|
|
|
|
'javelin-dom',
|
|
|
|
'javelin-stratcom',
|
|
|
|
'javelin-behavior-device',
|
|
|
|
'javelin-scrollbar',
|
|
|
|
'javelin-quicksand',
|
|
|
|
'phabricator-keyboard-shortcut',
|
|
|
|
'conpherence-thread-manager',
|
|
|
|
),
|
2015-01-14 01:10:57 +01:00
|
|
|
'2b8de964' => array(
|
|
|
|
'javelin-install',
|
|
|
|
'javelin-util',
|
|
|
|
),
|
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
|
|
|
),
|
2017-01-17 22:59:56 +01:00
|
|
|
'31420f77' => array(
|
|
|
|
'javelin-behavior',
|
|
|
|
),
|
2016-05-21 01:26:11 +02:00
|
|
|
'320810c8' => array(
|
|
|
|
'javelin-install',
|
Allow installs to customize project icons
Summary:
Ref T10010. Ref T5819. General alignment of the stars:
- There were some hacks in Conduit around stripping `fa-...` off icons when reading and writing that I wanted to get rid of.
- We probably have room for a subtitle in the new heavy nav, and using the icon name is a good starting point (and maybe good enough on its own?)
- The project list was real bad looking with redundant tag/names, now it is very slightly less bad looking with non-redundant types?
- Some installs will want to call Milestones something else, and this gets us a big part of the way there.
- This may slightly help to reinforce "tag" vs "policy" vs "group" stuff?
---
I'm letting installs have enough rope to shoot themselves in the foot (e.g., define 100 icons). It isn't the end of the world if they reuse icons, and is clearly their fault.
I think the cases where 100 icons will break down are:
- Icon selector dialog may get very unwieldy.
- Query UI will be pretty iffy/huge with 100 icons.
We could improve these fairly easily if an install comes up with a reasonable use case for having 100 icons.
---
The UI on the icon itself in the list views is a little iffy -- mostly, it's too saturated/bold.
I'd ideally like to try either:
- rendering a "shade" version (i.e. lighter, less-saturated color); or
- rendering a "shade" tag with just the icon in it.
However, there didn't seem to be a way to do the first one right now (`fa-example sh-blue` doesn't work) and the second one had weird margins/padding, so I left it like this for now. I figure we can clean it up once we build the thick nav, since that will probably also want an identical element.
(I don't want to render a full tag with the icon + name since I think that's confusing -- it looks like a project/object tag, but is not.)
Test Plan:
{F1049905}
{F1049906}
Reviewers: chad
Reviewed By: chad
Subscribers: 20after4, Luke081515.2
Maniphest Tasks: T5819, T10010
Differential Revision: https://secure.phabricator.com/D14918
2015-12-30 13:36:48 +01:00
|
|
|
'javelin-dom',
|
2016-05-21 01:26:11 +02:00
|
|
|
'javelin-vector',
|
Allow installs to customize project icons
Summary:
Ref T10010. Ref T5819. General alignment of the stars:
- There were some hacks in Conduit around stripping `fa-...` off icons when reading and writing that I wanted to get rid of.
- We probably have room for a subtitle in the new heavy nav, and using the icon name is a good starting point (and maybe good enough on its own?)
- The project list was real bad looking with redundant tag/names, now it is very slightly less bad looking with non-redundant types?
- Some installs will want to call Milestones something else, and this gets us a big part of the way there.
- This may slightly help to reinforce "tag" vs "policy" vs "group" stuff?
---
I'm letting installs have enough rope to shoot themselves in the foot (e.g., define 100 icons). It isn't the end of the world if they reuse icons, and is clearly their fault.
I think the cases where 100 icons will break down are:
- Icon selector dialog may get very unwieldy.
- Query UI will be pretty iffy/huge with 100 icons.
We could improve these fairly easily if an install comes up with a reasonable use case for having 100 icons.
---
The UI on the icon itself in the list views is a little iffy -- mostly, it's too saturated/bold.
I'd ideally like to try either:
- rendering a "shade" version (i.e. lighter, less-saturated color); or
- rendering a "shade" tag with just the icon in it.
However, there didn't seem to be a way to do the first one right now (`fa-example sh-blue` doesn't work) and the second one had weird margins/padding, so I left it like this for now. I figure we can clean it up once we build the thick nav, since that will probably also want an identical element.
(I don't want to render a full tag with the icon + name since I think that's confusing -- it looks like a project/object tag, but is not.)
Test Plan:
{F1049905}
{F1049906}
Reviewers: chad
Reviewed By: chad
Subscribers: 20after4, Luke081515.2
Maniphest Tasks: T5819, T10010
Differential Revision: https://secure.phabricator.com/D14918
2015-12-30 13:36:48 +01:00
|
|
|
),
|
2016-05-21 01:26:11 +02:00
|
|
|
'327a00d1' => array(
|
2016-01-15 13:25:22 +01:00
|
|
|
'javelin-behavior',
|
|
|
|
'javelin-stratcom',
|
|
|
|
'javelin-dom',
|
|
|
|
'javelin-workflow',
|
|
|
|
),
|
Emit a "Content-Security-Policy" HTTP header
Summary:
See PHI399. Ref T4340. This header provides an additional layer of protection against various attacks, including XSS attacks which embed inline `<script ...>` or `onhover="..."` content into the document.
**style-src**: The "unsafe-inline" directive affects both `style="..."` and `<style>`. We use a lot of `style="..."`, some very legitimately, so we can't realistically get away from this any time soon. We only use one `<style>` (for monospaced font preferences) but can't disable `<style>` without disabling `style="..."`.
**img-src**: We use "data:" URIs to inline small images into CSS, and there's a significant performance benefit from doing this. There doesn't seem to be a way to allow "data" URIs in CSS without allowing them in the document itself.
**script-src** and **frame-src**: For a small number of flows (Recaptcha, Stripe) we embed external javascript, some of which embeds child elements (or additional resources) into the document. We now whitelist these narrowly on the respective pages.
This won't work with Quicksand, so I've blacklisted it for now.
**connect-src**: We need to include `'self'` for AJAX to work, and any websocket URIs.
**Clickjacking**: We now have three layers of protection:
- X-Frame-Options: works in older browsers.
- `frame-ancestors 'none'`: does the same thing.
- Explicit framebust in JX.Stratcom after initialization: works in ancient IE.
We could probably drop the explicit framebust but it wasn't difficult to retain.
**script tags**: We previously used an inline `<script>` tag to start Javelin. I've moved this to `<data data-javelin-init ...>` tags, which seems to work properly.
**`__DEV__`**: We previously used an inline `<script>` tag to set the `__DEV__` mode flag. I tried using the "initialization" tags for this, but they fire too late. I moved it to `<html data-developer-mode="1">`, which seems OK everywhere.
**CSP Scope**: Only the CSP header on the original request appears to matter -- you can't refine the scope by emitting headers on CSS/JS. To reduce confusion, I disabled the headers on those response types. More headers could be disabled, although we're likely already deep in the land of diminishing returns.
**Initialization**: The initialization sequence has changed slightly. Previously, we waited for the <script> in bottom of the document to evaluate. Now, we go fishing for tags when domcontentready fires.
Test Plan:
- Browsed around in Firefox, Safari and Chrome looking for console warnings. Interacted with various Javascript behaviors. Enabled Quicksand.
- Disabled all the framebusting, launched a clickjacking attack, verified that each layer of protection is individually effective.
- Verified that the XHProf iframe in Darkconsole and the PHPAST frame layout work properly.
- Enabled notifications, verified no complaints about connecting to Aphlict.
- Hit `__DEV__` mode warnings based on the new data attribute.
- Tried to do sketchy stuff with `data:` URIs and SVGs. This works but doesn't seem to be able to do anything dangerous.
- Went through the Stripe and Recaptcha workflows.
- Dumped and examined the CSP headers with `curl`, etc.
- Added a raw <script> tag to a page (as though I'd found an XSS attack), verified it was no longer executed.
Maniphest Tasks: T4340
Differential Revision: https://secure.phabricator.com/D19143
2018-02-27 15:56:15 +01:00
|
|
|
'327f418a' => array(
|
|
|
|
'javelin-install',
|
|
|
|
'javelin-event',
|
|
|
|
'javelin-util',
|
|
|
|
'javelin-magical-init',
|
|
|
|
),
|
2017-05-20 13:58:09 +02:00
|
|
|
'358b8c04' => array(
|
|
|
|
'javelin-install',
|
|
|
|
'javelin-util',
|
|
|
|
'javelin-dom',
|
|
|
|
'javelin-vector',
|
|
|
|
),
|
2018-04-28 15:43:09 +02:00
|
|
|
'3935d8c4' => array(
|
|
|
|
'javelin-behavior',
|
|
|
|
'javelin-dom',
|
|
|
|
'javelin-stratcom',
|
|
|
|
),
|
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
|
|
|
),
|
2016-10-19 06:49:02 +02:00
|
|
|
'3dbf94d5' => array(
|
|
|
|
'javelin-behavior',
|
|
|
|
'javelin-dom',
|
|
|
|
'javelin-util',
|
|
|
|
'javelin-workflow',
|
|
|
|
'javelin-stratcom',
|
|
|
|
),
|
When disconnected from Aphlict after a successful connection, retry the first reconnect right away
Summary:
Fixes T12567. We currently retry after 2s, 4s, 8s, 16s, ...
If we connected cleanly once, retry the first time right away. There are a bunch of reasonable cases where this will work fine and we don't need to wait. Then we fall back: 0s, 2s, 4s, 8s, ...
Test Plan: {F4911905}
Reviewers: chad
Reviewed By: chad
Maniphest Tasks: T12567
Differential Revision: https://secure.phabricator.com/D17706
2017-04-17 22:20:48 +02:00
|
|
|
'3ffe32d6' => array(
|
|
|
|
'javelin-install',
|
|
|
|
),
|
2017-10-09 19:52:27 +02:00
|
|
|
'4047cd35' => array(
|
|
|
|
'javelin-behavior',
|
|
|
|
'javelin-dom',
|
|
|
|
'javelin-util',
|
|
|
|
'javelin-stratcom',
|
|
|
|
'javelin-workflow',
|
|
|
|
'javelin-behavior-device',
|
|
|
|
'javelin-history',
|
|
|
|
'javelin-vector',
|
|
|
|
'javelin-scrollbar',
|
|
|
|
'phabricator-title',
|
|
|
|
'phabricator-shaped-request',
|
|
|
|
'conpherence-thread-manager',
|
|
|
|
),
|
2017-02-14 23:08:56 +01:00
|
|
|
'408bf173' => array(
|
|
|
|
'javelin-behavior',
|
|
|
|
'javelin-dom',
|
|
|
|
'javelin-util',
|
|
|
|
'javelin-stratcom',
|
|
|
|
'javelin-workflow',
|
|
|
|
'phabricator-draggable-list',
|
|
|
|
),
|
2017-03-02 02:13:36 +01:00
|
|
|
'4250a34e' => array(
|
|
|
|
'javelin-behavior',
|
|
|
|
'javelin-dom',
|
|
|
|
'javelin-util',
|
|
|
|
'javelin-vector',
|
|
|
|
'javelin-stratcom',
|
|
|
|
'javelin-workflow',
|
|
|
|
'javelin-workboard-controller',
|
|
|
|
),
|
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
|
|
|
),
|
2017-11-30 14:14:05 +01:00
|
|
|
'464259a2' => array(
|
|
|
|
'javelin-behavior',
|
|
|
|
'javelin-stratcom',
|
|
|
|
'javelin-dom',
|
|
|
|
),
|
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',
|
|
|
|
),
|
2015-01-04 22:23:22 +01:00
|
|
|
48086888 => array(
|
|
|
|
'javelin-behavior',
|
|
|
|
'javelin-dom',
|
|
|
|
'javelin-workflow',
|
|
|
|
),
|
2016-05-21 01:26:11 +02:00
|
|
|
'484a6e22' => array(
|
|
|
|
'javelin-behavior',
|
|
|
|
'javelin-dom',
|
|
|
|
'phabricator-drag-and-drop-file-upload',
|
|
|
|
'phabricator-textareautils',
|
|
|
|
),
|
2016-10-20 20:41:57 +02:00
|
|
|
'485aaa6c' => array(
|
|
|
|
'javelin-install',
|
|
|
|
),
|
2016-06-07 00:01:18 +02:00
|
|
|
'491416b3' => array(
|
|
|
|
'javelin-behavior',
|
|
|
|
'javelin-uri',
|
|
|
|
'phabricator-notification',
|
|
|
|
),
|
2017-05-17 16:00:42 +02:00
|
|
|
'4976858c' => array(
|
|
|
|
'javelin-magical-init',
|
|
|
|
'javelin-install',
|
|
|
|
'javelin-util',
|
|
|
|
'javelin-vector',
|
|
|
|
'javelin-stratcom',
|
|
|
|
),
|
2016-07-15 23:02:24 +02:00
|
|
|
'4b3c4443' => array(
|
|
|
|
'phuix-icon-view',
|
|
|
|
),
|
2015-12-26 22:00:01 +01:00
|
|
|
'4b700e9e' => array(
|
|
|
|
'javelin-behavior',
|
|
|
|
'javelin-dom',
|
|
|
|
'javelin-util',
|
|
|
|
'phabricator-shaped-request',
|
|
|
|
),
|
2016-05-22 15:50:12 +02:00
|
|
|
'4c193c96' => array(
|
|
|
|
'javelin-behavior',
|
|
|
|
'javelin-uri',
|
|
|
|
'phabricator-notification',
|
|
|
|
),
|
Fix several duplication/replay behaviors in Aphlict
Summary:
Ref T12566. Ref T12563. This fixes three bugs with Aphlict replay stuff:
First, Conphernece would try to repaint the UI even if no thread was open. Only repaint when a thread is open.
Second, although we deduplicate JX.Leader messages, we didn't deduplicate actual notification messages. If you browsed the leader window, then it re-elected itelf as a leader and replayed history, it could rebroadcast notifications and other windows could show doubles. Deduplicate notifications to prevent this.
Third, we always replayed the last 60 seconds of history. When you browsed the leader window, whichever window became the new leader (possibly the one you just browsed) could replay messages from before it had opened, leading to duplicate messages. Particularly, after receiving a message and then browsing you could see that message again. Instead, only replay history as far back as when the window first opened.
Test Plan:
- Clicked "Repaint" with a thread open, saw a repaint. Clicked "Repaint" with Conpherence open but no thread, no repaint and no 404 request to `/update/null/`.
- In browser A, opened three windows. In browser B, sent a notification. In browser A, browsed the leader window away twice in a row. Observed that the window which never became a leader doesn't duplicate notifications.
- In browser A, opened three windows. In browser B, sent a notification. In browser A, browsed the leader window away over and over again. Observed that replay requests issued with appropriate history windows.
Reviewers: chad
Reviewed By: chad
Maniphest Tasks: T12566, T12563
Differential Revision: https://secure.phabricator.com/D17722
2017-04-18 20:14:37 +02:00
|
|
|
'4d863052' => array(
|
|
|
|
'javelin-dom',
|
|
|
|
'javelin-util',
|
|
|
|
'javelin-stratcom',
|
|
|
|
'javelin-install',
|
|
|
|
'javelin-aphlict',
|
|
|
|
'javelin-workflow',
|
|
|
|
'javelin-router',
|
|
|
|
'javelin-behavior-device',
|
|
|
|
'javelin-vector',
|
|
|
|
),
|
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
|
|
|
),
|
2018-03-16 23:10:26 +01:00
|
|
|
'4f774dac' => array(
|
|
|
|
'javelin-install',
|
|
|
|
'javelin-dom',
|
|
|
|
'javelin-stratcom',
|
|
|
|
'javelin-util',
|
|
|
|
'phabricator-notification-css',
|
|
|
|
),
|
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
|
|
|
),
|
2016-04-15 21:06:53 +02:00
|
|
|
'522431f7' => array(
|
|
|
|
'javelin-behavior',
|
|
|
|
'javelin-util',
|
|
|
|
'javelin-dom',
|
|
|
|
'javelin-stratcom',
|
|
|
|
'javelin-vector',
|
|
|
|
'javelin-typeahead-static-source',
|
|
|
|
),
|
2018-04-27 19:58:28 +02:00
|
|
|
'549459b8' => array(
|
|
|
|
'javelin-behavior',
|
|
|
|
),
|
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
|
|
|
),
|
2017-04-10 23:39:36 +02:00
|
|
|
'55616e04' => array(
|
|
|
|
'javelin-behavior',
|
|
|
|
'javelin-dom',
|
|
|
|
'javelin-util',
|
|
|
|
'javelin-workflow',
|
|
|
|
'javelin-stratcom',
|
|
|
|
'conpherence-thread-manager',
|
|
|
|
),
|
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
|
|
|
),
|
2016-05-21 01:26:11 +02:00
|
|
|
'58dea2fa' => array(
|
2016-02-19 22:41:03 +01:00
|
|
|
'javelin-install',
|
2016-05-21 01:26:11 +02:00
|
|
|
'javelin-util',
|
|
|
|
'javelin-request',
|
2016-02-19 22:41:03 +01:00
|
|
|
'javelin-dom',
|
2016-05-21 01:26:11 +02:00
|
|
|
'javelin-uri',
|
|
|
|
'phabricator-file-upload',
|
2016-02-19 22:41:03 +01:00
|
|
|
),
|
2018-03-16 23:10:26 +01:00
|
|
|
'599a8f5f' => array(
|
|
|
|
'javelin-behavior',
|
|
|
|
'javelin-aphlict',
|
|
|
|
'javelin-stratcom',
|
|
|
|
'javelin-request',
|
|
|
|
'javelin-uri',
|
|
|
|
'javelin-dom',
|
|
|
|
'javelin-json',
|
|
|
|
'javelin-router',
|
|
|
|
'javelin-util',
|
|
|
|
'javelin-leader',
|
|
|
|
'javelin-sound',
|
|
|
|
'phabricator-notification',
|
|
|
|
),
|
2015-04-02 05:10:32 +02:00
|
|
|
'59a7976a' => array(
|
|
|
|
'javelin-install',
|
|
|
|
'javelin-dom',
|
|
|
|
'javelin-fx',
|
|
|
|
),
|
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
|
|
|
),
|
2014-08-02 23:44:35 +02:00
|
|
|
'5c54cbf3' => array(
|
|
|
|
'javelin-behavior',
|
|
|
|
'javelin-stratcom',
|
|
|
|
'javelin-dom',
|
|
|
|
),
|
2016-10-02 05:37:28 +02:00
|
|
|
'5e2634b9' => array(
|
|
|
|
'javelin-behavior',
|
|
|
|
'javelin-aphlict',
|
|
|
|
'phabricator-phtize',
|
|
|
|
'javelin-dom',
|
|
|
|
),
|
2015-04-17 16:55:17 +02:00
|
|
|
'5e9f347c' => array(
|
|
|
|
'javelin-behavior',
|
|
|
|
'multirow-row-manager',
|
|
|
|
'javelin-dom',
|
|
|
|
'javelin-util',
|
|
|
|
'phabricator-prefab',
|
|
|
|
'javelin-json',
|
|
|
|
),
|
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
|
|
|
'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',
|
|
|
|
),
|
2015-04-17 16:55:17 +02:00
|
|
|
'635de1ec' => array(
|
|
|
|
'javelin-behavior',
|
|
|
|
'javelin-stratcom',
|
|
|
|
'javelin-workflow',
|
|
|
|
'javelin-dom',
|
|
|
|
),
|
2018-03-14 00:26:01 +01:00
|
|
|
66888767 => array(
|
|
|
|
'javelin-behavior',
|
|
|
|
'javelin-stratcom',
|
|
|
|
'javelin-util',
|
|
|
|
'javelin-dom',
|
|
|
|
'javelin-request',
|
|
|
|
'phabricator-keyboard-shortcut',
|
|
|
|
'phabricator-darklog',
|
|
|
|
'phabricator-darkmessage',
|
|
|
|
),
|
2018-04-11 23:44:06 +02:00
|
|
|
'66a62306' => array(
|
|
|
|
'javelin-behavior',
|
|
|
|
'javelin-stratcom',
|
|
|
|
'javelin-dom',
|
|
|
|
'javelin-history',
|
|
|
|
),
|
2018-01-19 16:32:28 +01:00
|
|
|
'66a6def1' => array(
|
|
|
|
'javelin-behavior',
|
|
|
|
'javelin-dom',
|
|
|
|
'javelin-util',
|
|
|
|
'multirow-row-manager',
|
|
|
|
'javelin-json',
|
|
|
|
'phuix-form-control-view',
|
|
|
|
),
|
2016-02-06 23:05:15 +01:00
|
|
|
'680ea2c8' => array(
|
|
|
|
'javelin-install',
|
|
|
|
'javelin-dom',
|
|
|
|
'phabricator-notification',
|
|
|
|
),
|
2017-05-30 23:47:50 +02:00
|
|
|
'68af71ca' => array(
|
|
|
|
'javelin-install',
|
|
|
|
'javelin-dom',
|
|
|
|
'phuix-button-view',
|
|
|
|
),
|
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
|
|
|
),
|
2018-03-22 18:58:56 +01:00
|
|
|
'6a726c55' => array(
|
|
|
|
'javelin-stratcom',
|
|
|
|
'javelin-request',
|
|
|
|
'javelin-dom',
|
|
|
|
'javelin-vector',
|
|
|
|
'javelin-install',
|
|
|
|
'javelin-util',
|
|
|
|
'javelin-mask',
|
|
|
|
'javelin-uri',
|
|
|
|
'javelin-routable',
|
|
|
|
),
|
2018-03-08 17:22:16 +01:00
|
|
|
'6b31879a' => array(
|
|
|
|
'javelin-behavior',
|
|
|
|
'javelin-stratcom',
|
|
|
|
'javelin-dom',
|
|
|
|
'javelin-mask',
|
|
|
|
'javelin-util',
|
|
|
|
'phuix-icon-view',
|
|
|
|
'phabricator-busy',
|
|
|
|
),
|
When logged-out users hit a "Login Required" dialog, try to choose a better "next" URI
Summary:
Ref T10004. After a user logs in, we send them to the "next" URI cookie if there is one, but currently don't always do a very good job of selecting a "next" URI, especially if they tried to do something with a dialog before being asked to log in.
In particular, if a logged-out user clicks an action like "Edit Blocking Tasks" on a Maniphest task, the default behavior is to send them to the standalone page for that dialog after they log in. This can be pretty confusing.
See T2691 and D6416 for earlier efforts here. At that time, we added a mechanism to //manually// override the default behavior, and fixed the most common links. This worked, but I'd like to fix the //default// beahvior so we don't need to remember to `setObjectURI()` correctly all over the place.
ApplicationEditor has also introduced new cases which are more difficult to get right. While we could get them right by using the override and being careful about things, this also motivates fixing the default behavior.
Finally, we have better tools for fixing the default behavior now than we did in 2013.
Instead of using manual overrides, have JS include an "X-Phabricator-Via" header in Ajax requests. This is basically like a referrer header, and will contain the page the user's browser is on.
In essentially every case, this should be a very good place (and often the best place) to send them after login. For all pages currently using `setObjectURI()`, it should produce the same behavior by default.
I'll remove the `setObjectURI()` mechanism in the next diff.
Test Plan: Clicked various workflow actions while logged out, saw "next" get set to a reasonable value, was redirected to a sensible, non-confusing page after login (the page with whatever button I clicked on it).
Reviewers: chad
Reviewed By: chad
Maniphest Tasks: T10004
Differential Revision: https://secure.phabricator.com/D14804
2015-12-17 15:10:04 +01:00
|
|
|
'6b8ef10b' => array(
|
|
|
|
'javelin-install',
|
|
|
|
),
|
Time control typeaheads.
Summary: Ref T8031, Time control typeaheads
Test Plan: Edit an event, type '3', typeahead should suggest, '3:00 AM', '3:30 AM', '3:00 PM', '3:30 PM'.
Reviewers: chad, epriestley, #blessed_reviewers
Reviewed By: epriestley, #blessed_reviewers
Subscribers: Korvin, epriestley
Maniphest Tasks: T8031
Differential Revision: https://secure.phabricator.com/D12953
2015-05-20 18:51:26 +02:00
|
|
|
'6c0e62fa' => array(
|
|
|
|
'javelin-install',
|
|
|
|
'javelin-typeahead-source',
|
|
|
|
),
|
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
|
|
|
),
|
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
|
|
|
),
|
2018-08-13 20:35:02 +02:00
|
|
|
'6d8c7912' => array(
|
|
|
|
'javelin-install',
|
|
|
|
'javelin-typeahead',
|
|
|
|
'javelin-dom',
|
|
|
|
'javelin-request',
|
|
|
|
'javelin-typeahead-ondemand-source',
|
|
|
|
'javelin-util',
|
|
|
|
),
|
2015-01-14 01:10:57 +01:00
|
|
|
'70baed2f' => array(
|
|
|
|
'javelin-install',
|
|
|
|
'javelin-dom',
|
|
|
|
'javelin-vector',
|
|
|
|
'javelin-util',
|
|
|
|
),
|
2015-06-30 18:37:12 +02:00
|
|
|
71237763 => array(
|
|
|
|
'javelin-behavior',
|
|
|
|
'javelin-dom',
|
|
|
|
'javelin-stratcom',
|
|
|
|
'javelin-workflow',
|
|
|
|
'phabricator-draggable-list',
|
|
|
|
),
|
2015-01-04 22:23:22 +01:00
|
|
|
'7319e029' => array(
|
|
|
|
'javelin-behavior',
|
|
|
|
'javelin-dom',
|
|
|
|
),
|
2017-05-22 19:47:19 +02:00
|
|
|
'758b4758' => array(
|
|
|
|
'javelin-install',
|
|
|
|
'javelin-workboard-card',
|
|
|
|
),
|
2017-06-07 00:47:47 +02:00
|
|
|
'75b83cbb' => array(
|
|
|
|
'javelin-behavior',
|
|
|
|
'javelin-dom',
|
|
|
|
'javelin-stratcom',
|
|
|
|
),
|
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
|
|
|
),
|
2017-10-09 19:52:27 +02:00
|
|
|
'77b0ae28' => 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',
|
|
|
|
),
|
2017-06-07 22:48:19 +02:00
|
|
|
'77c1f0b0' => array(
|
|
|
|
'javelin-behavior',
|
|
|
|
'javelin-dom',
|
|
|
|
'javelin-request',
|
|
|
|
'javelin-util',
|
|
|
|
),
|
2015-03-10 23:32:15 +01:00
|
|
|
'7927a7d3' => array(
|
|
|
|
'javelin-behavior',
|
|
|
|
'javelin-quicksand',
|
|
|
|
),
|
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
|
|
|
),
|
Replace the "Choose Subtype" radio buttons dialog with a simpler "big stuff you click" sort of UI
Summary:
Ref T13222. Fixes T12588. See PHI683. In several cases, we present the user with a choice between multiple major options: Alamnac service types, Drydock blueprint types, Repository VCS types, Herald rule types, etc.
Today, we generally do this with radio buttons and a "Submit" button. This isn't terrible, but often it means users have to click twice (once on the radio; once on submit) when a single click would be sufficient. The radio click target can also be small.
In other cases, we have a container with a link and we'd like to link the entire container: notifications, the `/drydock/` console, etc. We'd like to just link the entire container, but this causes some problems:
- It's not legal to link block eleements like `<a><div> ... </div></a>` and some browsers actually get upset about it.
- We can `<a><span> ... </span></a>` instead, then turn the `<span>` into a block element with CSS -- and this sometimes works, but also has some drawbacks:
- It's not great to do that for screenreaders, since the readable text in the link isn't necessarily very meaningful.
- We can't have any other links inside the element (e.g., details or documentation).
- We can `<form><button> ... </button></form>` instead, but this has its own set of problems:
- You can't right-click to interact with a button in the same way you can with a link.
- Also not great for screenreaders.
Instead, try adding a `linked-container` behavior which just means "when users click this element, pretend they clicked the first link inside it".
This gives us natural HTML (real, legal HTML with actual `<a>` tags) and good screenreader behavior, but allows the effective link target to be visually larger than just the link.
If no issues crop up with this, I'd plan to eventually use this technique in more places (Repositories, Herald, Almanac, Drydock, Notifications menu, etc).
Test Plan:
{F6053035}
- Left-clicked and command-left-clicked the new JS fanciness, got sensible behaviors.
Reviewers: amckinley
Reviewed By: amckinley
Subscribers: PHID-OPKG-gm6ozazyms6q6i22gyam
Maniphest Tasks: T13222, T12588
Differential Revision: https://secure.phabricator.com/D19855
2018-12-07 15:04:07 +01:00
|
|
|
'7a7c22af' => array(
|
|
|
|
'phui-oi-list-view-css',
|
|
|
|
),
|
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
|
|
|
'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
|
|
|
),
|
2017-04-17 21:10:29 +02:00
|
|
|
'7f243deb' => array(
|
|
|
|
'javelin-install',
|
|
|
|
),
|
Make the filetree view width sticky across show/hide and reload
Summary:
Ref T13090. The default width changed recently to become much wider, but the behavior on this control isn't great. Instead:
- Pick a default width somewhere between the two.
- Make the width sticky across show/hide (pressing "f" twice remembers your width instead of resetting it).
- Make the width sticky across reloads (dragging the bar, then reloading the page keeps the bar in the same place).
Test Plan:
- Without settings, loaded page: got medium-width bar.
- Dragged bar wide/narrow, toggled on/off with "f", got persistent width.
- Dragged bar wide/narrow, reloaded page, got persistent width.
- Dragged bar wide/narrow, toggled it off, reloaded page, toggled it on, got persistent width.
Maniphest Tasks: T13090
Differential Revision: https://secure.phabricator.com/D19129
2018-02-22 22:31:20 +01:00
|
|
|
'834a1173' => array(
|
|
|
|
'javelin-behavior',
|
|
|
|
'javelin-scrollbar',
|
|
|
|
),
|
2016-01-19 17:43:31 +01:00
|
|
|
'8499b6ab' => array(
|
|
|
|
'javelin-behavior',
|
|
|
|
'javelin-dom',
|
|
|
|
'javelin-stratcom',
|
|
|
|
),
|
2018-08-17 19:53:28 +02:00
|
|
|
'85ac9772' => array(
|
|
|
|
'javelin-install',
|
|
|
|
'javelin-dom',
|
|
|
|
),
|
2015-07-02 23:39:43 +02:00
|
|
|
'85ee8ce6' => array(
|
|
|
|
'aphront-dialog-view-css',
|
|
|
|
),
|
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
|
|
|
),
|
2017-01-24 16:25:57 +01:00
|
|
|
'8935deef' => array(
|
|
|
|
'javelin-install',
|
|
|
|
'javelin-dom',
|
|
|
|
'javelin-util',
|
|
|
|
'javelin-stratcom',
|
|
|
|
'javelin-workflow',
|
|
|
|
'phabricator-draggable-list',
|
|
|
|
'javelin-workboard-column',
|
|
|
|
),
|
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-12-30 11:54:21 +01:00
|
|
|
'8ce821c5' => array(
|
|
|
|
'phabricator-notification',
|
|
|
|
'javelin-stratcom',
|
|
|
|
'javelin-behavior',
|
|
|
|
),
|
2018-03-30 20:02:01 +02:00
|
|
|
'8d4a8c72' => array(
|
|
|
|
'javelin-install',
|
|
|
|
'javelin-dom',
|
|
|
|
'javelin-util',
|
|
|
|
),
|
2017-06-05 22:14:34 +02:00
|
|
|
'8e1baf68' => array(
|
|
|
|
'phui-button-css',
|
|
|
|
),
|
2016-04-13 18:20:15 +02:00
|
|
|
'8ff5e24c' => array(
|
|
|
|
'javelin-behavior',
|
|
|
|
'javelin-stratcom',
|
|
|
|
'javelin-dom',
|
|
|
|
),
|
2015-10-21 20:28:26 +02:00
|
|
|
'901935ef' => array(
|
|
|
|
'javelin-behavior',
|
|
|
|
'javelin-dom',
|
|
|
|
'javelin-request',
|
|
|
|
),
|
2017-05-20 13:10:32 +02:00
|
|
|
'9065f639' => array(
|
|
|
|
'javelin-install',
|
|
|
|
'javelin-dom',
|
|
|
|
'javelin-stratcom',
|
|
|
|
'javelin-vector',
|
|
|
|
),
|
2016-04-13 18:20:15 +02:00
|
|
|
'92b9ec77' => array(
|
|
|
|
'javelin-behavior',
|
|
|
|
'javelin-stratcom',
|
|
|
|
'javelin-dom',
|
|
|
|
),
|
2015-04-17 16:55:17 +02:00
|
|
|
'93d0c9e3' => array(
|
|
|
|
'javelin-behavior',
|
|
|
|
'javelin-stratcom',
|
|
|
|
'javelin-workflow',
|
|
|
|
'javelin-dom',
|
|
|
|
),
|
2015-03-10 23:30:49 +01:00
|
|
|
'949c0fe5' => array(
|
|
|
|
'javelin-install',
|
|
|
|
),
|
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',
|
|
|
|
),
|
2016-10-18 23:24:17 +02:00
|
|
|
'960f6a39' => array(
|
|
|
|
'javelin-behavior',
|
|
|
|
'javelin-dom',
|
|
|
|
'javelin-uri',
|
|
|
|
'javelin-mask',
|
|
|
|
'phabricator-drag-and-drop-file-upload',
|
|
|
|
),
|
2018-04-08 18:10:03 +02:00
|
|
|
'9a860428' => array(
|
|
|
|
'javelin-behavior',
|
|
|
|
'javelin-dom',
|
|
|
|
'javelin-stratcom',
|
|
|
|
'javelin-uri',
|
|
|
|
),
|
Remove 'full-display' setting from Conpherence, spruce up search results
Summary: This removes 'full-display', 'minimal-display' from Conpherence, which I recall was because we had 2 UIs for column and regular chat. I'm also tossing in slightly nicer search results, with a link to the actual message and the full date shown for context.
Test Plan: Post a message in mobile, tablet, full conpherence, and in durable column. Clean up UI in durable column. Do a search in Full UI, click on result date, get taken to the message... usually. My test data is a little wonky, but I think this works most of the time.
Reviewers: epriestley
Reviewed By: epriestley
Subscribers: Korvin
Differential Revision: https://secure.phabricator.com/D16710
2016-10-16 05:26:15 +02:00
|
|
|
'9bbf3762' => array(
|
|
|
|
'javelin-behavior',
|
|
|
|
'javelin-dom',
|
|
|
|
'javelin-util',
|
|
|
|
'javelin-workflow',
|
|
|
|
'javelin-stratcom',
|
|
|
|
),
|
2018-08-27 19:09:13 +02:00
|
|
|
'9d32bc88' => array(
|
|
|
|
'javelin-behavior',
|
|
|
|
'javelin-behavior-device',
|
|
|
|
'javelin-stratcom',
|
|
|
|
'javelin-dom',
|
|
|
|
'javelin-magical-init',
|
|
|
|
'javelin-vector',
|
|
|
|
'javelin-request',
|
|
|
|
'javelin-util',
|
|
|
|
),
|
2016-12-14 20:35:51 +01:00
|
|
|
'9d9685d6' => array(
|
|
|
|
'phui-oi-list-view-css',
|
|
|
|
),
|
2015-01-28 17:26:10 +01:00
|
|
|
'9f36c42d' => array(
|
|
|
|
'javelin-behavior',
|
|
|
|
'javelin-stratcom',
|
|
|
|
'javelin-dom',
|
|
|
|
'javelin-vector',
|
|
|
|
),
|
2015-01-25 17:46:22 +01:00
|
|
|
'a0b57eb8' => array(
|
|
|
|
'javelin-behavior',
|
|
|
|
'javelin-dom',
|
|
|
|
'javelin-stratcom',
|
|
|
|
'javelin-workflow',
|
|
|
|
'javelin-util',
|
|
|
|
'phabricator-keyboard-shortcut',
|
|
|
|
),
|
2017-10-09 19:52:27 +02:00
|
|
|
'a3714c76' => array(
|
|
|
|
'javelin-behavior',
|
|
|
|
'javelin-stratcom',
|
|
|
|
'javelin-dom',
|
|
|
|
'javelin-vector',
|
|
|
|
'javelin-install',
|
|
|
|
),
|
2016-12-14 20:35:51 +01:00
|
|
|
'a3a63478' => array(
|
|
|
|
'phui-workcard-view-css',
|
|
|
|
),
|
2015-04-24 01:37:56 +02:00
|
|
|
'a464fe03' => array(
|
|
|
|
'javelin-behavior',
|
|
|
|
'javelin-uri',
|
|
|
|
'phabricator-notification',
|
|
|
|
),
|
2017-02-10 17:34:12 +01:00
|
|
|
'a6b98425' => array(
|
|
|
|
'javelin-behavior',
|
|
|
|
'javelin-dom',
|
|
|
|
'phortune-credit-card-form',
|
|
|
|
),
|
2016-06-21 02:49:38 +02:00
|
|
|
'a6f7a73b' => array(
|
|
|
|
'javelin-behavior',
|
|
|
|
'javelin-stratcom',
|
|
|
|
'javelin-dom',
|
|
|
|
),
|
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
|
|
|
),
|
2016-12-14 20:35:51 +01:00
|
|
|
'a8beebea' => array(
|
|
|
|
'phui-oi-list-view-css',
|
|
|
|
),
|
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
|
|
|
),
|
When logged-out users hit a "Login Required" dialog, try to choose a better "next" URI
Summary:
Ref T10004. After a user logs in, we send them to the "next" URI cookie if there is one, but currently don't always do a very good job of selecting a "next" URI, especially if they tried to do something with a dialog before being asked to log in.
In particular, if a logged-out user clicks an action like "Edit Blocking Tasks" on a Maniphest task, the default behavior is to send them to the standalone page for that dialog after they log in. This can be pretty confusing.
See T2691 and D6416 for earlier efforts here. At that time, we added a mechanism to //manually// override the default behavior, and fixed the most common links. This worked, but I'd like to fix the //default// beahvior so we don't need to remember to `setObjectURI()` correctly all over the place.
ApplicationEditor has also introduced new cases which are more difficult to get right. While we could get them right by using the override and being careful about things, this also motivates fixing the default behavior.
Finally, we have better tools for fixing the default behavior now than we did in 2013.
Instead of using manual overrides, have JS include an "X-Phabricator-Via" header in Ajax requests. This is basically like a referrer header, and will contain the page the user's browser is on.
In essentially every case, this should be a very good place (and often the best place) to send them after login. For all pages currently using `setObjectURI()`, it should produce the same behavior by default.
I'll remove the `setObjectURI()` mechanism in the next diff.
Test Plan: Clicked various workflow actions while logged out, saw "next" get set to a reasonable value, was redirected to a sensible, non-confusing page after login (the page with whatever button I clicked on it).
Reviewers: chad
Reviewed By: chad
Maniphest Tasks: T10004
Differential Revision: https://secure.phabricator.com/D14804
2015-12-17 15:10:04 +01:00
|
|
|
'ab2f381b' => array(
|
|
|
|
'javelin-request',
|
|
|
|
'javelin-behavior',
|
|
|
|
'javelin-dom',
|
|
|
|
'javelin-router',
|
|
|
|
'javelin-util',
|
|
|
|
'phabricator-busy',
|
|
|
|
),
|
Use a tokenizer, not a gigantic poorly-ordered "<select />", to choose repositories in Owners
Summary: Depends on D19190. Fixes T12590. Ref T13099. Replaces the barely-usable, gigantic, poorly ordered "<select />" control with a tokenizer. Attempts to fix various minor issues.
Test Plan:
- Edited paths: include/exclude paths, from different repositories, different actual paths.
- Used "Add New Path" to add rows, got repository selector prepopulated with last value.
- Used "remove".
- Used validation typeahead, got reasonable behaviors?
The error behavior if you delete the repository for a path is a little sketchy still, but roughly okay.
Maniphest Tasks: T13099, T12590
Differential Revision: https://secure.phabricator.com/D19191
2018-03-08 02:29:06 +01:00
|
|
|
'ab9e0a82' => array(
|
|
|
|
'javelin-install',
|
|
|
|
'javelin-util',
|
|
|
|
'javelin-dom',
|
|
|
|
'javelin-typeahead-normalizer',
|
|
|
|
),
|
2017-04-26 17:49:53 +02:00
|
|
|
'acd29eee' => array(
|
|
|
|
'javelin-behavior',
|
|
|
|
'javelin-stratcom',
|
|
|
|
'javelin-dom',
|
|
|
|
'phabricator-phtize',
|
|
|
|
'phabricator-textareautils',
|
|
|
|
'javelin-workflow',
|
|
|
|
'javelin-vector',
|
|
|
|
'phuix-autocomplete',
|
|
|
|
'javelin-mask',
|
|
|
|
),
|
2017-11-30 14:57:39 +01:00
|
|
|
'ad54037e' => array(
|
|
|
|
'javelin-behavior',
|
|
|
|
'javelin-dom',
|
|
|
|
'javelin-stratcom',
|
|
|
|
'javelin-util',
|
|
|
|
),
|
2017-05-18 20:54:58 +02:00
|
|
|
'b003d4fb' => array(
|
2015-05-20 22:54:22 +02:00
|
|
|
'javelin-behavior',
|
|
|
|
'javelin-stratcom',
|
|
|
|
'javelin-dom',
|
2017-05-18 20:54:58 +02:00
|
|
|
'phuix-dropdown-menu',
|
2015-05-20 22:54:22 +02:00
|
|
|
),
|
2017-05-31 05:00:15 +02:00
|
|
|
'b0b8f86d' => array(
|
|
|
|
'javelin-behavior',
|
|
|
|
'javelin-dom',
|
|
|
|
'javelin-stratcom',
|
|
|
|
),
|
2015-05-18 21:18:10 +02:00
|
|
|
'b23b49e6' => array(
|
|
|
|
'javelin-behavior',
|
|
|
|
'javelin-dom',
|
|
|
|
'javelin-util',
|
|
|
|
'javelin-request',
|
|
|
|
'phabricator-shaped-request',
|
|
|
|
),
|
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-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
|
|
|
),
|
2018-02-09 01:55:54 +01:00
|
|
|
'b49b59d6' => array(
|
|
|
|
'javelin-dom',
|
|
|
|
'javelin-util',
|
|
|
|
'javelin-stratcom',
|
|
|
|
'javelin-install',
|
|
|
|
'javelin-workflow',
|
|
|
|
'javelin-router',
|
|
|
|
'javelin-behavior-device',
|
|
|
|
'javelin-vector',
|
|
|
|
'phabricator-diff-inline',
|
|
|
|
),
|
2015-11-17 18:33:06 +01:00
|
|
|
'b59e1e96' => array(
|
|
|
|
'javelin-behavior',
|
|
|
|
'javelin-stratcom',
|
|
|
|
'javelin-workflow',
|
|
|
|
'javelin-dom',
|
|
|
|
'phabricator-draggable-list',
|
|
|
|
),
|
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',
|
|
|
|
),
|
2015-05-25 14:34:23 +02:00
|
|
|
'b6993408' => array(
|
|
|
|
'javelin-behavior',
|
|
|
|
'javelin-stratcom',
|
|
|
|
'javelin-dom',
|
|
|
|
'javelin-json',
|
|
|
|
'phabricator-draggable-list',
|
|
|
|
),
|
2017-01-18 20:17:11 +01:00
|
|
|
'b95d6f7d' => array(
|
|
|
|
'javelin-behavior',
|
|
|
|
'javelin-stratcom',
|
|
|
|
'javelin-dom',
|
|
|
|
'phuix-dropdown-menu',
|
|
|
|
),
|
2016-04-10 13:26:53 +02:00
|
|
|
'ba158207' => array(
|
|
|
|
'javelin-behavior',
|
|
|
|
'javelin-uri',
|
|
|
|
'phabricator-notification',
|
|
|
|
),
|
2018-06-01 22:05:46 +02:00
|
|
|
'bb6e5c16' => array(
|
|
|
|
'javelin-dom',
|
|
|
|
'javelin-util',
|
|
|
|
'javelin-stratcom',
|
|
|
|
'javelin-install',
|
|
|
|
),
|
2016-02-03 17:26:30 +01:00
|
|
|
'bcaccd64' => array(
|
|
|
|
'javelin-behavior',
|
|
|
|
'javelin-behavior-device',
|
|
|
|
'javelin-stratcom',
|
|
|
|
'javelin-vector',
|
|
|
|
'phui-hovercard',
|
|
|
|
),
|
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
|
|
|
),
|
2016-11-17 13:01:35 +01:00
|
|
|
'bea6e7f4' => array(
|
|
|
|
'javelin-install',
|
|
|
|
'javelin-dom',
|
|
|
|
'javelin-stratcom',
|
|
|
|
'javelin-util',
|
|
|
|
'javelin-vector',
|
|
|
|
'javelin-magical-init',
|
|
|
|
),
|
2016-06-09 17:34:00 +02:00
|
|
|
'bee502c8' => array(
|
|
|
|
'javelin-behavior',
|
|
|
|
'javelin-stratcom',
|
|
|
|
'javelin-dom',
|
|
|
|
'javelin-workflow',
|
|
|
|
'javelin-quicksand',
|
|
|
|
'phabricator-phtize',
|
|
|
|
'phabricator-drag-and-drop-file-upload',
|
|
|
|
'phabricator-draggable-list',
|
|
|
|
),
|
2016-05-11 19:17:33 +02:00
|
|
|
'bf5374ef' => array(
|
|
|
|
'javelin-behavior',
|
|
|
|
'javelin-stratcom',
|
|
|
|
'javelin-dom',
|
|
|
|
),
|
2015-12-17 22:27:36 +01:00
|
|
|
'bff6884b' => array(
|
2015-12-04 23:37:27 +01:00
|
|
|
'javelin-install',
|
|
|
|
'javelin-dom',
|
|
|
|
),
|
2017-05-16 15:40:50 +02:00
|
|
|
'c19dd9b9' => array(
|
|
|
|
'javelin-install',
|
|
|
|
'javelin-util',
|
|
|
|
'javelin-stratcom',
|
|
|
|
'javelin-dom',
|
|
|
|
'javelin-vector',
|
|
|
|
),
|
2018-02-16 16:09:17 +01:00
|
|
|
'c3e917d9' => array(
|
|
|
|
'javelin-behavior',
|
|
|
|
'javelin-typeahead-ondemand-source',
|
|
|
|
'javelin-typeahead',
|
|
|
|
'javelin-dom',
|
|
|
|
'javelin-uri',
|
|
|
|
'javelin-util',
|
|
|
|
'javelin-stratcom',
|
|
|
|
'phabricator-prefab',
|
|
|
|
'phuix-icon-view',
|
|
|
|
),
|
2017-01-31 17:58:33 +01:00
|
|
|
'c420b0b9' => array(
|
|
|
|
'javelin-behavior',
|
|
|
|
'javelin-behavior-device',
|
|
|
|
'javelin-stratcom',
|
|
|
|
'phabricator-tooltip',
|
|
|
|
),
|
2016-02-11 00:06:20 +01:00
|
|
|
'c587b80f' => array(
|
|
|
|
'javelin-install',
|
|
|
|
),
|
2015-11-22 22:03:58 +01:00
|
|
|
'c7ccd872' => array(
|
|
|
|
'phui-fontkit-css',
|
|
|
|
),
|
2015-01-14 01:10:57 +01:00
|
|
|
'c90a04fc' => array(
|
|
|
|
'javelin-dom',
|
|
|
|
'javelin-dynval',
|
|
|
|
'javelin-reactor',
|
|
|
|
'javelin-reactornode',
|
|
|
|
'javelin-install',
|
|
|
|
'javelin-util',
|
|
|
|
),
|
Use a tokenizer, not a gigantic poorly-ordered "<select />", to choose repositories in Owners
Summary: Depends on D19190. Fixes T12590. Ref T13099. Replaces the barely-usable, gigantic, poorly ordered "<select />" control with a tokenizer. Attempts to fix various minor issues.
Test Plan:
- Edited paths: include/exclude paths, from different repositories, different actual paths.
- Used "Add New Path" to add rows, got repository selector prepopulated with last value.
- Used "remove".
- Used validation typeahead, got reasonable behaviors?
The error behavior if you delete the repository for a path is a little sketchy still, but roughly okay.
Maniphest Tasks: T13099, T12590
Differential Revision: https://secure.phabricator.com/D19191
2018-03-08 02:29:06 +01:00
|
|
|
'c96502cf' => array(
|
|
|
|
'multirow-row-manager',
|
|
|
|
'javelin-install',
|
|
|
|
'path-typeahead',
|
|
|
|
'javelin-dom',
|
|
|
|
'javelin-util',
|
|
|
|
'phabricator-prefab',
|
|
|
|
'phuix-form-control-view',
|
|
|
|
),
|
When logged-out users hit a "Login Required" dialog, try to choose a better "next" URI
Summary:
Ref T10004. After a user logs in, we send them to the "next" URI cookie if there is one, but currently don't always do a very good job of selecting a "next" URI, especially if they tried to do something with a dialog before being asked to log in.
In particular, if a logged-out user clicks an action like "Edit Blocking Tasks" on a Maniphest task, the default behavior is to send them to the standalone page for that dialog after they log in. This can be pretty confusing.
See T2691 and D6416 for earlier efforts here. At that time, we added a mechanism to //manually// override the default behavior, and fixed the most common links. This worked, but I'd like to fix the //default// beahvior so we don't need to remember to `setObjectURI()` correctly all over the place.
ApplicationEditor has also introduced new cases which are more difficult to get right. While we could get them right by using the override and being careful about things, this also motivates fixing the default behavior.
Finally, we have better tools for fixing the default behavior now than we did in 2013.
Instead of using manual overrides, have JS include an "X-Phabricator-Via" header in Ajax requests. This is basically like a referrer header, and will contain the page the user's browser is on.
In essentially every case, this should be a very good place (and often the best place) to send them after login. For all pages currently using `setObjectURI()`, it should produce the same behavior by default.
I'll remove the `setObjectURI()` mechanism in the next diff.
Test Plan: Clicked various workflow actions while logged out, saw "next" get set to a reasonable value, was redirected to a sensible, non-confusing page after login (the page with whatever button I clicked on it).
Reviewers: chad
Reviewed By: chad
Maniphest Tasks: T10004
Differential Revision: https://secure.phabricator.com/D14804
2015-12-17 15:10:04 +01:00
|
|
|
'c989ade3' => array(
|
|
|
|
'javelin-install',
|
|
|
|
'javelin-util',
|
|
|
|
'javelin-stratcom',
|
|
|
|
),
|
2017-01-17 22:59:56 +01:00
|
|
|
'caade6f2' => array(
|
|
|
|
'javelin-behavior',
|
|
|
|
'javelin-request',
|
|
|
|
'javelin-stratcom',
|
|
|
|
'javelin-vector',
|
|
|
|
'javelin-dom',
|
|
|
|
'javelin-uri',
|
|
|
|
'javelin-behavior-device',
|
|
|
|
'phabricator-title',
|
|
|
|
'phabricator-favicon',
|
|
|
|
),
|
2016-12-14 20:35:51 +01:00
|
|
|
'cd2b9b77' => array(
|
|
|
|
'phui-oi-list-view-css',
|
|
|
|
),
|
2017-10-09 19:52:27 +02:00
|
|
|
'd057e45a' => array(
|
|
|
|
'javelin-behavior',
|
|
|
|
'javelin-dom',
|
|
|
|
'javelin-stratcom',
|
|
|
|
'javelin-workflow',
|
|
|
|
'javelin-util',
|
|
|
|
'phabricator-notification',
|
|
|
|
'conpherence-thread-manager',
|
|
|
|
),
|
2016-02-05 19:30:20 +01:00
|
|
|
'd0c516d5' => array(
|
|
|
|
'javelin-behavior',
|
|
|
|
'javelin-dom',
|
|
|
|
'javelin-util',
|
|
|
|
'phuix-dropdown-menu',
|
|
|
|
'phuix-action-list-view',
|
|
|
|
'phuix-action-view',
|
|
|
|
'javelin-workflow',
|
|
|
|
'phuix-icon-view',
|
|
|
|
),
|
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
|
|
|
),
|
2015-03-28 15:38:14 +01:00
|
|
|
'd4505101' => array(
|
|
|
|
'javelin-stratcom',
|
|
|
|
'javelin-install',
|
|
|
|
'javelin-uri',
|
|
|
|
'javelin-util',
|
|
|
|
),
|
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
|
|
|
),
|
2015-12-08 15:14:47 +01:00
|
|
|
'd7a74243' => array(
|
|
|
|
'javelin-behavior',
|
|
|
|
'javelin-stratcom',
|
|
|
|
'javelin-workflow',
|
|
|
|
'javelin-dom',
|
|
|
|
'phabricator-draggable-list',
|
|
|
|
),
|
2017-04-18 00:08:51 +02:00
|
|
|
'd835b03a' => array(
|
2017-04-17 21:10:29 +02:00
|
|
|
'javelin-behavior',
|
|
|
|
'javelin-dom',
|
|
|
|
'javelin-util',
|
2017-04-18 00:08:51 +02:00
|
|
|
'phabricator-shaped-request',
|
2017-04-17 21:10:29 +02:00
|
|
|
),
|
Pass timeline view data to comment previews, restoring Differential comment previews
Summary:
Ref T13222. In D19918, I refactored how timelines get "view data". Today, this is always additional data about which images/changesets/diffs are visible on the current revision/commit/mock, so we can tell if inline comments should be linked to a `#anchor` on the same page (if the inline is rendered there somewhere) or to a `/D123?id=1&vs=2` full link on a different page (if it isn't), but in general this could be any sort of state information about the current page that affects how the timeline should render.
Previously, comment previews did not use any specialized object code and always rendered a "generic" timeline story. This was actually a bug, but none of the code we have today cares about this (since it's all inline related, and inlines render separately) so it never impacted anything.
After the `TimelineEngine` change, the preview renders with Differential-specific code. This is more correct, but we were not passing the preview the "view data" so it broke.
This preview doesn't actually need the view data and we could just make it bail out if it isn't present, but pass it through for consistency and so this works like we'd expect if we do something fancier with view data in the future.
Test Plan: Viewed comment and inline comment previews in Differential, saw old behavior restored.
Reviewers: amckinley
Reviewed By: amckinley
Maniphest Tasks: T13222
Differential Revision: https://secure.phabricator.com/D19943
2019-01-03 01:48:53 +01:00
|
|
|
'd848ec84' => array(
|
|
|
|
'javelin-behavior',
|
|
|
|
'javelin-stratcom',
|
|
|
|
'javelin-workflow',
|
|
|
|
'javelin-dom',
|
|
|
|
'phuix-form-control-view',
|
|
|
|
'phuix-icon-view',
|
|
|
|
'javelin-behavior-phabricator-gesture',
|
|
|
|
),
|
2018-04-08 20:38:19 +02:00
|
|
|
'db34a142' => array(
|
|
|
|
'phui-inline-comment-view-css',
|
|
|
|
),
|
2018-01-19 23:43:20 +01:00
|
|
|
'dca75c0e' => array(
|
|
|
|
'multirow-row-manager',
|
|
|
|
'javelin-install',
|
|
|
|
'javelin-util',
|
|
|
|
'javelin-dom',
|
|
|
|
'javelin-stratcom',
|
|
|
|
'javelin-json',
|
|
|
|
'phabricator-prefab',
|
|
|
|
),
|
2016-12-02 19:52:14 +01:00
|
|
|
'de2e896f' => array(
|
|
|
|
'javelin-behavior',
|
|
|
|
'javelin-dom',
|
|
|
|
'javelin-typeahead',
|
|
|
|
'javelin-typeahead-ondemand-source',
|
|
|
|
'javelin-dom',
|
|
|
|
),
|
2018-03-30 17:42:18 +02:00
|
|
|
'df1bbd34' => array(
|
|
|
|
'javelin-install',
|
|
|
|
'javelin-dom',
|
|
|
|
'phuix-icon-view',
|
|
|
|
'phabricator-prefab',
|
|
|
|
),
|
2014-08-09 17:49:01 +02:00
|
|
|
'e1d25dfb' => array(
|
|
|
|
'javelin-behavior',
|
|
|
|
'javelin-stratcom',
|
|
|
|
'javelin-workflow',
|
|
|
|
'javelin-dom',
|
|
|
|
'phabricator-draggable-list',
|
|
|
|
),
|
Fix several duplication/replay behaviors in Aphlict
Summary:
Ref T12566. Ref T12563. This fixes three bugs with Aphlict replay stuff:
First, Conphernece would try to repaint the UI even if no thread was open. Only repaint when a thread is open.
Second, although we deduplicate JX.Leader messages, we didn't deduplicate actual notification messages. If you browsed the leader window, then it re-elected itelf as a leader and replayed history, it could rebroadcast notifications and other windows could show doubles. Deduplicate notifications to prevent this.
Third, we always replayed the last 60 seconds of history. When you browsed the leader window, whichever window became the new leader (possibly the one you just browsed) could replay messages from before it had opened, leading to duplicate messages. Particularly, after receiving a message and then browsing you could see that message again. Instead, only replay history as far back as when the window first opened.
Test Plan:
- Clicked "Repaint" with a thread open, saw a repaint. Clicked "Repaint" with Conpherence open but no thread, no repaint and no 404 request to `/update/null/`.
- In browser A, opened three windows. In browser B, sent a notification. In browser A, browsed the leader window away twice in a row. Observed that the window which never became a leader doesn't duplicate notifications.
- In browser A, opened three windows. In browser B, sent a notification. In browser A, browsed the leader window away over and over again. Observed that replay requests issued with appropriate history windows.
Reviewers: chad
Reviewed By: chad
Maniphest Tasks: T12566, T12563
Differential Revision: https://secure.phabricator.com/D17722
2017-04-18 20:14:37 +02:00
|
|
|
'e1d4b11a' => array(
|
|
|
|
'javelin-install',
|
|
|
|
'javelin-util',
|
|
|
|
'javelin-websocket',
|
|
|
|
'javelin-leader',
|
|
|
|
'javelin-json',
|
|
|
|
),
|
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
|
|
|
),
|
2016-01-13 18:40:27 +01:00
|
|
|
'e2e0a072' => array(
|
|
|
|
'javelin-behavior',
|
|
|
|
'javelin-stratcom',
|
|
|
|
'javelin-workflow',
|
|
|
|
'javelin-dom',
|
|
|
|
'phabricator-draggable-list',
|
|
|
|
),
|
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
|
|
|
),
|
2016-01-28 22:29:27 +01:00
|
|
|
'e4232876' => array(
|
|
|
|
'javelin-behavior',
|
|
|
|
'javelin-dom',
|
|
|
|
'javelin-vector',
|
|
|
|
'phui-chart-css',
|
|
|
|
),
|
2014-12-30 11:53:27 +01:00
|
|
|
'e4cc26b3' => array(
|
|
|
|
'javelin-behavior',
|
|
|
|
'javelin-dom',
|
|
|
|
),
|
2017-07-21 17:08:24 +02:00
|
|
|
'e83d28f3' => array(
|
|
|
|
'javelin-dom',
|
|
|
|
),
|
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
|
|
|
),
|
2018-04-08 18:10:03 +02:00
|
|
|
'e9c95dd4' => array(
|
|
|
|
'syntax-default-css',
|
|
|
|
),
|
2017-10-09 19:52:27 +02:00
|
|
|
'ec1f3669' => 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',
|
|
|
|
),
|
Fix a hang in fancy date picker for Ye Olde Time Years
Summary:
Fixes T12960. When the user enters a date like "1917", we currently loop ~20 million times.
Instead:
- Be a little more careful about parsing.
- Javascript's default behavior of interpreting "2001-02-31" as "2001-03-03" ("February 31" -> "March 3") already seems reasonable, so just let it do that.
Test Plan:
Verified these behaviors:
- `2017-08-08` - Valid, recent.
- `17-08-08` - Valid, recent.
- `1917-08-08` - Valid, a century ago, no loop.
- `2017-02-31` - "February 31", interpreted as "March 3" by Javascsript, seems reasonable.
- `Quack` - Default, current time.
- `0/0/0`, `0/99/0` - Default, current time.
Reviewers: avivey, chad
Reviewed By: chad
Maniphest Tasks: T12960
Differential Revision: https://secure.phabricator.com/D18383
2017-08-10 12:31:20 +02:00
|
|
|
'ecf4e799' => array(
|
|
|
|
'javelin-behavior',
|
|
|
|
'javelin-util',
|
|
|
|
'javelin-dom',
|
|
|
|
'javelin-stratcom',
|
|
|
|
'javelin-vector',
|
|
|
|
),
|
2015-06-23 22:43:47 +02:00
|
|
|
'edf8a145' => array(
|
|
|
|
'javelin-behavior',
|
|
|
|
'javelin-uri',
|
|
|
|
),
|
2018-11-24 15:59:19 +01:00
|
|
|
'ef7e057f' => array(
|
|
|
|
'javelin-install',
|
|
|
|
),
|
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
|
|
|
),
|
2015-10-07 16:32:27 +02:00
|
|
|
'f01586dc' => array(
|
|
|
|
'javelin-behavior',
|
|
|
|
'javelin-dom',
|
|
|
|
'javelin-util',
|
|
|
|
'javelin-workflow',
|
|
|
|
'javelin-json',
|
|
|
|
),
|
In Differential standalone views, disable some keyboard shortcuts which don't work
Summary:
Ref T13164. See PHI693. In Differential, you can {nav View Options > View Standalone} to get a standalone view of a single changeset. You can also arrive here via the big changeset list for revisions affecting a huge number of files.
We currently suggest that all the keyboard shortcuts work, but some do not. In particular, the "Next File" and "Previous File" keyboard shortcuts (and some similar shortcuts) do not work. In the main view, the next/previous files are on the same page. In the standalone view, we'd need to actually change the URI.
Ideally, we should do this (and, e.g., put prev/next links on the page). As a first step toward that, hide the nonfunctional shortcuts to stop users from being misled.
Test Plan:
- Viewed a revision in normal and standalone views.
- No changes in normal view, and all keys still work ("N", "P", etc).
- In standalone view, "?" no longer shows nonfunctional key commands.
Reviewers: amckinley
Reviewed By: amckinley
Maniphest Tasks: T13164
Differential Revision: https://secure.phabricator.com/D19571
2018-08-13 17:21:16 +02:00
|
|
|
'f0eb6708' => array(
|
|
|
|
'javelin-behavior',
|
|
|
|
'javelin-dom',
|
|
|
|
'javelin-stratcom',
|
|
|
|
'phabricator-tooltip',
|
|
|
|
'phabricator-diff-changeset-list',
|
|
|
|
'phabricator-diff-changeset',
|
2018-06-07 18:43:59 +02:00
|
|
|
),
|
2017-07-19 23:38:55 +02:00
|
|
|
'f1ff5494' => array(
|
|
|
|
'phui-button-css',
|
|
|
|
'phui-button-simple-css',
|
|
|
|
),
|
2016-12-02 20:00:37 +01:00
|
|
|
'f50152ad' => array(
|
|
|
|
'phui-timeline-view-css',
|
|
|
|
),
|
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
|
|
|
),
|
2015-01-14 01:10:57 +01:00
|
|
|
'f829edb3' => array(
|
|
|
|
'javelin-view',
|
|
|
|
'javelin-install',
|
|
|
|
'javelin-dom',
|
2017-05-20 13:10:32 +02:00
|
|
|
),
|
2014-12-30 11:53:27 +01:00
|
|
|
'fc91ab6c' => array(
|
|
|
|
'javelin-behavior',
|
|
|
|
'javelin-dom',
|
|
|
|
'phortune-credit-card-form',
|
|
|
|
),
|
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-01-01 03:04:25 +01:00
|
|
|
),
|
2014-07-14 17:33:33 +02:00
|
|
|
'packages' => array(
|
2016-09-13 00:22:04 +02:00
|
|
|
'conpherence.pkg.css' => array(
|
|
|
|
'conpherence-durable-column-view',
|
|
|
|
'conpherence-menu-css',
|
2017-04-20 23:23:23 +02:00
|
|
|
'conpherence-color-css',
|
2016-09-13 00:22:04 +02:00
|
|
|
'conpherence-message-pane-css',
|
|
|
|
'conpherence-notification-css',
|
|
|
|
'conpherence-transaction-css',
|
2016-09-15 22:21:21 +02:00
|
|
|
'conpherence-participant-pane-css',
|
2016-09-15 03:34:11 +02:00
|
|
|
'conpherence-header-pane-css',
|
2016-09-13 00:22:04 +02:00
|
|
|
),
|
2016-09-15 05:05:14 +02:00
|
|
|
'conpherence.pkg.js' => array(
|
|
|
|
'javelin-behavior-conpherence-menu',
|
2016-09-15 22:21:21 +02:00
|
|
|
'javelin-behavior-conpherence-participant-pane',
|
2016-09-15 05:05:14 +02:00
|
|
|
'javelin-behavior-conpherence-pontificate',
|
|
|
|
'javelin-behavior-toggle-widget',
|
|
|
|
),
|
2014-07-14 17:33:33 +02:00
|
|
|
'core.pkg.css' => array(
|
2014-07-23 19:34:08 +02:00
|
|
|
'phabricator-core-css',
|
|
|
|
'phabricator-zindex-css',
|
|
|
|
'phui-button-css',
|
2017-06-01 22:30:00 +02:00
|
|
|
'phui-button-simple-css',
|
2016-09-03 22:37:48 +02:00
|
|
|
'phui-theme-css',
|
2014-07-23 19:34:08 +02:00
|
|
|
'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',
|
2016-09-30 23:55:04 +02:00
|
|
|
'application-search-view-css',
|
2014-07-23 19:34:08 +02:00
|
|
|
'phabricator-remarkup-css',
|
|
|
|
'syntax-highlighting-css',
|
2016-05-05 03:24:59 +02:00
|
|
|
'syntax-default-css',
|
2015-06-02 23:34:04 +02:00
|
|
|
'phui-pager-css',
|
2014-07-23 19:34:08 +02:00
|
|
|
'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
|
|
|
'phabricator-main-menu-view',
|
|
|
|
'phabricator-notification-css',
|
|
|
|
'phabricator-notification-menu-css',
|
2016-11-18 22:23:41 +01:00
|
|
|
'phui-lightbox-css',
|
|
|
|
'phui-comment-panel-css',
|
2014-07-23 19:34:08 +02:00
|
|
|
'phui-header-view-css',
|
|
|
|
'phabricator-nav-view-css',
|
2016-08-01 21:06:35 +02:00
|
|
|
'phui-basic-nav-view-css',
|
2015-01-23 22:30:00 +01:00
|
|
|
'phui-crumbs-view-css',
|
2016-12-14 20:35:51 +01:00
|
|
|
'phui-oi-list-view-css',
|
|
|
|
'phui-oi-color-css',
|
|
|
|
'phui-oi-big-ui-css',
|
|
|
|
'phui-oi-drag-ui-css',
|
|
|
|
'phui-oi-simple-ui-css',
|
|
|
|
'phui-oi-flush-ui-css',
|
2014-07-23 19:34:08 +02:00
|
|
|
'global-drag-and-drop-css',
|
|
|
|
'phui-spacing-css',
|
|
|
|
'phui-form-css',
|
|
|
|
'phui-icon-view-css',
|
|
|
|
'phabricator-action-list-view-css',
|
|
|
|
'phui-property-list-view-css',
|
|
|
|
'phui-tag-view-css',
|
|
|
|
'phui-list-view-css',
|
|
|
|
'font-fontawesome',
|
2016-09-03 22:37:48 +02:00
|
|
|
'font-lato',
|
2014-07-23 19:34:08 +02:00
|
|
|
'phui-font-icon-base-css',
|
2016-09-03 22:37:48 +02:00
|
|
|
'phui-fontkit-css',
|
2014-07-23 19:34:08 +02:00
|
|
|
'phui-box-css',
|
|
|
|
'phui-object-box-css',
|
|
|
|
'phui-timeline-view-css',
|
2016-09-03 22:37:48 +02:00
|
|
|
'phui-two-column-view-css',
|
|
|
|
'phui-curtain-view-css',
|
|
|
|
'sprite-login-css',
|
2014-07-23 19:34:08 +02:00
|
|
|
'sprite-tokens-css',
|
|
|
|
'tokens-css',
|
2016-09-03 22:37:48 +02:00
|
|
|
'auth-css',
|
2014-07-23 19:34:08 +02:00
|
|
|
'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',
|
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',
|
2016-09-03 22:37:48 +02:00
|
|
|
'phuix-icon-view',
|
2014-07-23 19:34:08 +02:00
|
|
|
'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',
|
2017-04-18 18:26:21 +02:00
|
|
|
'javelin-sound',
|
2014-07-23 19:34:08 +02:00
|
|
|
'javelin-aphlict',
|
|
|
|
'phabricator-notification',
|
|
|
|
'javelin-behavior-aphlict-listen',
|
|
|
|
'javelin-behavior-phabricator-search-typeahead',
|
|
|
|
'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',
|
2016-02-03 17:26:30 +01:00
|
|
|
'phui-hovercard',
|
|
|
|
'javelin-behavior-phui-hovercards',
|
2014-07-23 19:34:08 +02:00
|
|
|
'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',
|
2015-05-19 21:14:44 +02:00
|
|
|
'javelin-behavior-phui-dropdown-menu',
|
2014-07-23 19:34:08 +02:00
|
|
|
'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',
|
2015-05-03 16:51:00 +02:00
|
|
|
'javelin-quicksand',
|
|
|
|
'javelin-behavior-quicksand-blacklist',
|
|
|
|
'javelin-behavior-high-security-warning',
|
2016-04-09 14:41:08 +02:00
|
|
|
'javelin-behavior-read-only-warning',
|
2015-05-03 16:51:00 +02:00
|
|
|
'javelin-scrollbar',
|
|
|
|
'javelin-behavior-scrollbar',
|
|
|
|
'javelin-behavior-durable-column',
|
|
|
|
'conpherence-thread-manager',
|
2016-05-21 22:27:56 +02:00
|
|
|
'javelin-behavior-detect-timezone',
|
2016-06-07 00:01:18 +02:00
|
|
|
'javelin-behavior-setup-check-https',
|
2017-01-18 14:56:41 +01:00
|
|
|
'javelin-behavior-aphlict-status',
|
|
|
|
'javelin-behavior-user-menu',
|
|
|
|
'phabricator-favicon',
|
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-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',
|
2015-05-03 16:51:00 +02:00
|
|
|
'phui-inline-comment-view-css',
|
2016-09-30 23:55:04 +02:00
|
|
|
'phabricator-filetree-view-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-populate',
|
|
|
|
'javelin-behavior-differential-diff-radios',
|
|
|
|
'javelin-behavior-aphront-drag-and-drop-textarea',
|
|
|
|
'javelin-behavior-phabricator-object-selector',
|
|
|
|
'javelin-behavior-repository-crossreference',
|
|
|
|
'javelin-behavior-differential-user-select',
|
|
|
|
'javelin-behavior-aphront-more',
|
2017-05-16 01:35:06 +02:00
|
|
|
'phabricator-diff-inline',
|
2017-05-08 18:52:16 +02:00
|
|
|
'phabricator-diff-changeset',
|
|
|
|
'phabricator-diff-changeset-list',
|
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-subpriority-editor',
|
|
|
|
'javelin-behavior-maniphest-list-editor',
|
2014-01-01 03:04:25 +01:00
|
|
|
),
|
|
|
|
),
|
|
|
|
);
|