Closed
Bug 817160
Opened 12 years ago
Closed 10 years ago
Static page visibility
Categories
(Webtools Graveyard :: Air Mozilla, enhancement, P3)
Tracking
(Not tracked)
RESOLVED
DUPLICATE
of bug 1065479
People
(Reporter: richard, Unassigned)
References
Details
There should be a way to set the visibility of static pages that follows the visibility rules for videos i.e. public, mozillians, MoCo/MoFo If possible having CSS classes (.public .mozillian .mozilla) we could add to div tags within a static page to further control visibility would be useful.
Reporter | ||
Updated•12 years ago
|
Priority: -- → P2
Reporter | ||
Updated•10 years ago
|
Priority: P2 → P3
As a new contributor and junior engineer, I'm trying to understand the goal. Why are these visibility settings to "static pages" important? Are there certain videos that only loggedin Mozillians have access to and that public anonymous users (like myself) do not have access to? I understand that the technical implementation is that you can use css to set the video pages or "static pages" to be display:none or display:block depending on login type.
Comment 4•10 years ago
|
||
First of all, I'd strongly recommend we disregard the idea of using CSS selectors to hide or show stuff related to this. It's a dangerous potential that someone might say or reveal something and just because it's not visible in your browser doesn't mean a search engine bot can't pick it up. Susan, Yes, logging in dictates which videos you can see. I think I explained this today in some other bug. Basically, when you log in all of a sudden certain other video events appear. I think what Richard requires is that certain pages should only be accessible similar to how events are accessible. By default a Static page would be open to all users, but he could select a particular page (e.g. /howtos/how-to-get-an-office-badge) should only be accessible if you're logged in with a @mozilla.com or @mozillafoundation.org address. That wouldn't be very hard to do. However, the big question is, what about links to these static pages? For example, we have a hardcoded link to "/about" in the top navbar. Perhaps the linking to is a non-problem and we should first just focus on making the protected at all.
Reporter | ||
Comment 5•10 years ago
|
||
In retrospect, I think Peter is exactly right about CSS being exactly the wrong way to do this. Keep in mind that I'm not really a coder. I know just enough CSS and Javascript to be really dangerous sometimes.
Comment 6•10 years ago
|
||
So Richard, what do you think about linking to these? Or is that perhaps not real problem.
Comment 7•10 years ago
|
||
So Richard, what do you think about linking to these? Or is that perhaps not real problem.
Reporter | ||
Comment 8•10 years ago
|
||
Can't we handle this the same way we do restricted content. If you follow a link to a restricted video but you're not logged in at the appropriate level, you get a notice to sign in. I think we should support all 4 of our restriction categories, Public, Staff, Staff + Vouched Mozillians, and Staff + Mozillians in Curated Groups. ...although I guess we're about to get a 5th group: Members of the public with Logins who aren't Vouched Mozillians (e.g. folks with discussion rights).
Comment 9•10 years ago
|
||
FYI, we currently don't yet support non-vouched logins yet. I think my needinfo to you Richard was unclear. Let me try again: We can make static pages adhere to the same auth rules as events, but with events we make a list of events that you can click on dynamically. That's not the case for links to static pages. There's no dynamic page that lists links to static pages. The question was: Does that matter?
Reporter | ||
Comment 10•10 years ago
|
||
Peter, No, I don't think it matters.... unless there's an implication I'm missing. ..and while we don't yet actually have the 5th group we seem to be heading in that direction.
Comment 11•10 years ago
|
||
FYI, we currently don't yet support non-vouched logins yet. I think my needinfo to you Richard was unclear. Let me try again: We can make static pages adhere to the same auth rules as events, but with events we make a list of events that you can click on dynamically. That's not the case for links to static pages. There's no dynamic page that lists links to static pages. The question was: Does that matter?
Reporter | ||
Comment 12•10 years ago
|
||
I don't think it does matter. But closing this in favor of #1065479 which I think is a clearer description of the problem.
Status: NEW → RESOLVED
Closed: 10 years ago
Resolution: --- → DUPLICATE
Updated•3 years ago
|
Product: Webtools → Webtools Graveyard
You need to log in
before you can comment on or make changes to this bug.
Description
•