Skip to main content

MSTR Restricting access to data: Security filters

https://www2.microstrategy.com/producthelp/10.5/SystemAdmin/WebHelp/Lang_1033/Content/Admin/Restricting_access_to_dataSecurity_filters.htm

Restricting access to data: Security filters

Security filters enable you to control what warehouse data users can see when that data is accessed through MicroStrategy. A security filter can be assigned to a user or group to narrow the result set when they execute reports or browse elements. The security filter applies to all reports and documents, and all attribute element requests, submitted by a user.
For example, two regional managers can have two different security filters assigned to them for their regions: one has a security filter assigned to her that only shows the data from the Northeast region, and the other has a security filter that only shows data from the Southwest region. If these two regional managers run the same report, they may see different report results.
Security filters serve a similar function to database-level techniques such as database views and row level security. For information about controlling data security at the data warehouse level, see Controlling access to data at the database (RDBMS) level.
For more information about security filters, see the following:

Security filter example


How security filters work


Creating and applying a security filter


Security filters and metric levels


Using a single security filter for multiple users: System prompts


Merging security filters

Security filter example

A user in the MicroStrategy Tutorial project has a security filter defined as Subcategory=TV. When this user browses the Product hierarchy beginning with the Category attribute, she only sees the Electronics category. Within the Electronics category, she sees only the TV subcategory. Within the TV subcategory, she sees all Items within that subcategory.
When this user executes a simple report with Category, Subcategory, and Item in the rows, and Revenue in the columns, only the Items from the TV Subcategory are returned, as shown in the example below.
external image Security_Filter_1.gif
If this user executes another report with Category in the rows and Revenue in the columns, only the Revenue from the TV Subcategory is returned, as shown in the example below. The user cannot see any data from attribute elements that are outside the security filter.
external image Security_Filter_2.gif

How security filters work

Security filters are the same as regular filters except that they can contain only attribute qualifications, custom expressions, and joint element lists. Relationship filters and metric qualifications are not allowed in a security filter. A security filter can include as many expressions as you need, joined together by logical operators. For more information on creating filters, see the Filters chapter in the Basic Reporting Guide.
A security filter comes into play when a user is executing reports and browsing elements. The qualification defined by the security filter is used in the WHERE clause for any report that is related to the security filter’s attribute. By default, this is also true for element browsing: when a user browses through a hierarchy to answer a prompt, she only sees the attribute elements that the security filter allows her to see. For instructions on how to disable security filters for element browsing, see To disable security filters for element browsing.
Security filters are used as part of the cache key for report caching and element caching. This means that users with different security filters cannot access the same cached results, preserving data security. For more information about caching, see Improving Report and Document Response Time: Caching.
Each user or group can be directly assigned only one security filter for a project. Users and groups can be assigned different security filters for different projects. In cases where a user inherits one or more security filters from any groups that she belongs to, the security filters may need to be merged. For information about how security filters are merged, see Merging security filters.

Creating and applying a security filter

You create and apply security filters in the Security Filter Manager. Make sure you inform your users of any security filters assigned to them or their group. If you do not inform them of their security filters, they may not know that the data they see in their reports has been filtered, which may cause misinterpretation of report results.
Prerequisites
To create security filters, you must have the following privileges:

Create Application Objects (under the Common Privileges privilege group)


Use Report Filter Editor (under the Developer privilege group)


Use Security Filter Manager (under the Administration privilege group)

To create and apply a security filter for a user or group


1In Developer, from the Administration menu, point to Projects and then select Security Filter Manager. The Security Filter Manager opens.


2From the Choose a project drop-down list, select the project that you want to create a security filter for.

Create a security filter


3Select the Security Filters tab.


4Select one:


To create a new security filter, click New. The Security Filter Editor opens. For instructions on how to use this editor to create a filter, see the MicroStrategy Developer Help.


OR, to convert an existing filter into a security filter, click Import. Browse to the filter you want to convert and click Open. Specify a name and location for the new security filter and click Save.

Apply the security filter to a user or group


5In the left side of the Security Filter Manager, in the Security Filters tab, browse to the security filter that you want to apply, and select that security filter.


6In the right side of the Security Filter Manager, select Security Filters.


7Browse to the user or group that you want to apply the security filter to, and select that user or group.


8Click > to apply the selected security filter to the selected user or group.


9Click OK to close the Security Filter Manager.

To disable security filters for element browsing


