#9723 closed enhancement (fixed)
Heading of BlogList macro is still shown when a user doesn't have BLOG_VIEW permission
Reported by: | Ryan J Ollos | Owned by: | Ryan J Ollos |
---|---|---|---|
Priority: | normal | Component: | FullBlogPlugin |
Severity: | normal | Keywords: | |
Cc: | Trac Release: | 0.12 |
Attachments (1)
Change History (11)
Changed 13 years ago by
Attachment: | TracBlogMacro.png added |
---|
comment:1 Changed 13 years ago by
Type: | defect → enhancement |
---|
comment:2 Changed 13 years ago by
My reason for posting this as a defect was thinking that if a user doesn't have BLOG_VIEW
permission, they shouldn't see any components of the FullBlogPlugin.
If I'm following you, all of the other examples you gave apply to cases that a user DOES have BLOG_VIEW
permissions, so I'm not seeing how the change I suggested would affect those other users and use-cases.
comment:3 Changed 13 years ago by
Sorry, I forgot the most important example: That the user does not have general BLOG_VIEW
but a security policy may grant access to selected posts.
My point with the other examples was to illustrate the fact that I don't think that as far as rendering the box goes, there should not really be much difference between "no permission" and "no posts". To the user it would be the same thing.
comment:4 Changed 13 years ago by
Yeah, that makes sense. Personally, I'd prefer to hide the macro from some users, and if it didn't sound so much like feature bloat I'd suggest an option (hide_if_no_posts
), but maybe I'll just make some local modifications to satisfy my particular needs.
How is a security policy implemented that doesn't involve the standard Trac permissions?
comment:5 follow-up: 6 Changed 13 years ago by
As mentioned, I'll listen to good intuitive ideas.
How is a security policy implemented that doesn't involve the standard Trac permissions?
It involves standard Trac permissions of course, but like the various 'Private*' plugins elsewhere on this site, the permission policy may override the main user permission for specific resources - either that the user has _VIEW
and the policy denies viewing certain restricted ones (like hiding tickets with security issues), or that the user has no _VIEW
but the policy still grants it (like blog posts perhaps intended for a public wiki front page).
The difference is:
'BLOG_VIEW' in perm # vs 'BLOG_VIEW' in perm(Resource('blog', 'my_blog_post'))
- and of course whatever order configured for security policies (order matter too as policies are checked in turn).
Anyway, from the perspective of the macro it just don't make sense to care about "why" there are no posts. And like I do inside the Blog module, adding a "No posts." message makes sense to me when looking at your screenshot.
comment:6 Changed 13 years ago by
Replying to osimons:
As mentioned, I'll listen to good intuitive ideas.
My reason for wanting to hide it entirely is just to not clutter the page when the user doesn't have the BLOG_VIEW
permission. I think that your approach is more consistent with other similar features of Trac and therefore probably more appropriate for the plugin. For instance, when fine-grain permissions restrict access to a certain page, the link is shown as grayed-out, not hidden entirely.
comment:7 Changed 12 years ago by
Summary: | Heading of BlogList macro is still shown when a user doens't have BLOG_VIEW permission → Heading of BlogList macro is still shown when a user doesn't have BLOG_VIEW permission |
---|
comment:8 Changed 5 years ago by
Owner: | changed from osimons to Ryan J Ollos |
---|---|
Status: | new → accepted |
You reckon? Or may it be confusing for users/authors when there is no visual feedback displayed? What if user has
BLOG_VIEW
but sets selection criteria wrong so no posts appear? Or what if the user has generalBLOG_VIEW
, there are are matching posts, but some security policy restricts the user from seeing the items?I'd rather do
"No matching posts."
, or something to that effect. However, I'll listen to good arguments for alternatives.