Sign up Sign in Samples Blog contact support
restricting permissions on card names

Support Ticket

acknowledged
 
+issue

Can a link to a page you are not permitted to view not even show its title?

I have a group of users who want a collaboratively edited easy to use genealogy site. They want public pages for dead ancestors, but links to living children, and desire living children to be private. As showing the names of pages will leak that first generation's name, is there a user friendly way to not render those?

 
+discussion

I'm not sure if this is doable as an actual link with double brackets, but I'm pretty sure it will work if you instead use inclusions with view link, like so:

{{Mary Garvey|link}}

Which normally looks just like a link:

Mary Garvey

...but lack of permissions will prevent it from showing up at all, just like any inclusion.

--John Abbe.....2016-05-06 17:52:18 UTC

Actually, I think that will still render. Most name-based views (name, link, url, etc) do not require permissions.

 

However, search results will only return cards that a user has permissions to see. If you did a search for descendants, say, and showed each descendant in link view, then you should get only the links you want. Eg. {{+descendants|content|link}}

--Ethan McCutchen.....2016-05-06 18:36:07 UTC

So if you have a Pointer, you can make a Search for the Pointer and use that instead. But if you want links in a Basic card, it sounds like there's no way to stop them from showing up when the user doesn't have permissions.

 

Is there a ticket, or thought, to separate name and content permissions?

--John Abbe.....2016-05-06 20:22:45 UTC

I don't think so. Generally speaking, "nests in Basic cards" is a pattern that most are avoiding, because it makes casual users deal with syntax. Increasingly, wagneers use nests in structure rules and barely anywhere else. So revamping the permission system to handle name/content distinctions sounds like a lot of work for a rare use case, especially since the workaround is relatively straightforward. We'll have to hear from Michael, but I'd be pretty surprised if he actually wanted all his users to have to learn Wagn syntax.

 

I should mention that it might also be possible to write a quick mod that adds or alters views for this kind of thing. (Probably a couple of orders of magnitude less developer time than permissions overhaul).

 

I should also mention that the multilingual updates will necessarily involve more separation of the treatment of names and content, so if there were important use cases for permission separation, that would be the natural place to explore it.

--Ethan McCutchen.....2016-05-06 20:34:18 UTC

What are "nests" ?

+1 mods

--John Abbe.....2016-05-06 20:40:31 UTC

Warmer-sounding "inclusions." They even look like little nests, right? {{}}

--Ethan McCutchen.....2016-05-06 20:49:37 UTC

We haven't really launched an effort to replace "inclusion/include" with "nest" on wagn.org, but that will come soon.

--Ethan McCutchen.....2016-05-06 20:51:34 UTC

Ah, yes, I was only thinking of Michael using "nests" as a workaround. If Wagn did offer nuance on name/content viewing permissions, then I would think it would extend to regular double brackets links.

 

(FYI, "nest" made me think of some phrase with the connotation that's it's an intricate mess.)

--John Abbe.....2016-05-06 21:47:45 UTC

I'm okay with users having a "magic incantation" which does what they need, as long as it can be kept simple - I don't know enough about wagn syntax yet to know how difficult it would be for users, but I think they might forgive a fair bit for the privacy they want.

--Yevuard.....2016-05-12 09:25:55 UTC