Bug 729965
Summary: | Error in server log on clicking a resource link by a user having access to the resource | ||||||
---|---|---|---|---|---|---|---|
Product: | [Other] RHQ Project | Reporter: | Sunil Kondkar <skondkar> | ||||
Component: | Core UI | Assignee: | Ian Springer <ian.springer> | ||||
Status: | CLOSED CURRENTRELEASE | QA Contact: | Mike Foley <mfoley> | ||||
Severity: | medium | Docs Contact: | |||||
Priority: | urgent | ||||||
Version: | 4.1 | CC: | ccrouch, hrupp, ian.springer | ||||
Target Milestone: | --- | ||||||
Target Release: | --- | ||||||
Hardware: | Unspecified | ||||||
OS: | Unspecified | ||||||
Whiteboard: | |||||||
Fixed In Version: | Doc Type: | Bug Fix | |||||
Doc Text: | Story Points: | --- | |||||
Clone Of: | Environment: | ||||||
Last Closed: | 2012-02-07 19:28:45 UTC | Type: | --- | ||||
Regression: | --- | Mount Type: | --- | ||||
Documentation: | --- | CRM: | |||||
Verified Versions: | Category: | --- | |||||
oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |||||
Cloudforms Team: | --- | Target Upstream Version: | |||||
Embargoed: | |||||||
Bug Depends On: | |||||||
Bug Blocks: | 729848, 730796 | ||||||
Attachments: |
|
Description
Sunil Kondkar
2011-08-11 12:19:28 UTC
Created attachment 517781 [details]
Screenshot
[master b7d5d48] (http://git.fedorahosted.org/git/?p=rhq/rhq.git;a=commit;h=b7d5d48) fixes the issue with a non-admin user not being able to view Resources they are authorized to view. It turned out to be a regression caused by the recent drift work. As for the user being able to click on Ancestry Resource links for Resources they are not authorized to view, this is a known issue and one we do not currently plan on fixing. Here's a discussion I had w/ Jay on IRC: (03:09:55 PM) ips: jshaughn1: part of a bz i'm looking at is that resources in the ancestry field are links even if the current user doesn't have authz to view the resources (03:10:46 PM) jshaughn1: ips: that's a known (03:10:51 PM) ips: was that an oversight or something you chose not to address for some reason? (03:10:58 PM) jshaughn1: I'm not sure we really want to do anything about that (03:11:17 PM) jshaughn1: yeah, it didn't seem worthwhile to worry about that (03:11:27 PM) jshaughn1: it's true they can get a lazy exception (03:11:38 PM) jshaughn1: if they try to nav to a place they can't get to (03:11:39 PM) ips: yeah, it seems you could deal with it either by including another boolean in the ancestry field (eg - authorizedToView) (03:11:52 PM) ips: or making some extra calls to the server from coregui (03:12:02 PM) jshaughn1: it's more a matter of having to take that hit (03:12:21 PM) jshaughn1: for what I perceive is little gain (03:12:32 PM) mazz: wouldn't that require additional server-side access to determine that? (03:12:34 PM) ips: the former would suck because you'd have to worry about refreshing that boolean whenever perms got changed (03:12:43 PM) jshaughn1: yes, ips (03:12:51 PM) jshaughn1: so, that leads to the next topic (03:13:06 PM) ips: and the latter would suck for the usual hassle of making multiple async calls (03:13:10 PM) jshaughn1: in my mind we would perhaps be able to do this efficiently if/when we flatten permissions (03:13:32 PM) jshaughn1: pre-computing the permission matrix would make it potentially feasible (03:14:05 PM) jshaughn1: I'm pretty much pro-flattening the user-resource-perm mappings (03:14:09 PM) ips: like in a bitmap as a field on Resource? (03:14:46 PM) jshaughn1: probably not that, more like as a straight relational representation that would make for easy efficient joins (03:15:03 PM) ips: well i guess they would be different per Role (03:15:14 PM) jshaughn1: no, I think it would be the union (03:15:44 PM) jshaughn1: basically flattening todays role-group-resource-user perm joins (03:16:12 PM) jshaughn1: and keeping it up to date on perm and inventory changes (03:17:38 PM) jshaughn1: and then, perhaps, updating the ancestry pre-compute stuff to maybe do the perm checking in advance, not sure. (03:18:10 PM) jshaughn1: not sure about tying the two precomputes together or not (03:18:24 PM) ips: besides the ancestry use case, what other advantages would there be? (03:18:34 PM) ips: just the improved perf of not having to do those joins? (03:21:39 PM) pilhuhn: jshaughn1 +1 (03:21:52 PM) jshaughn1: ips - yes (03:21:53 PM) pilhuhn: ips we are doing those crappy joins on basically every server call I noticed another related issue where when you to try to view a Resource you don't have authz to view, you get a nasty uncaught server exception error. This is one I think we should fix. See https://bugzilla.redhat.com/show_bug.cgi?id=730112. Verified on build#279 (Version: 4.1.0-SNAPSHOT Build Number: fb70d80) When the authorized user clicks on the resource name link in Inventory tab of the group or clicks on the resource name link in 'Inventory'->Resources->Servers->resource name link, the resource tree is rendered and there is no error in server log. Marking as verified. changing status of VERIFIED BZs for JON 2.4.2 and JON 3.0 to CLOSED/CURRENTRELEASE |