Hi there “Process Automation” fans,

Welcome to a new installment of “Process Automation” tips.

Do you recognize this scenario: You’re in a low-code development flow; Which is a cycle of crafting, publishing, and testing (with a test user!). During your testing, you see things going wrong on your entity for whatever reason. Like for example fields getting a wrong value from a ‘Rule’ BB or a “BPM” update call. Only, at that moment you’re searching/working for something totally different and don’t want to dive into this small side-track issue. So, for a quick fix (to continue your larger scope), you quickly call an “Update” service from the ‘Webservice Interface Explorer’ artifact to put things straight (for now). A nice trick, but we can do this smarter! I mean “smarter” as of not moving towards the designer UI, but updating the value directly in runtime…WHAT? Yes, keep on reading my friend…

---

Let’s get right into it…

Time to boot up the VM with your favorite spot. In the meantime, let’s think this over…A “Godmode” tab? How would we implement such thing? Well, it should be a toggle switch which we can turn on/off from a central configuration standpoint. So, that’s a new “Application Configuration” type of entity. Next, we want to make sure this switch is only available for “special” users; Most of the time called “Administrators”…Whether it’s “techie” or functional, is up to you. So, we need a security with roles. Next, we want to show our “Godmode” tab in the UI, ONLY when the flag is enabled!

Be aware that enabling this flag will show the tab (in our entity layout) for each instance in runtime! For all users! Why not show this tab to administrators only? Well, that’s impossible as that would require us to use a business rule on the tab (via a rule category) to hide it using functions like isInRole(...), but they are not available for usage in a “property change” event (check the documentation!). I know!? #SUPPORT
Is it still wise to implement? From a development standpoint it is; from a production standpoint it could, but use it with care. It’s not for this post, but you can also extend this tab configuration to show it only for a specific entity ‘ItemId’ that you can configure next to the flag!

The bar is set…VM is up and running; Time for an implementation. Make sure you first create a basic ‘Case’ entity; Just with a couple of properties and the basic building blocks in place. I name them wisely, but that’s just a pro habit:

Edit the ‘Create’ form making it a little nicer…No fancy stuff! Just as simple as this; With some nice settings in the right panel matching the type of property:

I made the lst_cases a little better with correct columns and proper settings:

For the rest, it’s these slight changes in the entity overview:

• Set a default duration of 7 days
• Remove the ‘none’ option from the ‘Is active’ property
• Set a default progression of 10 with a minimal of 0 and maximum of 100; You can build rules for it to set it properly (not for now!)

Publish it, and try it in runtime with a test user (non-development!)…”Test user”? Yes, we as great low-code developers do all the testing with a real test user having the correct role feeling the pain of a bad security implementation.

Guess what? Your test user (at least my test user) can’t do anything with our solution as we did not implement any security (yet!). This is what my test account sees:

Exactly…nothing! What about the default “Homepage”? Well, that’s disabled! WHAT…How? Ask your administrator to update this setting:

Nice, but how do we show something to the end-user? Simple…create a role, create a homepage layout, set the runtime security to the homepage layout (from its context menu), and apply the test user to the role…Watch this:

Comment me, if you don’t have a clue where to click for these settings…I just want to make a quick progress incl. nice possible thinking routes. Ohw yes…The homepage only shows a ‘List’ panel of cases lst_cases!

Do a publication, and check the result in runtime:

Interesting question: My test-account can already create a new case instance AND even delete them? Yes, that’s correct as we did not implement any security on the entity (yet!) which makes it “open” for all! It’s your job to secure it wisely.

So, it’s about time to add the ‘Security’ BB to the ‘Case’ entity with a first implementation like this:

Now your test user can only create and update, but can’t delete! Who can delete? Well, that’s your record manager or the administration team…What are you waiting for; Create a new role (AND put the ‘End user’ role as sub-role)…

…add it to the security BB (AND don’t forget to apply your developer account with it from the ‘User Manager’ artifact!)

