| [ Index ] |
PHP Cross Reference of Phabricator |
[Source view] [Print] [Project Stats]
A @{class:PhabricatorQuery} which filters results according to visibility policies for the querying user. Broadly, this class allows you to implement a query that returns only objects the user is allowed to see. $results = id(new ExampleQuery()) ->setViewer($user) ->withConstraint($example) ->execute();
| File Size: | 649 lines (19 kb) |
| Included or required: | 0 times |
| Referenced: | 0 times |
| Includes or requires: | 0 files |
| setViewer(PhabricatorUser $viewer) X-Ref |
| Set the viewer who is executing the query. Results will be filtered according to the viewer's capabilities. You must set a viewer to execute a policy query. param: PhabricatorUser The viewing user. return: this |
| getViewer() X-Ref |
| Get the query's viewer. return: PhabricatorUser The viewing user. |
| setParentQuery(PhabricatorPolicyAwareQuery $query) X-Ref |
| Set the parent query of this query. This is useful for nested queries so that configuration like whether or not to raise policy exceptions is seamlessly passed along to child queries. return: this |
| getParentQuery() X-Ref |
| Get the parent query. See @{method:setParentQuery} for discussion. return: PhabricatorPolicyAwareQuery The parent query. |
| setRaisePolicyExceptions($bool) X-Ref |
| Hook to configure whether this query should raise policy exceptions. return: this |
| shouldRaisePolicyExceptions() X-Ref |
return: bool |
| requireCapabilities(array $capabilities) X-Ref |
| executeOne() X-Ref |
| Execute the query, expecting a single result. This method simplifies loading objects for detail pages or edit views. // Load one result by ID. $obj = id(new ExampleQuery()) ->setViewer($user) ->withIDs(array($id)) ->executeOne(); if (!$obj) { return new Aphront404Response(); } If zero results match the query, this method returns `null`. If one result matches the query, this method returns that result. If two or more results match the query, this method throws an exception. You should use this method only when the query constraints guarantee at most one match (e.g., selecting a specific ID or PHID). If one result matches the query but it is caught by the policy filter (for example, the user is trying to view or edit an object which exists but which they do not have permission to see) a policy exception is thrown. return: mixed Single result, or null. |
| execute() X-Ref |
| Execute the query, loading all visible results. return: list<PhabricatorPolicyInterface> Result objects. |
| getPolicyFilter() X-Ref |
| No description |
| getRequiredCapabilities() X-Ref |
| No description |
| applyPolicyFilter(array $objects, array $capabilities) X-Ref |
| No description |
| didRejectResult(PhabricatorPolicyInterface $object) X-Ref |
| No description |
| addPolicyFilteredPHIDs(array $phids) X-Ref |
| No description |
| getPolicyFilteredPHIDs() X-Ref |
| Return a map of all object PHIDs which were loaded in the query but filtered out by policy constraints. This allows a caller to distinguish between objects which do not exist (or, at least, were filtered at the content level) and objects which exist but aren't visible. return: map<phid, phid> Map of object PHIDs which were filtered |
| putObjectsInWorkspace(array $objects) X-Ref |
| Put a map of objects into the query workspace. Many queries perform subqueries, which can eventually end up loading the same objects more than once (often to perform policy checks). For example, loading a user may load the user's profile image, which might load the user object again in order to verify that the viewer has permission to see the file. The "query workspace" allows queries to load objects from elsewhere in a query block instead of refetching them. When using the query workspace, it's important to obey two rules: **Never put objects into the workspace which the viewer may not be able to see**. You need to apply all policy filtering //before// putting objects in the workspace. Otherwise, subqueries may read the objects and use them to permit access to content the user shouldn't be able to view. **Fully enrich objects pulled from the workspace.** After pulling objects from the workspace, you still need to load and attach any additional content the query requests. Otherwise, a query might return objects without requested content. Generally, you do not need to update the workspace yourself: it is automatically populated as a side effect of objects surviving policy filtering. param: map<phid, PhabricatorPolicyInterface> Objects to add to the query return: this |
| getObjectsFromWorkspace(array $phids) X-Ref |
| Retrieve objects from the query workspace. For more discussion about the workspace mechanism, see @{method:putObjectsInWorkspace}. This method searches both the current query's workspace and the workspaces of parent queries. param: list<phid> List of PHIDs to retrieve. return: this |
| getWorkspaceMapForPage(array $results) X-Ref |
| Convert a result page to a `<phid, PhabricatorPolicyInterface>` map. param: list<PhabricatorPolicyInterface> Objects. return: map<phid, PhabricatorPolicyInterface> Map of objects which can |
| getRawResultLimit() X-Ref |
| Get the number of results @{method:loadPage} should load. If the value is 0, @{method:loadPage} should load all available results. return: int The number of results to load, or 0 for all results. |
| willExecute() X-Ref |
| Hook invoked before query execution. Generally, implementations should reset any internal cursors. return: void |
| willFilterPage(array $page) X-Ref |
| Hook for applying a page filter prior to the privacy filter. This allows you to drop some items from the result set without creating problems with pagination or cursor updates. You can also load and attach data which is required to perform policy filtering. Generally, you should load non-policy data and perform non-policy filtering later, in @{method:didFilterPage}. Strictly fewer objects will make it that far (so the program will load less data) and subqueries from that context can use the query workspace to further reduce query load. This method will only be called if data is available. Implementations do not need to handle the case of no results specially. param: list<wild> Results from `loadPage()`. return: list<PhabricatorPolicyInterface> Objects for policy filtering. |
| didFilterPage(array $page) X-Ref |
| Hook for performing additional non-policy loading or filtering after an object has satisfied all policy checks. Generally, this means loading and attaching related data. Subqueries executed during this phase can use the query workspace, which may improve performance or make circular policies resolvable. Data which is not necessary for policy filtering should generally be loaded here. This callback can still filter objects (for example, if attachable data is discovered to not exist), but should not do so for policy reasons. This method will only be called if data is available. Implementations do not need to handle the case of no results specially. param: list<wild> Results from @{method:willFilterPage()}. return: list<PhabricatorPolicyInterface> Objects after additional |
| didFilterResults(array $results) X-Ref |
| Hook for removing filtered results from alternate result sets. This hook will be called with any objects which were returned by the query but filtered for policy reasons. The query should remove them from any cached or partial result sets. param: list<wild> List of objects that should not be returned by alternate return: void |
| didLoadResults(array $results) X-Ref |
| Hook for applying final adjustments before results are returned. This is used by @{class:PhabricatorCursorPagedPolicyAwareQuery} to reverse results that are queried during reverse paging. param: list<PhabricatorPolicyInterface> Query results. return: list<PhabricatorPolicyInterface> Final results. |
| shouldDisablePolicyFiltering() X-Ref |
| Allows a subclass to disable policy filtering. This method is dangerous. It should be used only if the query loads data which has already been filtered (for example, because it wraps some other query which uses normal policy filtering). return: bool True to disable all policy filtering. |
| canViewerUseQueryApplication() X-Ref |
| Determine if the viewer has permission to use this query's application. For queries which aren't part of an application, this method always returns true. return: bool True if the viewer has application-level permission to |
| Generated: Sun Nov 30 09:20:46 2014 | Cross-referenced by PHPXref 0.7.1 |