Loading...
 
Features / Usability

Features / Usability

Forum List Topic List

Forums » Features / Usability » Categories and Permissions
 
Thread actions
PDF Print this page
  • Print all pages

    • Categories and Permissions

    Posted by sirvenue posts: 3

    Hi,

    I have a simple question: Can I reverse the setting that one object that has two categories assigned can be seen by users of both the categories instead of one user who belongs to both groups? To me it makes no sense at all why a user would need to be a member of two groups (any explanation???)

    An example:

    I have an object for the Marketing department under the group "Marketing" then I have another one under the group "IT" and the last item is one that concerns both "IT && Marketing". I have two users, one is in the Marketing group, the other in the IT group - they need to collaborate on the third object (IT && Marketing), but shall be seperated when it comes to other objects such as the individual ones (IT object and Marketing object).

    How do I solve this issue? Did I misunderstand something?

    Some users can't even access our HomePage if we set some items to multiple categories than the one their group belongs to. Wouldn't it make more sense to simply make the given object invisible???

    PS: How can I get rid of the smileys??? wink

    Reads: 771
    Link
    Posted by Rick Sapir / Tiki for Smarties posts: 3665 United States

    >
    >How do I solve this issue? Did I misunderstand something?
    >

    The category groups are mutually exclusive. Therefore, you'll need to create "bridge" category that connects the two. In your example, you could create a new Marketing_and_IT category. Then place the third item in that category. Then grant the both groups to that category.


    >
    >PS: How can I get rid of the smileys???
    >

    Simply disable the Smileys option on the Admin: Text Area page.


    HTH,

    -Rick
    Need more help? Try TikiWiki for Dummies Smarties or read my Tiki Blog or visit my UserPage

    Link

    Posted by sirvenue posts: 3
    Oh ok, I see. Thanks for your help Rick! Do you know if an option (like the reversing I asked about) might get implemented in the near future in coming releases of Tikiwiki? Mutually inclusive categories just make more sense in our case don't they? Otherwise I have a database full of all possible combinations of groups (as the two where just an example). What about if we just add just a third one: Let's say 'Operations'. Now, I need, Marketing_and_Operations / IT_and_Operations / Marketing_and_IT plus all the individual groups. At the moment we have 5 individual groups - so you can imagine that there's substantial room for further pairing. Besides, it might confuse our employees which group is the right one..
    Link
    Posted by Darren posts: 289 United States

    I empathize with your predicament. I'm trying to implement a Tiki at work and have a similar situation where potentially many different departments are going to access wiki pages, and in some cases need to access and/or edit pages pertaining to other departments.

    In some cases it's easy because the pages are generic enough because I can just create catch-all categories so that basically any registered user group can edit those pages. In other cases, not so much. I have a similar situation to you where we have certain "power users" outside of the IT department, that might need to access some IT information (either view or edit).

    I don't think one single approach can address the issue fully but I've taken to creating hierarchies of user groups. So each department has it's own main user group but then it has higher (or lower depending on which way you look at it) sub-user groups, usually with a greater number of permissions.

    How does this help me? Well in the case of IT, I have the generic IT user group but then I also have "IT Mods" (moderators) and "IT Power" (power users). Nobody in the IT department is actually in the IT user group, they belong to either IT Mods or IT Power. The users that I do put into IT, are usually from other departments who may need to access some IT information (and they also belong to their own departmental user group, whatever that may be).

    To restrict access I then have to create different categories for different appropriate levels of access per user group. So one category can be accessed and edited by anyone with IT user group access (which includes IT Members since they are part of IT sub user groups), but for the IT stuff I don't want other departments to see, I only give access to the IT Mods or IT Power user groups.

    Sorry this is a bit long-winded, but I hope it helps a little. It's still not a perfect solution and could potentially become a security/administration nightmare, but I think that is, at least in part the nature of the beast.

    Link

    Posted by sirvenue posts: 3

    It looks like this problem concerns more than one person.

    01. Where can we suggest it as an option for future releases so the developers can implement it?
    02. Does someone know where we could change it ourselves in the code? It can't be that hard and will probably just be a couple of lines in php that need to be fixed..

    Link
    Posted by Darren posts: 289 United States

    I'd have to disagree there... I don't think it's an easy "fix". There may be a lot of conflicting consequences, by allowing multiple categories with distinct permissions, that you haven't taken into account Furthermore, "fix" isn't really the right term because that implies that it's broken, which it isn't, it just doesn't work the way we might like it to. biggrin

    The point of my previous post was this:

    1. What we are trying to do is not easy under any circumstances, even if multiple category cross-referencing permissions were developed
    2. There is always more than one way to achieve what you are trying to do. Often the simplest method is the best but sometimes there is no simple method (as in this case).


    You can make suggestions for new features on the Tiki Development site

    Thanks for your input.

    Link