How do I restrict a developer from creating versions in PD?

To get modifications into production immediately, my developers will create a new version, make the mods to the version, then check in the version into production. They can circumvent the package build process this way. If a user has a problem running a version, my first response is "let's test it in the DV / PY / TS environment to see if it works there". Problem is, the version doesn't exist in any of the environments because it was created directly in PD. How do I prevent my developers from creating versions directly in PD? Thanks,

Hi,

My advice would to be go on a "per environment" security.
Three different F00950 tables : one for PD, one for PY,
one for DV.
Then you can close their access to some of the
BV functionalities on the PD environment without affecting
their DV/PY work.

I'm probably being dense here, but how are they getting something checked into production? OMW activity rules should have them in their default project, even if they create a version while in PD on a Windows based client, when they do a check-in, it should be set up via OMW to actually check into DV.

So unless they have access to OMW to create a project and advance it, I'd assume that they are really checking it into DV.

Multiple security tables would be one solution...however, the bigger question/issue, is why do developers have access to PD? Especially if you need to be SOX compliant, this is a big no-no. While I realize sometimes that a developer needs to "see" something in PD, they certainly shouldn't have access to create or change. So my thinking would be to create a "view only" user ID for each developer for PD access. That way they can get in and see, but can't create/change. This would eliminate the need for multiple security tables. I'd think it's a heck of a lot easier to manage the additional user profile than to have to manage multiple security areas.

When a new version is created in Production and checked into Production, it is also checked into Development. Your problem seems to be an issue of notification that a new version has been created and needs to be promoted to other enviornments, not that it was created in Production.

Sometimes people forget what business they are in. Most, like us, are not in the information systems business. If my construction manager needs a new version to get a job done, I will do it in Production and worry about promoting it to other environments later. After all, his work for our customer is what pays the bills...and my salary too.

My 2¢.

Fred

The easiest way to prevent this is to update your OMW rules so they can't check in versions in PD

jstooge,
This is not necessarily the case. If a developer signs into production,creates a version and checks it in. As long as the OMW is set at a 21 it will check into both production and development. Versions are very tricky when it comes to OMW rules.

This is a very tough question, but I have to ask why your developers need access to production. Sarbanes Oxley 404 sees this as a segregation of duties and no developer is allowed into production without some type of approval process.

Anyways, off my soapbox. If a developer has access to production, you probably will not be able to secure them down so they can not create version in production. I would also assume your users create versions also.

This is something that should be handled through change control procedures through the company IT policies and procedures.

I am currently on Xe and in order to prevent this from happening I gave our developers a seperate PROD ID that is tied to an inquiry group that basically only has access to view data. OMW for them is secured and batch version copy and checkin and out is secured.

If your developers need to access PROD from a SOX angle they should only have inquiry access no update functionality, for us this was the easiest way to do it. Their PROD ID only has PD env and nothing else.

"To get modifications into production immediately"

Seriously, this is your first clue that it might be a bad idea.

Theres a few rules that you must set, right away, no qualms about it with development.

1) Developers never get access to production objects or data.
2) Developers never promote objects. Only CNC administrators do that. You can set that up via the OMW rules as the previous posters suggest.
3) Consider developers the most dangerous kinds of users.. lock them down as much as you can. I've seen developers muck with OCM, everything. Nuts.

When I came into my new job, everyone could go wild creating versions, run jobs locally, everything. That all changed in less than two weeks. I would suggest you do the same.

Did I mention they didn't have even menu security and everyone had access to fastpath?

- Morglum

Morglum,

What do you do if your CNC, development and support staff are the same four people?

Developers should not have access to the CNC tools. That is a given.

LIKEWISE - the CNC(s) should not have access to the Developer Tools. When the paths cross - (ESUs?) - the CNC should refer Developer aspects to the Developer and Setup to the Functional folks...

(db)

"what do you do if your CNC and Developer Staff are the same people/persons"

Make darn sure you are not a publicly held company - if you are, you are out of SOX compliance and ignore most 'rules' for administrative devide of duties.

If you are not public - your organization is still ignoring the segregation of duties... those issues will bite when a 'real' audit takes place.

YMMV

(db)

An easier way to have different security in PD and DV is to use roles. This is only if you are on 8.9 or higher though. You could create roles called DEV_PD and DEV_DV for example. And each role would only apply to PD and DV respectively. Then you just apply the proper security to each, and assign both roles to your developers. No multiple user profiles and no multiple security tables.

And I agree with an earlier post that said to set up action security to take away (in production for sure) the ability to Add, Copy, and Delete on the batch versions application; and to set up exit bar security to take away the check-in and check-out buttons in batch versions. That will force all users to use OMW to create batch versions, giving you control of what they can do and where.

Don't forgot to set up proper security in OMW so that developers can't advance the project status too.

Andrew

I found an undocumented solution!
Let's recap. My problem is that users are checking the new versions into PD, then because the versions are new, they can submit UBE using the Specs Only feature which causes the new specs to get pushed up to the application server, a short cut to the package build process. That version is then LIVE in production without having to go through any change management methodologies, and your CNC guys will be none the wiser.

But listen up. JDE.INI has a line in it that specifies what queue to use if a UBE was submitted with Specs Only.
SpecInstallQueues=1
SpcQueue1=QB7334

If you put a bad queue name in this parm, developers will never be able to get new version specs up to the apps server UNLESS there is a package build for that version. The UBE (type 001 for Submit Specs Only) goes into a constant Wait mode, never Processing because it can't find the queue.

So far, no rammifications and works like a charm. My developers aren't happy, but this reduces the risk of any untested logic going live and possibly messing up the data.

Enjoy!