1In Developer, log into a project. You must log in with a user account that has administrative privileges.


2From the Administration menu, point to Projects, and then select Project Configuration. The Project Configuration Editor opens.


3Expand the Project Definition category, and then select Advanced.


4Under Attribute element browsing, clear the Apply security filters to element browsing check box.


5Click OK to close the Project Configuration Editor.


6Restart Intelligence Server for your changes to take effect.

Security filters and metric levels

In certain situations involving level metrics, users may be able to see a limited amount of data from outside their security filter. Specifically, if a metric is defined with absolute filtering on a level above that used in the security filter’s expression, the filter expression is raised to the metric’s level. For information about metric levels and filtering in metrics, see the Metrics chapter in the Advanced Reporting Guide.
For example, consider a metric called Category Revenue that is defined to return the revenue across all items in each category. Its level expression is Target=Category, Filtering=Absolute. When a user with a security filter Subcategory=TV executes a report with the Category Revenue metric, the Category Revenue metric displays the total revenue for the category. The user’s security filter is effectively changed to show the entire Category in which TV is a Subcategory.
This behavior can be modified by using the top range attribute and bottom range attribute properties.

top range attribute specifies the highest level of detail in a given hierarchy that the security filter allows the user to view. If a top range attribute is specified, the security filter expression is not raised to any level above the top range.


bottom range attribute specifies the lowest level of detail in a given hierarchy that the security filter allows the user to view. If this is not specified, the security filter can view every level lower than the specified top range attribute, as long as it is within the qualification defined by the filter expression.
The top and bottom range attributes can be set to the same level.
For instructions on how to assign range attributes to security filters, see Assigning a top or bottom range attribute to a security filter.
The examples below use a report with Category, Subcategory, and Item on the rows, and three metrics in the columns:

Revenue


Subcategory Revenue, which is defined with absolute filtering to the Subcategory level


Category Revenue, which is defined with absolute filtering to the Category level
The user executing this report has a security filter that restricts the Subcategory to the TV element.

No top or bottom range attribute

If no top or bottom range attribute is specified, then at the level of the security filter (Subcategory) and below, the user cannot see data outside his or her security filter. Above the level of the security filter, the user can see data outside the security filter if it is in a metric with absolute filtering for that level. Even in this case, the user sees only data for the Category in which his or her security filter is defined.
In the example report below, the user’s security filter does not specify a top or bottom range attribute. Item-level detail is displayed for only the items within the TV category. The Subcategory Revenue is displayed for all items within the TV subcategory. The Category Revenue is displayed for all items in the Category, including items that are not part of the TV subcategory. However, only the Electronics category is displayed. This illustrates how the security filter Subcategory=TV is raised to the category level such that Category=Electronics is the filter used with Category Revenue.
external image Security_Filter_No_Limit.gif

Top range attribute: Subcategory

If a top range attribute is specified, then the user cannot see any data outside of her security filter. This is true even at levels above the top level, regardless of whether metrics with absolute filtering are used.
In the example report below, the user’s security filter specifies a top range attribute of Subcategory. Here, the Category Revenue is displayed for only the items within the TV subcategory. The security filter Subcategory=TV is not raised to the Category level, because Category is above the specified top level of Subcategory.
external image Security_Filter_Top_Limit.gif

Bottom range attribute: Subcategory

If a bottom range attribute is specified, the user cannot see data aggregated at a lower level than the bottom level.
In the example report below, the user’s security filter specifies a bottom range attribute of Subcategory. Item-level detail is not displayed, because Item is a level below the bottom level of Subcategory. Instead, data for the entire Subcategory is shown for each item. Data at the Subcategory level is essentially the lowest level of granularity the user is allowed to see.
external image Security_Filter_Bottom_Limit.gif

Assigning a top or bottom range attribute to a security filter

You assign top and bottom range attributes to security filters in the Security Filter Manager. You can assign range attributes to a security filter for all users, or to the security filters per user.
You can assign the same attribute to a security filter as a top and bottom range attribute. A security filter can have multiple top or bottom range attributes as long as they are from different hierarchies. You cannot assign multiple attributes from the same hierarchy to either a top or bottom range. However, you can assign attributes from the same hierarchy if one is a top range attribute and one is a bottom range attribute. For example, you can assign Quarter (from the Time hierarchy) and Subcategory (from the Products hierarchy) as top range attributes, and Month (from the Time hierarchy) and Subcategory as bottom range attributes.
Prerequisites
To modify security filters, you must have the Use Security Filter Manager privilege.

