Humanipro application (2 Viewers)

[Pat Hartman]

Much more complicated is limiting different users ability to do certain task within a form, (eg delete records). as every form will need manual coding to test the function and the user.

Take a look at my simple security. That's the point of the add/change/delete/view options. Each relevant event calls security as the first line of code in one of the four relevant events and either allows the event to proceed or cancels it.

 

[gemma-the-husky]

Take a look at my simple security. That's the point of the add/change/delete/view options. Each relevant event calls security as the first line of code in one of the four relevant events and either allows the event to proceed or cancels it.

Yes, but doesn't that mean you have to modify inside the form to call the appropriate function and determine what privileges are needed to execute the event? It's easy if the atomic event is "the form". It's much harder if each form contains multiple decision points. Don't you also need to explain to users how to manipulate the settings to authorise the users.

 

[MarlonVisser0408]

You gave us a bunch to "chew" on and you can probably expect comments to take a while in coming. I saw the above and want to comment on the specific implications. "Group" is unfortunately one of those words that runs into ambiguity in the Windows environment. The commonplace use of the word "group" - meaning some number of people who will use the application in a similar way - can be implemented by determining a User ID in some way and having a user table that lists the groups (or perhaps you mean roles) that each user would play.

The idea is that AccessUserGroup will hold the data from both the group and the AccessUserID. The form AccessUserOption will hold the options inside of it. In my head, they're not often touched. The Group will hold all the things you need to do your job and therefor you don't need to touch the AccessUserOption. The only reason that there's a second layer of permissions is so granting (temporary) access to a part of the application will be a lot easier and has a lot more ways of finetuning, all the while that you don't have to touch a group role or add one.

The complication is that Windows has groups, too, and they actually have the same meaning - but very different granularity - as the "role" concept that we often see in Access apps. The difficult part is that there is no built-in Access function to test Windows Group Identifiers. You must use one of the Win32 API calls and the one I looked up is ugly. I have used a single Windows Group Identifier as a way to gain/grant permission to open an Access app, but the user role within Access is best determined totally within Access. You would use the user's Domain ID to identify the user and then look up the user's role in a table. There are several relatively easy ways to more reliably determine a user ID if you are in a domain-based environment, and I might suggest some articles by our member isladogs to be an excellent - though not the only - source on that subject. Our SEARCH facilities allow you to put in a topic AND a username for your search, so that should help narrow down some articles.

Thats a very good point to make. I'll need to change the names to represent them being different kind of data than the Windows/Microsoft native data carrying the same name.

I've talked at length about some security options with a friend of mine. He's really into helping with small parts and coding at the background and he already looked into my situation for giving me some security outside of Access. There's multiple machines that I'm using throughout the week and some of them don't have the domain setup correctly. He's looking into making a custom set of code and help me get through a proper way of securing things - it's the reason I'm not too worried about that part.
One of the reasons is that we're going to put that part through Windows and my Microsoft environment for liability reasons. *If I understand it all correctly. It took him a flat 3 seconds to start talking about things that went straight over my head

I'm responding to a narrow subsection of your post simply because it will take a while to digest the whole thing and this is something I could offer quickly. If you really mean from that quote that you want to discuss a user's role in your company as a guide to how they would use the app, the keyword to look up in this forum is "role-based" (with or without the hyphen).

Yeah, that's the perfect thing to do here. At least now we got a better idea of some of the difficulties, the scale and some of the reasoning. I hope it wasn't too much of a tough read

 

[MarlonVisser0408]

@MarlonVisser0408

The trouble with spreadsheets is that they don't offer you the strong data-typing at the column level, that you get with a database field.
Their really is no comparison. It's pretty bad that spreadsheets get used for all sorts of things where a database would make much more sense, especially in commercial and even government applications. The problem is that a database requires a much deeper understanding than a spreadsheet, and a casual user just can't achieve credible results.

For instance though, a database is always multi-user, unlike a spreadsheet.

Yes, this I found out. Part of what made me wonder is the ignorance about if it would be able somehow to have both the applications communicate in a better way. Now that I found out that I should not look at them as compatible; things got really easy - no can do.

Much more complicated is limiting different users ability to do certain task within a form, (eg delete records). as every form will need manual coding to test the function and the user.

That's interesting and makes me want look into it, haha. I thought that it was as simple as checking if statements are true? Ignorant is bliss