Skip to Main Content
Feature Request FR-1988
Product Area Application Builder
Status ROADMAP

57 Voters

Allow page items to be submitted in shared components > list of values

koen.lostrie Internal
· Sep 22 2021

Idea Summary
Allow page items to be submitted in shared components > list of values or allow “extra values” display value to be derived from list of values.

Use Case
Use case is the following. Let's take the example of Product Teams in oracle as my LOV (shared components). 

  1. A record has a foreign key to the product team table.
  2. The product teams can be deactivated. (statuses are ACTIVE/INACTIVE)
  3. A user should not be able to select a deactivated team.
  4. If a record is linked to a deactivated team, then the should should NOT be forced to change it.

The logical option is to create a shared component with where clause ``STATUS = ‘ACTIVE’ ``` . 

  • If I set “Display Extra Value”  and user opens a form he'll see the id (which doesn't make any sense). I know I can make display value and return value the same but that goes against the concept of return/display values of the shared component.
  • If I uncheck “Display Extra Values” then the user is forced to select a new value, but he cannot see why because the value that is now no longer in the select list is not visible - he'll just see an empty value. Moreover, this user could be editing something else in that record and not know what new value to select.

There are 2 solutions that I currently know of:

The first solution is to not use a shared component but a query and do something like this:

select team_id ,team_name
  from pt_teams
where status = 'ACTIVE'
UNION
select team_id ,team_name
from pt_teams
where team_id = :P1_TEAM_ID

This works great, but I can no longer use a shared component since there is a dependency on a page item.

The 2nd solution is to use a shared component but make that dependent on all page items of the referenced pages. The query for the shared component would then be:

select team_id ,team_name
  from pt_teams
where status = 'ACTIVE'
UNION
select team_id ,team_name
from pt_teams
where team_id IN (:P1_TEAM_ID,:P2_TEAM_ID)

This works great too but is a little flaky because it needs to be updated whenever it is referenced on a new page. Also it could cause strange behaviour if the session state of the teams has a value for another page than the current.

Preferred Solution (Optional)
I see 2 possible solutions, both of which are not currently available in the product:

  1. It would be awesome if I could set the extra value as based on a list of values just like we can for items and report columns. In that case I could create 2 shared components: PRODUCT_TEAMS_ACTIVE (which would be the shared component for the select list) and PRODUCT_TEAMS_ALL (which would be the shared component for the extra values)
  2. If the List Of Values shared component would support page items to submit

Another cool related feature would be to allow display of disabled options (displayed but not selectable) just like in the JET select list

Comments

Comments

  • andreblu OP 3.8 years ago

    It's really a daily problem and in every project I have ever worked with.

  • ino.laurensse OP 3.7 years ago

    Requests for this go many, many years back. Especially from Forms developers moving to APEX. In Forms this was easy to do because there was a “page mode”. It was something like (Forms is now to long ago for me):

    where status = 'ACTIVE' or mode = 'ENTER_QUERY'
    

    In APEX, ENTER_QUERY can be replaced by ‘RENDER_PAGE’, or 'REGION_REFRESH", something like that.

  • roberto.capancioni OP 3.7 years ago

    with new SQL Macros you can create a function like this

    function get_lov(p_tab dbms_tf.table_t, p_id in number default null)
    return clob sql_macro is
    begin
    return q'{
    select cod D, id R
    from p_tab
    where active_yn='Y' or id = p_id
    order by 1
    }';
    end get_lov;

    and have a parameterized LOV like this

    select * from get_lov(my_tab,:P1_FK_ID);

  • jonathan.taylor OP 3.6 years ago

    Not tried it, but I think I solved this once by having an application item, e.g. AI_TEAM_ID.

    P1 would set AI_TEAM_ID to P1_TEAM_ID before page rendered.  LOV then indirectly refers to P1_TEAM_ID.

    Ditto for P2.

  • roberto.capancioni OP 4 months ago

    Is this idea still in the roadmap?

  • vincent morneau Admin OP 4 months ago

    Thanks of the nudge @roberto.capancioni and yes it's still on there.

  • roberto.capancioni OP 4 months ago

    ok, probably not with the highest priority 😁

  • roberto.capancioni OP 4 months ago

    I would like to point out an interesting use case where a parameter would be very useful: the display of inactive values

    select name as d,
    id as r  
    from table_name 
    where active = 'Y'    or id = to_number(p_id);
    
  • derik.tran OP 3 months ago

    It's been 2 years for roadmap.  Any updates?  We have to keep putting “(Inactive)” at the end of our reports because we can't remove the item which is very silly to our users.

  • vincent morneau Admin OP 3 months ago

    This feature is for convenience purposes so that you can pass parameters to an LOV. But you can have your LOV reference a page item or an application item today. I'm not sure what's blocking your requirement, can you explain this (Inactive) label and why you think this feature would solve it?

  • derik.tran OP 3 months ago

    This was my submission and was marked as CLOSED due to a duplicate on this item.  My use case is on that ticket.  My issue is NOT on the parameter but the actual output form or reports.  If it's not a duplicate, can someone re-open that and I would like to know how to address this.

      FR-3572

    https://apexapps.oracle.com/pls/apex/r/apex_pm/ideas/details?idea=FR-3572&session=110726646367272

  • govindasamy.chenniappan OP 3 months ago

    Hi Morneau, if the lov has been used in Interactive Grid, we need to pass other column's value as a parameter to the lov query. This is a limitation now I guess.

  • mark.w OP 3 months ago

    @vincent morneau I think referencing the page item is only half of  what is needed, because the user can (and will) change the item value in the browser. (At least that's a reason why I would reference page items in the LOV query, for example to make sure that two different values are chosen.) If the LOV query is only executed at render time (with the value the page item had at that time) this is not sufficient. In my interpretation this request is about something like a generalization of cascading LOVs. Many use cases can be served by cascading LOVs or dynamic actions to refresh the LOV. But I also found it sometimes difficult to make that work, particularly in Interactive Grids (one special problem in Interactive Grids is that sometimes you can refer to page item or colums, but at run time a page item is expected instead of a column).

  • vincent morneau Admin OP 3 months ago

    Thanks everybody for chiming in. We will discuss the current idea again, and FR-3572 was reopened for internal discussions.