Hi,

If you read the message, what's your understanding of it?

Hi VsoMDjexP,

Can you try the following:

Go to person window search for * as PersonID. If userId has your login user remove this and add it to a different user.

Regards,

Sahan

I have same problem - deleting or changing person ID attached to the login is not a option, because I want to add document as IFSAPP and it has to have person id as *.

Is there any other idea, why person * attached to IFSAPP is not allowed to create new docs? 

Hi @LKROL,

Let me ask the question from other side, why IFSAPP should create documents.

The only valid answer could be that the environment is a test or dev environment. Otherwise for majorly for security reasons it is highly advised that IFSAPP account should be kept locked unless needed for deployments.

For environments other than production, the best workaround is assigning another person to IFSAPP for testing.

But this is not a test this is a production version - for example user have no privileges to archive_tab - where all blobs are archived - I would like as ifsapp, take out those blobs from the database and attached them to LUs to particular records. Idea is to use custom events: when new record appears on archive_tab, take out the blob, export it as pdf to repository and then finaly attached it still as an IFSAPP to the LU.

Have to investigate your scenarios details deeply to suggest an appropriate solution but the first thing I would thought in such a scenario is using “report rules”  there is an action type “Check In To Document Management” maybe it can solve your problem,  

Other option, use views instead of tables with another user who has granted with “ADMINISTRATOR” system privilege.

Another option is more advanced solution, use a procedure ( I do not know if any exist out of box) to get the pdf data .

In all 3 scenarios creation of the docman record will be done with the user who ordered the original report.