Function security lets you restrict application functionality to authorized users.
Application developers register functions when they develop forms. A System Administrator administers function security by creating responsibilities that include or exclude particular functions.
For additional information on using Oracle Application Object Library Function Security, see the Oracle Applications System Administrator's Guide - Security.
Group the forms and functionality of an application into logical menu structures that will appear in the Navigator
Assign a menu to one or more responsibilities
Assign one or more responsibilities to one or more users
Oracle Applications GUI-based architecture aggregates several related business functions into a single form
Not all users should have access to every business function in a form
Oracle Applications provides the ability to identify pieces of application logic as functions
Functions can be secured on a responsibility basis (that is, included or excluded from a responsibility)
A function is a part of an application's functionality that is registered under a unique name for the purpose of assigning it to, or excluding it from, a menu (and by extension, a responsibility).
There are several types of functions: form functions, subfunctions, and non-form functions. We often refer to a form function simply as a form.
A form function (form) invokes an Oracle Forms Developer form. Form functions have the unique property that you may navigate to them using the Navigator window.
A subfunction is a securable subset of a form's functionality: in other words, a function executed from within a form.
A developer can write a form to test the availability of a particular subfunction, and then take some action based on whether the subfunction is available in the current responsibility.
Subfunctions are frequently associated with buttons or other graphical elements on forms. For example, when a subfunction is enabled, the corresponding button is enabled.
However, a subfunction may be tested and executed at any time during a form's operation, and it need not have an explicit user interface impact. For example, if a subfunction corresponds to a form procedure not associated with a graphical element, its availability is not obvious to the form's user.
Some functions provide a way to include other types of code, such as HTML pages or Java Server Pages (JSPs) on a menu and responsibility. These functions are typically used as part of the Oracle Self-Service Web Applications. These functions include other information such as URLs that point to the appropriate files or functionality.
A menu is a hierarchical arrangement of functions and menus of functions that appears in the Navigator. Each responsibility has a menu assigned to it.
The Oracle Applications default menu appears as the pulldown menu across the top of a window and is not generally controlled using Function Security.
See: Pulldown Menus and the Toolbar.
A menu entry is a menu component that identifies a function or a menu of functions. In some cases, both a function and a menu of functions correspond to the same menu entry. For example, both a form and its menu of subfunctions can occupy the same menu entry.
A responsibility defines an application user's current privileges while working with Oracle Applications. When an application user signs on, they select a responsibility that grants certain privileges, specifically:
The functions that the user may access. Functions are determined by the menu assigned to the responsibility.
The concurrent programs, such as reports, that the user may run (request security group).
The application database accounts that forms, concurrent programs, and reports connect to (data group).
A form is a special class of function that differs from a subfunction in two ways:
Forms appear in the Navigator window and can be navigated to. Subfunctions do not appear in the Navigator window and cannot be navigated to.
Forms can exist on their own. Subfunctions can only be called by logic embodied within a form; they cannot exist on their own.
A form as a whole, including all of its program logic, is always designated as a function. Subsets of a form's program logic can optionally be designated as subfunctions if there is a need to secure those subsets.
For example, suppose that a form contains three windows. The entire form is designated as a function that can be secured (included or excluded from a responsibility.) Each of the form's three windows can be also be designated as functions (subfunctions), which means they can be individually secured. Thus, while different responsibilities may include this form, certain of the form's windows may not be accessible from each of those responsibilities, depending on how function security rules are applied.
Developers can require parts of their Oracle Forms code to look up a unique function name, and then take some action based on whether the function is available in the current responsibility.
Developers register functions. They can also register parameters that pass values to a function. For example, a form may support data entry only when a function parameter is passed to it.
Register your functions and subfunctions on the Form Functions window.
Typically, developers define a menu including all the functions available in an application (that is, all the forms and their securable subfunctions). For some applications, developers may define additional menus that restrict the application's functionality by omitting specific forms and subfunctions.
When developers define menus of functions, they typically group the subfunctions of a form on a subfunction menu they associate with the form.
When you create a menu, you typically include each form, each subfunction, and each submenu on a separate line of the menu. Generally, each form and each submenu should have a prompt so it will show up as a separate item in the Navigator window.
Attention: Usually you should not include a prompt for subfunctions, as you usually do not want them to be visible to the user on the Navigator. This also applies for form functions that you may open using the CUSTOM library and Zoom, but that you do not want the user to navigate to explicitly (that is, you should include the form function on the menu so it will be available to the responsibility, but you should not give it a prompt).
See: Coding Zoom.
Each Oracle Applications product is delivered with one or more predefined menu hierarchies. System Administrators can assign a predefined menu hierarchy to a responsibility. To tailor a responsibility, System Administrators exclude functions or menus of functions from that responsibility using exclusion rules.
When a menu is excluded, all of its menu entries, that is, all the functions and menus of functions that it selects, are excluded.
When you exclude a function from a responsibility, all occurrences of that function throughout the responsibility's menu structure are excluded.
When a user first selects or changes their responsibility, a list of functions obtained from the responsibility's menu structure is cached in memory.
Functions a system administrator has excluded from the current responsibility are marked as unavailable.
Form functions in the function hierarchy (that is, the menu hierarchy) are displayed in the Navigator window. Available subfunctions are accessed by working with the application's forms.
To call a form from the Navigator window menu, you define a form function that consists of your form with any arguments you need to pass. You then define a menu that calls your form function.
You should use FND_FUNCTION.EXECUTE instead of OPEN_FORM whenever you need to open a form programatically. Using FND_FUNCTION.EXECUTE allows you to open forms without bypassing Oracle Applications security, and takes care of finding the correct directory path for the form. If you need to open a form programmatically and then restart the same instance of the form (for example, with different parameters), use APP_NAVIGATE.EXECUTE instead of FND_FUNCTION.EXECUTE.
When you define a form function in the Form Functions window or call an existing form function using FND_FUNCTION.EXECUTE or APP_NAVIGATE.EXECUTE, you can add the string:
QUERY_ONLY=YES
to the string in the Parameters field or in the arguments string (using the other_params argument). This argument causes the form to be called in query-only mode. The FND_FUNCTION.EXECUTE procedure (which is also used by the Oracle Application Object Library Navigator) sets the QUERY_ONLY flag that sets all database blocks to non-insertable, non-updatable, and non-deletable.
To dynamically determine when to call a form in query-only mode, add the string to the other_params argument of the call to FND_FUNCTION.EXECUTE.
Disable or remove all functionality that does not apply when the form is run in Query-Only mode, such as 'New' buttons in Find Windows. Entries on the menu (other than Special) are handled automatically. Turn off any logic that defaults values into new records when the form is in Query-Only mode (this logic is usually called from the WHEN-CREATE-RECORD triggers). Check for this mode by checking the parameter query_only:
IF name_in('parameter.query_only') != 'YES' THEN
<defaulting logic here> END IF;
Attention: Use query-only forms only when the user does not have update privileges on the form; not when the primary purpose of the form is viewing values.
Do not limit a form to query only because the primary need is viewing values. If the user has update privileges on a form, you should not create a separate query-only form function, even when calling the form from a special menu for the purpose of querying information. Forcing users to use the Navigator to reopen a form in an updatable mode if they need to make a change is a clear violation of our user interface standards.
There may be rare cases where technical limitations force you to limit the user to query mode on particular calls to a form. In general, however, update privileges should remain constant within a responsibility, regardless of how the user accesses the form (from a branch of the Navigator menu, or from a special menu in another form).
Some forms (such as the Submit Requests form) accept arguments that change the form window name. With the Submit Requests form, you use the parameter TITLE to specify the name of a message in the Message Dictionary. That message becomes the window title.
The syntax to use is:
TITLE="<appl_short_name>:<message_name>"
If the message REP_ROUTING contained (in English) the text "Report Routing", you use the argument
TITLE="MFG:REP_ROUTING"
to open the Submit Request window with the title Report Routing.
See the Oracle Applications System Administrator's Guide for more information on customizing the Submit Requests form.
When a user selects the help button in Oracle Applications, the applications try to open the correct help file at a help target consisting of the form name and the window name: form_name_window_name. You can override the form name portion (and optionally the application short name of the help file) of this target by passing the parameter
HELP_TARGET="Application_short_name/Alternate_Form_name"
For example, to use Oracle Receivables help for the Submit Requests form, you could define your form function for the FNDRSRUN form name with the following parameter:
HELP_TARGET="AR/FNDRSRUN"
You can pass the HELP_TARGET parameter either when calling the form function using FND_FUNCTION.EXECUTE or APP_NAVIGATE.EXECUTE (using the other_params argument) or when you define the function in the Form Functions window.
See the Oracle Applications System Administrator's Guide for more information on help targets in Oracle Applications.