Hi @batz18,

In our reference environments, ERROR_SYS and CLIENT_SYS seem to be granted to FND_RUNTIME role by default. Therefore, could you check whether FND_RUNTIME role has these objects granted in your environment? You can try exporting the role from an environment that is functioning properly and import it to this environment. 

Alternatively, in IFSAPP9 and earlier, you can use following PL/SQL block to reset Foundation1 permission sets to their correct state:

BEGIN
   Installation_Sys.Post_Installation_Object;
   Installation_Sys.Post_Installation_Data;  
END;

You need to execute this block as Application Owner. 

Hope this helps!

Dear Charith,

thanks for your suggestion. The PL/SQL block didn’t change the situation.

ERROR_SYS and CLIENT_SYS was not granted to FND_RUNTIME, but to FND_ENDUSER. I granted also to FND_RUNTIME (and even directly to the user itself), this did not help.

We have 2 environments, and none of them is working properly against ERROR_SYS and CLIENT_SYS. I don’t know what happened (both worked a few weeks ago).

Thanks & regards

Batz

Ah an RMB.  The anonymous block runs as the user and the user would then need to be granted the access directly (this is how oracle security works) because and RMB just issues the block without any controls on it.  What we had to do to get around the problem of having to grant execute directly to every user was to create a package.  In this package we create a procedure that runs the plsql that we want executed.  Then we grant execute on the procedure to the roles that need to run RMB functions.

What follows is an example.  Once you create the package and the spec method perform an dictionary refresh.  This will put the package and the method into the IFS security listing.  You can now grant what you want to the roles instead of giving everyone access.

CREATE OR REPLACE PACKAGE Val_Rmb_Passthrough_Api IS

    Module_  CONSTANT VARCHAR2(25) := 'ENTERP'; -- Do not touch, leave this where it is at!

    Lu_Name_ CONSTANT VARCHAR2(25) := 'ValRmbPassthrough'; -- Give it a name for the IFS security scan, leave this where it is at!

    

    ...

    -- This propogates the customer changes down to all sites.

    PROCEDURE Propagate_Cust(Customerid IN VARCHAR2, Company IN VARCHAR2);

    ...

END Val_Rmb_Passthrough_Api;

CREATE OR REPLACE PACKAGE BODY Val_Rmb_Passthrough_Api IS

    PROCEDURE Propagate_Cust(Customerid IN VARCHAR2, Company IN VARCHAR2) IS

    BEGIN

        Valbatch.Propagate_Cust(Customerid, Company);

    EXCEPTION

        WHEN OTHERS THEN

            Ifsapp.Error_Sys.Record_General(Lu_Name_  => Lu_Name_,

                                            Err_Text_ => SQLERRM || ' CustomerID: :P1, Company: :P2',

                                            P1_       => Customerid,

                                            P2_       => Company,

                                            P3_       => NULL);

    END Propagate_Cust;

    ...

End Val_Rmb_Passthrough_Api;

If my first reply does not work then I am going to suggest the same thing as Charith.  You need to export the roles from a known working instance and import them into the ones that are not working.

Hi @batz18 

Did You try to refresh Security Cache: Security_SYS.Refresh_Active_List__(1)?

Please check also that You have no db objects with name longer than 30 characters. It could also make problems with refreshing any kind of cache:

select * from all_objects
where object_name not like '%SVC'
and object_name not like '%VRT%'
and object_name not like 'AQ$%'
and owner = 'IFSAPP'
and length(object_name) > 30

Thank you @mwilson for your interesting suggestion, I keep your package proposal as a workaround to unblock the situation when needed. But in parallel, I am also checking how to restore the original situation and fix the issue, since it occured some weeks ago without any apparent reason.

From what I know, we have no working instance (to be confirmed, I will double check if there is no “old” unused environment left), so no role export applicable.

Dear @knepiosko I already refreshed the security cache before, it did not change anything. Your request returns Zero lines, thus there seems to be no issue on objects  names.

And you checked this to see that it is correctly indicated for the role?

What is the result of this query?

SELECT *

  FROM security_sys_tab

 WHERE ROLE = 'FND_RUNTIME'

   AND PACKAGE_NAME = 'CLIENT_SYS'

What version of IFS are you on?

What is the result of this query?

SELECT *

  FROM dba_tab_privs

 WHERE grantee = 'IFSSYS'

   AND TABLE_NAME = 'CLIENT_SYS'