wrapping security around ItemType on InventTable

I have a unique problem and im not sure the best way to approach it.

I want to be able to split out, either by group or by key, what users can create what type of item. each item type is maintained by a different group of users but some users do exist in both groups.

a few ideas i had where:

1). Create the combobox control manually looking a users groups or keys and add in appropriate values on the inventTable form then before the record is inserted convert the enum string back to its value. Ie:


2). Create a one off form for each item type like “BOM Item Details” or “Item Item Details” then default the itemType on create to the appropriate type

3). on the inventTable form, disable the CTRL + N functionality and add a button on the right to create a new item of each type then use standard security to lock down who can access specific type creation button.

RLS won’t work because even with an itemType filter for a group, you can still select a different enum value than the RLS query specifies. any input as the to the “Best” way to do this would be greatly appreciated. my perference is something like 1 or 3.

First, this is an ideal case for RLS and it should work. I just tested in my system with a test user and the issue was merely that the combobox displayed the optional results, but it wouldn’t allow a user to save and it broke the lookups of the other combo boxes.

I wouldn’t go hacking up the invent table if you don’t have to. The methods 1-3 all sound like you’d be hardcoding the menu items or something.

Also your option 1 doesn’t need so many nested methods (See page 30 here):

if (hasSecurityKeyAccess(securityKeyNum(Bank), AccessType::Add))

info(“Access to bank security key”);

alex, thanks for the reply. I can’t get RLS to work for me but i think that is related to our security model. its involves two basic types of groups: “AllTables” grants read only access to all tables on behalf of the system so dropdowns and stuff work then a second “function” group that grants create/edit/delete to specific tables and perms to forms, buttons reports and so on. Whenever i assign an RLS query to tot he “function” group, i don’t get the expected result. However, if i remove “allTables” then it works as expected but that allTables group is key for our security to work.nearly all security is predicated on the AllTables group so unfortunately we can’t get rid of it.

and thanks for the tip on the HasSecurityKeyAccess function.

As for option 3, i would just be adding buttons to create a new InventTable record, set the type based on the button clicked then locking the comboBox so the user can’t change the item type before the record is saved. it would basically be CTRL + N plus two lines to set the inventTable.ItemType and locking the control.

based on the “allTable” group i mentioned earlier, do you think RLS will still work? also, do you have a blog?

I’ve had issues with RLS and it sounds like it might be too big of a lift for you to get it working. I have a blog http://alexondax.blogspot.com/ .

Now to answer the root question, there are many ways to skin a cat here, and all of your solutions will “work”, but I’m personally not a fan and they don’t really follow best practices. They’ll work for now, but it’ll end up being tribal knowledge that only developers know and I’ve seen it too often where systems have so much customization that the only way to figure out what is going on is to jump into the debugger.

I don’t like the idea of disabling Ctrl+N because that should be a native functionality/feel throughout the application. I’d prefer overwrite the validatewrite() and throw an error there so they cannot save. That’s just how I’d solve the problem, but to implement it and make it scaleable…I’d do this (high level tech description):

  • On Forms\InventParameters, add tab called “Item Type Security” or whatever
  • Add a nested tab control with tab 1 being “Item Types”, which would display Item, BOM, Service in some type of control
  • Tab 2 of the nested control would have a SysListPanelRelationTableCallback form control with the left side being permitted user groups and the right side being remaining user groups. This would be a 1:n relationship from the first tab.

This way “administrators” can control the different security of user groups dynamically. I work with a SOX compliant company, and releasing code is a pain with the various approvals, testing, signoffs, so I try to make it best practice and able to be changed easily.

To see an example of the SysListPanelRelationTableCallback control in use, go to (Admin>Setup>Server configuration), and the far tab “Batch server groups”. The basics of how to use it would be create a class that extends SysListPanelRelationTableCallback and add whatever methods you need following how that parent class works. Create your own custom table that will store the “permitted user groups”. Lastly, put a bit of code to check the table during validatewrite (probably on the actual table unless you have other custom code preventing it from being on the table).

Again, it’s all how you want to design it and be creative with it :slight_smile:

unfortunately we have already passed that point (through no fault of any one developer here). our VAR/ISV have a fairly large product in our environment that ignores most, if not all, best practices. security was one particular mess i had to fix (ie, lots of things missing labels and keys)

I will invest a few hours in the sysListPanelRelationTableCallback approach but if start running out of scope, i will most likely go with option 1 above. this is our last round of fixes/enhancements before we end all development for 2009 and start implementing 2012.

also, i do want to say that i don’t like doing things against best practice but our specific environment is so far removed from standard AX that any of the options i listed above would fit right it :confused:

we are going to fix this with out 2012 implementation.

Believe me, I know how you feel. My current company has the most custom system I’ve ever seen and there are lots of things that don’t fit the best practice and it’s just been a ton of headache for me jumping in the middle, but “When it rains it pours” is sort of the attitude.

If you want to learn the sysListPanelRelationTableCallback it’s a fun tool…but I also see the value in saving time, so if you’re going to do option 1, I’d still put a check on the validateWrite() unless you feel pretty good about your combobox limitation. I know when you create an item, the type typically defaults, and if you allow users to use MorphX, I wonder if a user could re-add the ItemType to another tab or something and change it there, or if a future developer VAR/ISV drops a new InventTable or something. Who knows, your call. Good luck!