It sounds as though you are using the default assignment group as the partitioning attribute and yes that is the way it would work. Effectively partitioning adds an extra where clause on the end of every database access to check that the group you are in is the assignment group for that process
But you can choose your own partitioning attribute and the most flexible one I have found is described here
Thanks for the reply We're actually using a custom category as the partitioning attribute, in part due to recommendations in that post and to a response you gave me on a different post (thanks again for that too) and it works great except for this. I also tested it using the default data partitioning and the behavior is the same for both.
That's a little disappointing and it's going to cause some problems for us. If we give analysts access to the other data partitions so they can view their own tickets in them, that defeats the purpose of data partitioning, so we can't do that. So our only option is to leave them completely locked out of their own tickets and they'll have to resort to manual ways of responding. We may have to go back to the drawing board on this one and try to figure out an alternative method. I have a case open with LANDesk to see there's anything they recommend...we can't be the first to encounter this.
Let me know if you have any other suggestions and thanks again for your help.
I'm glad it helped. If you are using a category as the partitioning attribute you are going to need to allocate that to the end user. Partitioning really does lock people out of they do not have the key