Can you uncheck queryable checkbox for this attribute from the view object attributes section. After doing this , it won't be displayed on the query pannel.
the Query Panel is based on a VO like this:
select FieldA, FieldB, FieldC from Table where FieldD = :paramForFieldD
The Query Panel created by JDeveloper shows me the fields FieldA, FieldB, FieldC and FieldD.
Instead I would like to have only FieldA, FieldB, FieldC and the possibility to pass the value (the query parm) for FieldD programmatically.
The user do not have to choose the value for :paramForFieldD by the Query Panel.
Yeah, so hiding of that field will be done if you uncheck queryable from that attribute in VO.
For this you have to intercept the query execution and add your parameter. You can't use the 'All queriable attributes' view cirteria for this as this vc is build implicit and you cant change it. However, you can build your own vc and mimic the 'All queriable attributes' vc. In the VO create a new vc and all all attributes from the query to it. The one that you don't want to see you can hide (as rohanwalia post).
Then you have to use the technique shown in this blog https://blogs.oracle.com/aramamoo/entry/interpret_af_query_s_queryevent but instead of showing the popup you set the parameter from the bean to the viewcriteria row of your hidden parameter.
the technique you suggested me is useful but a bit cumbersome.
The problem is that all the view objects that I use to create "Query panels with table" have in their sql query the same condition with the same param.
So I would implement the technique for each "Query panel with table"... :-/
The value of the param used by the query of each view object is the same for all the query and I know it (the UserId).
Each "Query panel w/t" must work only on the records of the VO "where UserId = :UserId" but I know the value of the param only after the user logged in.
Is there a way, after the user is logged in, to add to the queries of my view objects the where clause condition, for example, "where UserId = 'James'"?
In this way the UserId param disappear in all the queries and the "Query panels w/t" will not ask me that param.
What kind of security do you use?
If you use ADF security you can add the where clause directly to the vo and use a groovy expression to get to the userId. No need to do anything else in this case as everything is in the security realm.
If you don't use adf security you can pass the userId to the application module and can reference it using groovy from there.
I'm not using ADF Security. Unfortunately I do not know how to use it. Does it imply to handle the users of an application using pre-defined Oracle tables?
I'm new to JDeveloper and I have to build a web application that uses already created SQL Server tables for handling (login, register, ...) users.
I would prefer using the second choice: "pass the userId to the application module and reference it using groovy from there".
I put my do_login function that queries the handle the login in the Application Module so it will be easy to store the UserId in a variable of the AM so that I can read its value everywhere in my application.
Is it sure to store infos in the AM? Or would it better to use a session scope bean? I don't know what vars I can reach by Groovy. Would be also good to reach flowScope variables?
Thanks again for your kind support,
1 person found this helpful
Federico, to catch up with ADF security you should read and work through Oracle ADF: Security for Everyone
ADF security is a wrapper which uses the security configured on the server. Yoo should be able to create your own security provider based on your tables, however this is not easy to do. If you want to go this way I can provide some more links on how to implement this.
If you want to pass the userid to the application module you can store this data but need to make sure that the data is stored (passivated) and reload (activated) when the application module is activated/passivated. For this you can refer JDev: Always Test Your App with ApplicationModule Pooling turned off | JDev &amp; ADF Goodies
Accessing values from managed beans from the application module is a bad practice. Managed bean data should only be accessed in the view layer.