To assign a top or bottom range attribute to a security filter


1In Developer, from the Administration menu, point to Projects and then select Security Filter Manager. The Security Filter Manager opens.


2From the Choose a project drop-down list, select the project that you want to modify security filters for.


3Select the Attributes tab.


4Browse to the attribute that you want to set as a top or bottom range attribute, and select that attribute.


5To apply a top or bottom range attribute to a security filter for all users:


aIn the right side of the Security Filter Manager, select Security Filters.


bBrowse to the security filter that you want to apply the range attribute to.


cExpand that security filter, and select either the Top range attributes or Bottom range attributes folder.


dClick > to apply the selected attribute to the selected security filter.


6To apply a top or bottom range attribute to a security filter for a single user or group:


aIn the right side of the Security Filter Manager, select Groups/Users.


bBrowse to the user or group that you want to apply the range attribute to.


cExpand that user or group and select the security filter that you want to apply the range attribute to.


dExpand that security filter, and select either the Top range attributes or Bottom range attributes folder.


eClick > to apply the selected attribute to the selected security filter for the selected user or group.


7Click OK to close the Security Filter Manager.

Merging security filters

A user can be assigned a security filter directly, and can inherit a security filter from any groups that she belongs to. Because of this, multiple security filters may need to be merged when executing reports or browsing elements.
MicroStrategy supports the following methods of merging security filters:

Merging related security filters with OR and unrelated security filters with AND (This is the default method for merging security filters)


Merging all security filters with AND
For the examples in these sections, consider a project with the following user groups and associated security filters:
GroupSecurity FilterHierarchy
ElectronicsCategory = ElectronicsProduct
DramaSubcategory = DramaProduct
MoviesCategory = MoviesProduct
NortheastRegion = NortheastGeography
You control how security filters are merged at the project level. You can change the merge settings in the Project Configuration Editor for the selected project, in the Security Filter category. After making any changes to the security filter settings, you must restart Intelligence Server for those changes to take effect.
Changing how security filters are merged does not automatically invalidate any result caches created for users who have multiple security filters. MicroStrategy recommends that you invalidate all result caches in a project after changing how security filters are merged for that project. For instructions on how to invalidate all result caches in a project, see Invalidating result caches.

Merging related security filters with OR and unrelated security filters with AND

By default, security filters are merged with an OR if they are related, and with an AND if they are not related. That is, if two security filters are related, the user can see all data available from either security filter. However, if the security filters are not related, the user can see only the data available in both security filters.
Two security filters are considered related if the attributes that they derive from belong in the same hierarchy, such as Country and Region, or Year and Month. In the example security filters given above, the Electronics, TV, and Movies security filters are all related, and the Northeast security filter is not related to any of the others.
Using this merge method, a user who is a member of both the Electronics and Drama groups can see data from the Electronics category and the Drama subcategory, as shown below:
external image Security_Filter_Drama_AND_Elec.gif
A user who is a member of both the Movies and Drama groups can see data from all subcategories in the Movies category, not just the Drama subcategory. A user who is a member of both the Electronics and Drama categories can see data from both categories.
If a user who is a member of the Movies and Northeast groups executes a report with Region, Category, and Subcategory in the rows, only data from the Movies category in the Northeast region is shown, as seen below:
external image Security_Filter_NE_AND_Movies.gif
Data for the Movies category from outside the Northeast region is not available to this user, nor is data for the Northeast region for other categories.

Merging all security filters with AND

You can also configure Intelligence Server to always merge security filters with an AND, regardless of whether they are related.
As in the first method, a user who is a member of both the Movies and Northeast groups would see only information about the Movies category in the Northeast region.
A user who is a member of both the Movies and Drama groups would see only data from the Drama subcategory of Movies, as shown below:
external image Security_Filter_Movies_AND_Drama.gif
Data for the other subcategories of Drama is not available to this user.
This setting may cause problems if a user is a member of two mutually exclusive groups. For example, a user who is a member of both the Movies and Electronics groups cannot see any data from the Product hierarchy, because that hierarchy does not contain any data that belongs to both the Movies and Electronics categories.
Prerequisites
To configure how security filters are merged, you must have the Configure Project Basic privilege.

To configure how Intelligence Server merges multiple security filters for a user or group


1In Developer, log into a project. You must log in as a user with administrative privileges.


