Hello StackExchange community, I'm in a bit of an impasse for my current project.

The software in question is a collaborative program designed to let employees work together on the platform and assign tasks to each other, that can be further split down into subtasks, as far down as the company would like to divide the work. In tandem to this, each layer defines a part of the company hierarchy.

E.g. A company decides on three layers. Layer one lists all tasks for a branch in the company, layer two defines the departments and layer 3 closes it off with tasks for employees. Additionally for each branch or department a user needs to be the designated manager, as to allow task creation in the first place.

So far our software had rudimentary access control in form of a simple flag based check whether the user can read, write, delete or manage Information for the entire account (where users of one company are seated). This is about to change as we now want users to be able to freely delete and write tasks that are assigned to them and to any department/branch/etc they are assigned to.

Now that I am designing the corresponding system I asked myself whether a role based system (rigid Admin/Management/User) would be enough in the long term, as the actual control hinges on where the user is assigned to, not what actions he is allowed to take. Reading is always allowed (except for account data, this is reserved for admins), and a user designated as department-manager, will always have full control over its tasks.

My worry here is, if we decide to expand the program with another module (like project management or inventory forecasting) and then suddenly need finetuning, however my take would be to completely separate access control for these modules and decide what the best approach would be for either of those.

I hope this was clear enough, and would humbly request tips, opinions or approaches. My gut tells me to go with the simple roles and maybe later implement a permission system for admins, if needed at all (the worst features are those never used), but I don't want to just forgo good software design.

3 Answers 3


It sounds like capabilities may be a good match for your security model, given the flexibility with which a department manager can delegate spending authority to folks working on a project.

A downside to that is what it takes to revoke Alice's authority when things change later. Typically it involves transitioning old project identifier to a new one that has never been disclosed to Alice.

Some government contracting firms maintain monthly paperwork on the set of staff who are allowed to incur expenses on a given project. If your finance oversight structure already has such a concept, then your specification has already been hashed out and it's just a matter of implementing it in code.

  • 1
    Thank you. I was thinking of something in the likes of this, but did not know there was already something defined in that way. I'll give it a go!
    – manimerz
    Feb 14, 2023 at 8:08

The standard role-based approach which is sufficient for many of comparable systems implements

  • user groups (like OrdinaryUsers, Management, Admin)
  • permissions (for example, ReadTasks, ReadWriteOwnTasks, ReadWriteDepartmentTasks, AccessProjectManagement, RunInventoryForecasting)

and assign users to user groups and link permissions to user groups (and sometimes link permissions directly to users).

If I understand your question correctly, you want to avoid a permissions table in your system (where the links to user groups can be assigned by admins) and implement the allowed actions for a certain user group directly in the code. Admins will only be required (and allowed) to assign users to user groups, not more.

Strangers like us cannot tell you if that will be sufficient for the organisation which uses the software - a requirement like that must be demanded by exactly that organisation. However, if you think hardcoding is enough for now, but may not be in the future, start with hardcoding the permissions, but implement them in a way which makes it easy to switch to admin-assigned permissions later.

So avoid to write code like this

  if(user.Group == Management || user.user.Group==Admin) { UpdateTasks(...);}

Instead, have a method User.GetPermissions() in your code which returns a list of permissions derived from the user groups the user belongs to by some static rules, and control allowed actions by testing against these permissions. Later, when it turns out the permissions need to be retrieved from some database table, it should be pretty simple to implement this - at best, you won't have to change anything in the area where the permissions will be evaluated.


Similar solution have a method:

Boolean User.HavePermission(permission.AllowUpdate)

usage: if(User.HavePermission(permission.AllowUpdate)) ...

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.