How to secure a specific field

Epicor ERP 10
1

Note: this is in our test environment, so affecting only new people trying to train…

This is a backwards question and may not be answerable, but thought I would give it a shot. Security of some kind has been implemented on most fields in Part Maintenance but for the life of me, I cannot figure out how it was implemented…

This is what happens:

The user can get to Part Maintenance.
The user can select New Part from the File menu
The user can enter the new part number, but after tabbing out of that field, almost every other field on the screen is greyed out, including all those that are required to save the part.

If I make the user a security manager, this problem goes away.

I have looked at the following:

  • Field Security on PartDescription: Default access = Full and the user access = default.

  • Service Security on bo.Part: did not see anything at all.

  • Method Directives: no method directives related to Part business object (some related to other things).

  • Data Directives: no data directives associated with the Part table.

What else should I check?

Thanks.

—sam

2

Any customizations on the form?

One more thing … you say the other fields are grayed out. Are they actually disabled? I made a theme for our test environment, that had a side affect of making regular fields look disabled.

3

Hi Calvin

Yes, the fields are actually disabled.

No customizations (was really hoping there were…).

Thanks.

—sam

4

Have you run a trace?

Do it for a user experiencing the problem, and then for a user who is Security Mngr, and compare them.

5

I am not the greatest at interpreting trace logs. Just ran the two. Is there anything specific I am looking for? Just started comparing the two and have two immediate differences:

In the SecManager log, this line has bpm = 1, but in the User log, bpm = 0:

Sec Mgr: executionTime total=“108” roundTrip=“69” channel="0 bpm=“1” other=“38” />
User: executionTime total=“52” roundTrip=“50” channel=“0” bpm=“0” other=“2” />

The second thing is that in the User log, the UserID is captured as a parameter; there no such line in teh SecMgr log:

parameter name=“UserID” type=“System.String”>![CDATA[NameChanged]]>

(I had to remove the leading carats so that the lines would show up)

So I am guessing it’s something to do with the UserID, but not sure where to go next.

Will keep going through for other differences.

6

More…

So for both UserIDs, I started the log with Part Maintenance open. I then selected New Part from the New icon drop-down. Here’s the weird thing:

In the SecMgr log, the first method called is GetNewPart
In the User log, the first method called is GetNewOrGetByID

So… is there something maybe upstream from Part Maintenance?

Will continue looking.

7

The bpm=1 and bpm=0 are just how long (in milliseconds) bpm processing took. That “1” is the same as zero - so no BPM processed during that particular method.

That difference in the first method called could be dependent on the previous state of the form. The exact steps I would do:

  1. Close any open Part Maintenance windows.
  2. Close the System Monitor (right click the icon in the systray, and close or exit). This is to reduce the number of entries in the log.
  3. Launch Part Maintenance
  4. Enable logging, and clear log.
  5. Back in Part Maintenance, type in an unused p/n and hit tab
  6. Turn off logging, and view log.

Repeat with the other user logged in.

After the second test, launch the system monitor (or just close and re-open the client program)

8

OK, I have done this (or at least I am pretty sure I have). Based on throwing both logs into Word and doing a document compare, the first difference (other than the expected differences for part number, userID and time fields) is just after Ice. Proxy.Lib.BOReaderImpl:

SecMgr:

<tracePacket>
  <businessObject>Ice.Proxy.Lib.BOReaderImpl</businessObject>
  <methodName>GetCodeDescList</methodName>

And the User

<tracePacket>
  <businessObject>Ice.Proxy.Lib.BOReaderImpl</businessObject>
  <methodName>GetList</methodName>

Not sure if this is significant. Will keep reading.