Hide virtual pages in the admin sitemap from users who are not admins or designers #102

Closed
jlong opened this Issue Mar 22, 2010 · 14 comments

Comments

Projects
None yet
3 participants
Owner

jlong commented Mar 22, 2010

Make this overridable on the object level, so that descendants of Page can determine their own visibility in extensions. The value should probably be cached in the DB for easy querying.

Owner

saturnflyer commented Apr 2, 2010

How would we store the visibility? Would this be a field like "visible_to" and a value of "admin,designer" or "all"?

Owner

jlong commented Apr 3, 2010

Mmm, good question. Would that be easy to query?

Owner

saturnflyer commented Apr 3, 2010

We'd be doing a LIKE match, which isn't the fastest, but I'd defer to someone with more db optimization knowledge on the best way to do this. Another option could be to have a separate table of page_restrictions (or something) and join that table in the query for the index page.

There are probably a lot of ways to solve this problem. It'd need some thought.

Owner

jlong commented Apr 4, 2010

Maybe we are over thinking this. Caching the attribute in the DB probably isn't necessary for the first pass.

Owner

saturnflyer commented Apr 4, 2010

Perhaps just the display needs to change. I might have a regular user, for example, who may need to update text on the FileNotFound page. Why restrict that? Maybe we just shrink the size of the table row and display things a little differently.

Owner

jlong commented Apr 4, 2010

I'm skeptical that you would ever have a regular user who would want to edit the text on the 404 page. :)

One other option (while we are brainstorming) is to have a per user setting that would allow them to view and edit virtual pages. Kind of like turning on "hidden files" on windows.

Owner

jlong commented Apr 4, 2010

But it sounds like we are both speculating. My vote is to implement it without a setting and see if anyone complains.

Owner

saturnflyer commented Apr 4, 2010

Alright, if you don't believe the 404 example, how about a virtual page that reads other data from the database? Such as a product listing. Or even as simple as the archive monthly index.

I'm fine with drawing a line in the sand there, as long as we're aware that we're changing what a regular user can do and we stick with the argument.

Before doing that, consider what it would mean to have content exist but not appear. Would a regular user not want to know how text on a monthly index magically appears? Would this lack of knowledge be beneficial or a possible hinderance to understanding the system? I think it would be good to show it, but either restrict access, or just minimize it's importance in the UI.

Owner

jlong commented Apr 4, 2010

Virtual pages tend to be the most confusing pages in the system and the least touched by regular users. In the case of the 404, archive, and product listing pages they are glorified templates. I can't think of an example where this is not the case. I would argue that templates are the designer's domain, not a regular user's.

And hiding this information from a regular user is the goal in my mind. We are trying to simplify their experience as much as possible. This is the same argument for hiding the "Design" tab from a regular user. The very same argument. Why can a regular user not see snippets or layouts?

Owner

saturnflyer commented Apr 4, 2010

Good points, but actual content is a bit different in my opinion. A layout is a layout and while it's true that virtual pages are glorified templates, they exist in the page tree which is (to the user) her content.

A major benefit of the page tree UI is that it clearly maps to the URLs of your website. Users understand that /about-us/team can be found under the About Us > Team page. A virtual page should also clearly map to some feature in the UI.

By changing the view, the UI could visually say "pssst, this is where that other stuff shows up. check with your designer about it if you have any questions" and this way a user would still see that it exists in the tree. Explaining the page tree is explaining the way of the world for content editors. Hiding pages would make it mystical which is not and idea I'd want to encourage (regardless of the fact that they may or may not edit it).

Not only that, but I've had users manage messages on Teleconference pages. It's all laid out already, but it makes more sense to say "go to this page and edit the standard text if you want to change the message". They are aware of the radius code, but understand how to work around it where needed. That's empowering for them since they feel like they truly own their content whereas layouts are known to be HTML-centric and are relegated to a technical person.

Owner

jlong commented Apr 4, 2010

I agree it is empowering for some users. I'm just not sure it is worth confusing the other 90%. (Now I am pulling numbers out of thin air!) And for those 10% that want to be empowered, why not set the designer bit? I mean, with the designer bit they can also pop into layouts or snippets and edit things like the text in the footer. (BTW, the line between content and template is extremely blurry. I don't think we should build an argument on this around what is and isn't content.)

Permissions are about trust. If you don't trust someone to edit your layouts, why would you trust them with your virtual pages (templates)? Or vice-versa. If you do trust them with virtual pages, why not layouts?

I need to sleep on this a bit. It's 1:30 am here. Happy Easter!

Owner

saturnflyer commented Apr 4, 2010

I realize that this won some favor when mentioned on the mailing list. But after being for it, and then thinking about it more, I'm concerned that the attempt to make things easier to understand will actually do the opposite by hiding content.

cypher commented Feb 26, 2013

Is this still current? Otherwise this issue can be closed, I think.

Owner

saturnflyer commented Feb 26, 2013

Thanks @cypher. I'm closing it. If it's a concern again, we can always revisit it

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment