Dear all,

We have external developers on site and we have to give them some sort of standard guidelines on What they can do and what not to do sort of guidelines.

Please if anyone got one so we can modify and fill in for our purpose.

Any help really appreciated.

thanks,
Eric Thomas

If it's specificaly related to code, then this should be moved into the Tools Dev. forum.

If it's related to the developper authorizations, then it's the right one but all depends of what do you want them to do and where are they allowed to changes. I don't think there is such a guide (a developper should know what he can or cannot do related to Baan).

I would start by checking the developpers authorizations. Restrict the maximum possible (eg., do not allow changes for the U_stnd layer, only give access to the right modules, etc.) to avoid problems and then document it - the result of a print developper authorizations is almost all they need anyway.

If they also know about Tools and know how Baan is structured, they can also do "damages" at OS level, so carefull with that access to the shell.

victor_cleto-Thanks for the reply.

We want to tell developers what they should not do in UNIX and Oracle. In baan we cannot restrict much as no audit in place to verify. But OS and DB access through shell out is the concern.

So we thought at least in writing we give them what they are not supposed to do.

Also should we let access to Unix at all ?

thanks
Eric Thomas

I shouldn't be very concerned about Oracle, they will not connect directly to it, only thru Baan. Make sure that sqlplus and svrmgrl is not executable by the bsp group and they can't connect to it.

Regarding UNIX, you can restrict their access to the shell if needed. The thread http://www.baanboard.com/baanboard/showthread.php?s=&threadid=1948&perpage=5&display=&pagenumber=1 is discussing this matter.

To be honest I feel kind of lost if I am not able to check on OS level e.g. the latest modification date/time of a report.

Basicly it't not really necessary but it can be usefull.

On the other hand as admin I don't like my developers leaving all kind of files all over my filesystems. If developing environment and live environment are on the same server I would try to make sure that the developers can access the live env. and 'solve' problems in their programs.

Regards,
Han