2011-01-25 20:31:40 +01:00
|
|
|
/**
|
|
|
|
|
* @provides aphront-dialog-view-css
|
|
|
|
|
*/
|
|
|
|
|
|
|
|
|
|
.aphront-dialog-view {
|
2017-08-10 05:01:31 +02:00
|
|
|
width: 580px;
|
2013-06-18 07:02:16 +02:00
|
|
|
margin: 32px auto 16px;
|
2013-09-02 17:10:47 +02:00
|
|
|
border: 1px solid {$lightblueborder};
|
2015-05-08 06:18:57 +02:00
|
|
|
border-radius: 3px;
|
2017-07-17 20:08:17 +02:00
|
|
|
background-color: {$page.content};
|
2016-02-11 21:54:48 +01:00
|
|
|
}
|
|
|
|
|
|
|
|
|
|
.jx-client-dialog .aphront-dialog-view {
|
2016-02-09 16:23:53 +01:00
|
|
|
box-shadow: {$dropshadow};
|
2013-06-17 01:31:14 +02:00
|
|
|
}
|
|
|
|
|
|
2013-06-18 07:02:16 +02:00
|
|
|
.device-phone .aphront-dialog-view {
|
|
|
|
|
margin: 16px;
|
|
|
|
|
width: auto;
|
|
|
|
|
}
|
|
|
|
|
|
2013-06-17 01:31:14 +02:00
|
|
|
.aphront-dialog-view-standalone {
|
2016-02-09 16:23:53 +01:00
|
|
|
margin: 32px auto;
|
2013-01-23 06:16:49 +01:00
|
|
|
}
|
|
|
|
|
|
2015-05-08 06:18:57 +02:00
|
|
|
.aphront-dialog-head {
|
2015-05-23 00:35:09 +02:00
|
|
|
padding: 12px 12px 0 12px;
|
2011-01-25 20:31:40 +01:00
|
|
|
}
|
|
|
|
|
|
2014-06-08 06:43:04 +02:00
|
|
|
.aphront-dialog-flush .aphront-dialog-body {
|
|
|
|
|
padding: 0;
|
|
|
|
|
}
|
|
|
|
|
|
2011-06-10 00:28:29 +02:00
|
|
|
.aphront-dialog-view-width-form {
|
2017-08-10 05:01:31 +02:00
|
|
|
width: 820px;
|
2011-06-10 00:28:29 +02:00
|
|
|
}
|
2011-01-25 20:31:40 +01:00
|
|
|
|
2012-12-11 23:01:51 +01:00
|
|
|
.aphront-dialog-view-width-full {
|
|
|
|
|
width: 90%;
|
2016-02-09 16:23:53 +01:00
|
|
|
max-width: 1040px;
|
2012-12-11 23:01:51 +01:00
|
|
|
}
|
|
|
|
|
|
2011-01-25 20:31:40 +01:00
|
|
|
.aphront-dialog-body {
|
2017-07-17 20:08:17 +02:00
|
|
|
background: {$page.content};
|
2013-06-18 07:02:16 +02:00
|
|
|
padding: 16px;
|
2011-01-25 20:31:40 +01:00
|
|
|
border: none;
|
|
|
|
|
}
|
|
|
|
|
|
2016-09-15 03:34:11 +02:00
|
|
|
.device-phone .aphront-dialog-body {
|
|
|
|
|
padding: 8px;
|
|
|
|
|
}
|
|
|
|
|
|
2011-01-25 20:31:40 +01:00
|
|
|
.aphront-dialog-tail {
|
|
|
|
|
border: none;
|
2016-06-21 02:29:56 +02:00
|
|
|
position: relative;
|
2013-09-02 22:57:48 +02:00
|
|
|
background: {$lightgreybackground};
|
2013-06-18 07:02:16 +02:00
|
|
|
padding: 8px 16px;
|
2015-02-19 17:45:37 +01:00
|
|
|
border-top: 1px solid {$thinblueborder};
|
2015-06-29 21:49:21 +02:00
|
|
|
border-bottom-left-radius: 3px;
|
|
|
|
|
border-bottom-right-radius: 3px;
|
2013-06-17 01:31:14 +02:00
|
|
|
}
|
|
|
|
|
|
2016-06-21 02:29:56 +02:00
|
|
|
.device .aphront-dialog-resize {
|
|
|
|
|
/* No resizing on devices. */
|
|
|
|
|
display: none;
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
.aphront-dialog-resize {
|
|
|
|
|
position: absolute;
|
|
|
|
|
right: -4px;
|
|
|
|
|
bottom: -4px;
|
|
|
|
|
width: 18px;
|
|
|
|
|
height: 18px;
|
|
|
|
|
background-image: url(/rsrc/image/resize.png);
|
|
|
|
|
background-size: 100%;
|
|
|
|
|
cursor: nwse-resize;
|
|
|
|
|
pointer-events: all;
|
|
|
|
|
}
|
|
|
|
|
|
2013-06-17 01:31:14 +02:00
|
|
|
.aphront-dialog-foot {
|
2013-06-18 07:02:16 +02:00
|
|
|
padding: 6px 0;
|
|
|
|
|
float: left;
|
2011-01-25 20:31:40 +01:00
|
|
|
}
|
|
|
|
|
|
|
|
|
|
.aphront-dialog-tail button,
|
|
|
|
|
.aphront-dialog-tail a.button {
|
|
|
|
|
float: right;
|
2013-08-26 20:53:11 +02:00
|
|
|
margin-left: 8px;
|
2011-01-25 20:31:40 +01:00
|
|
|
}
|
|
|
|
|
|
2011-02-02 00:52:04 +01:00
|
|
|
.jx-client-dialog {
|
2015-05-08 06:18:57 +02:00
|
|
|
position: absolute;
|
|
|
|
|
width: 100%;
|
2011-02-02 00:52:04 +01:00
|
|
|
}
|
|
|
|
|
|
|
|
|
|
.jx-mask {
|
2015-05-03 00:26:58 +02:00
|
|
|
opacity: .7;
|
|
|
|
|
background: #292f33;
|
2013-08-26 20:53:11 +02:00
|
|
|
position: fixed;
|
|
|
|
|
top: 0;
|
|
|
|
|
left: 0;
|
|
|
|
|
right: 0;
|
|
|
|
|
bottom: 0;
|
2012-10-23 20:39:33 +02:00
|
|
|
}
|
|
|
|
|
|
|
|
|
|
.jx-dark-mask {
|
2015-05-03 00:26:58 +02:00
|
|
|
background: #292f33;
|
|
|
|
|
opacity: 0.95;
|
2011-02-02 00:52:04 +01:00
|
|
|
}
|
2011-02-17 23:32:01 +01:00
|
|
|
|
2016-11-18 22:23:41 +01:00
|
|
|
.jx-white-mask {
|
|
|
|
|
background: #fff;
|
|
|
|
|
opacity: 1;
|
|
|
|
|
}
|
|
|
|
|
|
2016-11-15 19:09:52 +01:00
|
|
|
.jx-date-mask {
|
|
|
|
|
background: #292f33;
|
|
|
|
|
opacity: 0.5;
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
.device-desktop .jx-date-mask {
|
|
|
|
|
display: none;
|
|
|
|
|
}
|
|
|
|
|
|
2011-02-17 23:32:01 +01:00
|
|
|
.aphront-exception-dialog {
|
|
|
|
|
width: 95%;
|
|
|
|
|
}
|
|
|
|
|
|
2011-08-17 23:29:53 +02:00
|
|
|
.aphront-exception-dialog .exception-message {
|
|
|
|
|
font-size: 14px;
|
2015-02-19 17:45:37 +01:00
|
|
|
background: {$sh-yellowbackground};
|
|
|
|
|
border: 1px solid {$sh-yellowborder};
|
|
|
|
|
padding: 12px;
|
2012-04-09 00:07:34 +02:00
|
|
|
white-space: pre-wrap;
|
2011-08-17 23:29:53 +02:00
|
|
|
}
|
|
|
|
|
|
|
|
|
|
.aphront-exception-dialog .exception-trace {
|
2015-02-19 17:45:37 +01:00
|
|
|
margin-top: 16px;
|
2011-08-17 23:29:53 +02:00
|
|
|
}
|
Add basic per-object privacy policies
Summary:
Provides a basic start for access policies. Objects expose various capabilities, like CAN_VIEW, CAN_EDIT, etc., and set a policy for each capability. We currently implement three policies, PUBLIC (anyone, including logged-out), USERS (any logged-in) and NOONE (nobody). There's also a way to provide automatic capability grants (e.g., the owner of an object can always see it, even if some capability is set to "NOONE"), but I'm not sure how great the implementation feels and it might change.
Most of the code here is providing a primitive for efficient policy-aware list queries. The problem with doing queries naively is that you have to do crazy amounts of filtering, e.g. to show the user page 6, you need to filter at least 600 objects (and likely more) before you can figure out which ones are 500-600 for them. You can't just do "LIMIT 500, 100" because that might have only 50 results, or no results. Instead, the query looks like "WHERE id > last_visible_id", and then we fetch additional pages as necessary to satisfy the request.
The general idea is that we move all data access to Query classes and have them do object filtering. The ID paging primitive allows efficient paging in most cases, and the executeOne() method provides a concise way to do policy checks for edit/view screens.
We'll probably end up with mostly broader policy UIs or configuration-based policies, but there are at least a few cases for per-object privacy (e.g., marking tasks as "Security", and restricting things to the members of projects) so I figured we'd start with a flexible primitive and the simplify it in the UI where we can.
Test Plan: Unit tests, played around in the UI with various policy settings.
Reviewers: btrahan, vrana, jungejason
Reviewed By: btrahan
CC: aran
Maniphest Tasks: T603
Differential Revision: https://secure.phabricator.com/D2210
2012-04-14 19:13:29 +02:00
|
|
|
|
|
|
|
|
.aphront-access-dialog {
|
|
|
|
|
width: 50%;
|
|
|
|
|
}
|
2013-09-27 17:43:41 +02:00
|
|
|
|
2016-11-11 22:26:38 +01:00
|
|
|
.aphront-policy-explain-dialog .aphront-dialog-body {
|
Require several advanced postgraduate degrees to understand object policies
Summary:
Fixes T11836. See some prior discussion in T8376#120613.
The policy hint in headers in the UI is not exhaustive, and can not reasonably be exhaustive. For example, on a revision, it may say "All Users", but really mean "All users who can see the space this object is in and the repository it belongs to, plus the revision author and reviewers".
These rules are explained if you click (and, often, in the documentation), but "All Users" is still at least somewhat misleading.
I don't think there's any perfect solution here that balances the needs of both new and experienced users perfectly, but this change tries to do a bit better about avoiding cases where we say something very open (like "All Users") when the real policy is not very open.
Specifically, I've made these changes to the header:
- Spaces are now listed in the tag, so it will say `(S3 > All Users)` instead of `(All Users)`. They're already listed in the header, this just makes it more explicit that Spaces are a policy container and part of the view policy.
- Extended policy objects are now listed in the tag, so it will say `(S3 > rARC > All Users)` for a revision in the Arcanist repository which is also in Space 3.
- Objects can now provide a "Policy Codex", which is an object that represents a rulebook of more sophisticated policy descriptions. This codex can replace the tag with something else.
- Imported calendar events now say "Uses Import Policy" instead of, e.g., "All Users".
I've made these changes to the policy dialog:
- Split it into more visually separate sections.
- Added an explicit section for extended policies ("You must also have access to these other objects: ...").
- Broken the object policy rules into a "Special Rules" section (for rules like "you can only see a revision if you can see the repository it is part of") and an "Object Policy" section (for the actual object policy).
- Tried to make it a little more readable?
- The new policy dialogs are great to curl up with in front of a fire with a nice cup of cocoa.
I've made these changes to infrastructure:
- Implementing `PhabricatorPolicyInterface` no longer requires you to implement `describeAutomaticCapability()`.
- Instead, implement `PhabricatorPolicyCodexInterface` and return a `PhabricatorPolicyCodex` object.
- This "codex" is a policy rulebook which can set all the policy icons, labels, colors, rules, etc., to properly explain complex policies.
- Broadly, the old method was usually either not useful (most objects have no special rules) or not powerful enough (objects with special rules often need to do more in order to explain them).
Test Plan:
{F1912860}
{F1912861}
{F1912862}
{F1912863}
Reviewers: chad
Reviewed By: chad
Subscribers: avivey
Maniphest Tasks: T11836
Differential Revision: https://secure.phabricator.com/D16830
2016-11-09 19:02:25 +01:00
|
|
|
padding: 0 12px;
|
|
|
|
|
}
|
|
|
|
|
|
Allow applications to define new policy capabilities
Summary:
Ref T603. I want to let applications define new capabilities (like "can manage global rules" in Herald) and get full support for them, including reasonable error strings in the UI.
Currently, this is difficult for a couple of reasons. Partly this is just a code organization issue, which is easy to fix. The bigger thing is that we have a bunch of strings which depend on both the policy and capability, like: "You must be an administrator to view this object." "Administrator" is the policy, and "view" is the capability.
That means every new capability has to add a string for each policy, and every new policy (should we introduce any) needs to add a string for each capability. And we can't do any piecemeal "You must be a {$role} to {$action} this object" becuase it's impossible to translate.
Instead, make all the strings depend on //only// the policy, //only// the capability, or //only// the object type. This makes the dialogs read a little more strangely, but I think it's still pretty easy to understand, and it makes adding new stuff way way easier.
Also provide more context, and more useful exception messages.
Test Plan:
- See screenshots.
- Also triggered a policy exception and verified it was dramatically more useful than it used to be.
Reviewers: btrahan, chad
Reviewed By: btrahan
CC: chad, aran
Maniphest Tasks: T603
Differential Revision: https://secure.phabricator.com/D7260
2013-10-07 22:28:58 +02:00
|
|
|
.aphront-policy-rejection {
|
|
|
|
|
font-weight: bold;
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
.aphront-capability-details {
|
|
|
|
|
margin: 20px 0 4px;
|
|
|
|
|
}
|
Improve handling of email verification and "activated" accounts
Summary:
Small step forward which improves existing stuff or lays groudwork for future stuff:
- Currently, to check for email verification, we have to single-query the email address on every page. Instead, denoramlize it into the user object.
- Migrate all the existing users.
- When the user verifies an email, mark them as `isEmailVerified` if the email is their primary email.
- Just make the checks look at the `isEmailVerified` field.
- Add a new check, `isUserActivated()`, to cover email-verified plus disabled. Currently, a non-verified-but-not-disabled user could theoretically use Conduit over SSH, if anyone deployed it. Tighten that up.
- Add an `isApproved` flag, which is always true for now. In a future diff, I want to add a default-on admin approval queue for new accounts, to prevent configuration mistakes. The way it will work is:
- When the queue is enabled, registering users are created with `isApproved = false`.
- Admins are sent an email, "[Phabricator] New User Approval (alincoln)", telling them that a new user is waiting for approval.
- They go to the web UI and approve the user.
- Manually-created accounts are auto-approved.
- The email will have instructions for disabling the queue.
I think this queue will be helpful for new installs and give them peace of mind, and when you go to disable it we have a better opportunity to warn you about exactly what that means.
Generally, I want to improve the default safety of registration, since if you just blindly coast through the path of least resistance right now your install ends up pretty open, and realistically few installs are on VPNs.
Test Plan:
- Ran migration, verified `isEmailVerified` populated correctly.
- Created a new user, checked DB for verified (not verified).
- Verified, checked DB (now verified).
- Used Conduit, People, Diffusion.
Reviewers: btrahan
Reviewed By: btrahan
CC: chad, aran
Differential Revision: https://secure.phabricator.com/D7572
2013-11-12 23:37:04 +01:00
|
|
|
|
|
|
|
|
.aphront-dialog-view-paragraph + .aphront-dialog-view-paragraph {
|
|
|
|
|
margin-top: 16px;
|
|
|
|
|
}
|
2014-06-08 06:43:04 +02:00
|
|
|
|
2019-08-02 18:15:06 +02:00
|
|
|
.aphront-dialog-view-command {
|
|
|
|
|
padding: 8px 16px;
|
|
|
|
|
background: {$greybackground};
|
|
|
|
|
}
|
|
|
|
|
|
2016-12-14 20:35:51 +01:00
|
|
|
.device-desktop .aphront-dialog-flush .phui-oi-list-view {
|
2014-06-08 06:43:04 +02:00
|
|
|
margin: 0;
|
|
|
|
|
padding: 0;
|
|
|
|
|
}
|
|
|
|
|
|
2016-12-14 20:35:51 +01:00
|
|
|
.aphront-dialog-flush .phui-oi-list-view.phui-object-list-stackable
|
|
|
|
|
.phui-oi {
|
2014-06-08 06:43:04 +02:00
|
|
|
border: 0;
|
|
|
|
|
}
|
|
|
|
|
|
2016-12-14 20:35:51 +01:00
|
|
|
.aphront-dialog-flush .phui-oi-list-view.phui-object-list-stackable
|
|
|
|
|
.phui-oi-frame {
|
2014-06-08 06:43:04 +02:00
|
|
|
border: 0;
|
|
|
|
|
border-top: 1px solid {$thinblueborder};
|
|
|
|
|
}
|
2015-10-27 20:32:35 +01:00
|
|
|
|
|
|
|
|
.aphront-dialog-object-list .phui-object-box {
|
|
|
|
|
border: none;
|
|
|
|
|
padding: 0;
|
|
|
|
|
margin: 0;
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
.aphront-dialog-object-list .aphront-dialog-body {
|
|
|
|
|
padding: 0 12px;
|
|
|
|
|
}
|
2016-11-07 20:19:08 +01:00
|
|
|
|
|
|
|
|
.aphront-dialog-tab-group .aphront-dialog-body {
|
|
|
|
|
padding: 0 12px;
|
|
|
|
|
}
|
