Loading...
 
Skip to main content

Features / Usability

Forum List Topic List

Forums » Features / Usability » Can a Tracker be Shared Between Different Groups Independently ?
 
Thread actions
Print this page
  • Print all pages

    • Can a Tracker be Shared Between Different Groups Independently ?

    Posted by Vincent Bénatier posts: 3 France

    Hi,

    I am trying to build a tracker that could be used independently by users of different groups. By this, I mean that users of each group could create, update and delete items without seeing items created by users of the other groups... as this can be achieved in some database system with the row-level security feature.

    I tried different configurations within the tracker properties but i did not manage to find the solution.

    Newbie that I am, I am wondering if the only solution would be to use the PlugingTrackerList with the parameter view set to group, as specified under the option Group can see their own items inside the Permission section of the Tracker's properties => No extra permission is needed at the tracker permissions level to allow a group of users to see just their own items through Plugin TrackerList with the param view=group.

    But unfortunately, when I use the PlugingTrackerList with this setting, it raises a db error saying : Unknown column 'ttif$i.value' in 'where clause' .

    Reads: 870
    Posted by Bernard Sfez / Tiki Specialist posts: 8654 France

    Hello Vincent,

    This can be achieved in Tiki but there are certain level of complexity depending the path you choose. You have separate permissions for trackers + status items + username field or group field + user or group can see its own items.

    What I usually do the most now is to restrict access to trackers interface. Meaning user don’t see the tracker view (under the hood) but the page I prepare with specific interface for a specific group or groups. Using a plugin List and some filters and you are set (more easy to write than to do I guess 😉) But that’s what I’d do.
    First create an interface that do the job (not 100% waterproof)
    Second set permissions to make 100% waterproof

    But unfortunately, when I use the PlugingTrackerList with this setting, it raises a db error saying : Unknown column 'ttif$i.value' in 'where clause' .


    I’ve seen that in 2 occasions; Local issues with PHP version, with a sort parameter on an item list (only on local)... May be ?

    Posted by atup uxi posts: 1 United States
    Bernard Sfez / Tiki Specialist wrote:

    Hello Vincent,

    This can be achieved in Tiki but there are certain level of complexity depending the path you choose. You have separate permissions for trackers + status items + username field or group field + user or group can see its own items.

    What I usually do the most now is to restrict access to trackers interface. Meaning user don’t see the tracker view (under the hood) but the page I prepare with specific interface for a specific group or groups. Using a plugin List and some filters and you are set (more easy to write than to do I guess 😉) But that’s what I’d do.
    First create an interface that do the job (not 100% waterproof)
    Second set permissions to make 100% waterproof



    I’ve seen that in 2 occasions; Local issues with PHP version, with a sort parameter on an item list (only on local)... May be ?



    Thanks for sharing.

    Posted by Vincent Bénatier posts: 3 France
    Bernard Sfez / Tiki Specialist wrote:

    First create an interface that do the job (not 100% waterproof)
    Second set permissions to make 100% waterproof


    Thank you Bernard for sharing your experience. It saves me some precious time avoiding me looking for a feature that I would have never found. 😉


    Posted by Jonny Bradley posts: 126892 United Kingdom
    Vincent Bénatier wrote:
    ... users of each group could create, update and delete items without seeing items created by users of the other groups...


    Hi Vincent

    I think this can be done with a GroupSelector field and setting "group can modify" etc on the tracker permission properties - as with "user" owner fields you need to set the perms on the tracker so the groups you want can create new items, then they only can see or modify them.

    Maybe...

    Posted by Bernard Sfez / Tiki Specialist posts: 8654 France
    Jonny Bradley wrote:

    Hi Vincent

    I think this can be done with a GroupSelector field and setting "group can modify" etc on the tracker permission properties - as with "user" owner fields you need to set the perms on the tracker so the groups you want can create new items, then they only can see or modify them.

    Maybe...


    Vincent, this also could be part of solution (group fields I mentioned = GroupSelector field) but be aware that editing has "admin" can have harmful results on an item where the "modifier" or "creator" are auto-assigned.

    Recently I experiment this field in combination with user tracker registration and I almost locked my admin user out of the system changing a usergroup as I was logged as admin. (Hi Jonny 😂 )

    I kindly suggest before you polay with this you create a second admin with a different name and good password (of course) for safeties and you use a "super user" or the real user you target to test the behaviour (but mot admin).

    Posted by Jonny Bradley posts: 126892 United Kingdom
    Bernard Sfez / Tiki Specialist wrote:
    be aware that editing has "admin" can have harmful results on an item where the "modifier" or "creator" are auto-assigned.


    Not sure how that went wrong for you Bernard, if it's auto-assign = creator then an admin user won't overwrite it, and if it's set to modifier then any editor will get recorded as the modifier (just that admins can change that).

    However, there are two other options to avoid: "Assign to the group" and "Unassign from previous selection" unless you're using groups that don't have any permissions involved, and even then i think they're rather unpredictable and weird so best avoided.

    The "Item Owner" and other options i think work ok now following some fixes a Tiki or two ago...

    Posted by Bernard Sfez / Tiki Specialist posts: 8654 France

    Thanks for adding details.

    Jonny Bradley wrote:
    Not sure how that went wrong for you Bernard, if it's auto-assign = creator then an admin user won't overwrite it, and if it's set to modifier then any editor will get recorded as the modifier (just that admins can change that).


    I could reproduce several time so this is what I had, did and what happened:

    • I have a user tracker to store users information.
    • For this to work (user register = create a Tiki user and an item in the tracker users) username field is set with auto assign (and show realname... if it has some importance)
    • I set a group selector field and it was used to move a user from the register group (default) to the relevant group the user should be.
    • Each time I edited this field on a user item but logged as admin on save, admin user preferences were changed.


    During the tests to reproduce, i could easily reproduce by changing the admin real name preference (system administrator) that was changed for the last user edited real name (Arnold Conan). Once (as you know) my administrator user lost Admins group as I edited another user group using the field.

    Nevertheless, I believe it is our responsibility to remind a Tiki user, like Vincent, asking for support that he can experiment, but should first take care to have a backup plan (like a secondary user and a real backup of the database) in case things turns bad while playing with users and groups (permissions and access).

    Not all, depending their hosting, have backup and/or access to everything in the server to fix it (ssh, mysql database, etc) 😉