User Permissions and Form Control

I am transitioning from Access/VBA to VB.net, and this is my first real project (it is a Windows Forms Application project). I am using VS 2019 and MySQL. It is basically a custom small ERP system for tracking orders, defects, inventory, and some reports in a very niche manufacturing company. I am not sure if I am going about this correctly. I just don't know how to proceed otherwise.

I have a form for admins to be able to set permissions for users. (NOTE: The duplicate named check-boxes and labels in each section are just place holders.) Here is a partial screenshot.

Attachment 185962

In the db I have two tables: employees and permissions. The table has boolean fields for each checkbox. These tables are joined on Employee_No. I have read that it might be better to use permission groups based on roles, but then I have to create a lot of different groups to provide the level of control that I need per user.

Given my current plan/structure:

How do I apply permissions to the forms in the application? Are there Nuget packages or specific extensions for something like this? That is, allowing or disallowing certain buttons, selections, or the form in general?

Until now, I have always placed all form events (button clicks, combo box selections, etc) within the form. Basically just a lot of decision-making code with If-Thens and Select Case statements in each object event making this enabled or visible. I would like to know if this is the correct way or if there is another (correct) way. I have tried searching online but have not be able to find a definitive answer or examples of how to do this.

Any assistance would be greatly appreciated. If someone could suggest how to handle this, or a resource that has actual code or structure examples, I would be very thankful. If you need me to clarify something, please let me know.

That is certainly a way that is used quite often. It has a bit of a disadvantage in that you are baking those rules into the code, so if you change your mind, you have to change the code. Whether or not that's a real disadvantage is up to you.

Whether or not there is a better way probably depends a whole lot on the level of flexibility you need. If you are talking about whole forms being allowed or not, that could be somewhat different from 'a few controls' on a form that should be present or not. It also depends on whether or not you would ever want to change your mind.

Permission groups and roles could be talking about database access, which would be a different thing. In the case of forms, I'm not so sure that the actual work behind the scenes is all that much different from what you are already doing. It is certainly easier if entire forms, or menu items, can be denied to a user. Finer control requires a bit more work.

Thank you for the response. Should I put the code allowing or denying features/options in the form module (say the OnLoad event) or in a separate module?

As for changing my mind, this was the original intent of frmPermissions with all the check boxes. So when the main form for a section (Accounting, Manufacturing, etc.) is opened, I would query the status of permissions for that section and apply it? Is storing the permissions in the database the best option? Or would there be a way to generate a static file for each user when their permissions are set by the admin, then somehow use that user's static file to set the permissions?

I know that there are a lot of "what-ifs" and "or this way" in this topic. I am not discounting any of them. I am just trying to learn what the options are, and what would be best-practice for future updates and requirements. Maybe I should phrase it as a "what would you do" question. I don't have enough experience to really make some of these decisions.

Thanks again for your time and assistance.

Personally, I've only encountered this in a very trivial situation. Showing/hiding a single menu item was all I needed to do. Interestingly, I'm not sure that any of the dozens of users ever really understood that was all I was doing. They seemed to think there were two different programs.

If I were to do this on a larger scale, with many more options, I'd be inclined to go about it in a couple different ways depending on the situation.

1) If there is any realistic chance that somebody will hack/decompile the program, then something more significant would need to be done...all the way up to creating multiple versions.
2) Assuming that your users are fairly benign, then I would be inclined to just be either passing around the permissions as a value (could just be an integer, but an Enum would be considerably superior, and a string would be informative, but just plain worse), or have the permissions as a global variable, though I'd want to make it readonly, so perhaps a static Readonly property of...something accessible to all who needed it. Either way, I'd do the setup configuration in either the constructor or Load. Generally, I lean towards doing as much as possible in the constructor, rather than load, because that allows you to be a bit more flexible. After all, the constructor runs when you create the form, whereas Load runs when you show the form. Showing a form usually follows soon after creation, but it doesn't HAVE to, and if anything about the setup is slow, you can take advantage of that distinction.

Thank you very much for the input. I am always hesitant to ask "non-specific" questions like these. I learn a lot from them, not just corrections to my mistakes in code. I guess I will start blocking out the permissions and see how it works out. Thanks you.

It's been a while since I did security this way ... and at the time, what we did was have the info condenced into a number. So instead of columns of booleans, there was one column "Permission" ... then each thing we wanted to "lock" down was a ssigned a number powser of 2...
So View = 1, Edit = 2, Delete = 8 and so on... then we just mask the numbers so that we can test to see what permissions the user has.

Code:

---

If permVal and VIEW_PERMISSION = VIEW_PERMISION then ... they can view the data
If permVal and EDIT_PERMISSION = EDIT_PERMISION then ... they can edit the data
If permVal and DELETE_PERMISSION = DELETE_PERMISION then ... they can delete the data

---

So sopmeone who could view & delete the data would get 9 ... edit and delete? 10... 11 for all access (in this case)...

We also had roles that had precanned values... so rather than adding users to individual permissions, they were added to a role, which had the permission on it. We also then had the ability to oveerride that for individuals. This was done by loading the permissions based on role first, then loading by the user and overlaying it. Where there were changes, we'd apply the change, otherwise left it alone.

-tg

tg - Thanks for this additional information. The 'assigned number' method seems very promising. It gives me another avenue to consider .

Technically, the assigned number was what I was talking about, too. An Enum is an integer. Whether you use a constant or you use an Enum, it's all just an assigned number. Also, since you can assign a value to an Enum, so long as you assign powers of 2 to values in the Enum, you can put a person into multiple roles by ORing together multiple values.