OMW Check Out Security

Adrian TH

Active Member
Hi all,
We have outsourced developer working on this project.

I have some objects that I would NOT want them to touch in the Object Management Workbench (OMW).

Therefore, I'm trying to block these few particular users from checking out the object.

I have tried using OCM and set by Role but to no avail.
I have also tried using the Security Workbench but I do not see anything that I could use to set this.
I have also tried using OMC, but this application does not seem to be able to set it by object.

Do you all have any idea?

Here is an example:
User: ABC
Object: R55xx

Blocked ABC from checking out R55xx in OMW.

I am on E8.12, Oracle DB, SP8.96

Thanks in advance,
Adrian.
 
Adrian,

Are you over thinking this? Why don't you just document the objects that you don't want them to touch, and make that a condition of their contract? Furthermore, add in a control that they need to document all objects that they are working on and get your approval to work on those objects? In our shop, we pair up contracted developers with our regular developers. Our developers "supervise" the contractors and are responsible for their work. Our developers do all of the testing of the custom or modified objects. The contracted developers can work in the DV environment only, our developers do the promotion. This ensures accountability.

One other thought, make a copy of the key objects in your "save" environment. If you really want to lock things down, put on a database trigger on those objects so you know if they are touched.

Gregg
 
I agree with Greg that communicating to the contractor(s) is first.
If you still don't trust them - create a project that only you have access to and check out those objects to that project.
 
In Security Workbench - you could us Row Security and 'not' grant them
authority to objects you want to have honored.

OR

If you CNC policies and procedures are TIGHT - put the items you want
honored in 'your' project with the Tokens Taken. Once the tokens are taken,
no one else will be able to check them out (right???). It won't keep them
from looking at them, but it will keep them from updating them.

(db)



--
 
Adrian,

I think I remember a thread, possibly a few years ago, where a developer had cloned the security application to grant himself additional access. That thread may provide some helpful information. You'll have to search JDEList for it.
 
Hi all,
Thanks for the insight.

The reason for this TIGHT control is that we have multiple contract developers.

Report A is being done by Contract A. Subsequently, we would like some touch up by Contract B.
There was a time when we conveyed our message to Contract A that Report A has already been delivered by them and should not be touched anymore, and that Contract B was working on it, apparently Contract A was able to remove the token (Contract B did checked-out the object) and all the changes that Contract B did on the Report A could not be saved.
We would want to eliminate these kind of situation. Therefore, we would want to to deny access for user specific to not being able to check out these specific objects after they have been delivered.

Thanks.

Regards,
Adrian.
 
It's not really an answer to your question, just musing on the token issue: a token cannot be removed using OMW and a different account in a different project, although it can be removed if both users have enough authority (Allowed Actions + Activity Rules) within the same project, or by using another login - with such authority, or outside of OMW (i.e.: with some simple custom ER development).

Hence, the obvious conclusions are that 1) OMW configuration is not sufficient in all cases and 2) your developers have to be trusted - if you have development access, then there's no security that can stop you, even objects/data/security across environments can be manipulated through ER and 3) you will need some kind of auditing, preferably outside of JDE, so that it cannot be turned off or cleaned up by a developer + a review process to go through such audit logs to see who does what and then go from there.

That said, it's pretty paranoid, if you ask me ;-) I would really not expect any site in the world to have a really bullet-proof design for this, there are always holes, and this immediately brings us back to the question of trust...
 
Adrian,

You need to change your OMW policies such that 'Developers' cannot drop
tokens.

In the 'GLORIOUS' scheme of OMW - the Supervisor is to be All Powerfull.
If your site needs an ultra-control freakiness to moderate the activities of
your contractors - setup OMW in such a way that 'most' activities need to be
done by the manager.

Developers can:
- Move Objects into their own Project
- Move Objects out of their own project
- Check Out Objects
- Check In Objects
- Promote project to test

Manager has to:
- Create Project
- Add Developer/s to project
- Drop Tokens
- Demote Projects (control - so the boss knows there is a problem)

To fix your issue developers steeling tokens (which is comon) - don't allow
them to:
- Developers cannot drop tokens
- Developers cannot add themselves to other projects (06 is a no no )

This is just a short list of the control-freakiness-setup... as an example.
Some day I'll put together a full whitepaper on what a Developer should/not
be allowed to do in a truly untrustworth/SOX world.

ESPECIALLY in a contractor environment:
- Developers Develope what is assigned to them (by the manager)
- Manager Manages what the Developer is doing (Assigns via OMW)

Gophigure!

(db)




--
 
Hi all,
Thanks for the input. I think the easiest way is to trust the external developer in not to touch the objects.

DRBohner, I would take your advice for the future project.

Regards,
Adrian.
 
sounds pretty pour

Additional question to this:

As a newbie to JDE I only check out projects in state 21. Is there a way to stop a checkout in a higher state.
Is this somehow controlable?

(I know that the tools for JDE are very poor but who knows?)
 
It's not that the tools in JDE are poor, it's how you configure the software. If you don't want a checkout to occur past status 21 set those rules up in the P98230.
 
Back
Top