Skip to Main Content

Analytics Software

Announcement

For appeals, questions and feedback about Oracle Forums, please email oracle-forums-moderators_us@oracle.com. Technical questions should be asked in the appropriate category. Thank you!

Limit Dimension POV to selected members

MNWApr 28 2014 — edited May 13 2014

I want to limit the members all users can select under a particular dimension when viewing a report.

When I use User POV and limit it to "Selected Members," it doesn't limit it at all! If a user's FR preferences in workspace are set to view all members in that dimension in their User POV selection, they can view all members!

When I set up the grid POV and limit it to "Selected Members" the user has no way of selecting which member they'd like. A prompt doesn't appear like it does with User POV, and there's no link at the top of the report for users to click on.

When I setup the member selection in the columns, it works fine. But why would users have to view two separate prompts to set up their point of view?

What is the "best practice" to limit the members available in a report's Point of View to a select few?

This post has been answered by MNW on Apr 28 2014
Jump to Answer

Comments

NickR2600-Oracle

So when would it be beneficial to have an abstract method in a super class? One answer would be because the sub classes have no shared functionality. Or in other words, because the functionality is so different between subclasses. Or because the functionality can't be defined yet.

In Java Puzzle Ball, I have an abstract class called GameObject. It's inherited by a lot of different concrete classes: bumpers, assignable behaviors, level geometry... And one if its responsibilities is to define what happens when a collision occurs. But I have to leave the collision effect method abstract. The geometry of all these objects are so dramatically different, there isn't any shared functionality I can write to define how the physics of all these different angles and shapes should work. The best I can do is write an abstract method as a promise to implement the functionality somewhere later down the inheritance structure.

pastedImage_0.png

AjayKumarGuttikonda

Thank you so much for taking time out and answering the question in very elaborated manner. I understand, the conclusion is Account class need not be abstract as all methods are implemented and also there is no problem Account class being abstract as the abstract class by definition can have all methods implemented. Can you please also explain why in this case it is beneficial to have Account class as abstract since we have implemented all methods.

NickR2600-Oracle

You got it.  I'm glad you're enjoying the course

It's more of a design choice in this example.  Even though Account could technically exist as a concrete class, I only meant for it to be a container for all the fields and methods shared by savings and checking accounts.  So to reinforce that decision and prevent instances of Accounts from getting created, the class is left abstract.

One other thing to consider is that Accounts don't have an accountType field, but savings and checking account classes do.  Looking back, maybe I should have written an abstract method into the Account class to somehow enforce the need for this field.

1 - 3
Locked Post
New comments cannot be posted to this locked post.

Post Details

Locked on Jun 10 2014
Added on Apr 28 2014
3 comments
1,460 views