A template has a name and a set of fields. CB defines several types of templates that might be linked to client/server side logic. The simplest template type is Object, CB doesn't process/depend/use on records of such type. It's like a simple database record. All other types, like case or search have special meaning for CB. Example: when a record of type task is created, CB will send email notifications to those assigned in the task.
The list of CB template types:
It's the most used type of template that represents an object of the tree and is not linked to any custom logic on the serverside. Examples: a list of tags/categories, a set of products, blog posts etc.
A file uploaded is just an object in the tree, thus it should have a template. by default the config.default_file_template (see Core configuration) is used, but this can be changed by custom logic. When a file is double clicked in WebClient, CB will trigger an 'edit' action for the file. See File editing.
Casebox product has 'case' in its name due to a case template type. Although it's the same object type in terms of fields (a case can have any fields), there is serverside logic attached to such templates: CB has a case_id SOLR column. When any object is updated, CB will check what is the Case that contains it, and store its ID in SOLR.
Such feature allow to create "buckets" of objects, called Cases. It makes it possible to perform a SOLR query asking "show me all the objects inside this case". This query is used when scope == case in the configuration of field type _objects. See _objects fieldtype.
A template of type task should have these fields:
The logic attached to task templates:
Here are additional buttons displayed by CB in toolbar for Tasks: A "Done" button for those assigned, a "Close task" menuitem for the owner of the task.
Search forms can be created within CB. see chapter Search.
Comment is a system template with only one field: the text of the comment. Comments are not displayed in the Grid but in the Preview panel of an Object. The Comments plugin is responsible for displaying/adding/editing them.
Emails received by CB. to be revised
You might get confused by a "Template type" of type "Template". It sounds like a conceptual recursion.
Templates are created as objects in the tree, so there should be a "template class" used to instantiate templates. That's what template type is for. In CB this is called "Templates template" and there should be only one instance of "template" type of template. It's the base of all templates created in the system.
Below the two fundamental templates of CB are displayed: template and field.
All the templates and their fields are "instances" of these fundamental types. One of the benefits of such architecture is that a new CB language can be easily added to a core without serverside changes.
Example: You need to add 'French' language available in WebClient UI. It means that a user can switch from English to French, and template names should be translated. Let's say there is a "Product" template. In French this template should be seen as "Produit". To implement this, you need to add fr as a varchar field in the template template. Finally, when editing the "Product" template definition, there will be two fields "en" and "fr". The screenshot above shows this.
A template is defined by several properties like title, type, active, iconClass, these are fields. What is a field is also defined by a template.
Similar to the example above about en, fr fields in Templates, fieldnames also should be translatable: Let's say an object has a "Country" field, in French this field should be labeled as "Pais". To implement this, you need to add fr as a varchar field in the field template.
Localization is not the only benefit of having the definition of Template and Field in CB. Such flexibility allows one to redefine the concept of a Template/Field.