System Workbook - AdaptableApps/cornerstone GitHub Wiki

Cornerstone Low-Code Framework Wiki

System Workbook

When you create a new system using Cornerstone a excel workbook is created a folder within called {{SystemCode_ROOT}}/src/{{SystemCode}}.code.gen/Data. The workbook is named {{SystemCode}}.code.gen.data_{{SystemNameFileNameFriendly}}_{{SystemVersionPaddedFileNameFriendly}}code.gen.xlsx This workbook contains a worksheet for each project in your system. Each worksheet contains a list of the files that are generated for that project. The workbook also contains worksheets for all the Cornerstone models that allow you to define your system in a structured way. You are also able to add your own worksheets to the workbook to be able to pre-pid your system with your own models data.

The following Cornerstone model sheets are created by default:

Config

  • SystemCode
    • The system code you have chosen for your system.
  • SystemName
    • The name of your system.
  • SystemVersion
    • the version of this system data contained in this workbook
  • SystemVersionPaddedFileNameFriendly
    • SystemVersion formatted to be file name friendly
  • SystemCodeRootPathEnvironmentVariable
    • The name of the environment variable that contains the path to the root folder of your system. (usually {{SystemCode}}_ROOT))
  • SystemVersionIsReady
    • A flag to indicate if the system version is ready to be built. (usually set to false until you have completed the system version data)

Sheets

  • List of all the sheets in the workbook that we will be generating version import code for.
  • This also allows specification of chunking options so that large sheets are not all put in the same generated file (therefore making it possible for IDE's scanning tools not to fail to read the file due to its size)

CsConcept

  • This allows for definition of all the unique models in the system that are not already provided by Cornerstone
  • This is one of the main sheets used by the Source Dynamo code generation templates created automatically when the system is created

CsConceptAspectType

  • This allows for definition of Aspect Types that can be used by CsConceptAspects
  • This helps you generate different code for different aspects of a CsConcept according to there type

CsConceptAspect

  • This allows for definition of the Concept's Aspects
  • Essentially these become the properties of the Concept's generated model, and ultimately end up as columns in a table in the database
  • Having these defined here allow for configuration to control whether it a required aspect, whether its an aspect that links to other related aspects, and other options too

CsCurrency

  • This allows for definition of the Currencies that are used in the system

CsDataRegion

  • This allows for definition of the Data Regions that are used in the system
  • This is critical for cloud deployments as the system needs to know what data region it is running in

{{SystemCode}}Region

  • This provides Regions that are user visible in the system with Friendly Names
  • Each record must relate to the corresponding CsDataRegion model

CsView

  • This allows for definition of the Views that are used in the system
  • Includes the ability to define if the view is generated, dynamic, or neither of these (i.e. it is a custom view)
  • It also specifies if a view is the initial view or post login view
  • It also specifies if a view must show the app bar, the menu, and whether you can access the view only if logged in
  • It also specifies the max width settings of the view

CsViewSection

  • This allows for definition of the Sections on Views that are used in the system
  • It relates to the CsView
  • It has a CsViewSectionType that allows for specification of the type of section - whether its an Aspects section or a Relation section
  • Aspects sections:
    • Are used to edit models
    • It defines which CsConceptAspects are shown in the section
    • Only relevant for Dynamic or Generated Views
  • Relation sections:
    • Are used to show related models
    • Only relevant for Dynamic or Generated Views
  • It also specifies the order of the sections, whether they are initially expanded or not, whether they are active or not, and whether they allow for multi selection or not
  • It also has an optional custom filter stored CsDataQuery to allow for custom filtering of the section

CsViewSectionAspect

  • This allows for definition of which CsConceptAspects are shown in the section
  • Only relevant for Dynamic or Generated Views

CsViewSectionCsAction

  • This allows for definition of which Actions are shown in the section wil
  • These are rendered as buttons in the view or section according to the CsActionHorizontalPositionEnum
  • Custom code can be added to the Client or Server or Shared CsActionManager to handle the actions
  • Only relevant for Dynamic or Generated Views

CsMenu

  • This allows for definition of the Menus that are used in the system
  • Provides various options, including the position of the menu according to CsMenuPositionEnum

CsMenuItem

  • This allows for definition of the Menu Items that are used in the system
  • Relates to the CsMenu
  • Provides various options, including the target CsConcept, and the CsAction to be performed when the menu item is chosen, the icon to be used, and the order of the menu item

CsUser

  • This allows for definition a Cornerstone User - which is the primary model to identify who the user is to Cornerstone
  • Prepid in here initial users for your system - normally super admin users

{{SystemCode}}User

  • This allows for definition of your systems user
  • Its parent is CsUser
  • You can have additional aspects on this model that aren't provided by Cornerstones CsUser
  • Prepid in here initial users for your system - normally super admin users

CsWks

  • This allows for definition of a Cornerstone Workspace - which is the primary model that allows a system to have data split by tenant both conceptually and physically in terms of persisteance
  • Prepid in here initial workspaces for your system

{{SystemCode}}Wks

  • This allows for definition of your systems Workspace - which is the system specific model that allows a system to have data split by tenant both conceptually and physically in terms of persisteance
  • Its parent is CsWks
  • You can have additional aspects on this model that aren't provided by Cornerstones CsUser
  • Prepid in here initial workspaces for your system

CsRoleType

  • Part of the RBAC Feature in Cornerstone
  • This allows for definition of Role Types which are used to classify roles
  • Initial records are provided when your Systems Cornerstone Workbook is created.
  • You need to prepid additional ones you may require and use its aspects to define what the role type is

CsRole

  • Part of the RBAC Feature in Cornerstone
  • This allows for definition of the Roles in your system
  • Initial values are provided when your Systems Cornerstone Workbook is created
  • You need to prepid additional ones you may require and use its aspects to define what the role is

CsRoleMember

  • Part of the RBAC Feature in Cornerstone
  • This allows for definition of the Role Members in your system
  • Initial values are provided when your Systems Cornerstone Workbook is created
  • You need to prepid additional ones you may require and use its aspects to define what which users are role members should be created by default

CsRoleCsConceptCsAction

  • Part of the RBAC Feature in Cornerstone
  • This allows for definition of the Role Permissions in your system
  • Initial values are provided when your Systems Cornerstone Workbook is created
  • You need to prepid additional ones you may require and use its aspects to define what which permissions roles should be given be created by default