What you might want to do is create a SECA that is triggered on
PartyRole update. If the change isn't allowed, then return an error or
failure.
-Adrian
ARays wrote:
Thanks Adrian. I figured it would be easier to stick to using 'Role' than
PartyType to limit the number of changes and be reasonably close to the
trunk codebase. I would have liked a way to fix a role that can't be changed
or dropped (essentially achieving the same effect as my original intent of
picking a partyType) and my next steps would be to try and fix that sort of
thing.
- Arays
Adrian Crum wrote:
Employee is a party role, not a party type.
It would be less work for you to use the existing functionality.
-Adrian
ARays wrote:
Hi,
I am following the createEmployee flow of partymgr and trying to
establish
where the partyTypeId is set to 'PERSON'. I am looking to change that to
a
sub type called 'EMPLOYEE' that I have created. I could figure out how
alternative flow for 'PARTY_GROUP' is set , but unclear on how 'PERSON'
is
set. Would really appreciate pointers.
- Arays
