Shimoku docs
Ask or search…
K

Menu

To better understand the creation and distribution of the menu we provide a schematic view of the structure and relations of the Shimoku structure concepts:
Shimoku structure
Each workspace has a set of menu paths and boards, but boards are at the same level as menu paths. This changes in the web view as the boards appear as the first element of the menu, it's purpose is to group menu paths, a menu path can be included in multiple boards. As we can see in the image, Board 1.A shares a menu path with Board 2.A.
A menu path that is not included in a board is not visible, that is the reason why the SDK always includes a menu path that is being used for charting in a board. By default it uses the name 'Default Name', but this can be modified in various ways:
  • If the board already exists and you want to change the name, use the command:
    > shimoku cloud update board --new-name YOUR_NEW_NAME
  • To specify to the SDK which board is currently being used for charting use the method:
    s.set_board(name: str)
    The plotting module will always include the menu paths being used in a specified board, even if the menu path was included in another board.
  • To group a set of menu paths into a specified board use the command:
    > shimoku cloud create board --group-menu-paths
    This command will list the possible menu paths available in your workspace and will let you select any number of them, then it will group them in the new board.
  • By playing with all the board's options some may encounter that they have created too many of them, the recommended command in this case is:
    > shimoku cloud delete board --force
    The reason to use the command with '--force' is that it will always be able to delete an existing board. A board that has links to menu paths cannot be deleted, so this method ensures that all links are deleted before deleting a board.
    If an menu path is not linked to a board it will not be accessible in the web page, so if all boards are deleted using this method it will appear as if the workspace has no content, but the menu paths will exist still. A simple way to test if there are inaccessible menu paths is by executing the following command to see all the menu paths of a workspace:
    > shimoku cloud list menu-paths
The side menu is created automatically when new components are created. The SDK uses the context of execution to create the necessary boards and paths.
Board with multiple menu paths
The sidebar shows the workspace boards, each board can have multiple menu paths attached and each menu path can have multiple sub-paths.
The menu paths order is defined by creation order. If you first create the menu path test it is going to be the first in the board. If you want to apply an arbitrary ordering to the menu paths you can use the method s.workspaces.change_menu_order(). To get the order of the example shown above the method would be used like this:
s.workspaces.change_menu_order(
uuid=workspace_id,
menu_order=[
'Overview',
'Lead Scoring prediction',
'Anomaly suite',
'Retention suite',
'Stock suite',
]
)
Regarding the sub-paths they are also created by creation order. Nevertheless, you can use the same method but passing a tuple with the orders of the sub-paths:
s.workspaces.change_menu_order(
uuid=workspace_id,
menu_order=[
'Overview',
('Lead Scoring prediction', [
'Explainability',
'Simulator'
]),
('Anomaly suite', [
'Explainability',
'Simulator'
]),
('Retention suite', [
'Explainability',
'Simulator'
]),
('Stock suite', [
'Explainability',
'Simulator'
]),
]
)
Sub-paths order
The CLI can also be used when the process doesn't need to be repeated periodically, using the following command that will guide you through the process:
> shimoku cloud update menu-order
To change the sub paths use the flag --change-sub-paths.