Hello,
I was wondering how hard it would be to write a BPM that stops Parts Maintenance from opening and pops up a box telling them access denied? Would it also cover the right click to get to Part entry?
If it is not possible, I can go through the minefield of Menu Maintenance and try and alter to give certain people access to it in 11 different places… How would you stop the right-click to go to Parts Entry if going this route?
Any and all comments are appreciated.
Thanks,
Shawn
We created a security group called “Part Setup” and attached all references to Part Entry in Menu Maintenance to allow only that group.
Then, we gave that security group to only the users that needed.
Easy to give; easy to remove.
Maybe an expert here could do a quick “Experts Corner” posting of the differences between Menu, Field, and Process Security. When to use each, any shortfalls to a particular one, etc …
I can’t answer about a BPM, but we did have a situation where because people needed different permissions in different circumstances we created a customization that swapped out one form for a different one when opened.
And from doing that, I’d advise you to try to make Menu Maintenance and Security Groups work if you can. It might sound like less work to create something else, but it probably isn’t.
I definitely agree with the others, use Menu Security as it was intended.
The context menu (open with) will use the menu security of one specific menu ID. If you open it while developer mode is on, a box will pop up telling you which Process ID is called. That Process ID should match the menu ID from menu maintenance, so you can verify the security used by the context menu.
we did two security groups. one allows menu access to part entry for changes the second is on a bpm for adding new parts.
Hi Shawn,
I also lean towards the menu security. It does seem a hassle at onset, but not too difficult to manage once setup imo. We avoid use of field security… seems a really big hassle, but perhaps someone would disagree. Some things we’ve done, or found handy:
use a generic name for your deployed customizations. This way when assign to menu, it sticks in all the places. Note the revision of the customization on the top tab and in a comments section of code and use rev notation for in progress work, but when deploy, always save as/call it the same thing e.g. PartEntryCUST for your std customizations naming convention or something like that
instead of having two customizations for different security access, we have a customization that disables all controls, then enables those needed for particular functional groups… e.g. part planning fields accessible for planners, other part entry fields and new creations for engineers, etc.
Nancy
And make sure the actual menu item security is set. Just removing access to the menu’s Parent (like General Operations for Part entry) doesn’t do anything to prevent a user from using right click and “Open With…” ?
I did a test where I gave a user access to nothing more that Sales Mngmnt -> Order Mngmnt -> Reports.
All other “top level” menu were set to disallow access (but not their child menus) And was still able to get into Part Entry.
Here’s a GIF of using the Part filter field in a report, to open Part Entry.
Setting the security on the Part Entry menu item does the trick. After doing that, I get
When using the Open With…
For point 2 of Nancy, we add to the form name the version on the load of the form:
private void SalesOrderForm_Load(object sender, EventArgs args)
{
// Add Event Handler Code
EpiBaseForm form = sender as EpiBaseForm;
if(form != null)
form.Text += " - " + form.CustomizationName;
}