Canvas Items View
Canvas Items provide a complete view into all the changes that have been within a canvas itself. This view can take a while to run but gives you a complete overview of all the changes sitting in a canvas so you know what was done, by whom, and when, so you can make informed decisions as to how to recreate it, change it in to a new canvas, promote changes into the main system, or simply discard it.
Canvas Items Features
Canvas Items serve two main purposes. The first is to provide a window into the activity within a canvas. This can give you an understanding of the changes you made and what the results were. The second purpose is to provide the optional, and permissioned, ability to promote those changes into the main system itself.
When listing the changes the system only lists changes to root level items. All child related entities of that record won't show if they have changes because the parent is shown as having changes anyway.
Caution
For instance if you change a user, and add that user to another role, the system will show there is a change against the user - not the user and a userrole record.
This is to provide an easier ability to review the changes. Many parent records could have 1000's of child records that change during a calculation. All you want to do is see the change in the parent record, not the individually updated results of that. This way you can promote the change and the child records will be included in that promotion anyway.
Canvas Query
The results of the Canvas Items grid is provided by a standard system SQL Wrapper named GetCanvasItems (see here). You can open that SQL Wrapper to see how it queries the database to get the changes, and also create charts, pivots, etc from it using all the standard functionality of SQL Wrappers [more info].
Warning
Do not change this SQL Wrapper, it is automatically recreated by the system on any upgrade or use of reset system roles. You're changes will just be overwritten. Instead standard practice is to take a copy and make your changes there, and use that copy.
You can see that the Canvas Items view is just reusing our standard SQL Wrapper to get the required results. This is an example of how you can integrate custom sql results into the application seamlessly wherever you like.
Canvas Items Results
Canvas Items have the following properties:
Name | Description |
---|---|
Last Updated | The date/time stamp of when this change was made in the canvas |
Modified By User | The user who made this change in the canvas |
Type | The type of entity that has been changed. This can be a standard system entity, custom entity or any entity you've created through our API. |
Label | The title of the record that was changed |
Status | The type of change to the record:
|
Commands
Note
A Canvas Item has the standard set of commands and functions when being viewed from a grid. See our standard grid functionality.
Along with the standard commands the Canvas Items grid also has the following custom commands:
- Promote Item
If you have permissions you can select canvas items and promote them to the real system. This will take the latest changes you have made for that record (and its children) and apply those same changes to the main system. For instance if you have updated the name of a user, the promotion will make the same user in the main system have the new name. - Remove Item
This will remove the changes you have made for this record (and its children) from the canvas.
For instance if you have updated an item in the canvas, it will remove the update and the canvas will go back to showing the value of the original record from the main system.
Effectively this resets the canvas back to how it was originally with regards to that record - it doesn't remove the record itself completely from the canvas (unless it never existed in the main system to begin with (an InCanvasOnly status))
Warning
Note: Promotions will not overwrite any conflicts with the changes you are promoting from the canvas. For instance if you change the name of User 'Bob' to 'Bobby Heart', and meanwhile in the main system someone else changes User 'Bob' to 'B. Heart' then the system will only promote your change if your change has a date greater than the change in the main system.
The system plays everything safe by default and just fails to promote records if there are merge conflicts - it doesn't attempt resolution. You can always export your change from the canvas and import into the main system as a last result.
Ensure you are completely familiar with how promotions operate, and the changes that have been made in the main system, before promoting large changes into the main system. If unsure keep backups until you are experienced with the functionality.