Hi, I ran into this once and found the only way around it was to construct parallel logic to the measures in the body of the report and make sure the elements filtered on where in the presentation, but hidden. This solved my problem, where the measures pinned to dimension hierarchy tiers were consistently wrong even when I…

You might find this a useful reference; - Functions : Current_Date Current_Time Current_TimeStamp Day_Of_Quarter DayName DayOfMonth DayOfWeek DayOfYear Hour Minute Month Month_Of_Quarter MonthName Now Quarter_Of_Year Second TimestampAdd TimestampDiff Week_Of_Quarter Week_Of_Year Year Current_Date Returns the current date.…

Time series periodrolling by any chance?? If so, not missing anything obvious no, see => https://support.oracle.com/epmos/faces/DocumentDisplay?_afrLoop=532664018887607&id=2150459.1&_afrWindowMode=0&_adf.ctrl-state=1dmoua7uvi_4

You could create an opaque view on the physical layer and then use this to model in your business model layer very rapidly, but DDR should be temporary measures, not permanent solutions - and opaque views are not much improvement before anyone else says it...

Tangible - you mean we can take them to the bank?

I always feel 'bad' about saying it, but it really is for the benefit of all who use the board if we use the mechanisms to recognise the right answers - I don't much care about the points for me, I do care about the community and the usefulness that this forum brings for the benefit of all if people keep using it correctly.

So for the benefit of other users click on 'assumed answered' as a minimum, or if you want to recognise someone's efforts then mark 'Correct' and / or 'Helpful' as appropriate - this is good board etiquette generally. If you intend to be a regular board user it is also worth at least giving yourself a meaningful display…

Your other option is to create two dashboard prompts one for the from, the other for the two, populating presentation variables and then filtering based on these with two separate filters, or one sql based file, in your analysis.

I need "closure" after sticking with you until the end - did this resolve your issue?

Standard user security would mean that any pages (tabs) of the dashboard which the user has rights to would not appear. I would not build a security model over the security model, it is redundant and will only cause problems going forward. On your session variable what have you tried already when you say 'cannot seem to…

Hi, can you provide a picture showing your physical and logical table joins. Also can you explain if your measure then you are putting time series on is physical or logical and ditto for the elements involved in its calculation. Finally can you show what the content levels are set to for the logical table sources involved.

Thank you!

See => Oracle Business Intelligence (OBIEE): Presentation Layer Alias

Hi, see 'presentation layer alias' it is standard funtionality in rpd presentation layer in column properties and will not break your existing report.

Hi, you could set up and use a repository variable for this, see the function syntax palette for examples on how to pull them through to an analysis column, just concatenate the value into your static go_url syntax.

Yes, that is exactly it, delete it and all users will see all rows of data in that table, BUT, before you delete it - this is part of your security model, someone obviously put it there to apply a row level security in your OBIEE solution, don't you want to find out why BEFORE you remove it ??

Hi, I am asking you to open the table source for your fact and look at the Logical table there in. Then double click on that and look at the physical tables that make up the logical table source. If it is not there then check the physical table in the physical layer and see if anything has been applied in the WHERE clause…

It is not the correct way to apply row level security but you might want to check the logic table source of your FACT W_MEASUREMENTS_F to see if the row level security has been applied by joining to the other tables that way.

The thread may be dead, the number of people with this kind of "give me the haystack not the needle" mentality are unfortunately still live and kicking...

Follow the detail in row level security I have provided, really - the answer is there!