This is a design sketch for private categories on public wikis.
The goal of this design is to make the simplest possible working solution: we can improve and extend that over time.
Goals and use-cases
The reason for making this feature is to allow a single group of users (members of a site) to work privately and publicly without needing two structures. Today we typically create a private wiki to act as the work area for the public one. This causes extra work, and extra complexity for users. In many cases it causes the private wiki to become abandoned.
Configuration
Private categories are configured in the site manager as an extra row in the Permissions table:
Pages are visible to: [_] Anonymous [_] Registered users [_] Site members
If none are checked, then only mods and admins can see pages in the category. It is valid to give users the right to create pages in a category but not view the results.
By convention in the Iron Giant templates we would create a category 'private:' with this option.
How it works
- When a non-member tries to see any page (existing or not) in this category, they are shown a pop-up error ("Login and/or join this site to access this category"), and redirected to the site's start page.
- Files attached to pages in private categories cannot be accessed by non-members.
- Notifications on pages in private categories go to site members only.
- The Search module will not show private pages to non-members.
- The Clone module would not copy private categories but the Site Manager clone function would.
- In the initial version, there is no further security.
- In a further version, modules that show or link to pages create a boundary between public and private categories as follows: if they are used on a public page, they never show private pages. If they are used on a private page, they can show all pages. This affects these modules:
CountPages
TagCloud
PageCalendar
PageTree
Backlinks
WantedPages
OrphanedPages
Categories
RecentPosts
MiniRecentPosts
RatedPages
Pages
ChildPages
PagesByTag
Other use cases
Data forms can be used instead of the MailForm module, and submissions can be commented on by those with access to the private category, as well as using the existing 'watch this category' notifications structure to let people know about a new page creation.
Thanks Pieter, having given you a hard time over this I am obviously very pleased to see this move forward. And the way it is proposed to work, with Ed''s suggestion added, seems right.
In the list of features to be considered for a future version, would it be possible for me to put down a feature request that the permissions for a private category can be assigned to specific members (perhaps added manually in the same way as you enter an addressee for PMs) or all site members. It would be more complex but would give huge added flexibility.
Thanks.
Rob
Rob Elliott - Strathpeffer, Scotland - Wikidot first line support & community admin team.
For per-user rights, I think the better solution is to allow the creation of arbitrary user groups and then build permissions around those. We've discussed 'trusted users' and in many projects it would be really nice to create three, four, or more levels of user so that there is separation and promotion.
If I was redesigning Wikidot I'd replace moderators and admins with custom user groups. The site MA is always special.
But obviously we're stuck with admins, mods, and members as existing hard-coded groups.
Portfolio
Why not start with the same options that the permissions table currently supports?
Or does that over-complicate things?
Community Admin
Let's assume for now that this is feasible and roll back if Michal tells us it's not doable.
Portfolio
I would like to have a template of, for example, infobox, in invisible category, but I want mz infobox to be visible when I include that page in some other, visible page… So, if someone wants to se the very same page of my infobox, he cannot do that, but still that infobox can be seen if included in some article…
As a matter of fact, I need private categories for all the pages that are NOT articles, and serve that those article pages look well…
If slaughterhouses had glass walls, everyone would be vegan. - Paul McCartney
I was thinking about that.
But — you can imitate this, to a certain extent! (so it might not be necessary) For example, what you can do now is to add a redirect module to the page or live template so that whenever someone tries to view it, they are redirected elsewhere (e.g. start page)
~ Leiger - Wikidot Community Admin - Volunteer
Wikidot: Official Documentation | Wikidot Discord server | NEW: Wikiroo, backup tool (in development)
Hmm… No. :P Too complicated for me…. Not even mentioning my members, who are much less skilful than me in these things… This means that all the work that now is divided, depends only of me, and I wouldn't like that to happen.
Besides, including a page with redirect module means that this module will be visible also in a page in which I am including the include, which means that I have to add codes for "include a part of a page only", which is also too complicated, since I already have many pages with many include codes, which means that I would have to spend months in adding "include a part of a page only" codes to all pages in which I already have includes… No. I don't think so…
If slaughterhouses had glass walls, everyone would be vegan. - Paul McCartney
Nope, read my last point:
You put the redirect module into the live template (which is exactly the same as you're suggesting - making a category only semi-private).
Only the page's source code is included, so the redirect module that is inherited from the _template page won't be included.
~ Leiger - Wikidot Community Admin - Volunteer
Wikidot: Official Documentation | Wikidot Discord server | NEW: Wikiroo, backup tool (in development)
For the record, I know what you're saying and I admit that the solution I'm suggesting is slightly complicated. However it's not as complicated as you seem to think! :)
Pieter will have to answer on whether making a category private when viewed directly, but public when used in an [[include ...]], is a viable option.
To me, "private" means private always :S
~ Leiger - Wikidot Community Admin - Volunteer
Wikidot: Official Documentation | Wikidot Discord server | NEW: Wikiroo, backup tool (in development)
Maybe to add some option "semi-private"?
Are you sure? How come that redirect module is not visible in including page, if there is nothing to "tell" the include module what part of include page to include and what part to ignore?
If slaughterhouses had glass walls, everyone would be vegan. - Paul McCartney
I think this is a different problem: protecting and hiding templates and included pages from users.
My proposal for that would be that optionally, hidden pages (starting with underscore) cannot be viewed, edited except by admins/mods/members accordingly, or included in visible pages. So you can include somecat:_thispage in somecat:_template.
Portfolio
But I do not include infoboxes in live templates, but in each and every article. I also have an include for a photo, and photos are included in all articles… Maybe I don't understand what are you proposing…
If slaughterhouses had glass walls, everyone would be vegan. - Paul McCartney
For me, a private page that can be included or listed from a public page is not private, and thus makes no sense. If I put personal data on a private page and then discover someone can read this simply by creating a public page with an include… that's a bug, not a feature.
Semi-private, sometimes private, almost private… these concepts are unclear, complex to understand, complex to make, and will cause errors and confusion. So, as a designer, I reject them.
You can today protect included pages from being edited, using permissions. I do not understand what the benefit would be of making them private… is it to prevent people seeing the source, or to hide the fact that they exist at all?
Portfolio
This is why. In a normal site, you never see such things. Visitors do not need to know that such pages exist.
If slaughterhouses had glass walls, everyone would be vegan. - Paul McCartney
Okay, correct me if I'm wrong here. It sounds like a perfect solution to your problem would be the ability to change what pages can be found using the search box.
e.g. setting pages in the "admin", "system" and "sandbox" categories so that they can't be found through search and can only be accessed using a link or directly typing in the URL.
~ Leiger - Wikidot Community Admin - Volunteer
Wikidot: Official Documentation | Wikidot Discord server | NEW: Wikiroo, backup tool (in development)
No, I cannot do that. Because I have at least 50 includes included in hundreds of pages with this name that now they have, so you can't expect from me to change all of that. On the ohter hand, I don't want them to be visible to visitors, but I do want to find them easily when I want, and for this, I need a list of those pages, which I have and the link to that page is in my top bar menu. You see, I want to hide some pages from my visitors, but at the same time, I don't want to make the work for my members harder. Therefore I cannot expect from them to remember the names of all includes and infoboxes I have there, as well as all the parameters that each of them has. So, the best solution would be that I can put those pages to invisible mode, but that they still can be seen when included somewhere.
If slaughterhouses had glass walls, everyone would be vegan. - Paul McCartney
People would like private categories to be more configurable than this, so even though it is the initial version and will be extended in future, I think that the ability to set viewing permissions to just moderators and administrators is a much better idea for the first release of this feature.
Instead of:
I propose:
If both are left unchecked, then moderators and administrators are the only ones with viewing rights.
Furthermore, if both are left unchecked, but 'create page' permissions are allowed for site members, that would mean that site members are able to create pages in the category, but cannot view or edit them at a later stage. This has many advantages:
~ Leiger - Wikidot Community Admin - Volunteer
Wikidot: Official Documentation | Wikidot Discord server | NEW: Wikiroo, backup tool (in development)
When I was driving to campus today I was thinking about this issue, and possible problems with cloning came up. What would happen when someone attempted to clone a wiki that contained private categories?
~ Leiger - Wikidot Community Admin - Volunteer
Wikidot: Official Documentation | Wikidot Discord server | NEW: Wikiroo, backup tool (in development)
Clearly they would not get private content.
Allow me to add cloning to the design spec.
Portfolio