Can Analysts that are Affected Users see requests as End Users?

Peter_Wilkinson

Hi, might be a bit confusing this so here goes. We have separate departments that plan on using Service Manager, HR and Finance say. They are analysts on the Cireson portal so can do what they need to do with their own requests and views that are restricted using queues/permissions etc in SCSM. All works fine.

The problem comes when for example, a HR analyst logs a personal request to Finance. Since they are the Affected User and an Analyst they get implied permissions to the request so can view and edit everything about it. Then when a Finance analyst comes along and adds an In Private comment, the HR analyst can view the comment. Not the best if there's sensitive information on there (there shouldn't be but you never know with our users...).

I've already logged a request with Microsoft about SCSM and their response was "that's how it works" so was wondering if anything can be done on the Cireson side of things? Maybe something like: if user is analyst and user in AD support group then view as analyst else view as end user. Yeah I need to work on my coding skills...

Peter_Wilkinson

Hi guys, thanks for your input on this. After much digging, I've managed to cobble together the below code that does what I want it to:

// Remove an Analysts rights by modifying session.user
function disableAnalyst() {
    console.log('Analyst is not a member of support group, user rights restricted');
    // Prevents analyst tasks
    session.user.Analyst = 0;
    // Set the forms for IR's and SR's to be the default end user view
    // Removing access to views and restricting changing of fields
    session.user.IncidentForm = "DefaultEndUser";
    session.user.ServiceRequestForm = "DefaultEndUser";
}
// Function to find if the current user is a member of the requests support group
function findUserInGroup() {
    // If not an analyst dont run this function
    if (!session.user.Analyst) {
        return;
    }
    // try to get the pageForm, this can fail if not looking at requests
    // so has to be in a try catch that simply returns on failures
    try {
        var pageViewModel = pageForm.viewModel;
    }
    catch (err) {
        return;
    }
    // Variables to hold support group info
    var sgFieldName;
    var sgId;
    // Sets the name of support group field to check
    // IR/Incident = TierQueue
    // SR/Service Request = SupportGroup
    switch (pageViewModel.Id.substring(0, 2)) {
        case "IR":
            sgFieldName = 'TierQueue';
            break;
        case "SR":
            sgFieldName = 'SupportGroup';
            break;
    }
    // Get the support group ID
    sgId = (pageViewModel.get(sgFieldName)).Id;
    // if Id returned is not null
    if (sgId) {
        // Setup our api call
        // async has to be false for IE, it can be true/removed for Chrome
        var sgMembers = new kendo.data.DataSource({
            transport: {
                read: {
                    async: false,
                    url: '/api/V3/User/GetSupportGroupUsers?id=' + sgId,
                    dataType: "json"
                }
            }
        });
        // Call api to see if current user is in the support group
        sgMembers.fetch(function () {
            var currentUser = session.user.Id;
            var userInGroup = false;
            var sgData = sgMembers.data();
            // loop through all members of the support group
            sgData.forEach(function (sgMember) {
                if (currentUser === sgMember.Id) {
                    userInGroup = true;
                    // Return false to break out of forEach loop
                    return false;
                }
            });
            // If current user is in the support group, nothing needs to happen
            // otherwise remove their access rights
            if (userInGroup == true) {
                console.log('Analyst is a member of support group, full access granted');
            }
            else {
                disableAnalyst();
            }
        });
    }
    else {
        // If the support group ID is null then assume that the user wont be a member of it
        disableAnalyst();
    }
}
// When the page is ready, check for analysts to see if they are members of the support group
// If not only show them the default end user view so they cant mess with the request
$(document).ready(findUserInGroup);

Seems to work for what we need but having no real javascript coding experience, I'm not sure if this is the best way to be doing things or not. Meh seems to work.

Justin_Workman

You could have 2 portals with 1 SCSM instance?  HR is analysts in one, Finance is analyst in the other but it would the same underlying tickets.

Peter_Wilkinson

I would have never thought of that!

I'll give it a go and see what happens.

Peter_Wilkinson

Hi, sorry this took so long but had issues elsewhere...

Anyway, after some testing we've come to the conclusion that this wont work for us. We had to setup another server to host a new Cireson Cache Builder service and created a separate ServiceManagement database so we got two separate Cireson portals with HR as analysts on one and Finance as analysts on another.

Seems fine they can go between the sites and are end users on one and not the other etc. However HR can log a Finance job for themselves on the Finance page and on that page they cant see all the incident details so that's good but they can just go to the HR portal and see the incident under their My Requests view from there where they are analysts and have full access since both portals still link to the Service Manager database.

Only other thing would be to have two completely separate Service Manager environments which would be a bit unmanageable for us.

I guess we stick to telling users not to post anything they don't want others to see and not rely on the In Private tick box.

Justin_Workman

The other way would be to use queues.  You can have two different roles in SCSM one for your HR people and one for your Financial people.  Then have a queue for each group.  I assume they're in a support group or some other property that identifies incidents bound for them.  The queue definition would be based on that delineation. 

