1
0
Fork 0
mirror of https://we.phorge.it/source/phorge.git synced 2024-11-14 10:52:41 +01:00
phorge-phorge/resources/celerity/map.php

2149 lines
77 KiB
PHP
Raw Normal View History

<?php
/**
* This file is automatically generated. Use 'bin/celerity map' to rebuild it.
*
* @generated
*/
return array(
'names' => array(
'core.pkg.css' => 'c7059fd9',
'core.pkg.js' => 'eb8d4f82',
'darkconsole.pkg.js' => 'df001cab',
'differential.pkg.css' => '4a93db37',
Give files uploaded to objects a very restrictive view policy Summary: Fixes T4589. This implements much better policy behavior for files that aligns with user expectations. Currently, all files have permissive visibility. The new behavior is: - Files uploaded via drag-and-drop to the home page or file upload page get permissive visibility, for ease of quickly sharing things like screenshots. - Files uploaded via the manual file upload control get permissive visibility by default, but the user can select the policy they want at upload time in an explicit/obvious way. - Files uploaded via drag-and-drop anywhere else (e.g., comments or Pholio) get restricted visibility (only the uploader). - When the user applies a transaction to the object which uses the file, we attach the file to the object and punch a hole through the policies: if you can see the object, you can see the file. - This rule requires things to use ApplicationTransactions, which is why this took so long to fix. - The "attach stuff to the object" code has been in place for a long time and works correctly. I'll land D8498 after this lands, too. Test Plan: - Uploaded via global homepage upload and file drag-and-drop upload, saw permissive visibility. - Uploaded via comment area, saw restricted visibility. - After commenting, verified links were established and the file became visible to users who could see the attached object. - Verified Pholio (which is a bit of a special case) correctly attaches images. Reviewers: btrahan Reviewed By: btrahan Subscribers: epriestley Maniphest Tasks: T4589 Differential Revision: https://secure.phabricator.com/D10131
2014-08-02 23:46:13 +02:00
'differential.pkg.js' => 'eb182ccd',
'diffusion.pkg.css' => '591664fa',
'diffusion.pkg.js' => 'bfc0737b',
'maniphest.pkg.css' => 'f5d89daf',
'maniphest.pkg.js' => 'df4aa49f',
'rsrc/css/aphront/aphront-bars.css' => '231ac33c',
'rsrc/css/aphront/context-bar.css' => '1c3b0529',
'rsrc/css/aphront/dark-console.css' => '6378ef3d',
'rsrc/css/aphront/dialog-view.css' => '4dbbe3bb',
'rsrc/css/aphront/error-view.css' => '3462dbee',
'rsrc/css/aphront/lightbox-attachment.css' => '7acac05d',
'rsrc/css/aphront/list-filter-view.css' => '2ae43867',
'rsrc/css/aphront/multi-column.css' => '1b95ab2e',
'rsrc/css/aphront/notification.css' => 'ef2c9b34',
'rsrc/css/aphront/pager-view.css' => '2e3539af',
'rsrc/css/aphront/panel-view.css' => '5846dfa2',
'rsrc/css/aphront/phabricator-nav-view.css' => '9283c2df',
'rsrc/css/aphront/request-failure-view.css' => '7a83dc3a',
'rsrc/css/aphront/table-view.css' => 'b22b7216',
'rsrc/css/aphront/tokenizer.css' => '82ce2142',
'rsrc/css/aphront/tooltip.css' => '9c90229d',
'rsrc/css/aphront/transaction.css' => '5d0cae25',
'rsrc/css/aphront/two-column.css' => '16ab3ad2',
'rsrc/css/aphront/typeahead.css' => 'a989b5b3',
'rsrc/css/application/auth/auth.css' => '1e655982',
'rsrc/css/application/base/main-menu-view.css' => 'aceca0e9',
'rsrc/css/application/base/notification-menu.css' => '8ae4a008',
'rsrc/css/application/base/phabricator-application-launch-view.css' => '8b7e271d',
'rsrc/css/application/base/standard-page-view.css' => '517cdfb1',
'rsrc/css/application/chatlog/chatlog.css' => '852140ff',
'rsrc/css/application/config/config-options.css' => '7fedf08b',
'rsrc/css/application/config/config-template.css' => '25d446d6',
'rsrc/css/application/config/config-welcome.css' => 'b0d16200',
'rsrc/css/application/config/setup-issue.css' => '69e640e7',
'rsrc/css/application/conpherence/menu.css' => 'e1e0fdf1',
'rsrc/css/application/conpherence/message-pane.css' => '11a393ca',
'rsrc/css/application/conpherence/notification.css' => '04a6e10a',
'rsrc/css/application/conpherence/update.css' => '1099a660',
'rsrc/css/application/conpherence/widget-pane.css' => 'bf275a6c',
'rsrc/css/application/contentsource/content-source-view.css' => '4b8b05d4',
'rsrc/css/application/countdown/timer.css' => '86b7b0a0',
'rsrc/css/application/dashboard/dashboard.css' => 'a2bfdcbf',
'rsrc/css/application/diff/inline-comment-summary.css' => '8cfd34e8',
'rsrc/css/application/differential/add-comment.css' => 'c478bcaa',
'rsrc/css/application/differential/changeset-view.css' => 'ff8eacf8',
'rsrc/css/application/differential/core.css' => '7ac3cabc',
'rsrc/css/application/differential/results-table.css' => '239924f9',
'rsrc/css/application/differential/revision-comment.css' => '48186045',
2014-03-12 21:53:04 +01:00
'rsrc/css/application/differential/revision-history.css' => '0e8eb855',
'rsrc/css/application/differential/revision-list.css' => 'f3c47d33',
'rsrc/css/application/differential/table-of-contents.css' => '6bf8e1d2',
'rsrc/css/application/diffusion/diffusion-icons.css' => '9c5828da',
'rsrc/css/application/diffusion/diffusion-source.css' => '66fdf661',
'rsrc/css/application/feed/feed.css' => '4e544db4',
'rsrc/css/application/files/global-drag-and-drop.css' => '697324ad',
'rsrc/css/application/flag/flag.css' => '5337623f',
'rsrc/css/application/harbormaster/harbormaster.css' => '49d64eb4',
'rsrc/css/application/herald/herald-test.css' => '778b008e',
'rsrc/css/application/herald/herald.css' => 'c544dd1c',
'rsrc/css/application/maniphest/batch-editor.css' => '8f380ebc',
'rsrc/css/application/maniphest/report.css' => '6fc16517',
'rsrc/css/application/maniphest/task-edit.css' => '8e23031b',
'rsrc/css/application/maniphest/task-summary.css' => '00c3be7a',
'rsrc/css/application/objectselector/object-selector.css' => '029a133d',
'rsrc/css/application/owners/owners-path-editor.css' => '2f00933b',
'rsrc/css/application/paste/paste.css' => 'aa1767d1',
'rsrc/css/application/people/people-profile.css' => '5402f7a5',
'rsrc/css/application/phame/phame.css' => '19ecc703',
'rsrc/css/application/pholio/pholio-edit.css' => '3ad9d1ee',
'rsrc/css/application/pholio/pholio-inline-comments.css' => '8e545e49',
'rsrc/css/application/pholio/pholio.css' => '47dffb9c',
'rsrc/css/application/phortune/phortune-credit-card-form.css' => 'b25b4beb',
'rsrc/css/application/phortune/phortune.css' => '9149f103',
'rsrc/css/application/phrequent/phrequent.css' => 'ffc185ad',
'rsrc/css/application/phriction/phriction-document-css.css' => '7d7f0071',
'rsrc/css/application/policy/policy-edit.css' => '05cca26a',
'rsrc/css/application/policy/policy-transaction-detail.css' => '82100a43',
'rsrc/css/application/policy/policy.css' => '957ea14c',
'rsrc/css/application/ponder/comments.css' => '6cdccea7',
'rsrc/css/application/ponder/feed.css' => 'e62615b6',
'rsrc/css/application/ponder/post.css' => 'ebab8a70',
'rsrc/css/application/ponder/vote.css' => '8ed6ed8b',
'rsrc/css/application/profile/profile-view.css' => 'b459416e',
'rsrc/css/application/projects/project-icon.css' => 'c2ecb7f1',
'rsrc/css/application/releeph/releeph-core.css' => '9b3c5733',
'rsrc/css/application/releeph/releeph-preview-branch.css' => 'b7a6f4a5',
'rsrc/css/application/releeph/releeph-request-differential-create-dialog.css' => '8d8b92cd',
'rsrc/css/application/releeph/releeph-request-typeahead.css' => '667a48ae',
'rsrc/css/application/search/search-results.css' => 'f240504c',
'rsrc/css/application/slowvote/slowvote.css' => '266df6a1',
'rsrc/css/application/tokens/tokens.css' => '3d0f239e',
'rsrc/css/application/uiexample/example.css' => '528b19de',
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/css/core/core.css' => '40151074',
'rsrc/css/core/remarkup.css' => '7fd5585f',
'rsrc/css/core/syntax.css' => '863f3cd8',
'rsrc/css/core/z-index.css' => 'd1c137f2',
'rsrc/css/diviner/diviner-shared.css' => '38813222',
2014-05-16 18:28:01 +02:00
'rsrc/css/font/font-awesome.css' => '73d075c3',
'rsrc/css/font/font-source-sans-pro.css' => '91d53463',
'rsrc/css/font/phui-font-icon-base.css' => 'eb84f033',
'rsrc/css/layout/phabricator-action-header-view.css' => '83e2cc86',
'rsrc/css/layout/phabricator-crumbs-view.css' => '7fbf25b8',
'rsrc/css/layout/phabricator-filetree-view.css' => 'fccf9f82',
'rsrc/css/layout/phabricator-hovercard-view.css' => '893f4783',
'rsrc/css/layout/phabricator-side-menu-view.css' => 'a2ccd7bd',
'rsrc/css/layout/phabricator-source-code-view.css' => '7d346aa4',
'rsrc/css/phui/calendar/phui-calendar-day.css' => 'de035c8a',
'rsrc/css/phui/calendar/phui-calendar-list.css' => 'c1d0ca59',
'rsrc/css/phui/calendar/phui-calendar-month.css' => 'a92e47d2',
'rsrc/css/phui/calendar/phui-calendar.css' => '5e1ad989',
'rsrc/css/phui/phui-action-list.css' => '9ee9910a',
'rsrc/css/phui/phui-box.css' => '7b3a2eed',
'rsrc/css/phui/phui-button.css' => 'c7412aa1',
'rsrc/css/phui/phui-document.css' => 'a5615198',
'rsrc/css/phui/phui-feed-story.css' => 'e2c9bc83',
'rsrc/css/phui/phui-fontkit.css' => 'fff25cfa',
'rsrc/css/phui/phui-form-view.css' => 'ebac1b1d',
'rsrc/css/phui/phui-form.css' => 'b78ec020',
'rsrc/css/phui/phui-header-view.css' => '39594ac0',
'rsrc/css/phui/phui-icon.css' => 'd8526aa1',
'rsrc/css/phui/phui-image-mask.css' => '5a8b09c8',
'rsrc/css/phui/phui-info-panel.css' => '27ea50a1',
'rsrc/css/phui/phui-list.css' => '43ed2d93',
'rsrc/css/phui/phui-object-box.css' => 'e9f7e938',
'rsrc/css/phui/phui-object-item-list-view.css' => 'e1e6425f',
'rsrc/css/phui/phui-pinboard-view.css' => '3dd4a269',
'rsrc/css/phui/phui-property-list-view.css' => '86f9df88',
'rsrc/css/phui/phui-remarkup-preview.css' => '19ad512b',
'rsrc/css/phui/phui-spacing.css' => '042804d6',
'rsrc/css/phui/phui-status.css' => '2f562399',
'rsrc/css/phui/phui-tag-view.css' => 'c4158073',
'rsrc/css/phui/phui-text.css' => '23e9b4b7',
'rsrc/css/phui/phui-timeline-view.css' => 'bbd990d0',
'rsrc/css/phui/phui-workboard-view.css' => '2bf82d00',
'rsrc/css/phui/phui-workpanel-view.css' => 'e26044fa',
'rsrc/css/sprite-apps-large.css' => '12ea1ced',
'rsrc/css/sprite-apps.css' => '37ee4f4e',
'rsrc/css/sprite-conpherence.css' => '3b4a0487',
'rsrc/css/sprite-docs.css' => '5f65d0da',
'rsrc/css/sprite-gradient.css' => '4bdb98a7',
'rsrc/css/sprite-login.css' => '878ee4d8',
'rsrc/css/sprite-main-header.css' => '92720ee2',
'rsrc/css/sprite-menu.css' => '28281e16',
'rsrc/css/sprite-minicons.css' => 'df4f76fe',
'rsrc/css/sprite-payments.css' => 'cc085d44',
'rsrc/css/sprite-projects.css' => '7578fa56',
'rsrc/css/sprite-tokens.css' => '1706b943',
'rsrc/externals/font/fontawesome/fontawesome-webfont.eot' => '1cab0752',
'rsrc/externals/font/fontawesome/fontawesome-webfont.ttf' => '2ff84fd2',
'rsrc/externals/font/fontawesome/fontawesome-webfont.woff' => 'a119ee5e',
'rsrc/externals/font/sourcesans/SourceSansPro.woff' => '3614608c',
'rsrc/externals/font/sourcesans/SourceSansProBold.woff' => 'cbf46566',
Introduce CAN_EDIT for ExternalAccount, and make CAN_VIEW more liberal Summary: Fixes T3732. Ref T1205. Ref T3116. External accounts (like emails used as identities, Facebook accounts, LDAP accounts, etc.) are stored in "ExternalAccount" objects. Currently, we have a very restrictive `CAN_VIEW` policy for ExternalAccounts, to add an extra layer of protection to make sure users can't use them in unintended ways. For example, it would be bad if a user could link their Phabricator account to a Facebook account without proper authentication. All of the controllers which do sensitive things have checks anyway, but a restrictive CAN_VIEW provided an extra layer of protection. Se T3116 for some discussion. However, this means that when grey/external users take actions (via email, or via applications like Legalpad) other users can't load the account handles and can't see anything about the actor (they just see "Restricted External Account" or similar). Balancing these concerns is mostly about not making a huge mess while doing it. This seems like a reasonable approach: - Add `CAN_EDIT` on these objects. - Make that very restricted, but open up `CAN_VIEW`. - Require `CAN_EDIT` any time we're going to do something authentication/identity related. This is slightly easier to get wrong (forget CAN_EDIT) than other approaches, but pretty simple, and we always have extra checks in place anyway -- this is just a safety net. I'm not quite sure how we should identify external accounts, so for now we're just rendering "Email User" or similar -- clearly not a bug, but not identifying. We can figure out what to render in the long term elsewhere. Test Plan: - Viewed external accounts. - Linked an external account. - Refreshed an external account. - Edited profile picture. - Viewed sessions panel. - Published a bunch of stuff to Asana/JIRA. - Legalpad signature page now shows external accounts. {F171595} Reviewers: chad, btrahan Reviewed By: btrahan Subscribers: epriestley Maniphest Tasks: T3732, T1205, T3116 Differential Revision: https://secure.phabricator.com/D9767
2014-07-10 19:18:10 +02:00
'rsrc/externals/javelin/core/Event.js' => '85ea0626',
'rsrc/externals/javelin/core/Stratcom.js' => '8b0ad945',
'rsrc/externals/javelin/core/__tests__/event-stop-and-kill.js' => '717554e4',
'rsrc/externals/javelin/core/__tests__/install.js' => 'c432ee85',
'rsrc/externals/javelin/core/__tests__/stratcom.js' => 'da194d4b',
'rsrc/externals/javelin/core/__tests__/util.js' => 'd3b157a9',
'rsrc/externals/javelin/core/init.js' => 'b88ab49e',
'rsrc/externals/javelin/core/init_node.js' => 'd7dde471',
Introduce CAN_EDIT for ExternalAccount, and make CAN_VIEW more liberal Summary: Fixes T3732. Ref T1205. Ref T3116. External accounts (like emails used as identities, Facebook accounts, LDAP accounts, etc.) are stored in "ExternalAccount" objects. Currently, we have a very restrictive `CAN_VIEW` policy for ExternalAccounts, to add an extra layer of protection to make sure users can't use them in unintended ways. For example, it would be bad if a user could link their Phabricator account to a Facebook account without proper authentication. All of the controllers which do sensitive things have checks anyway, but a restrictive CAN_VIEW provided an extra layer of protection. Se T3116 for some discussion. However, this means that when grey/external users take actions (via email, or via applications like Legalpad) other users can't load the account handles and can't see anything about the actor (they just see "Restricted External Account" or similar). Balancing these concerns is mostly about not making a huge mess while doing it. This seems like a reasonable approach: - Add `CAN_EDIT` on these objects. - Make that very restricted, but open up `CAN_VIEW`. - Require `CAN_EDIT` any time we're going to do something authentication/identity related. This is slightly easier to get wrong (forget CAN_EDIT) than other approaches, but pretty simple, and we always have extra checks in place anyway -- this is just a safety net. I'm not quite sure how we should identify external accounts, so for now we're just rendering "Email User" or similar -- clearly not a bug, but not identifying. We can figure out what to render in the long term elsewhere. Test Plan: - Viewed external accounts. - Linked an external account. - Refreshed an external account. - Edited profile picture. - Viewed sessions panel. - Published a bunch of stuff to Asana/JIRA. - Legalpad signature page now shows external accounts. {F171595} Reviewers: chad, btrahan Reviewed By: btrahan Subscribers: epriestley Maniphest Tasks: T3732, T1205, T3116 Differential Revision: https://secure.phabricator.com/D9767
2014-07-10 19:18:10 +02:00
'rsrc/externals/javelin/core/install.js' => '1ffb3a9c',
'rsrc/externals/javelin/core/util.js' => 'e7995242',
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',
'rsrc/externals/javelin/ext/fx/Color.js' => '7e41274a',
'rsrc/externals/javelin/ext/fx/FX.js' => '54b612ba',
'rsrc/externals/javelin/ext/reactor/core/DynVal.js' => 'f6555212',
'rsrc/externals/javelin/ext/reactor/core/Reactor.js' => '77b1cf6f',
'rsrc/externals/javelin/ext/reactor/core/ReactorNode.js' => 'b4c30592',
'rsrc/externals/javelin/ext/reactor/core/ReactorNodeCalmer.js' => '76f4ebed',
'rsrc/externals/javelin/ext/reactor/dom/RDOM.js' => 'b6d401d6',
'rsrc/externals/javelin/ext/view/HTMLView.js' => 'e5b406f9',
'rsrc/externals/javelin/ext/view/View.js' => '0f764c35',
'rsrc/externals/javelin/ext/view/ViewInterpreter.js' => '0c33c1a0',
'rsrc/externals/javelin/ext/view/ViewPlaceholder.js' => '2fa810fc',
'rsrc/externals/javelin/ext/view/ViewRenderer.js' => '6c2b09a2',
'rsrc/externals/javelin/ext/view/ViewVisitor.js' => 'efe49472',
'rsrc/externals/javelin/ext/view/__tests__/HTMLView.js' => 'f92d7bcb',
'rsrc/externals/javelin/ext/view/__tests__/View.js' => 'bda69c40',
'rsrc/externals/javelin/ext/view/__tests__/ViewInterpreter.js' => '7a94d6a5',
'rsrc/externals/javelin/ext/view/__tests__/ViewRenderer.js' => '5426001c',
'rsrc/externals/javelin/lib/Cookie.js' => '6b3dcf44',
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/DOM.js' => 'c4569c05',
'rsrc/externals/javelin/lib/History.js' => 'c60f4327',
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',
'rsrc/externals/javelin/lib/Mask.js' => '8a41885b',
'rsrc/externals/javelin/lib/Request.js' => '97258e55',
'rsrc/externals/javelin/lib/Resource.js' => '0f81f8df',
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',
Introduce CAN_EDIT for ExternalAccount, and make CAN_VIEW more liberal Summary: Fixes T3732. Ref T1205. Ref T3116. External accounts (like emails used as identities, Facebook accounts, LDAP accounts, etc.) are stored in "ExternalAccount" objects. Currently, we have a very restrictive `CAN_VIEW` policy for ExternalAccounts, to add an extra layer of protection to make sure users can't use them in unintended ways. For example, it would be bad if a user could link their Phabricator account to a Facebook account without proper authentication. All of the controllers which do sensitive things have checks anyway, but a restrictive CAN_VIEW provided an extra layer of protection. Se T3116 for some discussion. However, this means that when grey/external users take actions (via email, or via applications like Legalpad) other users can't load the account handles and can't see anything about the actor (they just see "Restricted External Account" or similar). Balancing these concerns is mostly about not making a huge mess while doing it. This seems like a reasonable approach: - Add `CAN_EDIT` on these objects. - Make that very restricted, but open up `CAN_VIEW`. - Require `CAN_EDIT` any time we're going to do something authentication/identity related. This is slightly easier to get wrong (forget CAN_EDIT) than other approaches, but pretty simple, and we always have extra checks in place anyway -- this is just a safety net. I'm not quite sure how we should identify external accounts, so for now we're just rendering "Email User" or similar -- clearly not a bug, but not identifying. We can figure out what to render in the long term elsewhere. Test Plan: - Viewed external accounts. - Linked an external account. - Refreshed an external account. - Edited profile picture. - Viewed sessions panel. - Published a bunch of stuff to Asana/JIRA. - Legalpad signature page now shows external accounts. {F171595} Reviewers: chad, btrahan Reviewed By: btrahan Subscribers: epriestley Maniphest Tasks: T3732, T1205, T3116 Differential Revision: https://secure.phabricator.com/D9767
2014-07-10 19:18:10 +02:00
'rsrc/externals/javelin/lib/URI.js' => '6eff08aa',
'rsrc/externals/javelin/lib/Vector.js' => '23cbb8ac',
'rsrc/externals/javelin/lib/Workflow.js' => 'd149e002',
'rsrc/externals/javelin/lib/__tests__/Cookie.js' => '5ed109e8',
'rsrc/externals/javelin/lib/__tests__/DOM.js' => 'c984504b',
'rsrc/externals/javelin/lib/__tests__/JSON.js' => '2295d074',
'rsrc/externals/javelin/lib/__tests__/URI.js' => '003ed329',
'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',
'rsrc/externals/javelin/lib/control/tokenizer/Tokenizer.js' => 'a5b67173',
'rsrc/externals/javelin/lib/control/typeahead/Typeahead.js' => 'e614d22b',
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/normalizer/TypeaheadNormalizer.js' => 'aa93c7b0',
'rsrc/externals/javelin/lib/control/typeahead/source/TypeaheadCompositeSource.js' => '503e17fd',
'rsrc/externals/javelin/lib/control/typeahead/source/TypeaheadOnDemandSource.js' => '8b3fd187',
'rsrc/externals/javelin/lib/control/typeahead/source/TypeaheadPreloadedSource.js' => '54f314a0',
'rsrc/externals/javelin/lib/control/typeahead/source/TypeaheadSource.js' => 'fcba4ecc',
Introduce CAN_EDIT for ExternalAccount, and make CAN_VIEW more liberal Summary: Fixes T3732. Ref T1205. Ref T3116. External accounts (like emails used as identities, Facebook accounts, LDAP accounts, etc.) are stored in "ExternalAccount" objects. Currently, we have a very restrictive `CAN_VIEW` policy for ExternalAccounts, to add an extra layer of protection to make sure users can't use them in unintended ways. For example, it would be bad if a user could link their Phabricator account to a Facebook account without proper authentication. All of the controllers which do sensitive things have checks anyway, but a restrictive CAN_VIEW provided an extra layer of protection. Se T3116 for some discussion. However, this means that when grey/external users take actions (via email, or via applications like Legalpad) other users can't load the account handles and can't see anything about the actor (they just see "Restricted External Account" or similar). Balancing these concerns is mostly about not making a huge mess while doing it. This seems like a reasonable approach: - Add `CAN_EDIT` on these objects. - Make that very restricted, but open up `CAN_VIEW`. - Require `CAN_EDIT` any time we're going to do something authentication/identity related. This is slightly easier to get wrong (forget CAN_EDIT) than other approaches, but pretty simple, and we always have extra checks in place anyway -- this is just a safety net. I'm not quite sure how we should identify external accounts, so for now we're just rendering "Email User" or similar -- clearly not a bug, but not identifying. We can figure out what to render in the long term elsewhere. Test Plan: - Viewed external accounts. - Linked an external account. - Refreshed an external account. - Edited profile picture. - Viewed sessions panel. - Published a bunch of stuff to Asana/JIRA. - Legalpad signature page now shows external accounts. {F171595} Reviewers: chad, btrahan Reviewed By: btrahan Subscribers: epriestley Maniphest Tasks: T3732, T1205, T3116 Differential Revision: https://secure.phabricator.com/D9767
2014-07-10 19:18:10 +02:00
'rsrc/externals/javelin/lib/control/typeahead/source/TypeaheadStaticSource.js' => '316b8fa1',
'rsrc/externals/raphael/g.raphael.js' => '40dde778',
'rsrc/externals/raphael/g.raphael.line.js' => '40da039e',
'rsrc/externals/raphael/raphael.js' => '51ee6b43',
'rsrc/image/BFCFDA.png' => 'd5ec91f4',
'rsrc/image/actions/edit.png' => '2fc41442',
'rsrc/image/apple-touch-icon.png' => '8458dda7',
'rsrc/image/avatar.png' => '3eb28cd9',
'rsrc/image/checker_dark.png' => 'd8e65881',
'rsrc/image/checker_light.png' => 'a0155918',
'rsrc/image/checker_lighter.png' => 'd5da91b6',
'rsrc/image/credit_cards.png' => '72b8ede8',
'rsrc/image/darkload.gif' => '1ffd3ec6',
'rsrc/image/divot.png' => '94dded62',
'rsrc/image/examples/hero.png' => '979a86ae',
'rsrc/image/grippy_texture.png' => 'aca81e2f',
'rsrc/image/icon/fatcow/arrow_branch.png' => '2537c01c',
'rsrc/image/icon/fatcow/arrow_merge.png' => '21b660e0',
'rsrc/image/icon/fatcow/bullet_black.png' => 'ff190031',
'rsrc/image/icon/fatcow/bullet_orange.png' => 'e273e5bb',
'rsrc/image/icon/fatcow/bullet_red.png' => 'c0b75434',
'rsrc/image/icon/fatcow/calendar_edit.png' => '24632275',
'rsrc/image/icon/fatcow/document_black.png' => '45fe1c60',
'rsrc/image/icon/fatcow/flag_blue.png' => 'a01abb1d',
'rsrc/image/icon/fatcow/flag_finish.png' => '67825cee',
'rsrc/image/icon/fatcow/flag_ghost.png' => '20ca8783',
'rsrc/image/icon/fatcow/flag_green.png' => '7e0eaa7a',
'rsrc/image/icon/fatcow/flag_orange.png' => '9e73df66',
'rsrc/image/icon/fatcow/flag_pink.png' => '7e92f3b2',
'rsrc/image/icon/fatcow/flag_purple.png' => 'cc517522',
'rsrc/image/icon/fatcow/flag_red.png' => '04ec726f',
'rsrc/image/icon/fatcow/flag_yellow.png' => '73946fd4',
'rsrc/image/icon/fatcow/folder.png' => '95a435af',
'rsrc/image/icon/fatcow/folder_go.png' => '001cbc94',
'rsrc/image/icon/fatcow/key_question.png' => '52a0c26a',
'rsrc/image/icon/fatcow/link.png' => '7afd4d5e',
'rsrc/image/icon/fatcow/page_white_edit.png' => '39a2eed8',
'rsrc/image/icon/fatcow/page_white_link.png' => 'a90023c7',
'rsrc/image/icon/fatcow/page_white_put.png' => '08c95a0c',
'rsrc/image/icon/fatcow/page_white_text.png' => '1e1f79c3',
'rsrc/image/icon/fatcow/source/conduit.png' => '4ea01d2f',
'rsrc/image/icon/fatcow/source/email.png' => '9bab3239',
'rsrc/image/icon/fatcow/source/fax.png' => '04195e68',
'rsrc/image/icon/fatcow/source/mobile.png' => 'f1321264',
'rsrc/image/icon/fatcow/source/tablet.png' => '49396799',
'rsrc/image/icon/fatcow/source/web.png' => '136ccb5d',
'rsrc/image/icon/fatcow/thumbnails/default.p100.png' => '7d490b01',
'rsrc/image/icon/fatcow/thumbnails/default160x120.png' => 'f2e8a2eb',
'rsrc/image/icon/fatcow/thumbnails/default280x210.png' => '43e8926a',
'rsrc/image/icon/fatcow/thumbnails/default60x45.png' => '0118abed',
'rsrc/image/icon/fatcow/thumbnails/image.p100.png' => 'da23cf97',
'rsrc/image/icon/fatcow/thumbnails/image160x120.png' => '79bb556a',
'rsrc/image/icon/fatcow/thumbnails/image280x210.png' => '91ae054a',
'rsrc/image/icon/fatcow/thumbnails/image60x45.png' => 'c5e1685e',
'rsrc/image/icon/fatcow/thumbnails/pdf.p100.png' => '87d5e065',
'rsrc/image/icon/fatcow/thumbnails/pdf160x120.png' => 'ac9edbf5',
'rsrc/image/icon/fatcow/thumbnails/pdf280x210.png' => '1c585653',
'rsrc/image/icon/fatcow/thumbnails/pdf60x45.png' => 'c0db4143',
'rsrc/image/icon/fatcow/thumbnails/zip.p100.png' => '6ea5aae4',
'rsrc/image/icon/fatcow/thumbnails/zip160x120.png' => '75f9cd0f',
'rsrc/image/icon/fatcow/thumbnails/zip280x210.png' => 'dfda5b8e',
'rsrc/image/icon/fatcow/thumbnails/zip60x45.png' => 'af11bf3e',
'rsrc/image/icon/lightbox/close-2.png' => 'cc40e7c8',
'rsrc/image/icon/lightbox/close-hover-2.png' => 'fb5d6d9e',
'rsrc/image/icon/lightbox/left-arrow-2.png' => '8426133b',
'rsrc/image/icon/lightbox/left-arrow-hover-2.png' => '701e5ee3',
'rsrc/image/icon/lightbox/right-arrow-2.png' => '6d5519a0',
'rsrc/image/icon/lightbox/right-arrow-hover-2.png' => '3a04aa21',
'rsrc/image/icon/subscribe.png' => 'd03ed5a5',
'rsrc/image/icon/tango/attachment.png' => 'ecc8022e',
'rsrc/image/icon/tango/edit.png' => '929a1363',
'rsrc/image/icon/tango/go-down.png' => '96d95e43',
'rsrc/image/icon/tango/log.png' => 'b08cc63a',
'rsrc/image/icon/tango/upload.png' => '7bbb7984',
'rsrc/image/icon/unsubscribe.png' => '25725013',
'rsrc/image/lightblue-header.png' => '5c168b6d',
'rsrc/image/loading.gif' => '75d384cc',
'rsrc/image/loading/boating_24.gif' => '5c90f086',
'rsrc/image/loading/compass_24.gif' => 'b36b4f46',
'rsrc/image/loading/loading_24.gif' => '26bc9adc',
'rsrc/image/loading/loading_48.gif' => '6a4994c7',
'rsrc/image/loading/loading_d48.gif' => 'cdcbe900',
'rsrc/image/loading/loading_w24.gif' => '7662fa2b',
'rsrc/image/main_texture.png' => '29a2c5ad',
'rsrc/image/menu_texture.png' => '5a17580d',
'rsrc/image/people/harding.png' => '45aa614e',
'rsrc/image/people/jefferson.png' => 'afca0e53',
'rsrc/image/people/lincoln.png' => '9369126d',
'rsrc/image/people/mckinley.png' => 'fb8f16ce',
'rsrc/image/people/taft.png' => 'd7bc402c',
'rsrc/image/people/washington.png' => '40dd301c',
'rsrc/image/phortune/balanced.png' => 'f6ba2691',
'rsrc/image/phortune/paypal.png' => '9747cb33',
'rsrc/image/phortune/stripe.png' => 'bfedc2ce',
'rsrc/image/phortune/test.png' => '0235d8a7',
'rsrc/image/phortune/wepay.png' => 'b37163ce',
'rsrc/image/phrequent_active.png' => 'a466a8ed',
'rsrc/image/phrequent_inactive.png' => 'bfc15a69',
'rsrc/image/search-white.png' => '64cc0d45',
'rsrc/image/search.png' => '82625a7e',
'rsrc/image/sprite-apps-X2.png' => '10fe124a',
'rsrc/image/sprite-apps-X4.png' => '9c151271',
'rsrc/image/sprite-apps-large-X2.png' => '4a828a0f',
'rsrc/image/sprite-apps-large.png' => '141d8c93',
'rsrc/image/sprite-apps-xlarge.png' => 'a751a580',
'rsrc/image/sprite-apps.png' => 'f6a0599f',
'rsrc/image/sprite-conpherence-X2.png' => 'cd2d08d7',
'rsrc/image/sprite-conpherence.png' => 'a5ab2eb7',
'rsrc/image/sprite-docs-X2.png' => '6dc1adad',
'rsrc/image/sprite-docs.png' => '4636297f',
'rsrc/image/sprite-gradient.png' => 'ec15a417',
'rsrc/image/sprite-login-X2.png' => '3b2182c4',
'rsrc/image/sprite-login.png' => '9effdc71',
'rsrc/image/sprite-main-header.png' => '83521873',
'rsrc/image/sprite-menu-X2.png' => '39d78f97',
'rsrc/image/sprite-menu.png' => '259dab45',
'rsrc/image/sprite-minicons-X2.png' => '55377e4e',
'rsrc/image/sprite-minicons.png' => '272644ea',
'rsrc/image/sprite-payments.png' => 'd8576309',
'rsrc/image/sprite-projects-X2.png' => '218fdc8b',
'rsrc/image/sprite-projects.png' => '631ff9a7',
'rsrc/image/sprite-tokens-X2.png' => 'b4776580',
'rsrc/image/sprite-tokens.png' => '25b75533',
'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',
'rsrc/js/application/aphlict/Aphlict.js' => '4a07e8e3',
'rsrc/js/application/aphlict/behavior-aphlict-dropdown.js' => 'f51afce0',
'rsrc/js/application/aphlict/behavior-aphlict-listen.js' => 'a826c925',
'rsrc/js/application/aphlict/behavior-aphlict-status.js' => '58f7803f',
'rsrc/js/application/auth/behavior-persona-login.js' => '9414ff18',
'rsrc/js/application/config/behavior-reorder-fields.js' => '14a827de',
'rsrc/js/application/conpherence/behavior-menu.js' => 'f0a41b9f',
'rsrc/js/application/conpherence/behavior-pontificate.js' => '85ab3c8e',
'rsrc/js/application/conpherence/behavior-widget-pane.js' => '40b1ff90',
'rsrc/js/application/countdown/timer.js' => '361e3ed3',
'rsrc/js/application/dashboard/behavior-dashboard-async-panel.js' => '469c0d9e',
'rsrc/js/application/dashboard/behavior-dashboard-move-panels.js' => '82439934',
'rsrc/js/application/dashboard/behavior-dashboard-query-panel-select.js' => '453c5375',
'rsrc/js/application/dashboard/behavior-dashboard-tab-panel.js' => 'd4eecc63',
'rsrc/js/application/differential/ChangesetViewManager.js' => 'd2907473',
'rsrc/js/application/differential/DifferentialInlineCommentEditor.js' => 'f2441746',
'rsrc/js/application/differential/behavior-add-reviewers-and-ccs.js' => 'e10f8e18',
'rsrc/js/application/differential/behavior-comment-jump.js' => '4fdb476d',
'rsrc/js/application/differential/behavior-comment-preview.js' => '127f2018',
'rsrc/js/application/differential/behavior-diff-radios.js' => 'e1ff79b1',
'rsrc/js/application/differential/behavior-dropdown-menus.js' => '710f209e',
'rsrc/js/application/differential/behavior-edit-inline-comments.js' => '00861799',
'rsrc/js/application/differential/behavior-keyboard-nav.js' => '8d199d97',
'rsrc/js/application/differential/behavior-populate.js' => 'bdb3e4d0',
'rsrc/js/application/differential/behavior-show-all-comments.js' => '7c273581',
'rsrc/js/application/differential/behavior-show-field-details.js' => 'bba9eedf',
'rsrc/js/application/differential/behavior-show-more.js' => 'dd7e8ef5',
'rsrc/js/application/differential/behavior-toggle-files.js' => 'ca3f91eb',
'rsrc/js/application/differential/behavior-user-select.js' => 'a8d8459d',
'rsrc/js/application/diffusion/DiffusionLocateFileSource.js' => 'b42eddc7',
'rsrc/js/application/diffusion/behavior-audit-preview.js' => 'd835b03a',
'rsrc/js/application/diffusion/behavior-commit-branches.js' => 'bdaf4d04',
'rsrc/js/application/diffusion/behavior-commit-graph.js' => 'f7f1289f',
'rsrc/js/application/diffusion/behavior-jump-to.js' => '9db3d160',
'rsrc/js/application/diffusion/behavior-load-blame.js' => '42126667',
'rsrc/js/application/diffusion/behavior-locate-file.js' => '6d3e1947',
2014-05-12 20:53:31 +02:00
'rsrc/js/application/diffusion/behavior-pull-lastmodified.js' => '2b228192',
'rsrc/js/application/doorkeeper/behavior-doorkeeper-tag.js' => 'e5822781',
'rsrc/js/application/files/behavior-icon-composer.js' => '8ef9ab58',
'rsrc/js/application/files/behavior-launch-icon-composer.js' => '48086888',
'rsrc/js/application/herald/HeraldRuleEditor.js' => '3fc2c8f2',
'rsrc/js/application/herald/PathTypeahead.js' => 'f7fc67ec',
'rsrc/js/application/herald/herald-rule-editor.js' => '7ebaeed3',
'rsrc/js/application/maniphest/behavior-batch-editor.js' => 'f588412e',
'rsrc/js/application/maniphest/behavior-batch-selector.js' => '7b98d7c5',
'rsrc/js/application/maniphest/behavior-line-chart.js' => '22e16ae7',
'rsrc/js/application/maniphest/behavior-list-edit.js' => 'a9f88de2',
'rsrc/js/application/maniphest/behavior-subpriorityeditor.js' => '84845b5b',
'rsrc/js/application/maniphest/behavior-transaction-controls.js' => '44168bad',
'rsrc/js/application/maniphest/behavior-transaction-expand.js' => '5fefb143',
'rsrc/js/application/maniphest/behavior-transaction-preview.js' => 'f8248bc5',
'rsrc/js/application/owners/OwnersPathEditor.js' => 'aa1733d0',
'rsrc/js/application/owners/owners-path-editor.js' => '7a68dda3',
'rsrc/js/application/passphrase/phame-credential-control.js' => '3d51a746',
'rsrc/js/application/phame/phame-post-preview.js' => 'be807912',
'rsrc/js/application/pholio/behavior-pholio-mock-edit.js' => '9c2623f4',
'rsrc/js/application/pholio/behavior-pholio-mock-view.js' => '152178f0',
'rsrc/js/application/phortune/behavior-balanced-payment-form.js' => '3b3e1664',
'rsrc/js/application/phortune/behavior-stripe-payment-form.js' => '1693a296',
'rsrc/js/application/phortune/behavior-test-payment-form.js' => 'ab8d2723',
'rsrc/js/application/phortune/phortune-credit-card-form.js' => '2290aeef',
'rsrc/js/application/policy/behavior-policy-control.js' => 'f3fef818',
'rsrc/js/application/policy/behavior-policy-rule-editor.js' => 'fe9a552f',
'rsrc/js/application/ponder/behavior-votebox.js' => '4e9b766b',
'rsrc/js/application/projects/behavior-boards-dropdown.js' => '0ec56e1d',
'rsrc/js/application/projects/behavior-project-boards.js' => 'd4bf1f3c',
'rsrc/js/application/projects/behavior-project-create.js' => '065227cc',
'rsrc/js/application/projects/behavior-reorder-columns.js' => '09eee344',
'rsrc/js/application/releeph/releeph-preview-branch.js' => 'b2b4fbaf',
'rsrc/js/application/releeph/releeph-request-state-change.js' => 'ab836011',
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',
'rsrc/js/application/repository/repository-crossreference.js' => 'f9539603',
'rsrc/js/application/search/behavior-reorder-queries.js' => 'e9581f08',
'rsrc/js/application/slowvote/behavior-slowvote-embed.js' => 'd6f54db0',
'rsrc/js/application/transactions/behavior-transaction-comment-form.js' => '9f7309fb',
'rsrc/js/application/transactions/behavior-transaction-list.js' => '13c739ea',
'rsrc/js/application/uiexample/JavelinViewExample.js' => 'd4a14807',
'rsrc/js/application/uiexample/ReactorButtonExample.js' => 'd19198c8',
'rsrc/js/application/uiexample/ReactorCheckboxExample.js' => '519705ea',
'rsrc/js/application/uiexample/ReactorFocusExample.js' => '40a6a403',
'rsrc/js/application/uiexample/ReactorInputExample.js' => '886fd850',
'rsrc/js/application/uiexample/ReactorMouseoverExample.js' => '47c794d8',
'rsrc/js/application/uiexample/ReactorRadioExample.js' => '988040b4',
'rsrc/js/application/uiexample/ReactorSelectExample.js' => 'a155550f',
'rsrc/js/application/uiexample/ReactorSendClassExample.js' => '1def2711',
'rsrc/js/application/uiexample/ReactorSendPropertiesExample.js' => 'b1f0ccee',
'rsrc/js/application/uiexample/busy-example.js' => '60479091',
'rsrc/js/application/uiexample/gesture-example.js' => '558829c2',
'rsrc/js/application/uiexample/notification-example.js' => '7a9677fc',
'rsrc/js/core/Busy.js' => '6453c869',
Give files uploaded to objects a very restrictive view policy Summary: Fixes T4589. This implements much better policy behavior for files that aligns with user expectations. Currently, all files have permissive visibility. The new behavior is: - Files uploaded via drag-and-drop to the home page or file upload page get permissive visibility, for ease of quickly sharing things like screenshots. - Files uploaded via the manual file upload control get permissive visibility by default, but the user can select the policy they want at upload time in an explicit/obvious way. - Files uploaded via drag-and-drop anywhere else (e.g., comments or Pholio) get restricted visibility (only the uploader). - When the user applies a transaction to the object which uses the file, we attach the file to the object and punch a hole through the policies: if you can see the object, you can see the file. - This rule requires things to use ApplicationTransactions, which is why this took so long to fix. - The "attach stuff to the object" code has been in place for a long time and works correctly. I'll land D8498 after this lands, too. Test Plan: - Uploaded via global homepage upload and file drag-and-drop upload, saw permissive visibility. - Uploaded via comment area, saw restricted visibility. - After commenting, verified links were established and the file became visible to users who could see the attached object. - Verified Pholio (which is a bit of a special case) correctly attaches images. Reviewers: btrahan Reviewed By: btrahan Subscribers: epriestley Maniphest Tasks: T4589 Differential Revision: https://secure.phabricator.com/D10131
2014-08-02 23:46:13 +02:00
'rsrc/js/core/DragAndDropFileUpload.js' => 'f61aa8ec',
'rsrc/js/core/DraggableList.js' => '2cad29d1',
'rsrc/js/core/FileUpload.js' => 'a4ae61bf',
'rsrc/js/core/Hovercard.js' => '7e8468ae',
'rsrc/js/core/KeyboardShortcut.js' => '1ae869f2',
'rsrc/js/core/KeyboardShortcutManager.js' => 'ad7a69ca',
'rsrc/js/core/MultirowRowManager.js' => '41e47dea',
'rsrc/js/core/Notification.js' => '0c6946e7',
'rsrc/js/core/Prefab.js' => 'bbae734c',
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',
'rsrc/js/core/TextAreaUtils.js' => 'b3ec3cfc',
'rsrc/js/core/ToolTip.js' => '3915d490',
'rsrc/js/core/behavior-active-nav.js' => 'e379b58e',
'rsrc/js/core/behavior-audio-source.js' => '59b251eb',
'rsrc/js/core/behavior-autofocus.js' => '7319e029',
'rsrc/js/core/behavior-choose-control.js' => '6153c708',
'rsrc/js/core/behavior-crop.js' => 'fa0f4fc2',
'rsrc/js/core/behavior-dark-console.js' => '357b6e9b',
'rsrc/js/core/behavior-device.js' => '03d6ed07',
'rsrc/js/core/behavior-drag-and-drop-textarea.js' => '92eb531d',
'rsrc/js/core/behavior-error-log.js' => 'a5d7cf86',
'rsrc/js/core/behavior-fancy-datepicker.js' => 'a5573bcd',
'rsrc/js/core/behavior-file-tree.js' => '88236f00',
'rsrc/js/core/behavior-form.js' => '5c54cbf3',
'rsrc/js/core/behavior-gesture.js' => '3ab51e2c',
Give files uploaded to objects a very restrictive view policy Summary: Fixes T4589. This implements much better policy behavior for files that aligns with user expectations. Currently, all files have permissive visibility. The new behavior is: - Files uploaded via drag-and-drop to the home page or file upload page get permissive visibility, for ease of quickly sharing things like screenshots. - Files uploaded via the manual file upload control get permissive visibility by default, but the user can select the policy they want at upload time in an explicit/obvious way. - Files uploaded via drag-and-drop anywhere else (e.g., comments or Pholio) get restricted visibility (only the uploader). - When the user applies a transaction to the object which uses the file, we attach the file to the object and punch a hole through the policies: if you can see the object, you can see the file. - This rule requires things to use ApplicationTransactions, which is why this took so long to fix. - The "attach stuff to the object" code has been in place for a long time and works correctly. I'll land D8498 after this lands, too. Test Plan: - Uploaded via global homepage upload and file drag-and-drop upload, saw permissive visibility. - Uploaded via comment area, saw restricted visibility. - After commenting, verified links were established and the file became visible to users who could see the attached object. - Verified Pholio (which is a bit of a special case) correctly attaches images. Reviewers: btrahan Reviewed By: btrahan Subscribers: epriestley Maniphest Tasks: T4589 Differential Revision: https://secure.phabricator.com/D10131
2014-08-02 23:46:13 +02:00
'rsrc/js/core/behavior-global-drag-and-drop.js' => '07f199d8',
'rsrc/js/core/behavior-high-security-warning.js' => '8fc1c918',
'rsrc/js/core/behavior-history-install.js' => '7ee2b591',
'rsrc/js/core/behavior-hovercard.js' => 'f36e01af',
'rsrc/js/core/behavior-keyboard-pager.js' => 'a8da01f0',
'rsrc/js/core/behavior-keyboard-shortcuts.js' => 'd75709e6',
'rsrc/js/core/behavior-konami.js' => '5bc2cb21',
'rsrc/js/core/behavior-lightbox-attachments.js' => '0720f2cf',
'rsrc/js/core/behavior-line-linker.js' => 'f726d506',
'rsrc/js/core/behavior-more.js' => 'a80d0378',
'rsrc/js/core/behavior-object-selector.js' => '39841ead',
'rsrc/js/core/behavior-oncopy.js' => '2926fff2',
'rsrc/js/core/behavior-phabricator-nav.js' => '14d7a8b8',
'rsrc/js/core/behavior-phabricator-remarkup-assist.js' => 'e32d14ab',
Provide a global router for Ajax requests Summary: Fixes T430. Fixes T4834. Obsoletes D7641. Currently, we do some things less-well than we could: - We just let the browser queue and prioritize requests, so if you load a revision with 50 changes and then click "Award Token", the action blocks until the changes load in most/all browsers. It would be better to prioritize this action and queue it immediately. - Similarly, changes tend to load in order, even if the user has clicked to a specific file. When the user expresses a preference for a specific file, we should prioritize it. - We show a spinning GIF when waiting on requests. This is appropriate for some types of reuqests, but distracting for others. To fix this: - Queue all (or, at least, most) requests into a new queue in JX.Router. - JX.Router handles prioritizing the requests. Principally: - You can submit a request with a specific priority (500 = general content loading, 1000 = default, 2000 = explicit user action) and JX.Router will get the higher stuff fired off sooner. - You can name requests and then adjust their prorities later, if the user expresses an interest in specific results. - Only use the spinner gif for "workflow" requests, which is bascially when the user clicked something and we're waiting on the server. I think it's useful and not-annoying in this case. - Don't show any status for draft requests. - For content requests, show a subtle hipster-style top loading bar. Test Plan: - Viewed a diff with 93 changes, and clicked award token. - Prior to this patch, the action took many many seconds to resolve. - After this patch, it resolves quickly. - Viewed a diff with 93 changes and saw a pleasant subtle hipster-style loading bar. - Viewed a diff with 93 changes and typed some draft text. Previews populated fairly quickly and there was no spinner. - Viewed a diff with 93 changes and clicked something with workflow, saw a spinner after a moment. - Viewed a diff with 93 changes and clicked a file in the table of contents near the end of the list. - Prior to this patch, it took a long time to show up. - After this patch, it loads directly. Reviewers: chad, btrahan Reviewed By: btrahan Subscribers: epriestley Maniphest Tasks: T430, T4834 Differential Revision: https://secure.phabricator.com/D8979
2014-05-05 19:57:42 +02:00
'rsrc/js/core/behavior-refresh-csrf.js' => '7814b593',
'rsrc/js/core/behavior-remarkup-preview.js' => 'f7379f45',
'rsrc/js/core/behavior-reorder-applications.js' => '76b9fc3e',
'rsrc/js/core/behavior-reveal-content.js' => '60821bc7',
'rsrc/js/core/behavior-search-typeahead.js' => 'd712ac5f',
'rsrc/js/core/behavior-select-on-click.js' => '4e3e79a6',
Introduce CAN_EDIT for ExternalAccount, and make CAN_VIEW more liberal Summary: Fixes T3732. Ref T1205. Ref T3116. External accounts (like emails used as identities, Facebook accounts, LDAP accounts, etc.) are stored in "ExternalAccount" objects. Currently, we have a very restrictive `CAN_VIEW` policy for ExternalAccounts, to add an extra layer of protection to make sure users can't use them in unintended ways. For example, it would be bad if a user could link their Phabricator account to a Facebook account without proper authentication. All of the controllers which do sensitive things have checks anyway, but a restrictive CAN_VIEW provided an extra layer of protection. Se T3116 for some discussion. However, this means that when grey/external users take actions (via email, or via applications like Legalpad) other users can't load the account handles and can't see anything about the actor (they just see "Restricted External Account" or similar). Balancing these concerns is mostly about not making a huge mess while doing it. This seems like a reasonable approach: - Add `CAN_EDIT` on these objects. - Make that very restricted, but open up `CAN_VIEW`. - Require `CAN_EDIT` any time we're going to do something authentication/identity related. This is slightly easier to get wrong (forget CAN_EDIT) than other approaches, but pretty simple, and we always have extra checks in place anyway -- this is just a safety net. I'm not quite sure how we should identify external accounts, so for now we're just rendering "Email User" or similar -- clearly not a bug, but not identifying. We can figure out what to render in the long term elsewhere. Test Plan: - Viewed external accounts. - Linked an external account. - Refreshed an external account. - Edited profile picture. - Viewed sessions panel. - Published a bunch of stuff to Asana/JIRA. - Legalpad signature page now shows external accounts. {F171595} Reviewers: chad, btrahan Reviewed By: btrahan Subscribers: epriestley Maniphest Tasks: T3732, T1205, T3116 Differential Revision: https://secure.phabricator.com/D9767
2014-07-10 19:18:10 +02:00
'rsrc/js/core/behavior-toggle-class.js' => 'e566f52c',
'rsrc/js/core/behavior-tokenizer.js' => 'b3a4b884',
'rsrc/js/core/behavior-tooltip.js' => '3ee3408b',
'rsrc/js/core/behavior-watch-anchor.js' => '06e05112',
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',
'rsrc/js/core/phtize.js' => 'd254d646',
'rsrc/js/phui/behavior-phui-object-box-tabs.js' => '2bfa2836',
'rsrc/js/phui/behavior-phui-timeline-dropdown-menu.js' => '4d94d9c3',
'rsrc/js/phuix/PHUIXActionListView.js' => 'b5c256b8',
'rsrc/js/phuix/PHUIXActionView.js' => '6e8cefa4',
'rsrc/js/phuix/PHUIXDropdownMenu.js' => 'bd4c8dca',
'rsrc/swf/aphlict.swf' => 'f19daffb',
),
'symbols' => array(
'aphront-bars' => '231ac33c',
'aphront-contextbar-view-css' => '1c3b0529',
'aphront-dark-console-css' => '6378ef3d',
'aphront-dialog-view-css' => '4dbbe3bb',
'aphront-error-view-css' => '3462dbee',
'aphront-list-filter-view-css' => '2ae43867',
'aphront-multi-column-view-css' => '1b95ab2e',
'aphront-pager-view-css' => '2e3539af',
'aphront-panel-view-css' => '5846dfa2',
'aphront-request-failure-view-css' => '7a83dc3a',
'aphront-table-view-css' => 'b22b7216',
'aphront-tokenizer-control-css' => '82ce2142',
'aphront-tooltip-css' => '9c90229d',
'aphront-two-column-view-css' => '16ab3ad2',
'aphront-typeahead-control-css' => 'a989b5b3',
'auth-css' => '1e655982',
'changeset-view-manager' => 'd2907473',
'config-options-css' => '7fedf08b',
'config-welcome-css' => 'b0d16200',
'conpherence-menu-css' => 'e1e0fdf1',
'conpherence-message-pane-css' => '11a393ca',
'conpherence-notification-css' => '04a6e10a',
'conpherence-update-css' => '1099a660',
'conpherence-widget-pane-css' => 'bf275a6c',
'differential-changeset-view-css' => 'ff8eacf8',
'differential-core-view-css' => '7ac3cabc',
'differential-inline-comment-editor' => 'f2441746',
'differential-results-table-css' => '239924f9',
'differential-revision-add-comment-css' => 'c478bcaa',
'differential-revision-comment-css' => '48186045',
2014-03-12 21:53:04 +01:00
'differential-revision-history-css' => '0e8eb855',
'differential-revision-list-css' => 'f3c47d33',
'differential-table-of-contents-css' => '6bf8e1d2',
'diffusion-icons-css' => '9c5828da',
'diffusion-source-css' => '66fdf661',
'diviner-shared-css' => '38813222',
2014-05-16 18:28:01 +02:00
'font-fontawesome' => '73d075c3',
'font-source-sans-pro' => '91d53463',
'global-drag-and-drop-css' => '697324ad',
'harbormaster-css' => '49d64eb4',
'herald-css' => 'c544dd1c',
'herald-rule-editor' => '3fc2c8f2',
'herald-test-css' => '778b008e',
'inline-comment-summary-css' => '8cfd34e8',
'javelin-aphlict' => '4a07e8e3',
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',
'javelin-behavior-aphlict-dropdown' => 'f51afce0',
'javelin-behavior-aphlict-listen' => 'a826c925',
'javelin-behavior-aphlict-status' => '58f7803f',
'javelin-behavior-aphront-basic-tokenizer' => 'b3a4b884',
'javelin-behavior-aphront-crop' => 'fa0f4fc2',
'javelin-behavior-aphront-drag-and-drop-textarea' => '92eb531d',
'javelin-behavior-aphront-form-disable-on-submit' => '5c54cbf3',
'javelin-behavior-aphront-more' => 'a80d0378',
'javelin-behavior-audio-source' => '59b251eb',
'javelin-behavior-audit-preview' => 'd835b03a',
'javelin-behavior-balanced-payment-form' => '3b3e1664',
'javelin-behavior-boards-dropdown' => '0ec56e1d',
'javelin-behavior-choose-control' => '6153c708',
'javelin-behavior-config-reorder-fields' => '14a827de',
'javelin-behavior-conpherence-menu' => 'f0a41b9f',
'javelin-behavior-conpherence-pontificate' => '85ab3c8e',
'javelin-behavior-conpherence-widget-pane' => '40b1ff90',
'javelin-behavior-countdown-timer' => '361e3ed3',
'javelin-behavior-dark-console' => '357b6e9b',
'javelin-behavior-dashboard-async-panel' => '469c0d9e',
'javelin-behavior-dashboard-move-panels' => '82439934',
'javelin-behavior-dashboard-query-panel-select' => '453c5375',
'javelin-behavior-dashboard-tab-panel' => 'd4eecc63',
'javelin-behavior-device' => '03d6ed07',
'javelin-behavior-differential-add-reviewers-and-ccs' => 'e10f8e18',
'javelin-behavior-differential-comment-jump' => '4fdb476d',
'javelin-behavior-differential-diff-radios' => 'e1ff79b1',
'javelin-behavior-differential-dropdown-menus' => '710f209e',
'javelin-behavior-differential-edit-inline-comments' => '00861799',
'javelin-behavior-differential-feedback-preview' => '127f2018',
'javelin-behavior-differential-keyboard-navigation' => '8d199d97',
'javelin-behavior-differential-populate' => 'bdb3e4d0',
'javelin-behavior-differential-show-field-details' => 'bba9eedf',
'javelin-behavior-differential-show-more' => 'dd7e8ef5',
'javelin-behavior-differential-toggle-files' => 'ca3f91eb',
'javelin-behavior-differential-user-select' => 'a8d8459d',
'javelin-behavior-diffusion-commit-branches' => 'bdaf4d04',
'javelin-behavior-diffusion-commit-graph' => 'f7f1289f',
'javelin-behavior-diffusion-jump-to' => '9db3d160',
'javelin-behavior-diffusion-locate-file' => '6d3e1947',
2014-05-12 20:53:31 +02:00
'javelin-behavior-diffusion-pull-lastmodified' => '2b228192',
'javelin-behavior-doorkeeper-tag' => 'e5822781',
'javelin-behavior-error-log' => 'a5d7cf86',
'javelin-behavior-fancy-datepicker' => 'a5573bcd',
Give files uploaded to objects a very restrictive view policy Summary: Fixes T4589. This implements much better policy behavior for files that aligns with user expectations. Currently, all files have permissive visibility. The new behavior is: - Files uploaded via drag-and-drop to the home page or file upload page get permissive visibility, for ease of quickly sharing things like screenshots. - Files uploaded via the manual file upload control get permissive visibility by default, but the user can select the policy they want at upload time in an explicit/obvious way. - Files uploaded via drag-and-drop anywhere else (e.g., comments or Pholio) get restricted visibility (only the uploader). - When the user applies a transaction to the object which uses the file, we attach the file to the object and punch a hole through the policies: if you can see the object, you can see the file. - This rule requires things to use ApplicationTransactions, which is why this took so long to fix. - The "attach stuff to the object" code has been in place for a long time and works correctly. I'll land D8498 after this lands, too. Test Plan: - Uploaded via global homepage upload and file drag-and-drop upload, saw permissive visibility. - Uploaded via comment area, saw restricted visibility. - After commenting, verified links were established and the file became visible to users who could see the attached object. - Verified Pholio (which is a bit of a special case) correctly attaches images. Reviewers: btrahan Reviewed By: btrahan Subscribers: epriestley Maniphest Tasks: T4589 Differential Revision: https://secure.phabricator.com/D10131
2014-08-02 23:46:13 +02:00
'javelin-behavior-global-drag-and-drop' => '07f199d8',
'javelin-behavior-herald-rule-editor' => '7ebaeed3',
'javelin-behavior-high-security-warning' => '8fc1c918',
'javelin-behavior-history-install' => '7ee2b591',
'javelin-behavior-icon-composer' => '8ef9ab58',
'javelin-behavior-konami' => '5bc2cb21',
'javelin-behavior-launch-icon-composer' => '48086888',
'javelin-behavior-lightbox-attachments' => '0720f2cf',
'javelin-behavior-line-chart' => '22e16ae7',
'javelin-behavior-load-blame' => '42126667',
'javelin-behavior-maniphest-batch-editor' => 'f588412e',
'javelin-behavior-maniphest-batch-selector' => '7b98d7c5',
'javelin-behavior-maniphest-list-editor' => 'a9f88de2',
'javelin-behavior-maniphest-subpriority-editor' => '84845b5b',
'javelin-behavior-maniphest-transaction-controls' => '44168bad',
'javelin-behavior-maniphest-transaction-expand' => '5fefb143',
'javelin-behavior-maniphest-transaction-preview' => 'f8248bc5',
'javelin-behavior-owners-path-editor' => '7a68dda3',
'javelin-behavior-passphrase-credential-control' => '3d51a746',
'javelin-behavior-persona-login' => '9414ff18',
'javelin-behavior-phabricator-active-nav' => 'e379b58e',
'javelin-behavior-phabricator-autofocus' => '7319e029',
'javelin-behavior-phabricator-busy-example' => '60479091',
'javelin-behavior-phabricator-file-tree' => '88236f00',
'javelin-behavior-phabricator-gesture' => '3ab51e2c',
'javelin-behavior-phabricator-gesture-example' => '558829c2',
'javelin-behavior-phabricator-hovercards' => 'f36e01af',
'javelin-behavior-phabricator-keyboard-pager' => 'a8da01f0',
'javelin-behavior-phabricator-keyboard-shortcuts' => 'd75709e6',
'javelin-behavior-phabricator-line-linker' => 'f726d506',
'javelin-behavior-phabricator-nav' => '14d7a8b8',
'javelin-behavior-phabricator-notification-example' => '7a9677fc',
'javelin-behavior-phabricator-object-selector' => '39841ead',
'javelin-behavior-phabricator-oncopy' => '2926fff2',
'javelin-behavior-phabricator-remarkup-assist' => 'e32d14ab',
'javelin-behavior-phabricator-reveal-content' => '60821bc7',
'javelin-behavior-phabricator-search-typeahead' => 'd712ac5f',
'javelin-behavior-phabricator-show-all-transactions' => '7c273581',
'javelin-behavior-phabricator-tooltips' => '3ee3408b',
'javelin-behavior-phabricator-transaction-comment-form' => '9f7309fb',
'javelin-behavior-phabricator-transaction-list' => '13c739ea',
'javelin-behavior-phabricator-watch-anchor' => '06e05112',
'javelin-behavior-phame-post-preview' => 'be807912',
'javelin-behavior-pholio-mock-edit' => '9c2623f4',
'javelin-behavior-pholio-mock-view' => '152178f0',
'javelin-behavior-phui-object-box-tabs' => '2bfa2836',
'javelin-behavior-phui-timeline-dropdown-menu' => '4d94d9c3',
'javelin-behavior-policy-control' => 'f3fef818',
'javelin-behavior-policy-rule-editor' => 'fe9a552f',
'javelin-behavior-ponder-votebox' => '4e9b766b',
'javelin-behavior-project-boards' => 'd4bf1f3c',
'javelin-behavior-project-create' => '065227cc',
Provide a global router for Ajax requests Summary: Fixes T430. Fixes T4834. Obsoletes D7641. Currently, we do some things less-well than we could: - We just let the browser queue and prioritize requests, so if you load a revision with 50 changes and then click "Award Token", the action blocks until the changes load in most/all browsers. It would be better to prioritize this action and queue it immediately. - Similarly, changes tend to load in order, even if the user has clicked to a specific file. When the user expresses a preference for a specific file, we should prioritize it. - We show a spinning GIF when waiting on requests. This is appropriate for some types of reuqests, but distracting for others. To fix this: - Queue all (or, at least, most) requests into a new queue in JX.Router. - JX.Router handles prioritizing the requests. Principally: - You can submit a request with a specific priority (500 = general content loading, 1000 = default, 2000 = explicit user action) and JX.Router will get the higher stuff fired off sooner. - You can name requests and then adjust their prorities later, if the user expresses an interest in specific results. - Only use the spinner gif for "workflow" requests, which is bascially when the user clicked something and we're waiting on the server. I think it's useful and not-annoying in this case. - Don't show any status for draft requests. - For content requests, show a subtle hipster-style top loading bar. Test Plan: - Viewed a diff with 93 changes, and clicked award token. - Prior to this patch, the action took many many seconds to resolve. - After this patch, it resolves quickly. - Viewed a diff with 93 changes and saw a pleasant subtle hipster-style loading bar. - Viewed a diff with 93 changes and typed some draft text. Previews populated fairly quickly and there was no spinner. - Viewed a diff with 93 changes and clicked something with workflow, saw a spinner after a moment. - Viewed a diff with 93 changes and clicked a file in the table of contents near the end of the list. - Prior to this patch, it took a long time to show up. - After this patch, it loads directly. Reviewers: chad, btrahan Reviewed By: btrahan Subscribers: epriestley Maniphest Tasks: T430, T4834 Differential Revision: https://secure.phabricator.com/D8979
2014-05-05 19:57:42 +02:00
'javelin-behavior-refresh-csrf' => '7814b593',
'javelin-behavior-releeph-preview-branch' => 'b2b4fbaf',
'javelin-behavior-releeph-request-state-change' => 'ab836011',
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',
'javelin-behavior-remarkup-preview' => 'f7379f45',
'javelin-behavior-reorder-applications' => '76b9fc3e',
'javelin-behavior-reorder-columns' => '09eee344',
'javelin-behavior-repository-crossreference' => 'f9539603',
'javelin-behavior-search-reorder-queries' => 'e9581f08',
'javelin-behavior-select-on-click' => '4e3e79a6',
'javelin-behavior-slowvote-embed' => 'd6f54db0',
'javelin-behavior-stripe-payment-form' => '1693a296',
'javelin-behavior-test-payment-form' => 'ab8d2723',
Introduce CAN_EDIT for ExternalAccount, and make CAN_VIEW more liberal Summary: Fixes T3732. Ref T1205. Ref T3116. External accounts (like emails used as identities, Facebook accounts, LDAP accounts, etc.) are stored in "ExternalAccount" objects. Currently, we have a very restrictive `CAN_VIEW` policy for ExternalAccounts, to add an extra layer of protection to make sure users can't use them in unintended ways. For example, it would be bad if a user could link their Phabricator account to a Facebook account without proper authentication. All of the controllers which do sensitive things have checks anyway, but a restrictive CAN_VIEW provided an extra layer of protection. Se T3116 for some discussion. However, this means that when grey/external users take actions (via email, or via applications like Legalpad) other users can't load the account handles and can't see anything about the actor (they just see "Restricted External Account" or similar). Balancing these concerns is mostly about not making a huge mess while doing it. This seems like a reasonable approach: - Add `CAN_EDIT` on these objects. - Make that very restricted, but open up `CAN_VIEW`. - Require `CAN_EDIT` any time we're going to do something authentication/identity related. This is slightly easier to get wrong (forget CAN_EDIT) than other approaches, but pretty simple, and we always have extra checks in place anyway -- this is just a safety net. I'm not quite sure how we should identify external accounts, so for now we're just rendering "Email User" or similar -- clearly not a bug, but not identifying. We can figure out what to render in the long term elsewhere. Test Plan: - Viewed external accounts. - Linked an external account. - Refreshed an external account. - Edited profile picture. - Viewed sessions panel. - Published a bunch of stuff to Asana/JIRA. - Legalpad signature page now shows external accounts. {F171595} Reviewers: chad, btrahan Reviewed By: btrahan Subscribers: epriestley Maniphest Tasks: T3732, T1205, T3116 Differential Revision: https://secure.phabricator.com/D9767
2014-07-10 19:18:10 +02:00
'javelin-behavior-toggle-class' => 'e566f52c',
'javelin-behavior-view-placeholder' => '2fa810fc',
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',
'javelin-color' => '7e41274a',
'javelin-cookie' => '6b3dcf44',
'javelin-diffusion-locate-file-source' => 'b42eddc7',
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-dom' => 'c4569c05',
'javelin-dynval' => 'f6555212',
Introduce CAN_EDIT for ExternalAccount, and make CAN_VIEW more liberal Summary: Fixes T3732. Ref T1205. Ref T3116. External accounts (like emails used as identities, Facebook accounts, LDAP accounts, etc.) are stored in "ExternalAccount" objects. Currently, we have a very restrictive `CAN_VIEW` policy for ExternalAccounts, to add an extra layer of protection to make sure users can't use them in unintended ways. For example, it would be bad if a user could link their Phabricator account to a Facebook account without proper authentication. All of the controllers which do sensitive things have checks anyway, but a restrictive CAN_VIEW provided an extra layer of protection. Se T3116 for some discussion. However, this means that when grey/external users take actions (via email, or via applications like Legalpad) other users can't load the account handles and can't see anything about the actor (they just see "Restricted External Account" or similar). Balancing these concerns is mostly about not making a huge mess while doing it. This seems like a reasonable approach: - Add `CAN_EDIT` on these objects. - Make that very restricted, but open up `CAN_VIEW`. - Require `CAN_EDIT` any time we're going to do something authentication/identity related. This is slightly easier to get wrong (forget CAN_EDIT) than other approaches, but pretty simple, and we always have extra checks in place anyway -- this is just a safety net. I'm not quite sure how we should identify external accounts, so for now we're just rendering "Email User" or similar -- clearly not a bug, but not identifying. We can figure out what to render in the long term elsewhere. Test Plan: - Viewed external accounts. - Linked an external account. - Refreshed an external account. - Edited profile picture. - Viewed sessions panel. - Published a bunch of stuff to Asana/JIRA. - Legalpad signature page now shows external accounts. {F171595} Reviewers: chad, btrahan Reviewed By: btrahan Subscribers: epriestley Maniphest Tasks: T3732, T1205, T3116 Differential Revision: https://secure.phabricator.com/D9767
2014-07-10 19:18:10 +02:00
'javelin-event' => '85ea0626',
'javelin-fx' => '54b612ba',
'javelin-history' => 'c60f4327',
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-install' => '1ffb3a9c',
'javelin-json' => '69adf288',
'javelin-magical-init' => 'b88ab49e',
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',
'javelin-reactor' => '77b1cf6f',
'javelin-reactor-dom' => 'b6d401d6',
'javelin-reactor-node-calmer' => '76f4ebed',
'javelin-reactornode' => 'b4c30592',
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-request' => '97258e55',
'javelin-resource' => '0f81f8df',
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',
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-stratcom' => '8b0ad945',
'javelin-tokenizer' => 'a5b67173',
'javelin-typeahead' => 'e614d22b',
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',
'javelin-typeahead-normalizer' => 'aa93c7b0',
'javelin-typeahead-ondemand-source' => '8b3fd187',
'javelin-typeahead-preloaded-source' => '54f314a0',
'javelin-typeahead-source' => 'fcba4ecc',
Introduce CAN_EDIT for ExternalAccount, and make CAN_VIEW more liberal Summary: Fixes T3732. Ref T1205. Ref T3116. External accounts (like emails used as identities, Facebook accounts, LDAP accounts, etc.) are stored in "ExternalAccount" objects. Currently, we have a very restrictive `CAN_VIEW` policy for ExternalAccounts, to add an extra layer of protection to make sure users can't use them in unintended ways. For example, it would be bad if a user could link their Phabricator account to a Facebook account without proper authentication. All of the controllers which do sensitive things have checks anyway, but a restrictive CAN_VIEW provided an extra layer of protection. Se T3116 for some discussion. However, this means that when grey/external users take actions (via email, or via applications like Legalpad) other users can't load the account handles and can't see anything about the actor (they just see "Restricted External Account" or similar). Balancing these concerns is mostly about not making a huge mess while doing it. This seems like a reasonable approach: - Add `CAN_EDIT` on these objects. - Make that very restricted, but open up `CAN_VIEW`. - Require `CAN_EDIT` any time we're going to do something authentication/identity related. This is slightly easier to get wrong (forget CAN_EDIT) than other approaches, but pretty simple, and we always have extra checks in place anyway -- this is just a safety net. I'm not quite sure how we should identify external accounts, so for now we're just rendering "Email User" or similar -- clearly not a bug, but not identifying. We can figure out what to render in the long term elsewhere. Test Plan: - Viewed external accounts. - Linked an external account. - Refreshed an external account. - Edited profile picture. - Viewed sessions panel. - Published a bunch of stuff to Asana/JIRA. - Legalpad signature page now shows external accounts. {F171595} Reviewers: chad, btrahan Reviewed By: btrahan Subscribers: epriestley Maniphest Tasks: T3732, T1205, T3116 Differential Revision: https://secure.phabricator.com/D9767
2014-07-10 19:18:10 +02:00
'javelin-typeahead-static-source' => '316b8fa1',
'javelin-uri' => '6eff08aa',
'javelin-util' => 'e7995242',
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-vector' => '23cbb8ac',
'javelin-view' => '0f764c35',
'javelin-view-html' => 'e5b406f9',
'javelin-view-interpreter' => '0c33c1a0',
'javelin-view-renderer' => '6c2b09a2',
'javelin-view-visitor' => 'efe49472',
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-workflow' => 'd149e002',
'lightbox-attachment-css' => '7acac05d',
'maniphest-batch-editor' => '8f380ebc',
'maniphest-report-css' => '6fc16517',
'maniphest-task-edit-css' => '8e23031b',
'maniphest-task-summary-css' => '00c3be7a',
'multirow-row-manager' => '41e47dea',
'owners-path-editor' => 'aa1733d0',
'owners-path-editor-css' => '2f00933b',
'paste-css' => 'aa1767d1',
'path-typeahead' => 'f7fc67ec',
'people-profile-css' => '5402f7a5',
'phabricator-action-list-view-css' => '9ee9910a',
'phabricator-application-launch-view-css' => '8b7e271d',
'phabricator-busy' => '6453c869',
'phabricator-chatlog-css' => '852140ff',
'phabricator-content-source-view-css' => '4b8b05d4',
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-core-css' => '40151074',
'phabricator-countdown-css' => '86b7b0a0',
'phabricator-crumbs-view-css' => '7fbf25b8',
'phabricator-dashboard-css' => 'a2bfdcbf',
Give files uploaded to objects a very restrictive view policy Summary: Fixes T4589. This implements much better policy behavior for files that aligns with user expectations. Currently, all files have permissive visibility. The new behavior is: - Files uploaded via drag-and-drop to the home page or file upload page get permissive visibility, for ease of quickly sharing things like screenshots. - Files uploaded via the manual file upload control get permissive visibility by default, but the user can select the policy they want at upload time in an explicit/obvious way. - Files uploaded via drag-and-drop anywhere else (e.g., comments or Pholio) get restricted visibility (only the uploader). - When the user applies a transaction to the object which uses the file, we attach the file to the object and punch a hole through the policies: if you can see the object, you can see the file. - This rule requires things to use ApplicationTransactions, which is why this took so long to fix. - The "attach stuff to the object" code has been in place for a long time and works correctly. I'll land D8498 after this lands, too. Test Plan: - Uploaded via global homepage upload and file drag-and-drop upload, saw permissive visibility. - Uploaded via comment area, saw restricted visibility. - After commenting, verified links were established and the file became visible to users who could see the attached object. - Verified Pholio (which is a bit of a special case) correctly attaches images. Reviewers: btrahan Reviewed By: btrahan Subscribers: epriestley Maniphest Tasks: T4589 Differential Revision: https://secure.phabricator.com/D10131
2014-08-02 23:46:13 +02:00
'phabricator-drag-and-drop-file-upload' => 'f61aa8ec',
'phabricator-draggable-list' => '2cad29d1',
'phabricator-fatal-config-template-css' => '25d446d6',
'phabricator-feed-css' => '4e544db4',
'phabricator-file-upload' => 'a4ae61bf',
'phabricator-filetree-view-css' => 'fccf9f82',
'phabricator-flag-css' => '5337623f',
'phabricator-hovercard' => '7e8468ae',
'phabricator-hovercard-view-css' => '893f4783',
'phabricator-keyboard-shortcut' => '1ae869f2',
'phabricator-keyboard-shortcut-manager' => 'ad7a69ca',
'phabricator-main-menu-view' => 'aceca0e9',
'phabricator-nav-view-css' => '9283c2df',
'phabricator-notification' => '0c6946e7',
'phabricator-notification-css' => 'ef2c9b34',
'phabricator-notification-menu-css' => '8ae4a008',
'phabricator-object-selector-css' => '029a133d',
'phabricator-phtize' => 'd254d646',
'phabricator-prefab' => 'bbae734c',
'phabricator-profile-css' => 'b459416e',
'phabricator-remarkup-css' => '7fd5585f',
'phabricator-search-results-css' => 'f240504c',
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',
'phabricator-side-menu-view-css' => 'a2ccd7bd',
'phabricator-slowvote-css' => '266df6a1',
'phabricator-source-code-view-css' => '7d346aa4',
'phabricator-standard-page-view' => '517cdfb1',
'phabricator-textareautils' => 'b3ec3cfc',
'phabricator-tooltip' => '3915d490',
'phabricator-transaction-view-css' => '5d0cae25',
'phabricator-ui-example-css' => '528b19de',
'phabricator-uiexample-javelin-view' => 'd4a14807',
'phabricator-uiexample-reactor-button' => 'd19198c8',
'phabricator-uiexample-reactor-checkbox' => '519705ea',
'phabricator-uiexample-reactor-focus' => '40a6a403',
'phabricator-uiexample-reactor-input' => '886fd850',
'phabricator-uiexample-reactor-mouseover' => '47c794d8',
'phabricator-uiexample-reactor-radio' => '988040b4',
'phabricator-uiexample-reactor-select' => 'a155550f',
'phabricator-uiexample-reactor-sendclass' => '1def2711',
'phabricator-uiexample-reactor-sendproperties' => 'b1f0ccee',
'phabricator-zindex-css' => 'd1c137f2',
'phame-css' => '19ecc703',
'pholio-css' => '47dffb9c',
'pholio-edit-css' => '3ad9d1ee',
'pholio-inline-comments-css' => '8e545e49',
'phortune-credit-card-form' => '2290aeef',
'phortune-credit-card-form-css' => 'b25b4beb',
'phortune-css' => '9149f103',
'phrequent-css' => 'ffc185ad',
'phriction-document-css' => '7d7f0071',
'phui-action-header-view-css' => '83e2cc86',
'phui-box-css' => '7b3a2eed',
'phui-button-css' => 'c7412aa1',
'phui-calendar-css' => '5e1ad989',
'phui-calendar-day-css' => 'de035c8a',
'phui-calendar-list-css' => 'c1d0ca59',
'phui-calendar-month-css' => 'a92e47d2',
'phui-document-view-css' => 'a5615198',
'phui-feed-story-css' => 'e2c9bc83',
'phui-font-icon-base-css' => 'eb84f033',
'phui-fontkit-css' => 'fff25cfa',
'phui-form-css' => 'b78ec020',
'phui-form-view-css' => 'ebac1b1d',
'phui-header-view-css' => '39594ac0',
'phui-icon-view-css' => 'd8526aa1',
'phui-image-mask-css' => '5a8b09c8',
'phui-info-panel-css' => '27ea50a1',
'phui-list-view-css' => '43ed2d93',
'phui-object-box-css' => 'e9f7e938',
'phui-object-item-list-view-css' => 'e1e6425f',
'phui-pinboard-view-css' => '3dd4a269',
'phui-property-list-view-css' => '86f9df88',
'phui-remarkup-preview-css' => '19ad512b',
'phui-spacing-css' => '042804d6',
'phui-status-list-view-css' => '2f562399',
'phui-tag-view-css' => 'c4158073',
'phui-text-css' => '23e9b4b7',
'phui-timeline-view-css' => 'bbd990d0',
'phui-workboard-view-css' => '2bf82d00',
'phui-workpanel-view-css' => 'e26044fa',
'phuix-action-list-view' => 'b5c256b8',
'phuix-action-view' => '6e8cefa4',
'phuix-dropdown-menu' => 'bd4c8dca',
'policy-css' => '957ea14c',
'policy-edit-css' => '05cca26a',
'policy-transaction-detail-css' => '82100a43',
'ponder-comment-table-css' => '6cdccea7',
'ponder-feed-view-css' => 'e62615b6',
'ponder-post-css' => 'ebab8a70',
'ponder-vote-css' => '8ed6ed8b',
'project-icon-css' => 'c2ecb7f1',
'raphael-core' => '51ee6b43',
'raphael-g' => '40dde778',
'raphael-g-line' => '40da039e',
'releeph-core' => '9b3c5733',
'releeph-preview-branch' => 'b7a6f4a5',
'releeph-request-differential-create-dialog' => '8d8b92cd',
'releeph-request-typeahead-css' => '667a48ae',
'setup-issue-css' => '69e640e7',
'sprite-apps-css' => '37ee4f4e',
'sprite-apps-large-css' => '12ea1ced',
'sprite-conpherence-css' => '3b4a0487',
'sprite-docs-css' => '5f65d0da',
'sprite-gradient-css' => '4bdb98a7',
'sprite-login-css' => '878ee4d8',
'sprite-main-header-css' => '92720ee2',
'sprite-menu-css' => '28281e16',
'sprite-minicons-css' => 'df4f76fe',
'sprite-payments-css' => 'cc085d44',
'sprite-projects-css' => '7578fa56',
'sprite-tokens-css' => '1706b943',
'syntax-highlighting-css' => '863f3cd8',
'tokens-css' => '3d0f239e',
),
'requires' => array(
'00861799' => array(
'javelin-behavior',
'javelin-stratcom',
'javelin-dom',
'javelin-util',
'javelin-vector',
'differential-inline-comment-editor',
),
'029a133d' => array(
'aphront-dialog-view-css',
),
'03d6ed07' => array(
'javelin-behavior',
'javelin-stratcom',
'javelin-dom',
'javelin-vector',
'javelin-install',
),
'065227cc' => array(
'javelin-behavior',
'javelin-dom',
'javelin-stratcom',
'javelin-workflow',
),
'06e05112' => array(
'javelin-behavior',
'javelin-stratcom',
'javelin-dom',
'javelin-vector',
),
'0720f2cf' => array(
'javelin-behavior',
'javelin-stratcom',
'javelin-dom',
'javelin-mask',
'javelin-util',
'phabricator-busy',
),
Give files uploaded to objects a very restrictive view policy Summary: Fixes T4589. This implements much better policy behavior for files that aligns with user expectations. Currently, all files have permissive visibility. The new behavior is: - Files uploaded via drag-and-drop to the home page or file upload page get permissive visibility, for ease of quickly sharing things like screenshots. - Files uploaded via the manual file upload control get permissive visibility by default, but the user can select the policy they want at upload time in an explicit/obvious way. - Files uploaded via drag-and-drop anywhere else (e.g., comments or Pholio) get restricted visibility (only the uploader). - When the user applies a transaction to the object which uses the file, we attach the file to the object and punch a hole through the policies: if you can see the object, you can see the file. - This rule requires things to use ApplicationTransactions, which is why this took so long to fix. - The "attach stuff to the object" code has been in place for a long time and works correctly. I'll land D8498 after this lands, too. Test Plan: - Uploaded via global homepage upload and file drag-and-drop upload, saw permissive visibility. - Uploaded via comment area, saw restricted visibility. - After commenting, verified links were established and the file became visible to users who could see the attached object. - Verified Pholio (which is a bit of a special case) correctly attaches images. Reviewers: btrahan Reviewed By: btrahan Subscribers: epriestley Maniphest Tasks: T4589 Differential Revision: https://secure.phabricator.com/D10131
2014-08-02 23:46:13 +02:00
'07f199d8' => array(
'javelin-behavior',
'javelin-dom',
'javelin-uri',
'javelin-mask',
'phabricator-drag-and-drop-file-upload',
),
'09eee344' => array(
'javelin-behavior',
'javelin-stratcom',
'javelin-workflow',
'javelin-dom',
'phabricator-draggable-list',
),
'0a3f3021' => array(
'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
),
'0c33c1a0' => array(
'javelin-view',
'javelin-install',
'javelin-dom',
),
'0c6946e7' => array(
'javelin-install',
'javelin-dom',
'javelin-stratcom',
'javelin-util',
'phabricator-notification-css',
),
'0ec56e1d' => array(
'javelin-behavior',
'javelin-dom',
'javelin-stratcom',
'phuix-dropdown-menu',
),
'0f764c35' => array(
'javelin-install',
'javelin-util',
),
'0f81f8df' => array(
'javelin-util',
'javelin-uri',
'javelin-install',
),
'127f2018' => array(
'javelin-behavior',
'javelin-stratcom',
'javelin-dom',
'javelin-request',
'javelin-util',
'phabricator-shaped-request',
),
'13c739ea' => array(
'javelin-behavior',
'javelin-stratcom',
'javelin-workflow',
'javelin-dom',
'javelin-uri',
'phabricator-textareautils',
),
'14a827de' => array(
'javelin-behavior',
'javelin-stratcom',
'javelin-dom',
'javelin-json',
'phabricator-draggable-list',
),
'14d7a8b8' => array(
'javelin-behavior',
'javelin-behavior-device',
'javelin-stratcom',
'javelin-dom',
'javelin-magical-init',
'javelin-vector',
'javelin-request',
'javelin-util',
),
'152178f0' => 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',
),
'1693a296' => array(
'javelin-behavior',
'javelin-dom',
'phortune-credit-card-form',
),
'1ae869f2' => array(
'javelin-install',
'javelin-util',
'phabricator-keyboard-shortcut-manager',
),
'1def2711' => array(
'javelin-install',
'javelin-dom',
'javelin-reactor-dom',
),
'1ffb3a9c' => array(
'javelin-util',
'javelin-magical-init',
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
),
'2290aeef' => array(
'javelin-install',
'javelin-dom',
'javelin-json',
'javelin-workflow',
'javelin-util',
),
'22e16ae7' => array(
'javelin-behavior',
'javelin-dom',
'javelin-vector',
),
'23cbb8ac' => array(
'javelin-install',
'javelin-event',
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
),
'2926fff2' => array(
'javelin-behavior',
'javelin-dom',
),
'29274e2b' => array(
'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
),
'2b228192' => array(
'javelin-behavior',
'javelin-dom',
'javelin-util',
'javelin-workflow',
'javelin-json',
2014-05-12 20:53:31 +02:00
),
'2bfa2836' => array(
'javelin-behavior',
'javelin-stratcom',
'javelin-dom',
),
'2cad29d1' => array(
'javelin-install',
'javelin-dom',
'javelin-stratcom',
'javelin-util',
'javelin-vector',
'javelin-magical-init',
),
'2fa810fc' => array(
'javelin-behavior',
'javelin-dom',
'javelin-view-renderer',
'javelin-install',
),
'316b8fa1' => array(
'javelin-install',
'javelin-typeahead-source',
Introduce CAN_EDIT for ExternalAccount, and make CAN_VIEW more liberal Summary: Fixes T3732. Ref T1205. Ref T3116. External accounts (like emails used as identities, Facebook accounts, LDAP accounts, etc.) are stored in "ExternalAccount" objects. Currently, we have a very restrictive `CAN_VIEW` policy for ExternalAccounts, to add an extra layer of protection to make sure users can't use them in unintended ways. For example, it would be bad if a user could link their Phabricator account to a Facebook account without proper authentication. All of the controllers which do sensitive things have checks anyway, but a restrictive CAN_VIEW provided an extra layer of protection. Se T3116 for some discussion. However, this means that when grey/external users take actions (via email, or via applications like Legalpad) other users can't load the account handles and can't see anything about the actor (they just see "Restricted External Account" or similar). Balancing these concerns is mostly about not making a huge mess while doing it. This seems like a reasonable approach: - Add `CAN_EDIT` on these objects. - Make that very restricted, but open up `CAN_VIEW`. - Require `CAN_EDIT` any time we're going to do something authentication/identity related. This is slightly easier to get wrong (forget CAN_EDIT) than other approaches, but pretty simple, and we always have extra checks in place anyway -- this is just a safety net. I'm not quite sure how we should identify external accounts, so for now we're just rendering "Email User" or similar -- clearly not a bug, but not identifying. We can figure out what to render in the long term elsewhere. Test Plan: - Viewed external accounts. - Linked an external account. - Refreshed an external account. - Edited profile picture. - Viewed sessions panel. - Published a bunch of stuff to Asana/JIRA. - Legalpad signature page now shows external accounts. {F171595} Reviewers: chad, btrahan Reviewed By: btrahan Subscribers: epriestley Maniphest Tasks: T3732, T1205, T3116 Differential Revision: https://secure.phabricator.com/D9767
2014-07-10 19:18:10 +02:00
),
'357b6e9b' => array(
'javelin-behavior',
'javelin-stratcom',
'javelin-util',
'javelin-dom',
'javelin-request',
'phabricator-keyboard-shortcut',
),
'361e3ed3' => array(
'javelin-behavior',
'javelin-dom',
),
'3915d490' => array(
'javelin-install',
'javelin-util',
'javelin-dom',
'javelin-vector',
),
'39841ead' => array(
'javelin-behavior',
'javelin-dom',
'javelin-request',
'javelin-util',
),
'3ab51e2c' => array(
'javelin-behavior',
'javelin-behavior-device',
'javelin-stratcom',
'javelin-vector',
'javelin-dom',
'javelin-magical-init',
),
'3b3e1664' => array(
'javelin-behavior',
'javelin-dom',
'phortune-credit-card-form',
),
'3d51a746' => array(
'javelin-behavior',
'javelin-dom',
'javelin-stratcom',
'javelin-workflow',
'javelin-util',
'javelin-uri',
),
'3ee3408b' => array(
'javelin-behavior',
'javelin-behavior-device',
'javelin-stratcom',
'phabricator-tooltip',
),
'3fc2c8f2' => array(
'multirow-row-manager',
'javelin-install',
'javelin-util',
'javelin-dom',
'javelin-stratcom',
'javelin-json',
'phabricator-prefab',
),
'40a6a403' => array(
'javelin-install',
'javelin-dom',
'javelin-reactor-dom',
),
'40b1ff90' => array(
'javelin-behavior',
'javelin-dom',
'javelin-stratcom',
'javelin-workflow',
'javelin-util',
'phabricator-notification',
'javelin-behavior-device',
'phuix-dropdown-menu',
'phuix-action-list-view',
'phuix-action-view',
),
'41e47dea' => array(
'javelin-install',
'javelin-stratcom',
'javelin-dom',
'javelin-util',
),
'44168bad' => array(
'javelin-behavior',
'javelin-dom',
'phabricator-prefab',
),
'453c5375' => array(
'javelin-behavior',
'javelin-dom',
),
'469c0d9e' => array(
'javelin-behavior',
'javelin-dom',
'javelin-workflow',
),
'47c794d8' => array(
'javelin-install',
'javelin-dom',
'javelin-reactor-dom',
),
'4a07e8e3' => array(
'javelin-install',
'javelin-util',
),
'4d94d9c3' => array(
'javelin-behavior',
'javelin-stratcom',
'javelin-dom',
'phuix-dropdown-menu',
),
'4e3e79a6' => array(
'javelin-behavior',
'javelin-stratcom',
'javelin-dom',
),
'4e9b766b' => array(
'javelin-behavior',
'javelin-dom',
'javelin-util',
'javelin-stratcom',
'javelin-request',
),
'4fdb476d' => array(
'javelin-behavior',
'javelin-stratcom',
'javelin-dom',
),
'503e17fd' => array(
'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
),
'519705ea' => array(
'javelin-install',
'javelin-dom',
'javelin-reactor-dom',
),
'54b612ba' => array(
'javelin-color',
'javelin-install',
'javelin-util',
),
'54f314a0' => array(
'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
),
'558829c2' => array(
'javelin-stratcom',
'javelin-behavior',
'javelin-vector',
'javelin-dom',
),
'58f7803f' => array(
'javelin-behavior',
'javelin-aphlict',
'phabricator-phtize',
'javelin-dom',
),
'59b251eb' => array(
'javelin-behavior',
'javelin-stratcom',
'javelin-vector',
'javelin-dom',
),
'5bc2cb21' => array(
'javelin-behavior',
'javelin-stratcom',
),
'5c54cbf3' => array(
'javelin-behavior',
'javelin-stratcom',
'javelin-dom',
),
'5fefb143' => array(
'javelin-behavior',
'javelin-dom',
'javelin-workflow',
'javelin-stratcom',
),
'60821bc7' => array(
'javelin-behavior',
'javelin-stratcom',
'javelin-dom',
),
'6153c708' => array(
'javelin-behavior',
'javelin-stratcom',
'javelin-dom',
'javelin-workflow',
),
'61cbc29a' => array(
'javelin-magical-init',
'javelin-util',
),
'6453c869' => array(
'javelin-install',
'javelin-dom',
'javelin-fx',
),
'69adf288' => array(
'javelin-install',
),
'6b3dcf44' => array(
'javelin-install',
'javelin-util',
),
'6c2b09a2' => array(
'javelin-install',
'javelin-util',
),
'6d3e1947' => array(
'javelin-behavior',
'javelin-diffusion-locate-file-source',
'javelin-dom',
'javelin-typeahead',
'javelin-uri',
),
'6e8cefa4' => array(
'javelin-install',
'javelin-dom',
'javelin-util',
),
'6eff08aa' => array(
'javelin-install',
'javelin-util',
'javelin-stratcom',
Introduce CAN_EDIT for ExternalAccount, and make CAN_VIEW more liberal Summary: Fixes T3732. Ref T1205. Ref T3116. External accounts (like emails used as identities, Facebook accounts, LDAP accounts, etc.) are stored in "ExternalAccount" objects. Currently, we have a very restrictive `CAN_VIEW` policy for ExternalAccounts, to add an extra layer of protection to make sure users can't use them in unintended ways. For example, it would be bad if a user could link their Phabricator account to a Facebook account without proper authentication. All of the controllers which do sensitive things have checks anyway, but a restrictive CAN_VIEW provided an extra layer of protection. Se T3116 for some discussion. However, this means that when grey/external users take actions (via email, or via applications like Legalpad) other users can't load the account handles and can't see anything about the actor (they just see "Restricted External Account" or similar). Balancing these concerns is mostly about not making a huge mess while doing it. This seems like a reasonable approach: - Add `CAN_EDIT` on these objects. - Make that very restricted, but open up `CAN_VIEW`. - Require `CAN_EDIT` any time we're going to do something authentication/identity related. This is slightly easier to get wrong (forget CAN_EDIT) than other approaches, but pretty simple, and we always have extra checks in place anyway -- this is just a safety net. I'm not quite sure how we should identify external accounts, so for now we're just rendering "Email User" or similar -- clearly not a bug, but not identifying. We can figure out what to render in the long term elsewhere. Test Plan: - Viewed external accounts. - Linked an external account. - Refreshed an external account. - Edited profile picture. - Viewed sessions panel. - Published a bunch of stuff to Asana/JIRA. - Legalpad signature page now shows external accounts. {F171595} Reviewers: chad, btrahan Reviewed By: btrahan Subscribers: epriestley Maniphest Tasks: T3732, T1205, T3116 Differential Revision: https://secure.phabricator.com/D9767
2014-07-10 19:18:10 +02:00
),
'710f209e' => array(
'javelin-behavior',
'javelin-dom',
'javelin-util',
'javelin-stratcom',
'javelin-workflow',
'phuix-dropdown-menu',
'phuix-action-list-view',
'phuix-action-view',
'phabricator-phtize',
'changeset-view-manager',
),
'7319e029' => array(
'javelin-behavior',
'javelin-dom',
),
'76b9fc3e' => array(
'javelin-behavior',
'javelin-stratcom',
'javelin-workflow',
'javelin-dom',
'phabricator-draggable-list',
),
'76f4ebed' => array(
'javelin-install',
'javelin-reactor',
'javelin-util',
),
'77b1cf6f' => array(
'javelin-install',
'javelin-util',
),
'7814b593' => array(
'javelin-request',
'javelin-behavior',
'javelin-dom',
'javelin-router',
'javelin-util',
'phabricator-busy',
Provide a global router for Ajax requests Summary: Fixes T430. Fixes T4834. Obsoletes D7641. Currently, we do some things less-well than we could: - We just let the browser queue and prioritize requests, so if you load a revision with 50 changes and then click "Award Token", the action blocks until the changes load in most/all browsers. It would be better to prioritize this action and queue it immediately. - Similarly, changes tend to load in order, even if the user has clicked to a specific file. When the user expresses a preference for a specific file, we should prioritize it. - We show a spinning GIF when waiting on requests. This is appropriate for some types of reuqests, but distracting for others. To fix this: - Queue all (or, at least, most) requests into a new queue in JX.Router. - JX.Router handles prioritizing the requests. Principally: - You can submit a request with a specific priority (500 = general content loading, 1000 = default, 2000 = explicit user action) and JX.Router will get the higher stuff fired off sooner. - You can name requests and then adjust their prorities later, if the user expresses an interest in specific results. - Only use the spinner gif for "workflow" requests, which is bascially when the user clicked something and we're waiting on the server. I think it's useful and not-annoying in this case. - Don't show any status for draft requests. - For content requests, show a subtle hipster-style top loading bar. Test Plan: - Viewed a diff with 93 changes, and clicked award token. - Prior to this patch, the action took many many seconds to resolve. - After this patch, it resolves quickly. - Viewed a diff with 93 changes and saw a pleasant subtle hipster-style loading bar. - Viewed a diff with 93 changes and typed some draft text. Previews populated fairly quickly and there was no spinner. - Viewed a diff with 93 changes and clicked something with workflow, saw a spinner after a moment. - Viewed a diff with 93 changes and clicked a file in the table of contents near the end of the list. - Prior to this patch, it took a long time to show up. - After this patch, it loads directly. Reviewers: chad, btrahan Reviewed By: btrahan Subscribers: epriestley Maniphest Tasks: T430, T4834 Differential Revision: https://secure.phabricator.com/D8979
2014-05-05 19:57:42 +02:00
),
'7a68dda3' => array(
'owners-path-editor',
'javelin-behavior',
),
'7a9677fc' => array(
'phabricator-notification',
'javelin-stratcom',
'javelin-behavior',
),
'7b98d7c5' => array(
'javelin-behavior',
'javelin-dom',
'javelin-stratcom',
'javelin-util',
),
'7c273581' => array(
'javelin-behavior',
'javelin-stratcom',
'javelin-dom',
),
'7cbe244b' => array(
'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
),
'7e41274a' => array(
'javelin-install',
),
'7e8468ae' => array(
'javelin-install',
'javelin-dom',
'javelin-vector',
'javelin-request',
'javelin-uri',
),
'7ebaeed3' => array(
'herald-rule-editor',
'javelin-behavior',
),
'7ee2b591' => array(
'javelin-behavior',
'javelin-history',
),
'82ce2142' => array(
'aphront-typeahead-control-css',
),
'84845b5b' => array(
'javelin-behavior',
'javelin-dom',
'javelin-stratcom',
'javelin-workflow',
'phabricator-draggable-list',
),
'85ab3c8e' => array(
'javelin-behavior',
'javelin-dom',
'javelin-util',
'javelin-workflow',
'javelin-stratcom',
),
'85ea0626' => array(
'javelin-install',
Introduce CAN_EDIT for ExternalAccount, and make CAN_VIEW more liberal Summary: Fixes T3732. Ref T1205. Ref T3116. External accounts (like emails used as identities, Facebook accounts, LDAP accounts, etc.) are stored in "ExternalAccount" objects. Currently, we have a very restrictive `CAN_VIEW` policy for ExternalAccounts, to add an extra layer of protection to make sure users can't use them in unintended ways. For example, it would be bad if a user could link their Phabricator account to a Facebook account without proper authentication. All of the controllers which do sensitive things have checks anyway, but a restrictive CAN_VIEW provided an extra layer of protection. Se T3116 for some discussion. However, this means that when grey/external users take actions (via email, or via applications like Legalpad) other users can't load the account handles and can't see anything about the actor (they just see "Restricted External Account" or similar). Balancing these concerns is mostly about not making a huge mess while doing it. This seems like a reasonable approach: - Add `CAN_EDIT` on these objects. - Make that very restricted, but open up `CAN_VIEW`. - Require `CAN_EDIT` any time we're going to do something authentication/identity related. This is slightly easier to get wrong (forget CAN_EDIT) than other approaches, but pretty simple, and we always have extra checks in place anyway -- this is just a safety net. I'm not quite sure how we should identify external accounts, so for now we're just rendering "Email User" or similar -- clearly not a bug, but not identifying. We can figure out what to render in the long term elsewhere. Test Plan: - Viewed external accounts. - Linked an external account. - Refreshed an external account. - Edited profile picture. - Viewed sessions panel. - Published a bunch of stuff to Asana/JIRA. - Legalpad signature page now shows external accounts. {F171595} Reviewers: chad, btrahan Reviewed By: btrahan Subscribers: epriestley Maniphest Tasks: T3732, T1205, T3116 Differential Revision: https://secure.phabricator.com/D9767
2014-07-10 19:18:10 +02:00
),
'88236f00' => array(
'javelin-behavior',
'phabricator-keyboard-shortcut',
'javelin-stratcom',
),
'886fd850' => array(
'javelin-install',
'javelin-reactor-dom',
'javelin-view-html',
'javelin-view-interpreter',
'javelin-view-renderer',
),
'8a41885b' => array(
'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
),
'8b0ad945' => array(
'javelin-install',
'javelin-event',
'javelin-util',
'javelin-magical-init',
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
),
'8b3fd187' => array(
'javelin-install',
'javelin-util',
'javelin-request',
'javelin-typeahead-source',
),
'8d199d97' => array(
'javelin-behavior',
'javelin-dom',
'javelin-stratcom',
'phabricator-keyboard-shortcut',
),
'8ef9ab58' => array(
'javelin-behavior',
'javelin-dom',
'javelin-stratcom',
),
'8fc1c918' => array(
'javelin-behavior',
'javelin-uri',
'phabricator-notification',
),
'92eb531d' => array(
'javelin-behavior',
'javelin-dom',
'phabricator-drag-and-drop-file-upload',
'phabricator-textareautils',
),
'9414ff18' => array(
'javelin-behavior',
'javelin-resource',
'javelin-stratcom',
'javelin-workflow',
'javelin-util',
),
'97258e55' => array(
'javelin-install',
'javelin-stratcom',
'javelin-util',
'javelin-behavior',
'javelin-json',
'javelin-dom',
'javelin-resource',
'javelin-routable',
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
),
'988040b4' => array(
'javelin-install',
'javelin-dom',
'javelin-reactor-dom',
),
'9c2623f4' => array(
'javelin-behavior',
'javelin-stratcom',
'javelin-dom',
'javelin-workflow',
'phabricator-phtize',
'phabricator-drag-and-drop-file-upload',
'phabricator-draggable-list',
),
'9db3d160' => array(
'javelin-behavior',
'javelin-vector',
'javelin-dom',
),
'9f7309fb' => array(
'javelin-behavior',
'javelin-dom',
'javelin-util',
'javelin-request',
'phabricator-shaped-request',
),
'a155550f' => array(
'javelin-install',
'javelin-dom',
'javelin-reactor-dom',
),
'a4ae61bf' => array(
'javelin-install',
'javelin-dom',
'phabricator-notification',
),
'a5573bcd' => array(
'javelin-behavior',
'javelin-util',
'javelin-dom',
'javelin-stratcom',
'javelin-vector',
),
'a5b67173' => array(
'javelin-dom',
'javelin-util',
'javelin-stratcom',
'javelin-install',
),
'a5d7cf86' => array(
'javelin-dom',
),
'a80d0378' => array(
'javelin-behavior',
'javelin-stratcom',
'javelin-dom',
),
'a826c925' => array(
'javelin-behavior',
'javelin-aphlict',
'javelin-stratcom',
'javelin-request',
'javelin-uri',
'javelin-dom',
'javelin-json',
'javelin-router',
'javelin-util',
'phabricator-notification',
),
'a8d8459d' => array(
'javelin-behavior',
'javelin-dom',
'javelin-stratcom',
),
'a8da01f0' => array(
'javelin-behavior',
'javelin-uri',
'phabricator-keyboard-shortcut',
),
'a9f88de2' => array(
'javelin-behavior',
'javelin-dom',
'javelin-stratcom',
'javelin-workflow',
'javelin-fx',
'javelin-util',
),
'aa1733d0' => array(
'multirow-row-manager',
'javelin-install',
'path-typeahead',
'javelin-dom',
'javelin-util',
'phabricator-prefab',
),
'aa93c7b0' => array(
'javelin-install',
Introduce CAN_EDIT for ExternalAccount, and make CAN_VIEW more liberal Summary: Fixes T3732. Ref T1205. Ref T3116. External accounts (like emails used as identities, Facebook accounts, LDAP accounts, etc.) are stored in "ExternalAccount" objects. Currently, we have a very restrictive `CAN_VIEW` policy for ExternalAccounts, to add an extra layer of protection to make sure users can't use them in unintended ways. For example, it would be bad if a user could link their Phabricator account to a Facebook account without proper authentication. All of the controllers which do sensitive things have checks anyway, but a restrictive CAN_VIEW provided an extra layer of protection. Se T3116 for some discussion. However, this means that when grey/external users take actions (via email, or via applications like Legalpad) other users can't load the account handles and can't see anything about the actor (they just see "Restricted External Account" or similar). Balancing these concerns is mostly about not making a huge mess while doing it. This seems like a reasonable approach: - Add `CAN_EDIT` on these objects. - Make that very restricted, but open up `CAN_VIEW`. - Require `CAN_EDIT` any time we're going to do something authentication/identity related. This is slightly easier to get wrong (forget CAN_EDIT) than other approaches, but pretty simple, and we always have extra checks in place anyway -- this is just a safety net. I'm not quite sure how we should identify external accounts, so for now we're just rendering "Email User" or similar -- clearly not a bug, but not identifying. We can figure out what to render in the long term elsewhere. Test Plan: - Viewed external accounts. - Linked an external account. - Refreshed an external account. - Edited profile picture. - Viewed sessions panel. - Published a bunch of stuff to Asana/JIRA. - Legalpad signature page now shows external accounts. {F171595} Reviewers: chad, btrahan Reviewed By: btrahan Subscribers: epriestley Maniphest Tasks: T3732, T1205, T3116 Differential Revision: https://secure.phabricator.com/D9767
2014-07-10 19:18:10 +02:00
),
'ab836011' => array(
'javelin-behavior',
'javelin-dom',
'javelin-stratcom',
'javelin-workflow',
'javelin-util',
'phabricator-keyboard-shortcut',
),
'ab8d2723' => array(
'javelin-behavior',
'javelin-dom',
'phortune-credit-card-form',
),
'ad7a69ca' => array(
'javelin-install',
'javelin-util',
'javelin-stratcom',
'javelin-dom',
'javelin-vector',
),
'b1f0ccee' => array(
'javelin-install',
'javelin-dom',
'javelin-reactor-dom',
),
'b2b4fbaf' => array(
'javelin-behavior',
'javelin-dom',
'javelin-uri',
'javelin-request',
),
'b3a4b884' => array(
'javelin-behavior',
'phabricator-prefab',
),
'b3e7d692' => array(
'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
),
'b3ec3cfc' => array(
'javelin-install',
),
'b42eddc7' => array(
'javelin-install',
'javelin-dom',
'javelin-typeahead-preloaded-source',
'javelin-util',
),
'b4c30592' => array(
'javelin-install',
'javelin-reactor',
'javelin-util',
'javelin-reactor-node-calmer',
),
'b5c256b8' => array(
'javelin-install',
'javelin-dom',
),
'b6d401d6' => array(
'javelin-dom',
'javelin-dynval',
'javelin-reactor',
'javelin-reactornode',
'javelin-install',
'javelin-util',
),
'bba9eedf' => array(
'javelin-behavior',
'javelin-stratcom',
'javelin-dom',
),
'bbae734c' => 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',
),
'bd4c8dca' => array(
'javelin-install',
'javelin-util',
'javelin-dom',
'javelin-vector',
'javelin-stratcom',
),
'bdaf4d04' => array(
'javelin-behavior',
'javelin-dom',
'javelin-util',
'javelin-request',
),
'bdb3e4d0' => array(
'javelin-behavior',
'javelin-dom',
'javelin-stratcom',
'phabricator-tooltip',
'changeset-view-manager',
),
'be807912' => array(
'javelin-behavior',
'javelin-dom',
'javelin-util',
'phabricator-shaped-request',
),
'c4569c05' => array(
'javelin-magical-init',
'javelin-install',
'javelin-util',
'javelin-vector',
'javelin-stratcom',
),
'c60f4327' => array(
'javelin-stratcom',
'javelin-install',
'javelin-uri',
'javelin-util',
),
'ca3f91eb' => array(
'javelin-behavior',
'javelin-dom',
'javelin-stratcom',
'phabricator-phtize',
),
'd149e002' => array(
'javelin-stratcom',
'javelin-request',
'javelin-dom',
'javelin-vector',
'javelin-install',
'javelin-util',
'javelin-mask',
'javelin-uri',
'javelin-routable',
2014-01-27 22:55:01 +01:00
),
'd19198c8' => array(
'javelin-install',
'javelin-dom',
'javelin-util',
'javelin-dynval',
'javelin-reactor-dom',
),
'd254d646' => array(
'javelin-util',
),
'd2907473' => array(
'javelin-dom',
'javelin-util',
'javelin-stratcom',
'javelin-install',
'javelin-workflow',
'javelin-router',
'javelin-behavior-device',
'javelin-vector',
),
'd4a14807' => array(
'javelin-install',
'javelin-dom',
'javelin-view',
),
'd4bf1f3c' => array(
'javelin-behavior',
'javelin-dom',
'javelin-util',
'javelin-stratcom',
'javelin-workflow',
'phabricator-draggable-list',
),
'd4eecc63' => array(
'javelin-behavior',
'javelin-dom',
'javelin-stratcom',
),
'd6f54db0' => array(
'javelin-behavior',
'javelin-request',
'javelin-stratcom',
'javelin-dom',
),
'd712ac5f' => array(
'javelin-behavior',
'javelin-typeahead-ondemand-source',
'javelin-typeahead',
'javelin-dom',
'javelin-uri',
'javelin-util',
'javelin-stratcom',
'phabricator-prefab',
),
'd75709e6' => array(
'javelin-behavior',
'javelin-workflow',
'javelin-json',
'javelin-dom',
'phabricator-keyboard-shortcut',
),
'd835b03a' => array(
'javelin-behavior',
'javelin-dom',
'javelin-util',
'phabricator-shaped-request',
),
'dd7e8ef5' => array(
'javelin-behavior',
'javelin-dom',
'javelin-workflow',
'javelin-util',
'javelin-stratcom',
),
'de2e896f' => array(
'javelin-behavior',
'javelin-dom',
'javelin-typeahead',
'javelin-typeahead-ondemand-source',
'javelin-dom',
Introduce CAN_EDIT for ExternalAccount, and make CAN_VIEW more liberal Summary: Fixes T3732. Ref T1205. Ref T3116. External accounts (like emails used as identities, Facebook accounts, LDAP accounts, etc.) are stored in "ExternalAccount" objects. Currently, we have a very restrictive `CAN_VIEW` policy for ExternalAccounts, to add an extra layer of protection to make sure users can't use them in unintended ways. For example, it would be bad if a user could link their Phabricator account to a Facebook account without proper authentication. All of the controllers which do sensitive things have checks anyway, but a restrictive CAN_VIEW provided an extra layer of protection. Se T3116 for some discussion. However, this means that when grey/external users take actions (via email, or via applications like Legalpad) other users can't load the account handles and can't see anything about the actor (they just see "Restricted External Account" or similar). Balancing these concerns is mostly about not making a huge mess while doing it. This seems like a reasonable approach: - Add `CAN_EDIT` on these objects. - Make that very restricted, but open up `CAN_VIEW`. - Require `CAN_EDIT` any time we're going to do something authentication/identity related. This is slightly easier to get wrong (forget CAN_EDIT) than other approaches, but pretty simple, and we always have extra checks in place anyway -- this is just a safety net. I'm not quite sure how we should identify external accounts, so for now we're just rendering "Email User" or similar -- clearly not a bug, but not identifying. We can figure out what to render in the long term elsewhere. Test Plan: - Viewed external accounts. - Linked an external account. - Refreshed an external account. - Edited profile picture. - Viewed sessions panel. - Published a bunch of stuff to Asana/JIRA. - Legalpad signature page now shows external accounts. {F171595} Reviewers: chad, btrahan Reviewed By: btrahan Subscribers: epriestley Maniphest Tasks: T3732, T1205, T3116 Differential Revision: https://secure.phabricator.com/D9767
2014-07-10 19:18:10 +02:00
),
'e10f8e18' => array(
'javelin-behavior',
'javelin-dom',
'phabricator-prefab',
),
'e1ff79b1' => array(
'javelin-behavior',
'javelin-stratcom',
'javelin-dom',
),
'e32d14ab' => array(
'javelin-behavior',
'javelin-stratcom',
'javelin-dom',
'phabricator-phtize',
'phabricator-textareautils',
'javelin-workflow',
'javelin-vector',
),
'e379b58e' => array(
'javelin-behavior',
'javelin-stratcom',
'javelin-vector',
'javelin-dom',
'javelin-uri',
),
'e566f52c' => array(
'javelin-behavior',
'javelin-stratcom',
'javelin-dom',
Introduce CAN_EDIT for ExternalAccount, and make CAN_VIEW more liberal Summary: Fixes T3732. Ref T1205. Ref T3116. External accounts (like emails used as identities, Facebook accounts, LDAP accounts, etc.) are stored in "ExternalAccount" objects. Currently, we have a very restrictive `CAN_VIEW` policy for ExternalAccounts, to add an extra layer of protection to make sure users can't use them in unintended ways. For example, it would be bad if a user could link their Phabricator account to a Facebook account without proper authentication. All of the controllers which do sensitive things have checks anyway, but a restrictive CAN_VIEW provided an extra layer of protection. Se T3116 for some discussion. However, this means that when grey/external users take actions (via email, or via applications like Legalpad) other users can't load the account handles and can't see anything about the actor (they just see "Restricted External Account" or similar). Balancing these concerns is mostly about not making a huge mess while doing it. This seems like a reasonable approach: - Add `CAN_EDIT` on these objects. - Make that very restricted, but open up `CAN_VIEW`. - Require `CAN_EDIT` any time we're going to do something authentication/identity related. This is slightly easier to get wrong (forget CAN_EDIT) than other approaches, but pretty simple, and we always have extra checks in place anyway -- this is just a safety net. I'm not quite sure how we should identify external accounts, so for now we're just rendering "Email User" or similar -- clearly not a bug, but not identifying. We can figure out what to render in the long term elsewhere. Test Plan: - Viewed external accounts. - Linked an external account. - Refreshed an external account. - Edited profile picture. - Viewed sessions panel. - Published a bunch of stuff to Asana/JIRA. - Legalpad signature page now shows external accounts. {F171595} Reviewers: chad, btrahan Reviewed By: btrahan Subscribers: epriestley Maniphest Tasks: T3732, T1205, T3116 Differential Revision: https://secure.phabricator.com/D9767
2014-07-10 19:18:10 +02:00
),
'e5822781' => array(
'javelin-behavior',
'javelin-dom',
'javelin-json',
'javelin-workflow',
'javelin-magical-init',
),
'e5b406f9' => array(
'javelin-install',
'javelin-dom',
'javelin-view-visitor',
'javelin-util',
),
'e614d22b' => array(
'javelin-install',
'javelin-dom',
'javelin-vector',
'javelin-util',
),
'e9581f08' => array(
'javelin-behavior',
'javelin-stratcom',
'javelin-workflow',
'javelin-dom',
'phabricator-draggable-list',
),
'efe49472' => array(
'javelin-install',
'javelin-util',
),
'f0a41b9f' => array(
'javelin-behavior',
'javelin-dom',
'javelin-util',
'javelin-stratcom',
'javelin-workflow',
'javelin-behavior-device',
'javelin-history',
'javelin-vector',
'phabricator-shaped-request',
),
'f2441746' => array(
'javelin-dom',
'javelin-util',
'javelin-stratcom',
'javelin-install',
'javelin-request',
'javelin-workflow',
),
'f36e01af' => array(
'javelin-behavior',
'javelin-behavior-device',
'javelin-stratcom',
'javelin-vector',
'phabricator-hovercard',
),
'f3fef818' => array(
'javelin-behavior',
'javelin-dom',
'javelin-util',
'phuix-dropdown-menu',
'phuix-action-list-view',
'phuix-action-view',
'javelin-workflow',
),
'f51afce0' => array(
'javelin-behavior',
'javelin-request',
'javelin-stratcom',
'javelin-vector',
'javelin-dom',
'javelin-uri',
'javelin-behavior-device',
),
'f588412e' => array(
'javelin-behavior',
'javelin-dom',
'javelin-util',
'phabricator-prefab',
'multirow-row-manager',
'javelin-json',
),
Give files uploaded to objects a very restrictive view policy Summary: Fixes T4589. This implements much better policy behavior for files that aligns with user expectations. Currently, all files have permissive visibility. The new behavior is: - Files uploaded via drag-and-drop to the home page or file upload page get permissive visibility, for ease of quickly sharing things like screenshots. - Files uploaded via the manual file upload control get permissive visibility by default, but the user can select the policy they want at upload time in an explicit/obvious way. - Files uploaded via drag-and-drop anywhere else (e.g., comments or Pholio) get restricted visibility (only the uploader). - When the user applies a transaction to the object which uses the file, we attach the file to the object and punch a hole through the policies: if you can see the object, you can see the file. - This rule requires things to use ApplicationTransactions, which is why this took so long to fix. - The "attach stuff to the object" code has been in place for a long time and works correctly. I'll land D8498 after this lands, too. Test Plan: - Uploaded via global homepage upload and file drag-and-drop upload, saw permissive visibility. - Uploaded via comment area, saw restricted visibility. - After commenting, verified links were established and the file became visible to users who could see the attached object. - Verified Pholio (which is a bit of a special case) correctly attaches images. Reviewers: btrahan Reviewed By: btrahan Subscribers: epriestley Maniphest Tasks: T4589 Differential Revision: https://secure.phabricator.com/D10131
2014-08-02 23:46:13 +02:00
'f61aa8ec' => array(
'javelin-install',
'javelin-util',
'javelin-request',
'javelin-dom',
'javelin-uri',
'phabricator-file-upload',
),
'f6555212' => array(
'javelin-install',
'javelin-reactornode',
'javelin-util',
'javelin-reactor',
),
'f726d506' => array(
'javelin-behavior',
'javelin-stratcom',
'javelin-dom',
'javelin-history',
),
'f7379f45' => array(
'javelin-behavior',
'javelin-dom',
'javelin-util',
'phabricator-shaped-request',
),
'f7f1289f' => array(
'javelin-behavior',
'javelin-dom',
'javelin-stratcom',
),
'f7fc67ec' => array(
'javelin-install',
'javelin-typeahead',
'javelin-dom',
'javelin-request',
'javelin-typeahead-ondemand-source',
'javelin-util',
),
'f8248bc5' => array(
'javelin-behavior',
'javelin-dom',
'javelin-util',
'javelin-json',
'javelin-stratcom',
'phabricator-shaped-request',
),
'f9539603' => array(
'javelin-behavior',
'javelin-dom',
'javelin-stratcom',
'javelin-uri',
),
'fa0f4fc2' => array(
'javelin-behavior',
'javelin-dom',
'javelin-vector',
'javelin-magical-init',
),
'fcba4ecc' => array(
'javelin-install',
'javelin-util',
'javelin-dom',
'javelin-typeahead-normalizer',
),
'fe9a552f' => array(
'javelin-behavior',
'multirow-row-manager',
'javelin-dom',
'javelin-util',
'phabricator-prefab',
'javelin-json',
),
42126667 => array(
'javelin-behavior',
'javelin-dom',
'javelin-request',
),
48086888 => array(
'javelin-behavior',
'javelin-dom',
'javelin-workflow',
),
60479091 => array(
'phabricator-busy',
'javelin-behavior',
),
82439934 => array(
'javelin-behavior',
'javelin-dom',
'javelin-util',
'javelin-stratcom',
'javelin-workflow',
'phabricator-draggable-list',
),
),
'packages' => array(
'core.pkg.css' => array(
'phabricator-core-css',
'phabricator-zindex-css',
'phui-button-css',
'phabricator-standard-page-view',
'aphront-dialog-view-css',
'phui-form-view-css',
'aphront-panel-view-css',
'aphront-table-view-css',
'aphront-tokenizer-control-css',
'aphront-typeahead-control-css',
'aphront-list-filter-view-css',
'phabricator-remarkup-css',
'syntax-highlighting-css',
'aphront-pager-view-css',
'phabricator-transaction-view-css',
'aphront-tooltip-css',
'phabricator-flag-css',
'aphront-error-view-css',
'sprite-gradient-css',
'sprite-menu-css',
'sprite-apps-css',
'sprite-apps-large-css',
'phabricator-main-menu-view',
'phabricator-notification-css',
'phabricator-notification-menu-css',
'lightbox-attachment-css',
'phui-header-view-css',
'phabricator-filetree-view-css',
'phabricator-nav-view-css',
'phabricator-side-menu-view-css',
'phabricator-crumbs-view-css',
'phui-object-item-list-view-css',
'global-drag-and-drop-css',
'phui-spacing-css',
'phui-form-css',
'phui-icon-view-css',
'phabricator-application-launch-view-css',
'phabricator-action-list-view-css',
'phui-property-list-view-css',
'phui-tag-view-css',
'phui-list-view-css',
'font-fontawesome',
'phui-font-icon-base-css',
'sprite-main-header-css',
'phui-box-css',
'phui-object-box-css',
'phui-timeline-view-css',
'sprite-tokens-css',
'tokens-css',
'phui-status-list-view-css',
),
'core.pkg.js' => array(
'javelin-util',
'javelin-install',
'javelin-event',
'javelin-stratcom',
'javelin-behavior',
'javelin-resource',
'javelin-request',
'javelin-vector',
'javelin-dom',
'javelin-json',
'javelin-uri',
'javelin-workflow',
'javelin-mask',
'javelin-typeahead',
'javelin-typeahead-normalizer',
'javelin-typeahead-source',
'javelin-typeahead-preloaded-source',
'javelin-typeahead-ondemand-source',
'javelin-tokenizer',
'javelin-history',
'javelin-router',
'javelin-routable',
'javelin-behavior-aphront-basic-tokenizer',
'javelin-behavior-workflow',
'javelin-behavior-aphront-form-disable-on-submit',
'phabricator-keyboard-shortcut-manager',
'phabricator-keyboard-shortcut',
'javelin-behavior-phabricator-keyboard-shortcuts',
'javelin-behavior-refresh-csrf',
'javelin-behavior-phabricator-watch-anchor',
'javelin-behavior-phabricator-autofocus',
'phuix-dropdown-menu',
'phuix-action-list-view',
'phuix-action-view',
'phabricator-phtize',
'javelin-behavior-phabricator-oncopy',
'phabricator-tooltip',
'javelin-behavior-phabricator-tooltips',
'phabricator-prefab',
'javelin-behavior-device',
'javelin-behavior-toggle-class',
'javelin-behavior-lightbox-attachments',
'phabricator-busy',
'javelin-aphlict',
'phabricator-notification',
'javelin-behavior-aphlict-listen',
'javelin-behavior-phabricator-search-typeahead',
'javelin-behavior-konami',
'javelin-behavior-aphlict-dropdown',
'javelin-behavior-history-install',
'javelin-behavior-phabricator-gesture',
'javelin-behavior-phabricator-active-nav',
'javelin-behavior-phabricator-nav',
'javelin-behavior-phabricator-remarkup-assist',
'phabricator-textareautils',
'phabricator-file-upload',
'javelin-behavior-global-drag-and-drop',
'javelin-behavior-phabricator-reveal-content',
'phabricator-hovercard',
'javelin-behavior-phabricator-hovercards',
'javelin-color',
'javelin-fx',
'phabricator-draggable-list',
'javelin-behavior-phabricator-transaction-list',
'javelin-behavior-phabricator-show-all-transactions',
'javelin-behavior-phui-timeline-dropdown-menu',
'javelin-behavior-doorkeeper-tag',
),
'darkconsole.pkg.js' => array(
'javelin-behavior-dark-console',
'javelin-behavior-error-log',
),
'differential.pkg.css' => array(
'differential-core-view-css',
'differential-changeset-view-css',
'differential-results-table-css',
'differential-revision-history-css',
'differential-revision-list-css',
'differential-table-of-contents-css',
'differential-revision-comment-css',
'differential-revision-add-comment-css',
'phabricator-object-selector-css',
'phabricator-content-source-view-css',
'inline-comment-summary-css',
),
'differential.pkg.js' => array(
'phabricator-drag-and-drop-file-upload',
'phabricator-shaped-request',
'javelin-behavior-differential-feedback-preview',
'javelin-behavior-differential-edit-inline-comments',
'javelin-behavior-differential-populate',
'javelin-behavior-differential-show-more',
'javelin-behavior-differential-diff-radios',
'javelin-behavior-differential-comment-jump',
'javelin-behavior-differential-add-reviewers-and-ccs',
'javelin-behavior-differential-keyboard-navigation',
'javelin-behavior-aphront-drag-and-drop-textarea',
'javelin-behavior-phabricator-object-selector',
'javelin-behavior-repository-crossreference',
'javelin-behavior-load-blame',
'differential-inline-comment-editor',
'javelin-behavior-differential-dropdown-menus',
'javelin-behavior-differential-toggle-files',
'javelin-behavior-differential-user-select',
'javelin-behavior-aphront-more',
),
'diffusion.pkg.css' => array(
'diffusion-icons-css',
),
'diffusion.pkg.js' => array(
'javelin-behavior-diffusion-pull-lastmodified',
'javelin-behavior-diffusion-commit-graph',
'javelin-behavior-audit-preview',
),
'maniphest.pkg.css' => array(
'maniphest-task-summary-css',
),
'maniphest.pkg.js' => array(
'javelin-behavior-maniphest-batch-selector',
'javelin-behavior-maniphest-transaction-controls',
'javelin-behavior-maniphest-transaction-preview',
'javelin-behavior-maniphest-transaction-expand',
'javelin-behavior-maniphest-subpriority-editor',
'javelin-behavior-maniphest-list-editor',
),
),
);