Hi

I have the problem that we want to give a developer DevStudio to work on reports that one access one application the meta-data of which he must not alter.

To restrict the application we used applock - this did not work exactly as it said in the docs.

IBI Applock tech memo

Its settable in 2 files

ibi\srv71\wfs\bin\edaserve.cfg

applock = n

(global setting)

and
ibi\profiles\admin.cfg

admin_level = APP
BEGIN
applock = n
END
admin_level = OPR
BEGIN
applock = n
END
admin_level = USR
BEGIN
applock = y
END

Security level setting referred to in the memo.

metadata > application directories > configure path

At end of path list check boxes appear.

The way things seem to work is
applock = n - Application directories listed are those below application root + those in path

applock = y - Application directories are those in first path statement in EDASPROF with any others mentioned in the personal profile ibi\profile\username.prf being appended to the list regardless of whether it is app append, app preappend or app on its own.

The conclusion I reach from this is that effectively you will have to list the applications allowed in each user profile since EDASPROF cannot be overridden it can only be added to. This is inconvenient but I can achieve what I want by putting enough effort into it.

The read only bit is a bit harder since I can't seem to find any docs on this.

We are using windows authentication for our users. Initially I considered the possibility that the process that carried out the work on the server would inherit the rights of the webfocus authentication user. It would then be a simple matter of attaching an ACL to the directory preventing the user making updates.

However on investigation this proved not to be the case and logically thinking about this it would be impractical to implement wf in this way.

So I'm stuck - does anyone have any suggestions!

Best regards

John

Found this about &&APP_PERMIT but how does it apply to an individual application?


http://documentation.informationbuilders.com/masterinde...pdf_wf_52/tm4523.pdf

I'm guessing no one else has tried this by lack of replies so here's my advice.

The APP_LOCK and APP_PERMIT is half implemented and does not work properly for the reasons outlined above so dont waste your time playing with it!

We ended up with a compromise in that we ran a dedicated server for the developer with only the APP PATH directories the user is permitted to view or modify recorded in EDASPROF. (User profiles with dots in them - see my other topic - dont work so there is no other way!).

The metadata is protected by setting the read-only flag on the files in windows with attrib +r *.* in windows since we can reach the server. It's a pain that we will have to un read-only the files if we want to modify them.

I think this is a feature that will eventually properly be implemented once someone who really wants it raises a Hottrack and is prepared to work with support to get it working but currently I just don't have the time to do this!

Fundamentally to cure the problem 3 things need to be done.

1. The APP list needs to be modified so that each of the path entries has attributes

EXECUTE_ONLY | READ_ONLY | ALL

2. The APP_LOCK feature needs to pick up the final APP PATH setting after both EDASPROF and the user profile has run. (Not the arbitary way it works now of the first PATH statement in EDASPROF to which the user profile PATH statements are added even if they are not PATH APPEND or PREAPPEND!)

3. User profiles with a dot in the username need to be catered for somehow!

Regards

John

Interesting stuff. Seems like you're the only one frustrated by the half-baked new feature.

In my case, our production WF532 focexecs are on a UNIX server, and I thank I.B. profusely for a loophole in Dev Studio that allows me to update focexecs that are UNIX read only files. If I had to go through the rigmarole required by I.T. I'd never get anything done.