Peter_Wilkinson

Yep we already use queues based on the different support groups, that bit works so HR analysts can only see incidents in the HR support group and there's no cross over with Finance. Problem comes when any analyst logs an incident/request with another group and is the affected user they have full control of that incident/request regardless of what support group it ends up with.

Here's how we got it setup:

AD Groups - Cireson-Analysts, HR-Admins, Finance-Admins. Both HR and Finance are members of the Cireson-Analysts group.

SCSM Queues - "HR Incidents" limited to HR Support Group, "Finance Incidents" limited to Finance Support Group.

User Roles - HR-Incident Resolver, Finance-Incident Resolver. The incident resolvers are limited to their respective queues and everything else has full access (like the default incident resolver role).

We have separate service offerings and request offerings for HR and Finance that are available to all domain users.

HR-Admin comes along in the Cireson portal. Logs a generic Finance incident from the Home page, it goes in to their My Requests queue and when they open it, full access. Would expect them to only have Add to Watchlist and Print as their tasks and only be able to add comments and file attachments but no they can do what they want with it.

Have I got my wires crossed somewhere, just doesn't seem to be working like I expect it to.

Geoff_Ross

Hi Peter,

This is working how i would expect but appreciate your frustration here as its not what you need.

Two things are working together here to give the undesired results.
1. An affected user will always have full permission on their own tickets. They can access everything on it, inc Private Analyst comments, (from raw SCSM permissions level). This is normally handled by removing these from the data set for End Users before rendering the page.

2. In the Cireson Portal an Analyst is an Analyst for everything, so will get the full Analyst form, with all the Tasks and will not get the Private Comments removed.

The only solution I can suggest is a fairly complex customisation where permissions are checked on every work item load and tasks / comments / fields etc could all be removed from the interface.

Not a simple one I'm afraid.

Geoff

Peter_Wilkinson

Hi guys, thanks for your input on this. After much digging, I've managed to cobble together the below code that does what I want it to:

// Remove an Analysts rights by modifying session.user
function disableAnalyst() {
    console.log('Analyst is not a member of support group, user rights restricted');
    // Prevents analyst tasks
    session.user.Analyst = 0;
    // Set the forms for IR's and SR's to be the default end user view
    // Removing access to views and restricting changing of fields
    session.user.IncidentForm = "DefaultEndUser";
    session.user.ServiceRequestForm = "DefaultEndUser";
}
// Function to find if the current user is a member of the requests support group
function findUserInGroup() {
    // If not an analyst dont run this function
    if (!session.user.Analyst) {
        return;
    }
    // try to get the pageForm, this can fail if not looking at requests
    // so has to be in a try catch that simply returns on failures
    try {
        var pageViewModel = pageForm.viewModel;
    }
    catch (err) {
        return;
    }
    // Variables to hold support group info
    var sgFieldName;
    var sgId;
    // Sets the name of support group field to check
    // IR/Incident = TierQueue
    // SR/Service Request = SupportGroup
    switch (pageViewModel.Id.substring(0, 2)) {
        case "IR":
            sgFieldName = 'TierQueue';
            break;
        case "SR":
            sgFieldName = 'SupportGroup';
            break;
    }
    // Get the support group ID
    sgId = (pageViewModel.get(sgFieldName)).Id;
    // if Id returned is not null
    if (sgId) {
        // Setup our api call
        // async has to be false for IE, it can be true/removed for Chrome
        var sgMembers = new kendo.data.DataSource({
            transport: {
                read: {
                    async: false,
                    url: '/api/V3/User/GetSupportGroupUsers?id=' + sgId,
                    dataType: "json"
                }
            }
        });
        // Call api to see if current user is in the support group
        sgMembers.fetch(function () {
            var currentUser = session.user.Id;
            var userInGroup = false;
            var sgData = sgMembers.data();
            // loop through all members of the support group
            sgData.forEach(function (sgMember) {
                if (currentUser === sgMember.Id) {
                    userInGroup = true;
                    // Return false to break out of forEach loop
                    return false;
                }
            });
            // If current user is in the support group, nothing needs to happen
            // otherwise remove their access rights
            if (userInGroup == true) {
                console.log('Analyst is a member of support group, full access granted');
            }
            else {
                disableAnalyst();
            }
        });
    }
    else {
        // If the support group ID is null then assume that the user wont be a member of it
        disableAnalyst();
    }
}
// When the page is ready, check for analysts to see if they are members of the support group
// If not only show them the default end user view so they cant mess with the request
$(document).ready(findUserInGroup);

Seems to work for what we need but having no real javascript coding experience, I'm not sure if this is the best way to be doing things or not. Meh seems to work.

Geoff_Ross

Peter_Wilkinson said:

Meh seems to work.

My exact philosophy!!! Nice work Peter and thanks for sharing.