Is there any specific reason why you are not using IFSAPP to do your developments?

Commonly, irrespective of the instance being on premise or on the cloud, customers have access to IFSAPP in the development instance where all the developments are done.  Once the development is completed along with unit testing, the work can then be deployed to the Test instance for user acceptance testing, and finally the work will be deployed in the Production instance once it has been signed off.  The deployment of the work in other instances can be done without having access to IFSAPP.

All things you develop must be deployed by the application owner user (IFSAPP in most cases).

App. owner user owns all database objects.

I guess in your case you have now created a database package “PURCH_CHG_ORD_LINE_API” owned by the user you are logged in as. (The package owned by IFSAPP is untouched) If so, that package will not be used by IFS.

So you must login as app. owner user in Developer Studio.

For development the Appowner user should be used. In Test and Prod I think it is best practice to use another ID for appowner.

Thanks for your answers..

@Technical Outlaws  We about 10 people use IFSAPP for analysis and development. So when everyone use same user , it can be hard to find something from logs. That is why we don’t want to use IFSAPP.  

As my colleagues have mentioned above, purely from a development perspective, you should always use IFSAPP to develop.

Any analysis or investigative work, you don’t necessarily need to use IFSAPP, it depends on the nature of the work I suppose.

For any testing of development work, you should never use IFSAPP to test, it should always be an end user account instead.

We have a permission set IT_ONLY that has a few Oracle system privileges:

SELECT ANY TABLE

SELECT ANY DICTIONARY

ALTER SYSTEM

FLASHBACK ANY TABLE

Granting these along with granting every IFS object gives our whole IT team enough to do any kind of analysis that might be necessary.

For development, you may want to consider separating development from deployment. The onus for a clean and smooth deployment is still most definitely on the developer, but separating these also makes your work more visible and helps to ensure the versions are delineated. (We don’t do this because of the size of our team, for what it’s worth.)

If you have a session open in a tool like SQL Developer, you can make queries easier to write with shorthand:

ALTER SESSION SET current_schema = IFSAPP;

This doesn’t elevate privileges; it just changes which schema gets the lookups for unqualified object names.

We have seperated IT users for analysis or investigative works and created new permission set for system privileges.

We continue to use IFSAPP for developments. 

Thank you all 

Another method you can use is proxy authentication. This has the affect of setting up another password to the same account.

ALTER USER anotheruser IDENTIFIED BY ░░░░ ACCOUNT UNLOCK;
ALTER USER ifsapp GRANT CONNECT THROUGH anotheruser;

sqlplus anotherusertifsapp]/░░░░@tns_name
sqlplus anotheruserpifsapp]/░░░░@hostname:1521/service_name

By the way, your application owner is probably a Foundation user, and the IFSSYS user has proxy authentication access to every Foundation user account. This means your IFSSYS user can use proxy authentication to log in as your application owner, so you should treat that password with at least as much care as your application owner password.

sqlplus ifssys>ifsapp]/ifssys_password@...

Hello,

As i mentioned my previous replies, We have seperated our IT users and given them needed privileges.

Now i have noticed that the user cannot grant any schema.views to other users, but IFSAPP can do.

Example: grant select on IFSINFO.TEST_VIEW to X_USER

What privileges I must give IT users to able to do that  ?

Sincerely..

The database grant must include WITH GRANT OPTION.

GRANT SELECT ON ifsinfo.test_view TO x_user WITH GRANT OPTION;

Alternatively, if you really trust these users, you can allow them to grant everything.

GRANT GRANT ANY PRIVILEGE TO it_superusers;

As a word of caution, this gives as much power as the DBA permission set because it even allows the user to grant DBA to themselves.