3 Replies Latest reply on Jun 26, 2015 10:02 AM by erik.marple

    Data partition using custom attribute

    erik.marple Specialist

      I'll be as brief as I can with this. I'm a n00b LDSD admin and searched around but couldn't find anything similar. I've raised an incident with LANDesk but wanted to ask around and hopefully at least get some best practice suggestions.

       

      I've been tasked with enabling data partitioning on our soon to be launched LDSD system. Unfortunately, the default data partitioning where support groups are restricted from viewing anything but tickets within their group was deemed insufficient. We have tons of groups, so just adding people to multiple groups wasn't an acceptable idea either (this also prevents results from Incident queries showing from more than the selected group, which management wasn't happy about).

       

      What I've been asked to do is set up data partitioning using a custom attribute similar to how it is outlined in the LDSD Admin guide for 7.7.1 on page 27. We have lots of groups within IT, and they all need to be able to view each other's incidents, but they don't need to be in each other's groups (e.g. PC Support should be able to view Messaging's incidents but doesn't need to be part of their group). Then we have other non-IT groups that need their incidents to remain unseen to others, but still visible between their batch of groups.

       

      I've actually managed to get this working somewhat, but only if the user who creates the incident manually selects the partition attribute from the incident window. Obviously we want something automated, preferably setting the data partition based on the group assigned to the incident. Our incidents are assigned to groups based on categories the user selects, so maybe that would do it, but I haven't been able to set this anywhere. When I attempt to set a value type on the attribute, I get an error saying "Object reference not set to an instance of an object" or the attribute just isn't listed under Latest Assignment Group even though I've related it to Group / Support Group. Perhaps because in the process this hasn't been set yet...I'm stumped and not sure where to go next or if I'm even moving in the right direction

       

      Any suggestions? Sorry if that's not detailed enough...I can provide more info if needed. Thank you for any help!

        • 1. Re: Data partition using custom attribute
          dmshimself ITSMMVPGroup

          I'd look as using a category for your partitioning attribute as it provides hierarchical partitioning.  I tend to use a lock and key analogy for this discussion.  Let's say you had an attribute which has top level values like Account and then Payable and Receivable as levels under that. You could have another top level value in the same category called IS with values such as Desktop and ServiceDesk as second level items.  This category is your lock that is applied to the process and this will be the attribute you added to the process.  You also add this attribute to (say) groups ad this will be your partitioning attribute.  Anyone without the right key will not be able to access this process.  So anyone allocated the key Accounts will be able to see all process where the lock value is Accounts, Accounts-Payable or Accounts-Receivable, but nothing in IS.  Anyone with the key Accounts-Payable will only be able to see processes with that partitioning value set and not (say) Accounts-Receivable or Accounts.

           

          The same applies to the key value IS.  Anyone allocated this key will see everything locked with IS, IS-Desktop and IS-ServiceDesk.  Anyone with the key IS-ServiceDesk will just see those and not IS-Desktop or IS.

           

          A way to allocate keys then is to put that same attribute on the Group object and administer it into place.  This needs to be done by hand to match your requirements.  So the group Accounts Team Leaders might have the key Accounts and another group might have the key Accounts-Payable.  You have to map this out.

           

          Now when a process is assigned, use a windowless action after the assignment to pull in the key from the group and apply it to the process as the lock.  That way the user doesn't have to choose and its all automatic.  The hierarchy of a category allows you to place the lock at the right point and let people cascade their access from that point down their key.

           

          A few other comments.  You can have master groups where their key is empty - they will see everything.  You can also public processes that have locks that are empty, anyone can see these.

           

          This very general mechanism takes some thought beforehand to implement, but seems to cover all the requirements I've come across so far.  But I'm sure your mileage will vary :-)

           

          If you are just starting on the partitioning voyage of discovery and/ or LDSD design in general, then I would recommend seeing if you can get some consulting support from whoever did your implementation.  There might a few bear traps on the way to implementing the above outline and while this forum is good/great for ideas, it isn't a substitute for experience or time.  Just a thought.

          • 2. Re: Data partition using custom attribute
            erik.marple Specialist

            Thank you for the detailed reply. I'll definitely look into that as a possibility and post back with results. I would love to get our consultant to come back and polish some of the rough edges left for us, but I'm not sure that's in the budget. At least I have something to go on now. Thanks again!

            • 3. Re: Data partition using custom attribute
              erik.marple Specialist

              Looks like I forgot to update this one with the results. Using a category as the partition attribute is what we ultimately went with and I really appreciate the advice on this one The solution isn't perfect, but it seems to be the best the system can do.

               

              Due to the category structure, you may potentially get into a scenario where an analyst needs access to two separate partitions and thus has to be given more access than you really want, since they'd have to be set to the top level category in common with both.

               

              Also, analysts end up getting locked out of incidents they've submitted for themselves if the incident is in a data partition they do not have access to (imagine an IT analyst submitting a ticket to Payroll for an issue with their own paycheck). I have an enhancement request out here to improve that: Allow raise user to view their own incidents if in a different data partition

               

              This hasn't generated too many complaints for us, but there is a LOT of room for improvement. Security like this is a pretty basic concept and is just a given in other systems, so I was really surprised to learn about LDSD's limitations. It'd be nice if it could just be set up like individual folder permissions on an OS.