2From the Administration menu, point to Projects, and then select Project Configuration. The Project Configuration Editor opens.


3Expand the Security Filter category, and then select General.


4Under Security Filter Merge Options, select one of the options:


Union (OR) Security Filters on related attributes, intersect (AND) Security Filters on unrelated attributes (see Merging related security filters with OR and unrelated security filters with AND)


Intersect (AND) all Security Filters (see Merging all security filters with AND)


5Click OK to close the Project Configuration Editor.


6Restart Intelligence Server for your changes to take effect.

Using a single security filter for multiple users: System prompts

system prompt is a special type of prompt that does not require an answer from the user. Instead, it is answered automatically by Intelligence Server. System prompts are in the Public Objects/Prompts/System Prompts folder in Developer.

Note the following:

Like other prompt objects, answers to system prompts are used to match caches. Therefore, users do not share caches for reports that contain different answers to system prompts.


The system prompts Token 1, Token 2, Token 3, and Token 4 are provided to support using an XQuery source to authenticate users for a MicroStrategy project. For steps to report on and authenticate using XQuery sources, see the Advanced Reporting Guide.

The User Login prompt is a system prompt that is automatically answered with the login name of the user who executes the object containing the prompt. It can provide flexibility when implementing security mechanisms in MicroStrategy. You can use this prompt to insert the user’s login name into any security filter, or any other object that can use a prompt.
If you are using LDAP authentication in your MicroStrategy system, you can import LDAP attributes into your system as system prompts. You can then use these system prompts in security filters, in the same way that you use the User Login system prompt, as described above. For instructions on how to import LDAP attributes as system prompts, see Using LDAP attributes in security filters.
For examples of how to use system prompts in security filters, see:

Simplifying the security filter definition process


Implementing a report-level security filter


Using database tables that contain security information

To create a security filter using a system prompt


1In Developer, from the Administration menu, point to Projects and then select Security Filter Manager. The Security Filter Manager opens.


2From the Choose a project drop-down list, select the project that you want to create a security filter for.


3Select the Security Filters tab.


4Click New. The Security Filter Editor opens.


5Double-click on the text Double-click here to add a qualification. The Filtering Options pane opens.


6Select Add an advanced qualification and click OK.


7From the Option drop-down list, select Custom Expression.


8Type your custom expression in the Custom Expression area. You can drag and drop a system prompt or other object to include it in the custom expression. For detailed instructions on creating custom expressions in filters, see the Filters chapter of the Advanced Reporting Guide.


9When you have finished typing your custom expression, click Validate to make sure that its syntax is correct.


10Click Save and close. Type a name for the security filter and click Save. The new security filter is saved.

Simplifying the security filter definition process

You can use a system prompt to apply a single security filter to all users in a group. For example, you can create a security filter using the formula User@ID=?[User Login] that displays information only for the element of the User attribute that matches the user’s login.
For a more complex example, you can restrict Managers so that they can only view data on the employees that they supervise. Add the User Login prompt to a security filter in the form Manager=?[User Login]. Then assign the security filter to the Managers group. When a manager named John Smith executes a report, the security filter generates SQL for the condition Manager='John Smith' and only John Smith’s employees’ data is returned.

Implementing a report-level security filter

You can also use the User Login system prompt to implement security filter functionality at the report level, by defining a report filter with a system prompt. For example, you can define a report filter with the User Login prompt in the form Manager=?[User Login]. Any reports that use this filter return data only to those users who are listed as Managers in the system.

Using database tables that contain security information

If your organization maintains security information in database tables, you can use a system prompt to build MicroStrategy security mechanisms using the database security tables. For example, you can restrict the data returned based on a user’s login by creating a report filter that accesses columns in your security tables and includes the User Login system prompt. You can also restrict data access based on two or more unrelated attributes by using logical views (database views) and the User Login system prompt in a security filter. For more information, including detailed instructions, on how to implement these examples, see MicroStrategy Tech Note TN11351.

