How to improve Request view in portal while maintaining Security Levels?

Question

I'm looking for ways to improve the customer experience of the Request page in the portal, and since there isn't much that can be done natively, I've been looking at Marketplace apps. I haven't found many options, so I wanted to see what others do/if anyone has any suggestions.

The main one I see recommended is My Requests Extension for JSM, and seems nearly perfect except for the limit on work items with security levels. If there are more than 1000 work items with a security level assigned, it stops checking for security level, then it either shows everything or it only shows work items without a security level assigned.

We currently have a security level assigned to 98% of our Request Types, and I don't see that changing.

Goal: Give end-users a better experience than the native Requests page by:

* Providing global filters that can be limited by the user’s role/group/something.
* Allowing the user to save their own filters.
* Allowing the user to filter based on fields additional to the native page.
* Allowing the user to view columns additional to the native page.
* All while ensuring that everyone sees everything they need and nothing they don't.

Our current setup:

* We’re on JSM Cloud.
* All of JSM is internal, and everyone is always logged in.
* All end-users are in the same organization.* I’ve thought about multiple organizations, but some users would need to be in more than one, and I don’t like the way JSM handles sharing within organizations if someone is in multiple.

* Currently, I use groups rather than organizations to accomplish what I want with Security Levels.
* All request types except one have a Security level.
* Currently, Security Levels mean that each end-user can see tickets they’ve raised, tickets that have been shared with them (along with all of one particular request type that does not have an Issue Security Level set).
* As most of our tickets have a Security Levels, we have several thousand tickets that most users cannot see (and the ones they do see depend on their role/group/whatever is in the Security Level).
* We want to keep it that way. We do not want all users to see all tickets.

Secondary question - How do y'all handle request visibility? Does anyone allow everyone to view everything? Any particularly compelling reasons to do that/not do that?

Laura Castro · Answer

I've done a lot of work with the native parts of the request views, and I think I've about reached the limitations of what it can do. Unfortunately saved filters are essentially a non-negotiable to our business users for a space I'm trying to build up.

And you're right about security. We have it set up that way for a reason. I'm going to try to shut down that request. Our stakeholders are having a hard time understanding why we don't want everything viewable to everyone.

Laura Castro · Answer

Thanks Ajay, I hadn't looked at ones like those, dashboards weren't even on my radar.

There are some great options, but I worry they'll have the same limitation for Security Levels. I've reached out to a few to inquire.

Arkadiusz Wroblewski · Answer

Hello @Laura Castro

Honestly, staying with the native portal is probably the safer choice, even if it is less flexible than you want. A nicer view is not worth weakening visibility controls.

I would focus on improving the parts JSM does support natively, like request types, portal structure, naming, and the available request list columns, rather than trying to replace the whole request view.

And on your second question no, you should not open everything by default. If visibility already needs to depend on role or context, then the restricted model is there for a reason.