Roles Pattern

It's been a while since my last post, but I trust this one will more than compensate, as it addresses a seemingly innocuous yet common issue.

Previously, I delved into the realm of privileges, exploring how to identify who holds access to what. I'd call it curing or dealing with the symptopms - in perfect world you wouldn't need it. Todays post will try to treat the causes. It's a pattern I've used in few applications already, and for my cases it works really well.

The problem

WEBCON let us manage privileges on many levels, very granularly, which is great! Isn't it? It looks like that at first sight, but...

We can set privileges on many scopes, from most generic to more detailed:

• System
• Application
• Process
• Workflow/Form
• Form elements
  • Attributes
  • Paths
  • Menu buttons
• Presentation
  • Reports
  • Start buttons
  • Dashboards

Navigating through these layers can be daunting, especially when specific permissions are required for individual users. This complexity often leads to what can only be described as a "privileges spaghetti," particularly when trying to replicate permissions for new hires based on existing individuals' privileges. It's a challenge I encountered early in my WEBCON development journey, and one you may be grappling with currently.

The pattern

In traditional programming paradigms, patterns abound, aiding in the resolution of recurring issues. They are helping with solving recurring challenges. You can read about those more on refactoring guru, which i find explains those really well.

Refactoring and Design Patterns

Refactoring is a controllable process of improving code without creating new functionality. Design Patterns are typical solutions to the commonly occurring problems in software design.

email

With low-code though we don't face exactly same challenges, but there still are some good, and bad practices, the do's and don'ts. This in my opinion fits into the do's.

Now let's get to the meat.

Rather than defining privileges per department or individual, consider defining roles. Pose the question: what roles require specific permissions? Then, create placeholders for these roles, which can later be assigned to individuals or groups.

This is not something new, there are already applications which let you assign roles, GitHub, GitLab, Entra, even Microsoft Word thinks in concept of roles - there is Reviewer, and Editor those not necessarily manage permissions, but someone thought during the development, that not everyone will create content in word, some people will just review it.

In WEBCON role will often be connected with a job title, or the department but not always. This will require a good business analysis to get what kind of activities will be there in our application. If you are familiar with user stories, this is the first blank spot to fill in. If not this short video will get you to know this technique.

As a __ (role) I want to __ so i can __.

For example:

As a manager I want to get notification, when my subordinate asks for a leave, so i can review it.

As a manager I want to see if any of my employees have taken leave for the same days.

As an employee I want to see how many leave days i still have, so i don't have to ask about it every time in HR.

As a maintainer/administrator I want to be able to Cancel process, at any time.

From examples above, we can clearly see three roles: Manager, Maintainer and Employee, it doesn't matter what is job title, or department of a person everyone is Employee and process of asking for a leave is the same. Maintainer role could be done by HR representative, IT, developer, or a maintenance department member.

I hope, this will get you on board with understanding what roles are. But how do we use that in WEBCON?

Implementation

I've tried two ways:

• Defining roles in Active Directory (AD)
• Defining roles as WEBCON Groups

From my perspective it works much better with WEBCON Groups, and this have some advantages too. First of all - if you want to create groups in AD you'll need to get your IT Department on board with it - it might be hard. Secondly, keeping them as AD groups doesn't keep them attached to the application.

Let's say you are WEBCON partner, and you create applications for multiple organizations - you won't copy AD between them, but WEBCON groups, are kept within .bpe packages, so you can import ready application, and just assign people to already prepared roles.

For each role you defined during analysis phase, create a WEBCON group. Use that group for all places where you want to make sure that only specific user can see, or do something.

In this case manager, and employee roles are very dynamic - everyone can request a leave, and everyone have a manager (except the last one in hierarchy). Employee role will be filled with all people in organization, and this role will have privilege to register leave request, and view the application.

Manager is kind of tricky - it's not a set of people who can see something about everything, so in this case there won't be a need to create such role as WEBCON group, but to make sure only manager of requestor can see collisions - there should be a business rule for that.

Maintainer/Administrator - this is a role, that should be created as a WEBCON group, there are specific people who have those Business administrator privileges, and only they should see that Cancel button in each step.

So to sum it up:

• Avoid assigning permissions per specific person/department
• Try to define roles in applications, which are assigned to users, or rather which users are fulfilling, user stories might help you with that
• WEBCON Groups, are pretty good place do define roles, as you can use them in business rules, and also in visibility restrictions on reports

I hope this pattern will help you with maintaining applications in the long run, and also in creating new features, which could have more thought about who will really need them!

Bonus

I've reached to other WEBCON MVP - Daniel Krüger before publishing this post to get some feedback. He shared that he's using similar pattern. Daniel also gave few tips:

• If you need a default person for some roles, then you could use webcon dictionaries to achieve it.
• If you want to have better overview where roles are used - you can create constants for those roles, and use them through constants rather than directly.