Find your people. Pick a challenge. Ship something real. The CreatorCon Hackathon is coming to the Community Pavilion for one epic night. Every skill level, every role welcome. Join us on May 5th and learn more here.

Chrome tab availability for specific role user in service operations workspace

axtsxna
Tera Contributor

Hi, I am working on Service Operations Workspace and want this chrome tab ("New Change Request") to be available for just a specific role user and not itil. How can I achieve this with ACL's ?

 

axtsxna_0-1708666561421.png

 

2 ACCEPTED SOLUTIONS

Tai Vu
Kilo Patron

Hi @axtsxna 

That tab is managed through UX Page Property named chrome_tab.

At the condition > tableDescription > canCreate, this is only visible if the user can create a record on that table.

So you can change the ACL Create in the table to control the visibility of the item accordingly.

{
    "label": {
        "translatable": true,
        "message": "New Change Request"
    },
    "routeInfo": {
        "route": "create-change-request-page",
        "fields": {},
        "multiInstField": ""
    },
    "condition": {
        "tableDescription": {
            "table": "change_request",
            "canCreate": true
        }
    }
}

 

In the other hand, if you wouldn't like to change the ACL, you can modify the property by adding new attribute roles into the condition to apply specific for workspace.

Sample

 

{
    "label": {
        "translatable": true,
        "message": "New Change Request"
    },
    "routeInfo": {
        "route": "create-change-request-page",
        "fields": {},
        "multiInstField": ""
    },
    "condition": {
        "tableDescription": {
            "table": "change_request",
            "canCreate": true
        },
        "roles": ["admin"]
    }
}

 

Cheers,

Tai Vu

 

View solution in original post

Hi @axtsxna 

The M2M Applicability could be the thing you're looking for. Try to check the List Applicabilities [sys_ux_applicability_m2m_list] table and see whether those lists have been associated to an Applicability that contains your custom role. 

 

Let's have a look to the nice post below for details how to config List Applicability.

Ref: Configuring Lists in Configurable Workspace

 

Cheers,

Tai Vu

View solution in original post

20 REPLIES 20

Hi @axtsxna 

There you go!

Selected tab index

[selectedTabIndex]

Dynamically sets the tab that is open by default when bound to data by string queries or data resources. To set the default tab statically, use defaultTabProperty​.

 

URL:  https://<your_instance_name>/nav_to.do?uri=sys_ux_screen.do?sys_id=1a2baf67534130108e4dddeeff7b125f

Timi_0-1709182900811.png

 

Changes here will apply wherever the Record SNC is utilized.

 

Cheers,

Tai Vu

 

 

 

axtsxna
Tera Contributor

I tried it @Tai Vu . But its changing even for other records as well. For Example: selected tab index 1 for problem record is problem tasks so its opening that instead of details.

 

axtsxna_0-1709188110455.png

I want details tab as default for all records whether it is change,problem,request,interaction,etc.

sayali97
Tera Contributor

Hi @Tai Vu 

 

I did the tab configuration for sc_cat_item table its working for admins but for non admins it's not working. Even I provided the roles seems ACL is blocking it. In that case what needs to be done?

Hi @sayali97

 

Yes, the user must pass the ACL check first, meaning they need the proper access rights to interact with the sc_cat_item table.

The Roles attribute in the tab configuration is used only to control who can create new records by using the "+" icon on the Chrome tab in SOW. It doesn’t override ACLs.
Think of it like trying to open a locked door with a badge. The tab might say "you’re allowed," but if ACLs say no, the system won’t let you in.

 

In that case what needs to be done?
We’ll need to review the ACLs for the sc_cat_item table and confirm whether the assigned role actually grants Create access. Adjust them according to your business requirements.

 

Cheers,

Tai Vu

sayali97
Tera Contributor

Hi @Tai Vu 

 

Thank you for your update. I found it why this happened it's not the ACL it's the condition written in the JSON if we remove that condition its accessible to the ITIL user as well and now it's working fine for me. The code is:

{
"label": {
"translatable": true,
"message": "New Request"
},
"routeInfo": {
"route": "record",
"fields": {
"table": "sc_cat_item",
"sysId": "-1"
},
"multiInstField": "sysId"
}
},