Comments

  1. There is so much in this article that I would never have thought of on my own. Your content gives readers things to think about in an interesting way. Thank you for your clear information. Remote Wipe iPhone

    ReplyDelete
    Replies
    1. Mstr Restricting Access To Data: Security Filters >>>>> Download Now

      >>>>> Download Full

      Mstr Restricting Access To Data: Security Filters >>>>> Download LINK

      >>>>> Download Now

      Mstr Restricting Access To Data: Security Filters >>>>> Download Full

      >>>>> Download LINK Hd

      Delete
  2. This was a stunning and valuable content. thanks for sharing this informative post.
    Certified Ethical Hacking Course
    Best Ethical Hacking Certification

    ReplyDelete
  3. Mstr Restricting Access To Data: Security Filters >>>>> Download Now

    >>>>> Download Full

    Mstr Restricting Access To Data: Security Filters >>>>> Download LINK

    >>>>> Download Now

    Mstr Restricting Access To Data: Security Filters >>>>> Download Full

    >>>>> Download LINK NW

    ReplyDelete

Post a Comment

Popular posts from this blog

Microstrategy Caches explained

Microstrategy Caches Improving Response Time: Caching A  cache is a result set that is stored on a system to improve response time in future requests.  With caching, users can retrieve results from Intelligence Server rather than re-executing queries against a database. To delete all object caches for a project 1 In Developer, log into a project. You must log in with a user account that has administrative privileges. 2 From the  Administration  menu, point to  Projects , and then select  Project Configuration . The Project Configuration Editor opens. 3 Expand  Caching , expand  Auxiliary Caches , then select  Objects . To delete all configuration object caches for a server 1 Log in to the project source. 2 From the  Administration  menu in Developer, point to  Server , and then select  Purge Server Object Caches . 4 Click  Purge Now . To purge web cache follow the steps in the link ...

Microstrategy Custom number formatting symbols

Custom number formatting symbols If none of the built-in number formats meet your needs, you can create your own custom format in the Number tab of the Format Cells dialog box. Select  Custom  as the Category and create the format using the number format symbols listed in the table below. Each custom format can have up to four optional sections, one each for: Positive numbers Negative numbers Zeros Text Each section is optional. Separate the sections by semicolons, as shown in the example below: #,###;(#,###);0;"Error: Entry must be numeric" For more examples, see  Custom number formatting examples . To jump to a section of the formatting symbol table, click one of the following: Numeric symbols Character/text symbols Date and time symbols Text color symbols Currency symbols Conditional symbols Numeric symbols For details on how numeric symbols apply to the Big Decimal data type, refer to the  Project Design Guide . ...

Case functions Microstrategy

