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.