Issues while submitting the wrokflow form

[shajipappan]

Hi Guys,

When i am trying to submit a workflow as a normal user i am getting a message saying that "User not authorized for action on this entity".
But if i submit the workflow as the manager of the recipient, then i will be able to submit successfully.
I have given access for all users to this workflow in the trustee DN. I also checked whether there is any script which checks if the initiator user is the manager of the recipient at the time of submit action. But there isn't any.
Does anyone know why i am getting this?

[Reddy Siva Saran]

Dear shajipappan,

Requesting for a PRD which donot have initiate rights would result such message

Make sure the PRD has enough rights before making a request to it.

The below doc link might help you to provide the required rights for the PRD to solve the issue

https://www.netiq.com/documentation/identity-manager-46/identity_apps_admin/data/t4299dzufz8x.html

Thanks & Regards,
SivaSaran.K.R

[geoffc]

On 4/27/2018 6:24 AM, sivasaran wrote:
>
> Dear shajipappan,
>
> Requesting for a PRD which donot have initiate rights would result such
> message
>
> Make sure the PRD has enough rights before making a request to it.
>
> The below doc link might help you to provide the required rights for the
> PRD to solve the issue
>
> https://www.netiq.com/documentation/identity-manager-46/identity_apps_admin/data/t4299dzufz8x.html

To elaborate on what Siva is saying, and the docs do not really explain
in this link...

There are a series of attributes in eDir that control permission access
to User App functions. (The IDM engine uses a similar model for
starting/stopping drivers).

You can read more about this in my article from a few weeks ago.

https://www.netiq.com/communities/cool-solutions/different-permissions-user-application/

Basically these attributes, nrfAssignTaskAddressee that Siva references,
do not exist on users. Instead, UA does a getEffectiveWrites() style
call to see if you (logged in user) COULD write to this attribute if you
wanted to, but never does write. Odd, right? Odder is that normal eDir
permissions (Browse and Compare to the eDir objects of the PRD to SEE
the PRD) are used one way, then this model to actually use the PRD. It
is more flexible this way, and allows arbitrary permissions to be added,
by just implementing its enforcement against this model.