Web Portal Customization

You would need to customize the Angular code - I wouldn't try this without a test environment.

I do agree with Ben

First have a look at permissions and roles, as you did with Data Administration. The more you could achieve with roles and permissions without modifying the code , the better.

Hello Ben and Juancarlos, thank you for your responses. 
I do agree that is better to look at permissions and roles without modifying the code. Over the past few days, I have been trying to understand how to achieve this correctly.
How can i create a custom Application Role that grants access only to specific functionality? Basically, after the creation of the Application Role, where and how do I define which functionality is visible or accessible to members of that role?
Thanks

The current roles are designed for use with current code (i.e. the levels it already has it set at - top menu), it isn't dynamic enough to simply create a role and somehow attach that to a functionality in the portal.

Compared to the old web portal, the Angular portal will predominantly use Dialog rights of the current logged in user to control a lot of "access" (not "functionaltiy"), so new roles can also add the complexity of handling all the associated Dialog rights as well.

I suspect your "quick win" might be having everyone as a member of the Admin Role for the menu, then hide the required sub menus based on other memberships - this is Angular code change.

At our last client, we had to create custom code under Data Administration for several reasons:

1. We were running 9.0 LTS which acted more like a 'beta' product compared with current releases so limited OOTB functionality
2. Client requirements:
   1. again, limited ability to configure basics such as display/edit columns, etc. with version (can see this is much better with 10.0)
   2. flow requirements when Angular forms are submitted (i.e. not direct object modifications, but complex PWO/Attestation flows)
   3. Visual display requirements
   4. Lookup filters
   5. "Authorised User" functionality versus "Administrator" functionality (latter being able to perform a few additional tasks and bypasses some flows)

Hello,

I agree with juancarlos camargo  and Ben  on this topic.

You can limit what a user can see by creating a custom AERole, assigning a custom permission group, and linking program functions to it.

Program functions control access to “specific” parts of the portal UI.

Steps

1. Create an AERole in One Identity Manager.

2. Create a custom permission group in One Identity Designer.
   2.1 In that permission group, assign the required Program Functions
   (tip: check the descriptions under the Portal section to pick the right ones).

3. Assign the permission group to your custom AERole.

4. Add your test user to this AERole.

5. Log in to the portal and verify the visible sections.

Additional tip

In the Angular source, check:
imxweb\projects\qer\src\lib\admin\qer-permissions-helper.ts

You’ll see some permission-related program functions referenced there. They often act like guard logic (e.g., “if the user has X, show Y”).

Important note

This is a double-edged sword. Assigning advanced program functions to a subset of users can easily break portal behavior if required dependencies are missing.

If the customer requirement is showing a custom table with identities, it’s usually better to do this server-side (custom API endpoint / filtering) and a custom Angular component.

Hope this helps,
Zan