I am trying to figure out the best (easiest, too) way to implement security based on CRUD access.There is menu security, service security, field security, extended properties, context menu maintenance and customizations.
It was recently discovered that one of our sales reps (let’s call her “Mary”) used Job Manager to figure out availability of inventory. She used the context menu of the part number to launch Job Manager.
A request has come down from on high to limit access to Job Manager. I know that I can simply remove it from the context menus, but we don’t mind if she sees it, we just don’t want her to touch it…
So… it seems to me there are the following options:
-
Remove Job Manager from the context menu. Unfortunately, this would remove it for people who are allowed to access it.
-
Menu security. Prevent Mary from navigating to Job Manager. This is already in place.
-
Service security. Can prevent Mary from accessing Job manager altogether, but this seems like overkill, if all we are worried about is an errant change.
-
Field-level options seem too low-level for what we would like to do.
A few questions:
-
If we were to secure via Service Security, but did not secure the menu, would Mary still have access? Or would she see the menu item but get an error when she clicked it? Bad user experience but good security.
-
Is there relatively easy way to make a service / business object read-only for a specific set of users?
-
If we have made a service read-only , I assume I can use field-level security to open up one or two fields which are editable by a user or users?
Best practices, anyone, for replicating security based on typical CRUD operations?
Thanks.
–sam