Loading...
 
[edu.t.o] Users Main Forum

[edu.t.o] Users Main Forum


Strategy for restricted Workspaces?

posts: 3
Given:

  • A project management Workspace is accessible only by members of the Workspace group. Other users of the Tiki site (except admins) have no read access to it.

  • Wiki page ABCDEF was created by a user who is not a member of the Workspace group.


Problem: A member of this restricted Workspace group categorizes wiki page ABCDEF as part of the Workspace category. The user who created the page can no longer access it.


Question: What's the best strategy to prevent this situation?


Options:

  • A Workspace group member can only categorize objects into the Workspace category if s/he created the object.
    • What if a legacy document needs to be categorized into the Workspace category? Ask a Wiki admin to do it?

  • A Workspace group member can only categorize objects into the Workspace category at the time of object creation.
    • What if the Workspace group member forgets to categorize it until his/her third edit? Ask a Wiki admin to do it?

  • Don't try to prevent it with permissions. It's a wiki - anything bad that's done can be undone by admins, including an undesirable categorization.

- ))MacLeod((
posts: 158
Hi MacLeod:

I would go walk the category permissions path. I know you say it's a wiki and other admins can change perms (if you design your stie to allow that). , but I would say that the solution is to design a permission scheme in sync between categories and objects, and talk (agree in a meeting) with your other admins on how to proceed.

HTH

Switch Language