You see, I’m only selecting the ‘Delete’ action here, but this role can also ‘Create’ a new instance (although not selected)! Why? That’s because of the applied ‘End user’ sub-role! Is it smart to leave it like this? Well, it depends on how your comrades/team-members see this as now they need to “remember” that sub-role implementation, and removing the sub-role will remove all other privileges (like updating) on the instances! Be smart, and checkmark the rest too!

…

A quick recap; So, our test user can create new cases from a dedicated homepage layout and our administrator can even delete an instance which the end users can’t do.

The form is now open for changes, but as your project gets bigger, you’ll see (for whatever business logic you implement) that fields will be disabled and/or you require additional “hidden” properties helping you to implement a feature. With a closed/read-only form you can’t change/see anything in the UI; Even from an administrator team! Now, this team can of-course watch the developer tools of your browser on some non-UI values; Or they use the CRUD operations on your entity (if exposed), but there is a quicker way which will also benefit development!

…

This is the heart of our post where we first make sure the end user can’t change things in the default ‘Create’ form:

This is just a quick change for the demo; I also pick the ‘Create’ form as it’s both in the create screen and the layout view (after creation)…I know; We could do better, but that’s not for now! You can also add a container, add a ‘Rule category’ to it, and create a UI ‘Rule’ to disable the container/category. Another approach is to disable the ‘Update’ checkmarks in the ‘Security’ building block. What is “wise” depends on your requirements.

Next, we’ll add a second form (can be a copy of the ‘Create’ form) with the wise name frm_godmode where you enable all fields AND nothing is required (to avoid weird errors in runtime; A valid choice as you’re the administrator/developer understanding what you’re doing!). You can add this new form to the default layout with a new ‘Rule’ category rc_god_mode:

Do a publication, and test in runtime…Your end-users will see two tabbed forms now!

Now we need to make sure the tab is “hidden” based on a global setting; That setting is a special type of entity called the “Application Configuration” entity. Right-click the project and add new one. It’s just an entity like any other entity, and we only require a new Boolean type of property with the name is_godmode.

These are my other changes for this configuration entity:

• The Boolean only has TRUE|FALSE (default FALSE)
• ‘Create’ form shows this property as checkbox
• Layout has a proper label Generic configuration as we’ll see this in /app/admin
• From the entity properties section name this entity cfg_generic with label Generic config
• It’s even possible to change the location of this entity in the quick access menu in the top-left of the entity-crafting-screen

Publish again, check /app/admin (with your developer account) on this link:

Now you guess what’s behind this link? Yes, the “Godmode” enablement!

Great, one thing left!…showing (or “un-hide”) our new tab when “Godmode” is TRUE (or “NOT FALSE”)! That’s business logic on the ‘Case’ entity from a ‘Rule’ building block perspective with the fancy name e_opc_hide_godmode_tab; Simple and easy like this:

For you to copy: !(config.cfg_generic.Properties.is_godmode)
And indeed; These are valid too, but weird from a programmatic view: config.cfg_generic.Properties.is_godmode==false or config.cfg_generic.Properties.is_godmode!=true

…

I’d rather loved to do something like this as an expression: !(config.cfg_generic.Properties.is_godmode && isInRole('opa_tips prj_generic', 'fun_administrators')). Only, this isInRole method will only work when you have pushed platform roles into OTDS and consolidated them back into OPA; Read about it here…This is the end-result, so you see where the values of that function are received from:

And after #RTFM, I conclude this is not possible on a “property change” event:

#WTF…Ok, we’ll just swallow and continue life as is! Our flag is working which is sufficient for our post to let you ReThink!

---

That’s an after-taste “DONE” where we did an implementation of a new “Godmode” tab. This makes it possible to change ad-hoc properties on your entity without moving away from the runtime UI. Keeping it in a separate tab makes it easy to hide it with a simple configuration toggle. Put this toggle under the restraint of the administration team, and you have also a straightforward way to update data live in production when smartly implemented by you. That’s how you expose great power…But never forget…it also comes with great responsibility! Have a great weekend…cheers! 🍻

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 Process Automation guy”?