LSDUMP from one profile to another

Any time a security class is loaded, it will overwrite the role association. That's just the way it works. These all need to be reestablished by hand. Also, do not dump the entire profile and use it on a productline named differently than the source one as some of the metadata will point at the original productline name. Particularly disasterous if your security is looking at an _employee service that doesn't exist. Dump all of the source profiles security classes and then load them to a newly created profile.

So, If I am using LSDUMP/LSLOAD to promote changes from development to production, I would have to reassociate all the security classes with the roles? That seems like a lot of unnecessary work.

What is common practice moving security changes from development to production?

What about lsdump ROLE? Will this associate the the security classes with the roles as they load?

The common practice is to reassociate and, yes, it does seem like alot of unnecessary work. If you use lsdump ROLE, the association will remain intact until another role uses the same class and the other associations are overwritten. i.e. Role A uses SecClasses A,B,C and Role B uses SecClasses A,B If Role A is loaded and then Role B, the net result will be Role A associated to only SecClass C and Role B associated to SecClass A,B Unfortunately, the most painless way to perform the copy is to copy security classes and then reassociate to the roles unless doing a one off type of copy.

What do you mean by a one off type of copy??

Sorry, I meant if you were going to copy only one reworked or new security class from test to prod for instance.