Ca se functions Microstrategy Case functions return specified data in a SQL query based on the evaluation of user-defined conditions. In general, a user specifies a list of conditions and corresponding return values. Case This function evaluates multiple expressions until a condition is determined to be true, then returns a corresponding value. If all conditions are false, a default value is returned.  Case  can be used for categorizing data based on multiple conditions. This is a single-value function. Syntax Case ( Condition1 ,  ReturnValue1 ,  Condition2 , ReturnValue2 ,...,  DefaultValue ) Example Case(([Total Revenue] < 300000), 0, ([Total Revenue] < 600000), 1, 2) sum(Case (Day@DESC in (“Sat”,”Sun”), Sales, 0) {~+} Sum(Case(Category@DESC In("Books","Electronics"),Revenue,0)){~+} CaseV (case vector) CaseV  evaluates a single metric and returns different values according to the results. It can be used to perfo...

Microstrategy Dossiers explained

Microstrategy  Dossiers With the release of MicroStrategy 10.9, we’ve taken a leap forward in our dashboarding capabilities by simplifying the user experience, adding storytelling, and collaboration.MSTR has  evolved dashboards to the point that they are more than dashboards - they are  interactive, collaborative analytic stories . Ultimately, it was time to go beyond dashboards, both in concept and in name, and so  the've  renamed VI dashboards to  ‘ dossiers ’.  Dossiers can be created by using the new Desktop product or Workstation or simply from the Web interface which replaces Visual Insights. All the existing visual Insights dashboards will be converted to Dossiers   With MicroStrategy 10.9, there was an active focus on making it easier to build dashboards for the widest audience of end users. To achieve this, some key new capabilities were added that make it easier to author, read, interact and collaborate on dashboards ...

MicroStrategy Connection File

Creating a Connection File in Microstrategy Workstation A MicroStrategy connection file (also know as the .mstrc) is a text file that contains all of the information needed to connect Workstation to a MicroStrategy environment.  With a .mstrc file, users can simply import the file and enter their credentials, and then they will be connected to a MicroStrategy On-Premises Environment. Requisites   MicroStrategy Workstation URL for your Environment MicroStrategy Login credentials How to create the connection file With the integrated option  Connect to New Environment: Open Workstation window. Go to  Environments  located under  Manage  on the left side.   Click on the plus symbol with the label of  Connect to a New Environment .   Assign a friendly environment name. Provide the Environment URL and click  Continue . Note: If it is a default MicroStrategy installation of MicroStrategy Library, the Environment U...

Apply or Pass-through functions in Microstrategy

Ap ply (Pass-Through) functions MSTR Apply functions provide access to functions or syntactic constructs that are not standard in MicroStrategy but are provided by various RDBMS systems.. Syntax common to Apply functions Apply Function Name   ("expression with placeholders", Arg1, Arg2, Arg3, …ArgN) where: Apply Function Name  – is a generic name used for the predefined pass-through functions described above expression with placeholders  – is the string describing the actual expression or syntax that the engine uses while generating the SQL and which is sent to the RDBMS. The placeholders are represented by #0, #1, and so on. "#" is a reserved character for MicroStrategy. Arg  – is an argument that replaces the parameter markers in the pattern. Arg1 replaces #0, Arg2 replaces #1, and so on. There are   five  pre-defined Apply functions to replace regular, predefined functions of the same type. For more details, cli...

Sort by metric subtotals and attribute elements together in Microstrategy

Sort by metric subtotals and attribute elements together in Microstrategy Users may observer that when creating a report that contains advance sorting with a metric that contains subtotals the report results appear to be only sorted by the metric values specified. Even if a sort is specified for the attribute elements on the report, the results in the report appear as if the attribute sort was not defined. In the screenshot below, the results for a report are shown where the Advance Sorting option 'Sort metrics hierarchically using: Total' is selected. For this report, a second sort is defined on the Customer Gender - 'DESC' form, users would notice that the ordering of the this attribute is not consistent: The sort definition for the report is shown below: CAUSE: When the option to 'Sort metrics hierarchically using: Total' option is selected, the MicroStrategy Engine first sorts the results based on the Total values, and then sorts th...

Custom Tooltips in Microstrategy developer and Web

Custom Tooltips in Microstrategy developer and Web The following table describes the macros you can use to customize graph tooltips in both MicroStrategy Developer and MicroStrategy Web: Macro Information Displayed {&TOOLTIP} All relevant labels and values associated with a graph item. {&GROUPLABEL} Name of the graph item's category. This value is often the graph item's attribute element information, as attributes are commonly used as the categories of graph reports. {&SERIESLABEL} Name of the graph item’s series. This value is often the graph item's metric name information, as metrics are commonly used as the series of graph reports. {&VALUE} The value of a given data point. {&XVALUE} The X-value of a data point. Only applicable to Bubble charts and Scatter plots. {&YVALUE} The Y-value of a data point. Only applicable to Bubble charts and Scatter plots. {&ZVALUE} The Z-value of a data point. Only applicable to Bubble charts and Scatter plots. {...

Prompt-in-prompt(Nested Prompts) in Microstrategy

Prompt-in-prompt(Nested Prompts) in  Microstrategy Nested prompts allows you to create one prompt based on the other and other bases on another, nested prompts allows us to prompt the highest level(Like year) to middle level(like Quarter, then to the low level(like Month). Here you can see how to  create a 3-level deep nested prompt that will prompt the user to select a year, then a quarter within that year, then a month within that quarter. Prompt-in-prompt is a feature in which the answer to one prompt is used to define another prompt. This feature is only implemented for element list prompts . The following procedure describes how to achieve this: Create the highest level filter. This is a filter which contains a prompt on an attribute element list. Create a filter on the attribute "Year." Click "prompt on attribute element list" and click "Next" through the rest of the screens to accept the default values. Do not set any additio...

MicroStrategy default sort order for an attribute elements browsing

MicroStrategy default sort order for an attribute elements browsing and display How does MicroStrategy 9.x resolve the default sort order for an attribute when different sort orders are defined for different forms? Consider the following cases: CASE 1 A new attribute is created with three forms, all with sort order set to none. Form Name Form Type Default Sort Order ID ID None DESC DESC None LongDesc None None The overall sort order is evaluated and stored in the attribute definition when the attribute is saved. With all form sort orders set to none there is no saved sort order, MicroStrategy defaults to sort ascending by ID. CASE 2 The same attribute is modified so the forms are now: Form Name Form Type Default Sort Order ID ID None DESC DESC Descending LongDesc None Ascending Now when the attribute is saved, MicroStrategy goes through each form in the order they appear in the main 'Forms' window of the attribute editor. The first...