You need to fire this computation on post-authentication, within your authentication scheme.
Thanks, for answering.
I do see that there is a slot for "Post-Authentication Procedure Name" in the Authentication Scheme page. However, I am still unclear, specifically, how to invoke it (from there or anywhere else).
I have an application item named IS_USER_READ_ONLY. I then have an application computation defined for this item of type PL/SQL Function Body.
How, exactly, do I call it? I mean what would be the syntax to do so?
Often there will be syntax example by clicking on the attribute label.
Post-authentication is expecting a reference to a procedure, which can be defined inline within the authentication scheme, or exist within a package (or as a stand-alone procedure)
Right...I know how to invoke a Stored Procedure...or, for that matter, even an Application Process (as opposed to an Application Computation).
The question is, specifically, can a Computation be fired after login?
Until they put a 'post authentication' option in the 'fires on' attribute, Computations are not appropriate for this.
Put your calculation in a package and call that from post-authentication in your authentication scheme. Leave computations for page level calculations.
Yes, I had long ago gotten around the problem by using a packaged procedure. So, your work around, for sure, does work. This thread was posted, specifically, because I just wanted to know if it was *possible* to re-fire an Application Computation. I get, now, that the answer is a flat No.
To your comment about using computations only for page items. I have to, most respectfully, disagree with you on this one. There is a reason that these were provided at the application level. That reason being that one wouldn't need to recalculate a value every single time a page was loaded when one knew that the value wouldn't change. That is, APEX provides the means to calculate a value once and, thereafter, to be able to access that value on every page.
While a "Fire On" attribute would, of course, be the most flexible way to approach this; simply providing a post or pre authentication flag would go a very long way. For one thing, it's always struck me as a bit of a security "glitch" that the APEX_PUBLIC_USER connects to the database and run all sorts of queries before we've established anything about the user. Moreover, almost none of these queries (computations) are actually needed to load the Login screen itself.
It's not really a work around, it's how you set up item values based on the user logged in.
Put common code in a package, call it from multiple locations within APEX.
I didn't say computations were only for page items, I said "page level" computations. Calculate application/page items at some point during the render of each page. These computations can be set to calculate only for certain pages, events, requests etc.
Application computations allow these calculations to occur at this frequency.
If you only want something calculated once, you add a declarative condition that tests for null. But if it's only calculated once, when should it be calculated? If not required for login page, say where page not = 101, but I would again question the timing - should it be an application computation?
APEX_PUBLIC_USER is not really a glitch, it's a catalyst. Your parsing schema is the gateway to the database, so make sure that's as lean as it needs to be. Not all applications require login before anything happens.