/ Development  

Tips to get rid of the "Identity Package" homepage in runtime

Hi there AppWorks fans,

Welcome to a new installment of AppWorks tips.

Finally…An answer to a question that always gets asked during almost every project! How to get rid of the ‘Identity Package’ in runtime (the ‘identity Homepage’ and ‘Identity’ list category) when we don’t need it!?

Spoiler! During the creation of this blog post I’m using version 20.4 of the AppWorks platform and there I see that the identity homepage is already removed from the ‘regular’ user in runtime by default!. I couldn’t find anything on this in the release notes for 20.3 and 20.4, but I know there are some security changes done on the platform that probably have a positive impact on showing the ‘Identity package’ homepage only to the administration rolled accounts!

Let get right into it…

First an answer to the question: What is the “Identity Package” and why would you need it?

Well, the ‘Identity Package’ is nothing more than a standard AppWorks solution (created by OpenText) that delivers ‘identity’ components into your solution. It is delivered with a variety of entities with all kinds of preconfigured building blocks for you to consume from. We did already a post about ‘Consuming the Identity Package’ where we learned about the great stuff that is delivered with it.

Let’s give a list of bullets why you would like the identity package to be used:

  • It’s tightly connected with OTDS (the authentication spider of our architecture)
  • The use of teams, groups, users, worklists, contacts, countries…etc.
  • A default set of entities that you can import in your solution (and customize if required)
  • The identity homepage to manage all the ‘Identity’ data
  • It provides an inbox for end users to retrieve tasks

But!…Do you remember that first project where you saw that a ‘regular’ user always had to click pass by the ‘Identity Homepage’ and ‘Identity’ list category? Well, this post will tell you the steps you need to accomplish to hide away those 2 the best way we can. We also show you what you don’t/can’t do!

How to change what we see as a simple user?

A great question to start with…as we normally start explaining from the ‘awdev’ account perspective that has our ‘Developer’ role applied (and in my case also the ‘Administrator’ role!). It’s also a good practice to create a simple user account to test your solution with! Also, when you’re still in ‘development’ mode. This makes sure you bring the functionality to the correct user at the correct place, because as a ‘Developer’ role you will see much more information on the screen than a regular end-user will.

So, jump into your organization with our ‘awdev’ account and open the ‘User manager’ artifact. I do the assumption you just have plain AppWorks running without any OTDS connected with it as the intention for this post is not to use it!

Let’s create a new platform user ‘awuser’ and provide it with your own password (in my case ‘admin’ as I use for all my accounts)


Now, let’s go into runtime with that new user and see what we get?


That is a pretty clean screen with only the ‘Default’ homepage and an inbox! You see in version 20.4 the ‘Identity’ components are already removed by default…nice!

Let’s see if we can clean it up a bit more and introduce our own ‘start’ homepage!?

When you go to the /app/admin panel of AppWorks you will see 2 solutions already deployed

1. OpenTextEntityIdentityComponents

Here you see the homepages of the ‘Identity package’ passing by:


You can indeed disable the ‘Home Page’, but this option is not available for the ‘Identity Home Page’ as that one is visible when you have the role ‘Identity Administrator’ applied!

Also, if you remove that ‘Home Page’ from the ‘Entity Runtime User’ (like you see in the screenshot) you will see that the user in runtime will end up with an endless running loading icon as it can’t load any default homepage anymore!

To get that one fixed make sure you create a new ‘Homepage’ layout in your solution and make sure that the correct runtime security is applied to it…

Watch and learn…

So create a new homepage layout (in a nice ‘layouts’ folder to keep that steady project structure)


When done…define the runtime security on that homepage:


In that ‘Runtime Security’ you just add the ‘Identity User’ or another role, but ‘Identity User’ is applied to every user by default…easy as that! Don’t forget to mark that ‘View’ option for the role.


A publication and refresh in runtime will give you a new default homepage…How nice is that!? 👊


Yeah…I tried to load https://www.google.com/ in a ‘Web Content’ panel, but that’s more my image that fails to connect…Whatever!?

2. OpenTextInboxTaskManagement

You also saw another solution passing by in the /app/admin panel. This solution makes it possible to ‘hide’ the inbox from the users in runtime!

Let’s enable the previous disabled homepage (where you saw that inbox) and now we disable the inbox feature from this solution…


A refresh (directly) in runtime for an ‘awuser’ account will hide that inbox from that default home page!


This is much, much better manageable than it was in earlier versions of the AppWorks platform…Great job!

So, again, to not forget…That ‘Security runtime’ feature I’ve just shown is more required since the last versions of the platform! Not only on BPMs, but also another document types as well!

You might raise the valuable question: But how is that arranged for entities?…Well, what about the ‘Security’ building block…And yes, that’s another post, but to get you in the correct direction…A sample screenshot:


Again, simple, and easy with the already available ‘Identity User’ role, but you can apply any role you like! After this publish? It makes my ‘todo’ entity available in runtime for the ‘regular’ user!

Do I hear a ‘smart guy’ asking…What about the ‘Solution security’ in the /app/admin panel for my solution?…Well, that’s the beauty…It’s not needed anymore…Hooray AppWorks! 🍻

Disable in /app/admin (can’t do it!)

Yes…read that header again…I’ve tried it…See this result:


Uninstall the CAP (don’t do it!)

Let me be clear on this…DON’T do it!!

For you to understand and learning things:


This ‘Application Deployer’ will be available for the ‘Administrator’ role, and it’s best to play with CAP files from the ‘system’ organization.

For you to see what will happen…Some screenshots:


Hit ‘Next >’


Hit that ‘Undeploy’ button (But again…not recommended!)

To be clear…I’m on a VM with a snapshot!


Time for lunch…


There you have it…So, don’t do it!

Use roles with security

To finalize the post a share about the roles that can be used with the Identity package. These roles can be found in the ‘User Manager’ artifact with an exception to the “Identity User” role. This role is applied by default for all users! It enables access to the standard homepage that contains the user inbox to retrieve tasks (when enable as you saw during the demo in this post). This we have the “Identity Administrator” which enables the access to the identity homepage for managing user information!

So when you assign a user to it like this:


You will start to see the ‘Identity Homepage’ in runtime for that user:


The last role for the ‘Identity package’ is the role with the name Identity Push Service. This role is used for making connection from OTDS to AppWorks and makes sure that user/groups/roles are consolidated via the user that has this role applied. For your convenience: This post uses that role.

What else?

In the ‘Low Code Development Guide’ from OpenText you can also find a lot of information on the ‘Identity Package’ and what is included in it. It is even explained how you can customize it in your solution (but that’s another post!)

I also found out this small section that also explains a bit what was shown in this post…


Well…”DONE”…Again learned a lot of information on how to start playing around with the “Identity Package” that includes several roles and homepages. We learned how to hide identity homepages based on the ‘Identity User’ role and how to create a new ‘default’ homepage to the end-user in runtime. This post even covered what you don’t want to do…We tried it out, but you saw the devastating results!

Have the best of all week-end…CU in the next post on another great installment on AppWorks Tips…

Don’t forget to subscribe to get updates on the activities happening on this site. Have you noticed the quiz where you find out if you are also “The AppWorks guy”?