Hi @RobMagruderLantronix 

It’s sometimes need to grant company/site access to IFSCONNECT since the integrations through IFS Connect runs as this user.

One use case for this explained below thread.

Change Initiated By user in Outbound Async Message | IFS Community

Instead of granting IFSCONNECT the access, we took the approach to impersonate user within our code.

However it’s not recommend to use IFSCONNECT as the user to authenticate IFS integrations since it’s a internal super user. You may create a new user and grant sufficient permission to invoke the integrations.

Cheers!

Damith

Dear DSJ,

Thank you for this information.  It was helpful.  I was aware that you don’t want to use IFSCONNECT to authenticate, we use service accounts for those integrations, but it was good to learn that it might be necessary for other processes.  Thank you again and I appreciate the quick response.

Sincerely,

Rob Magruder

Thanks @dsj for the response. That helped me as well.

However, I have a similar situation where you can help. I agreed to a concept of implementing an integration between IFS and our support ticket system to automate the user management (creation, grant and revoke permissions, company, site, user group manipulation, etc.). But, the user IFSCONNECT doesn’t have enough privileges to manage the users.

In this case, the solution is to grant IFSCONNECT with ADMINISTRATOR or individual roles (ugly, dirty and also is not recommended). If not, another approach is to make the inbound files to update an internal custom table, and execute a scheduled task (by appowner) to read values and execute separately (won’t be the perfect solution).

Do you have any suggestion for me?

Thank you.

Hi bro,

What about user impersonation, Is there any limitations you can’t use it?

Otherwise, I vote for creating a background job and execute as appowner since it could be useful for logging the information on what has happened during the execution as well, so you could promote it as an extended feature of the integration 

Cheers!

Damith

Oh, shoot me @DAALLK Damith..!! 

I did try impersonation and it ended up with the error You do not have privileges to use the "Fnd_Session_API.Impersonate_Fnd_User operation for "Foundation Session Public View. 

Like a dumb, I concluded the testing and looked out for alternatives.

What I actually did was add the impersonation into the PLSQL Developer’s IFSCONNECT session test window for testing. Shame on me..!! 

Long story short - impersonation works like a charm - you are correct..!

There’s no need for my other “fancy and silly” solutions