Limited rights on Calls/Incidents...

[fabrice]

How to configure SC4 to allow operators to view all the calls/Inc but modify only those assigned to their group?



Thanks, ???

[eisefr]

Maybe trough the dbdict / Datapolicies of the problem-database..



For every field what you want to access only when it is assigned to a group of the member i would do it like this:





index(assignment, $G.ownergroup)=0



Write it into the datapolicy under READ ONLY.



Maybe it works.. I didn't try it out!!!!!

[harn145]

The easiest way is to modify the profiles for IM to limit the "update" and/or "close" function.



==> go to the profiles and click "expand", you can now enter conditions for the different functions.



Set the condition for close (on the privileges tab) to:



index(assignment in $filep, $lo.pm.assignments)>0



For calls its a bit harder, as you can't (by default) set up an evaluating boolean. Anyway, if you are sure the assignment group in the call is the owner group, modify the displayoptions in cc.first and cc.edit.incidents for close/complete (Unique ID's: 443, 444, 533, 534, 571, 573).



Modify by changing/adding a "User Condition", this condition will override the default condition, so you can leave it as it is.



User Condition should read something like this:index(assignment,1 in $L.filed, $lo.pm.assignments)>0

[ambarnes]

Harn:

I've recently come into needing the same feature. We're going to be deploying SAP within a couple of months and all incident tickets in SC we do not want other support teams to be able to open them to see the details of the ticket.

I tried your expression index(assignment in $filep, $lo.pm.assignments)>0 and put it in the open, update and close fields.

Well it worked ok in preventing access to ALL tickets. The user I tested this on was not able to access his own group's tickets. Did you come across the same problem?

[harn145]

Aaron,

You can't use the expression on open.

Besides the fact that would not make too much sense as open means creating a new ticket, which is not holding an assignment group yet and not "opening a ticket for viewing" there are conditions in the displayoptions that evaluate the open value in the profile (for inboxes and searches). This in you set up would refer to a $filep variable, that would not yet be available.

Hope this helps,
Jos

[Maggie]

Well, maybe not the nicest solution, but we solved things like this by setting the readonly condition... So if you'r not, for instance, helpdesk, you can can't update or do x, y, z., which shuold only be done by heldesk.

easy way, I know, but works :wink:

[ambarnes]

Jos and Maggie - thanks for the help. That did correct the problem when I put Jos's code into only the update and close.

I guess what I'm trying to do is a little different.

What I'd like to try and make happen is if a user from Group A pulls up the incident queue list of Group B, I'm sure it would display the tickets in Group B's queue. What I want is if a Group A member double-clicks one of the tickets to try and pull it up, I'd like some kind of access denied thing to pop up so that it will not even display the details of the ticket.

Currently with Jos's script the member of Group A may not be able to really do anything with Group B's ticket, but that Group A member can still read the details of the ticket.

Is there a method to do this?

[tommy]

Then You need to use mandanten security.

It works by setting up security groups which are autorized to view records that have certain values in a specific field. (one primary field per file)

If this is setup the user from group A would not even be able to pull the list for Group B, not tickets would be listed.

[ambarnes]

Thanks Tommy, I better read up on that as I've never even had to use mandanten before.

[PieterVanPetegem]

When you use a readonly condition to handle this issue, make sure you test the condition.

I used the same thing but in SC 5 and simply pressing enter bypassed the readonly and allowed the operators to make changes.

Make sure it isn't the same in SC 4.

[harn145]

Aaron,

In that case, you can use a validation on display in the Formatcontrol(s) for update(problem.*.update), that will check whether or not the user is in the AG (same condition as for the profile, but now with $file :wink: )

This will disallow access to the record, with a message you can control! :P

Manadanten can also be used, but will cause you some additional headaches, as it will be part of all database interactions. The requirement you describe more or less states that anyone can 'run into' a ticket, but not view it. Manadanten will also prevent 'running into' a ticket, by appending limiting queries to all interactions with the database (mind the indexing here) and will require additional user administration.

Hope this helps,
Jos

[ambarnes]

Thanks to all for the help and also for tommy providing the screenshots for examples.

Jos brought up a good point that using mandanten will increase user administration responsibilities which can suck sometimes because you have more details to worry about, however I think I'll still stick with this method because that same disadvantage is also its own advantage. It allows for detailed user administration. That is essentially what I needed. For now the reason for bringing this additional level of security is because of our HR department wanting to use it, and thus sensitive information may be stored in tickets. Later on other departments may follow suit with a similar scenario.