thinkwise-software-factory-cubes

The documented path is task_enrichment_create_cube bound to the cube entity, but live testing showed it rejects staging against a not-yet-existing cube key. The reliable fallback is a plain add of the cube row with model_id, branch_id, cube_id, and description, then building cube_field rows individually.

Set the child cube_field's cube_field_grp_id to the parent field's cube_field_id to establish the parent-child identity. Then place every hierarchy level as its own cube_view_field row in the same area, ancestor-to-leaf, since the grouping alone does not render nested rows.

Use a cube when users repeatedly rearrange, drill, and slice operational data. Prefer a Grid or Form for record editing, a report for pixel-perfect documents, fixed tiles for a few KPIs, and Power BI or Qlik via OData export for cross-system enterprise analytics.

A pivot cell is editable only when all preconditions hold: update permission on the subject, the field is a value, the column is editable, summary_type is min, max, sum, or average, exactly one underlying row feeds the cell, and the role's editable right is granted.

The task_cube_view_field_area_drag_drop task takes no parameters and only backs the visual drag-drop panel, so patch cube_area directly instead. A combined write can silently drop the field, so set cube_area last among the properties and re-read the row to confirm it stuck.

No live preview exists in the Software Factory. The documented workaround is building the view once in the running application, then replicating that field arrangement back into the model; write-back from the app is a stated future direction, not shipped.