Cube task for all rows

Hi Peter,

This is currently working as intended, as all underlying rows should be represented by the first row - they all share the same dimensions.

The task should ideally be bound on the row properties and column properties representing the row, not on the key of the record.

For instance, when you have an invoice status per customer, every cell represents a combination of invoice_status + customer_id

When you bind the table-task on invoice_status+customer_id instead of invoice_id, you’ll get the scope of the records representing the cell.

Can you explain a bit more about your scenario?

Hi Anne,

I get what you are saying, but that only seems to apply to cubes with static predefined views.

The problem with the current implementation lies with cubes the user is free to design the view. In these cubes you never know how the user has aggregated the data when executing a task. Neither is there a possibility to block the execution of the task when the data is aggregated on a higher level. The user also does not know how he should aggregate the data for the task to work properly.

So in your example if the user would aggregate with just the invoice_status dimension, the task will only execute for the customer of the first row.

Possible solution
I think the best solution would be that the task would be executed for all distinct columns of the cube that are connected as a task parameter (within the selected aggregation). So in the invoice example with only the invoice_status dimension it would select all distinct invoice_status + customer_ids for the selected invoice_status dimension and execute the task for all these rows.

Context of my current scenario
We have a cube of sales orders. This cube is the start of different work processes; basically the users make sure all relevant data is filled correctly before processing the order. The users are able to gather the relevant data real easy with making their own cube view (they are really enthusiastic about this). Depending on the specific required action, the user wants to navigate from this cube aggregation selection to the list of orders, order-lines, products or product-details to fill in/change missing data. With the task on the cube, the user would be able to create a worklist for himself.

Limited workaround
For orders we have made a workaround by placing a treeview tab page behind the cube. The treeview is grouped on order no. (so it doesn’t display duplicate rows) and next to the treeview there is a detail with the order form. This works so that the treeview shows all distinct orders in a list based on the aggregation selection in the cube. But this setup has one big limitation: we can only create one treeview (grouping) per cube, so we cannot make another tab page for products on the same cube.