As an addendum, I tested with a user whose group has fullaccess to the form, it successfully blocked the user since they weren't the manager or engineer
(ok, there's also an ELSE in my code that does the this.ccontainer1.setaccessreadonly()), but when I made the user the manager it worked properly and gave access back. So a user whose group has readonly access still has readonly even though I've tried to specify otherwise and a user whose group has full access only has it if they are the manager/engineer in this scenario. And just to clarify, lsecurityenabled=.t. and lspecifyaccess=.t.

I changed lspecifyaccess to .f. to see what would happen, the readonly user is still readonly and now the fullaccess user has fullaccess to everything no matter if they are not the manager/engineer

So clearly the group is playing a significant role in this. Any suggestions?

thanks!

>Ok, I'm working with Tony and trying to implement this suggestion. However, I've taken an approach that isn't working properly. Probably due to having the order of operations confused.
>I have a new form (projectform) that's a subclass of cbizobjmaintenanceform. On the second page, I dropped an instance of ccontainer onto it and put ctextboxl controls inside it. Works great. I have users in groups and have security turned on. The container is the secured object. Now, here's where I think I'm getting into trouble. My test user belongs to a group whose access to the container is readonly, since this is the default desired behavior. To get around that for the few projects the person should have access to, in the activate of the page I've put the following:
>
>if goapp.osecuritymgr.iusrgroupid=v_projects.imanager_id or ;
> goapp.osecuritymgr.iusrgroupid=v_projects.iengineer_id
> this.ccontainer1.setaccessfull()
>endif
>
>in an attempt to override the security model. The code executes, but it doen't make the textboxes accessible. I'm guessing it's because something else is being triggered that is resetting the default security. I've tried tracing thru the code of the form, but it's very hard to follow in the debug window and the event tracker was somewhat worse.
>
>I really dislike putting code in the activate method, but I'm not sure where else to put it that will guarantee its' execution.
>
>Any advice or suggestions on what/where to look at settings would be deeply appreciated.
>
>tia!
>
>laurisa