Secure data access in a multidimensional data environment7039871Abstract A web-based data access system is described that allows users to securely access, manipulate and share information. The data access system includes a database that stores multidimensional data and transactional data. A server presents a user interface for setting access rights to members of the multidimensional data and access rights to transactional data. The server presents a web-based interactive environment for creating electronic reports from the multidimensional data. A page generation module executing on the server generates web pages for the environment based on the set access rights. The page generation module formats the web pages to permit an author of the electronic report to include only the accessible dimensions and members in the electronic report according to the set access rights. Claims The invention claimed is: Description TECHNICAL FIELD
Page generation module 26 constructs queries to retrieve multi-dimensional data from data cubes 17 based on report object 15. In one embodiment, an OLAP server storing data cube 17 executes the queries and communicates a result set to cube interface object 24 in response. Page generation module 26 stores the result set as report data 28. State data 29 includes a variety of information defining the current viewing state of the user including the current row, current column, font size, column width, row height, column height, row width, the number of lines, labels consumed, and the like. Page generation module 26 analyzes the results and determines how to best layout the report, given report object 15, state data 29 and report data 28. Page generation module 26 performs various calculations to determine the appropriate layout for the viewable page and, upon concluding those calculations, generates the appropriate code such as HTML. Page generation engine 26 formats the appropriate query string based on the report object model 15 and invokes the OLAP services in order to generate the code. Based on the responses, page generation module 26 builds dictionary 31, which comprises a list of accessible members. Because the page layout calculations are performed by page generation module 26, a web browser executing on the client-device can render and display the page quicker than in other systems that perform similar calculations at the client. Page generation module 26 generates the client-side code for displaying the current page using a conventional browser. In one embodiment, page generation module 26 generates the page to display a subset of the data returned in the results set and communicates the remaining data to the client-device in the background. As described below, the client device of user 4 maintains a client-side representation of report object 15 in order to perform some operations locally. Model converter 27 of application server 14 translates report object 15 into a client side script that, when executed by the client, builds a client side representation of report object 15, referred to herein as the presentation model. The presentation model is built in a native language or format supported by a browser executing on the client-device and controls how the browser presents the report to the user. Packet engine 21 transmits information, including the report pages generated by page generation module 26, the client-side script generated by model converter 27 and report data 28 to the client device in a stream of packets. As described below, packet engine 27 may communicate an initial set of packets such that the client device can quickly display a first page of the report to the user, with the remaining packets transferred in the background. Admin modules 30 allow users 4 to define web-access rights for data cubes 17 and transactional data 16. When creating a report, a user can define fine-grain access control rights, thereby controlling access to individual members of the various dimensions. Furthermore, as illustrated in detail below, the user can define the extent to which other users can customize the report. FIG. 5 is a block diagram illustrating the various components that may reside upon a client-device 32 through which user 4 interacts with data access system 12. Notably, client-device 32 is a "thin-client" that does not require software to be installed other than a web browser 33, such as Internet Explorer™ from Microsoft Corporation. Furthermore, because much of the page layout and data presentation is handled by data access system 12, no additional "plug-in" is needed for browser 33, such as client-side ActiveX or Java Applets. As such, system 2 is flexible and can be integrated completely on the web. As described above, web browser 33 receives scripts from model converter 27 of data access system 12 (FIG. 4) that causes browser 33, upon execution of the scripts, to build and maintain presentation model 35, which is a client-side representation of report object 15. Presentation model 15 controls how browser 33 presents the report to the user. In one embodiment, model converter 27 generates the scripts in Jscript format such that web browser 33 builds presentation model 33 according to a standard document object model supported by Internet Explorer™ from Microsoft Corporation™. Web browser 33 receives data from data access system 12 and stores the data in virtual table 34. A subset of the data within virtual table 34 is used to fill the current web page displayed to user 4. Web browser 33 renders and displays the web page based on presentation model 35 and the data stored within the currently viewed portion of virtual table 34. FIG. 6 illustrates in further detail a virtual table 34 for storing data received from data access system 12. As described below, data access system communicates the data in a stream of packets, which client-device 32 assembles to form virtual table 34. Based on input from the user, such as a request to scroll down, client-device 32 manipulates pointers into the virtual table 34 to retrieve and display a viewable window 38 of the data. Client-device 32 manipulates the document object model of web browser 33 based on input received from user 4 and data extracted from viewable window 36. When the document object model is adjusted, browser 22 refreshes the display of client-device 32, thereby allowing the user to scroll viewable window 36 throughout virtual table 34 and display a number of rows and columns. In one embodiment, virtual table 36 is organized as a series of arrays. FIG. 7 is a flowchart illustrating a user 4 accessing an existing report. Initially, user 4 accesses data access system 12 via client device 32 and attempts to open a report (41). In response, page generation module 26 accesses one of the data cubes 17 corresponding to the requested report and retrieves the cube definition, including the number of dimensions and the members for each dimension (42). For example, in one embodiment, page generation module 26 issues queries to an OLAP server storing the data cube 17 in order to get the cube definition. Based on the responses, page generation module 26 builds dictionary 31 of accessible members and assembles report object 15, including instantiating dimension objects 16, query set objects 17 and member objects 18 as illustrated in FIG. 3 (42). After building report object 15 for the requested report, page generation module generates an initial page for display to the user 4 (43). For example, generally the page present a portion of report data in table format arranged in rows and columns. Page generation module 26 analyzes the content of the page including: (1) labels for the individual columns, (2) labels of the page itself, and (3) the data returned in the result set from the OLAP server and calculates appropriate widths for the columns and the row headers to accommodate the content. Finally, based on the calculations, page generation module 26 generates the appropriate code, such as hypertext markup language (HTML), for displaying the initial page of the report to the user 4. Next, packet engine 21 transmits an initial set of data packets to client-device 9 to populate an initial portion of virtual table 34 and display the initial web page (44). The initial packet includes all data necessary to display the first browser page as well as the HTML or other code for displaying the code. For example, packet engine 21 may transmit a single packet containing data to populate an initial ten rows of virtual table 34. Upon receiving the initial packets, web browser 33 stores the data and presents the page to the user (46). After receiving the first packet web browser 33 displays scroll bars, thus giving the user the option to scroll through the data within virtual table 36. In this manner the user is able to quickly view the data while, as described below, client-device 32 receives the remaining data for virtual table 34. This allows a user to view the report without waiting for the full data set to load. After browser 33 initially loads and displays the first page, an "unload" event triggers, which instructs client device 32 to retrieve the remaining data. Client device 32 issues a request to application server 22 and requests script for creating presentation model 35 (47). In response, model converter 27 translates report object 15 into a client-side script, such as J script, that when executed by browser 33, builds presentation model 35 as a client-side representation of the report object 15 (48). After model converter 27 generates the client-side script, packet engine 21 transmits the script to web browser 33 via network 8 (50). Upon receiving the script, client device 9 executes the script and builds a presentation model 35 (52). In addition, client device 9 requests any remaining data that the OLAP services returned to page generation module 26 in the result set, but that was not already transmitted to the client (54). Upon receiving the request, packet engine 21 transmits the remaining data in a series of packets to client device 9 for populating the remainder of virtual table 34 (56). The user can further manipulate the electronic report by interacting with browser 33 (58). For example, the user may request to expand a dimension, reload the data or scroll through the data. FIG. 8 is a flowchart of an example process illustrating data access system 12 handling a user request to expand a member of one of the dimensions of the multidimensional data. In response to a user request to expand a member (62), web browser 33 sends an expand request to cube interface object 24 (64). As described above, in one embodiment web browser 33 accesses an Active Server Page corresponding to an expand request, which invokes a corresponding method of cube interface object 24. Cube interface object 24 updates report object 15 to reflect the changes to the report (65). For example, for an expand request, the report object model is updated to include all of the children of the member to be expanded. Based on the updated report object 15, page generation module 26 constructs queries to retrieve multi-dimensional data from data cubes 17 based on report object 15 for expanding virtual table 34. In one embodiment, an OLAP server storing data cube 17 executes the queries and communicate a result set to page generation module 26 in response. Page generation module 26 stores the result set as report data 28 (66). When constructing the query, cube interface object 24 accesses state data 29 to determine the current location of viewing window 36 within virtual table 34 in order to reduce the amount of data retrieved from data cube 17, i.e., the size of the result set. In this manner, page generation module 26 retrieves data from data cube 17 that is localized to the current viewable window 36. The typical overhead of an expand operation is thereby lessened. In one embodiment, page generation module 26 retrieves all rows starting at the current position of viewable window 36 and below. In another embodiment, page generation module 26 retrieves only those rows proximate to window within virtual table. The result set is then used to update the report object model 15. For example, referring to FIG. 3, cube interface object 24 updates query set object 17 of one or more dimension objects 16 to reflect the expansion. In addition, cube interface object 24 updates member objects 18 of the expanded dimension to reflect the new members. Based on the updated report object 15, page generation module 26 performs the page calculations described above and generates HTML or other software for displaying the page to user 4 (66). Next, as described above, packet engine 21 transmits an initial set of data packets to client-device 9 to populate an initial portion of virtual table 34 (68), which web browser 33 presents to the user 4 (70). Client device 32 then issues a request to application server 22 for the any additional data necessary to populate the expanded virtual table 34 (72). In response, model converter 27 generates client-side script to update presentation model 35 to redimension virtual table 34 to the appropriate number of rows to accommodate an expand or collapse request (74). In one embodiment, presentation model 35 is persistent between data loads. For example, presentation model 35 may be stored in a unique frame such that it remains in memory between page refreshes. Packet engine 21 transmits the script and any remaining data to client-device 32 (76). Client-device 32 executes the script to update presentation model 35 and stores the additional data in virtual table 34 (78). FIG. 9 is a flowchart of an example process for handling a user request to scroll viewing window 36 through virtual table 34. Notably, the entire request is serviced by client-device 9 without requiring communication with data access system 12. Upon receiving a user request to scroll (82), client-device 32 manipulates the presentation model 35, which may be in the form of a document object model (84). For example, client-device 32 may move a top row of the presentation model 35 to the bottom row, thereby shifting all the rows of the presentation model up. Next, client-device 32 loads the bottom row of the presentation model with data from the next row of virtual table 34, i.e., the row below the current position of window 36 (86). When the presentation model is adjusted, browser 33 refreshes the display of client-device 32 (88). In this manner, the user can scroll viewable window 36 throughout virtual table 34 without requiring interaction with data access system 12. FIGS. 10 through 28 illustrate an example web-based user interface of data access system 12 by which user 4 composes a report from data cube 17. FIG. 10 illustrates an example web page 90 presented by data access system 12 upon receiving a request to compose a new report. Web page 90 includes filter area 92 from which the user 4 selects one or more dimensions to include in the report. Filter area 92 lists all of the dimensions for the selected data cube 17 including, for example, Customers, Gender, Product, Promotions, Time, Educational Level, Marital Status, Promotion Media, Store Type and Yearly Income. Web page 90 also includes layout area 94 for defining the dimensions to be included in the composed report. For example, layout area 94 lists one active dimension, Store, and a number of a number of measures for the dimension: Profit, Profit per Units Sales, Store Cost, Store Sales and Unit Sales. In order to construct a report, a user 4 simply selects a dimension listed in filter area 92 and drags the dimension to layout area 92. FIG. 11, for example, illustrates a "drag and drop" feature of the user interface when constructing a report. Here, user 4 has selected the Promotions dimension and is adding it to layout area 94, thereby making it an active dimension for the report. Layout area 94 displays the active dimensions in a nested fashion indicating their respective places in the dimension hierarchy. As displayed in web page 90, the current layout for the report defines a dimension hierarchy of Promotions within Stores. The direction of arrow 96 indicates where the dimension being added will be nested in relation to the currently active dimensions. As illustrated, arrow 96 points to the left meaning that the new dimension will be added above the active dimension, creating, for example, a dimension hierarchy of Stores within Promotions. After the dimension is added, user 4 can manipulate the hierarchy by simply rearranging the dimensions within layout area 94. FIG. 12 illustrates web page 90 once the Stores dimension has been added to layout area 94. In addition to adding and removing dimensions, the user may interact with layout area 94 to expand or collapse any currently active dimensions. FIG. 13 illustrates web page 90 presented after the user 4 has elected to expand the Store dimension. Upon an expansion or collapse of a dimension, client-device 32 expands virtual table 34 (FIG. 5), as described above, and updates window 90 to accurately display viewing area 92 (FIG. 6) in data area 96. As illustrated in FIG. 13, the user has expanded the Store dimension by "drilling" into the All Store Total member, the USA member, the WA member, to show stores in cities in Washington. Data access system 12 allows the user to continue to expand into a dimension as far as the levels supported by data cube 17. FIG. 14 illustrates the expansion of a second dimension, the Promotion dimension. Upon expanding the Promotion dimension, data area 92 is updated to include members for the Promotion dimension including Bag Stuffers, Best Savings, Big Promo, Big Time Discounts, etc. Data area 92 includes more rows than can be displayed by web page 90. As such, page generation module 26 automatically generates web page 90 to include scrolling bar 98. Notably, browser 33 does not generate scroll bar 98, as is typical in a web environment, but rather by page generation module 26 of data access system 12. This is advantageous for several reasons. Upon refreshing a page, the controlled scroll bar 98 allows the user interface to refresh the data to the exact point where the user previously was, without requiring that the user scroll down in order to return to his or her last position. In typical environments, when a page is refreshed the user is placed at the top of the data. Here, the entire page is built by data access system 12, including scroll bar 98, and the location of the data presented in the scroll window. As described above, data access system 12 maintains state data 29 to independently track the row and column location of the user. The user interface presented by storage access device 12 can operate in several modes including a single mode and a multiple mode for expansion and collapse operations. Window 90 displays a multiple mode icon 100 indicating that data access device 12 is currently operating in single mode and that the user can toggle into multiple-click mode by pressing icon 100. In single mode, an expansion operation displays additional data in data area 96 for the individual member that is expanded. For example, as illustrated in FIG. 14, data area 96 displays additional data only for the All Promotions member when the user expanded the All Promotions member. FIG. 15 illustrates an expansion when the user is in multiple mode, note the single icon 102 displayed by web page 90. In this mode, an expansion operation causes data area 96 to show Store detail for every member of the Promotion dimension when the Promotions dimension is expanded. FIG. 16 illustrates the report as displayed by web page 90 after the user has scrolled down in the report and is about to expand further into the Store dimension. As discussed above, data access system maintains state data 29 to store information detailing the current position of the user within the report. Note, at this position, Cash Register member 104 of the Promotion dimension is currently at the top of the report. FIG. 17 illustrates web page 90 after the user have expanded in the OR member to show cities of Oregon. Notably, upon expanding into the member, page generation module 26 automatically generates web page 90 such that Cash Register member 104 is displayed at the same location, instead of returning to the top of the report as conventional applications. Furthermore, scroll bar 98 has been constructed to reflect the current position of the user, i.e., the position of display window 92 within virtual table 90 (FIG. 6). Another feature of the user interface allows the user to select and deselect individual members of a dimension, including parents, children, grandchildren, etc., for inclusion in the report. FIG. 18 illustrates web page 90 when the user has selected a left tab 106 of the Store dimension. When the user selects the tab 106, web page 90 displays a pop-up sub-filter window 108 by which the user can select and deselect members the Store dimension. Currently, the user elected to view all of the members of the Store dimension. FIG. 19 illustrates the user interacting with sub-filter window 108 to create a narrow view of the data. Specifically, the user has selected only the Seattle member of the Store dimension to be displayed. Parent members WA, USA and All Store all have a grayed box that indicates at least one sub-member has been selected within the member structure, but that higher-level members have not been included. Similarly, empty boxes indicate those subtotals and all sub-members have been excluded. FIG. 20 illustrates web page 90 as generated by page generation module 26 based on the sub-filter settings. Notably, data area 96 displays promotional data from the Promotions dimension only for the Seattle member of the Location dimension. The user may select any combination of the members, as illustrated in web page 90 of FIG. 21, such as the Seattle member and then the WA member and the USA member. FIG. 22 illustrates web page 90 created by page generation module 26 after updating based on the current settings of sub-filter window 108 of FIG. 21. The user interface presented by data access system 12 supports similar filter capabilities for dimensions not currently active. FIG. 23 illustrates web page 90 when the user selects and displays filter window 110 for the Store Type dimension displayed in filter area 92. The filter functionality for dimensions that are not currently in the active is similar to the functionality as described above for dimensions listed in layout area 94. For any listed dimension, user 4 can select and view members and sub-members. Unlike sub-filter window 108 for active dimensions, filter window 10 allows the user to select one member or submember for a dimension. For, example, for the Store Type dimension the user could select the Clams member but not Anchovies member and the Clams member. If user 4 wants multiple selections, user 4 can activate the dimension by dragging the dimension down into layout area 94 and use sub-filter window 108. FIG. 24 illustrates web page 90 when the user has selected the Clams dimension form filter window 110. Based on the selected dimensions, page generation module 26 dynamically updates tile 112 of web page 90 to reflect the filter selections. Title 112 lists the dimensions used for measuring sales: Promotions and Store, as well as the selected members of the member hierarchy: Clams/Canned Foods/Food/All Products. Data area 96 reflects the filter selections and, because in this example page generation module 26 is set to exclude empty data rows, the user can easily tell that not every promotion has been used for clams in every store location. The user interface of data access system 12 has integrated graphing functionality that allows the user to easily generate graphs for the displayed data. FIG. 25 illustrates the user preparing to create an embedded graph for the report. Specifically, the user has swapped the Store and Promotion dimensions within layout area 94 and changed set the filter for the Product dimension to All Products. The user has also selected a range of cells 114 for use with the graphing functionality. Web page 90 highlights and the range of cells 114 and displays Select Function box 116, which offers several types of available charts or other functions. FIG. 26 illustrates a graph 118 generated by the user interface and displayed to the user for the selected range of cells 114. In addition to creating charts from selected data ranges, the user can elect to view the underlying transactional data 16 (FIG. 2). Similar to charting functions, the user selects a data range 114, but selects transactions from Select Function box 116 instead of a charting option. In response, the data access system 12 identifies the corresponding tables within transactional data 16 and retrieves records of the transactional data underlying the multidimensional data. FIG. 27 illustrates a window 120 that lists records 122 retrieved from transactional data 16 that correspond to the selected range of cells 114. Window 120 includes column headings 126 for the data fields of the records. In one embodiment, the headings are dynamically created based on the field names within the corresponding tables of transactional data 16. By selecting icon 124, the user can download the displayed records to client-device 32 in a variety of formats, such as tab-delimited or spreadsheet format. As described above, the user interface allows the user to easily and efficiently create and manipulate complex reports. For example, FIG. 28 illustrates a report in which the user has used sub-filters for the Measures dimension to select two measures: Profit per Unit Sales 126 and Unit Sales 128. The user has also used a sub-filter to: (1) select the OR member of the Store dimension, (2) select the San Francisco member and display a CA subtotal, (3) selected the Meat Products member within the Canned Foods member of the Product dimension, and (4) filtered on Time to select 1998. After creating a report, the user can "publish" a report, thereby making is available to other users 4 simply by clicking on the publishing icon 130. FIGS. 29 through 33 illustrate the user interacting with the user interface of data access system 12 to publish a report for access by other users 4. FIG. 29 illustrates a web page 132 after the user has transitioned from compose mode to publish mode by clicking publishing icon 130 (FIG. 19). Web page 132 includes a number of changes from web page 90 when the user was creating a report. Filter area 92 has been removed such that the user cannot add or remove dimensions. Furthermore, the active dimensions no longer have tabs for changing sub-filter selections. In addition, the user cannot rearrange the dimension hierarchy of the report by dragging and dropping the dimensions. Data area 96 displays the data in rows and columns, as displayed while the user was composing the report. The user can incorporate filtering options into the report by selecting the filter icon 134, thereby making selective filtering available to other users when the report is published. FIG. 30 illustrates the web page 132 when the user has selected filter icon 134. The user can add filter and/or sub-filter capabilities back into the report before publishing to other users by selecting from the list of dimensions. FIG. 31 illustrates web page 132 as updated based on the new filtering capabilities. Web page 132 now includes filter selection window 136 by which the user can select filters for the active dimensions. In addition, the active measures and dimensions now have filter selection buttons 138 that allow sub-filtering on the active dimensions and measures. As illustrated in FIG. 32, once the report is ready for publishing, the user can select the publish icon to display publish window 140. The user then provides a name for the report as it will appear to other users 4 that access data access system 12 via network 8. In addition, the user can select a folder in which he or she wants to save the report. Once a report is published, other authorized users 4 can immediately access the report via data access system 12. FIG. 33 illustrates a web page 142 in which a selection window 144 is displayed listing the available folders and reports maintained by data access system 12. The user, however, may elect not to publish a report for use by other, but maintain the report for his individual use. For example, the user can elect to bookmark the report as it currently is viewed and then save that within personal bookmarks on the server. Server-based bookmarks are advantageous in that the user can access them when he or she travels, as opposed to desktop-specific bookmarks. Data access system 12 provides a number of security measures for providing a highly secure environment in which to share data. For example, data access system 12 allows a user to define groups of users and map the groups to different views of a given data cube 17. In other words, a user can define the viewable dimensions of a data cube 17 for each user group. In addition, while composing a report, the user can identify which dimensions may be configured by a user while viewing the report. For example, while composing the report, the user can define which dimensions may be filtered and sub-filtered by users viewing the report. FIGS. 34 through 41, for example, illustrate various security mechanisms that allow users to set access rights to the multidimensional data and the underlying transactional data from which the multidimensional data was derived. FIG. 34 illustrates an interface 148 provided by data access system 12 by which a user can register a data cube 17 and define any necessary security requirements. When registering a new data cube 17, the user supplies a label for the cube within text box 150. In addition, the user may define any necessary connection information 152 needed to locate the cube within data access system 12 including names for the server and database on which the data cube resides. Interface 148 includes an input area 154 for securing access to data within data cube 17 and an input area 156 for securing access to the corresponding transactional data 16. Within the input areas 154 and 156, the user can set security access for user groups to the cube data and the transactional data, respectively. The user groups can comprise one or more users and can be mapped to different levels of access to the data within data cube 17 or transactional data 16. In the illustrated embodiment, each group can have no access, full access or partial access. For example, the user group entitled Oregon Supply Chain has partial access for both data cube 17 and transactional data 16. Input area 158 is used to control both data cube access and transactional data access, and lists the dimensional hierarchy for the defined data cube 17. After selecting a group from within input area 154 or 156, the user can then specify which dimensions, and members thereof, the group can access. For transactional data, as illustrated below, input area lists the underlying tables tables that store the transactional data. By clicking on and opening the dimensions or measures within input area 158, granular security can be defined by the user and enforced by data access system 12. For example, FIG. 35 illustrates that the Oregon Supply Chain user group will only be allowed to see the Unit Sales measure 160, among all available measures, as indicated by the adjacent solid box. A solid box indicates the member and all child members are accessible. An ampersand in a white box indicates that the sub-members are available, but not the subtotal. FIG. 36 further illustrates security such that the user group Oregon Supply Chain will only be able to view a few canned shellfish members within Canned Foods. FIG. 37 illustrates the interface 148 while the user is setting security for transactional data 16. Similar to cube-level security, the user can give a group full, partial or no access to the transactional data, independent of the cube access rights defined for the group. Input area 162 lists the tables of the database that were used to create data cube 17. As illustrated in FIG. 38, the user may interact with interface 148 to give a group limited access to fields of the Store a given table, such Address, State, City, Phone, Fax and Manager within the Store table 163. Once the user has defined the security settings for a report, access by other users 4 is controlled by data access system 12 according to the settings. FIG. 39 illustrates a user 4 within the Oregon Supply Chain user group logging into data access system 12 to view the published report. Because of the defined security settings, page generation module 26 produces web page 162 such that the user 4 can only view canned shellfish, including the members Clams, Oysters and Shrimp. The user 4, however, can expand down into the authorized portions of data cube 17 until reaching the lowest sub-members of the accessible dimensions. Based on the cube-level security, the filter and sub-filter functionality of the report is limited to the members and sub-members for which access to the user was granted. For example, in filter selection box 166, the user can only filter on the Time dimension, and not the Store Type dimension, based on the security settings. In addition, when selecting the Measure dimension, sub-filter window 164 allows the user to only sub-filter on Unit Sales, the only member to which the user has access. Similarly, as illustrated in FIG. 40, although the user has a filter icon to select dimensions for filtering, window 168 only displays the dimensions for which they have been authorized. FIG. 41 illustrates a window 170 displayed by the user interface when the user selects a range of cells and elects to view the underlying transactional data 16. The records 172 listed by window 170 are limited to only the fields for which the user has been authorized, i.e., product and store information in this example. In addition to viewing and analyzing the data in a report, a user may be able to toggle into compose mode to compose a second report based on the permission settings for the user group. If the user has compose permissions, as indicated by a compose icon 174 (FIG. 39), the user can toggle into compose mode where the report layout is preserved visually. Security, however, remains enforced such that the user can only manipulate the dimensions, members and sub-members, that he or she has been given access. FIG. 42 illustrates a web page 176 generated by page generation module 26 when the user toggles into compose mode. Notably, web page 176 has a filter area 92 and a layout area 94, as described above, with which the user can interact to create a new report, limited to the accessible dimensions and members. Various embodiments of the invention have been described. These and other embodiments are within the scope of the following claims.
|
Same subclass Same class Consider this |
|||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||