DBObject "category" values

Here is a sample DBObject PHP declaration, with the category property visible :

class Foo extends DBObject
{
   public static function Init()
   {
        $aParams = array
        (
            "category" => "addon/authentication,grant_by_profile",
            // ...
        );
        // ...
   }
}

Same in XML :

<?xml version="1.0" encoding="UTF-8"?>
<itop_design xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" version="3.0">
        <classes>
                <class id="Bar" _delta="define">
                        <parent>cmdbAbstractObject</parent>
                        <properties>
                                <category>bizmodel,searchable</category>
<!-- ... -->
                        </properties>
<!-- ... -->
                </class>
        </classes>
</itop_design>

What is the purpose of the “category” iTop class property?
We can list two purposes, which can help determine for this class :

• its business meaning
• its behavior

As they are a class property, they differ from inheritance.

To sum up, iTop classes behaviors are determined by all of those characteristics :

• class category property
  • user rights
  • CSV exports
• class source code
  • iTop's native code
  • code added by customizations
• inheritance: the class parent object
  • DBObject : persistence + silos
  • CMDBObject: DBObject + history tracking + bulk update
  • cmdbAbstractObject: CMDBObject + user rights+ edit GUI + CSV exports

NB: Some categories only take effect if classes inherit from cmdbAbstractObject.

This will help you choose which category to pick for your new iTop class.
More detailed informations will be given in the next chapter.

That means a class that would be :

• editable : extends cmdbAbstractObject
• available in the universal search functionality (Administration / Universal Search): bizmodel
• available as a dashlet source: bizmodel
• available in the global search (search the whole application, field located in the top bar): searchable
• importable: bizmodel or addon/authentication or application
• access rights dependent: bizmodel or addon/userrights
• always available even when in read only mode: view_in_gui

Create a cmdbAbstractObject child, having following categories : bizmodel,searchable,view_in_gui

That means a class that would be :

• non editable : extends CMDBObject
• available in the universal search functionality (Administration / Universal Search): bizmodel
• available as a dashlet source: bizmodel
• available in the global search (search the whole application, field located in the top bar): searchable
• access rights dependent: bizmodel, and also addon/userrights
• always available even when in read only mode: view_in_gui

Create a CMDBObject child, having following categories : bizmodel,searchable,view_in_gui
You could add also addon/authentication, application, or also addon/userrights.

That means a class that would be :

• no change history: extends DBObject

Create a DBObject child, without any categories.

Those category property values will only be used to add a meaning to the class. In iTop they won't be used for anything.

• addon
• changemgmt
• cloud
• configmgmt
• core
• designer
• incidentmgmt
• knownerrormgmt
• lnkknownerror
• m2prequest
• problemmgmt
• quizz
• requestmgmt
• servicemgmt
• structure
• survey

Fun fact:
At first the bizmodel category was part of those semantic meaning only categories. It was meant to indicate business objects, and that aren't part of iTop framework. But as time goes by some behaviors were added to this category, and the iTop framework began using it ! In consequence bizmodel isn't anymore a semantic only category.

• Category: bizmodel.
• Where: \DashletBadge::GetPropertiesFields
• Feature: class becomes available in dashlets' classes list

• Category: bizmodel.
• Where : pages/UniversalSearch.php
• Feature: class get listed in the universal search

• Category: searchable
• Where: pages/ajax.render.php $operation='full_text_search'
• Feature: global search is searching in the class objects

• Category: bizmodel.
• Where: pages/csvimport.php GetClassesSelect()
• Feature: class objects can be imported with the CSV import page

• Category: addon/authentication, application.
• Where: pages/csvimport.php GetClassesSelect()
• Feature: for admin users, class objects can be imported with the CSV import page

• Category: bizmodel, silo, filter
• Where: \UserRights::GetSelectFilter
• Feature:
  • Silos are applied on classes having an org_id field, using the User Allowed Organizations
  • For classes having bizmodel or silo category, iTop check within the Grant Matrix if the user has read access to that class (IsActionAllowed()). So an explicit read access must be given by one of the User's Profiles for those classes. If not, the Select will return an empty set.
  • For other classes which have grant_by_profile, but neither bizmodel, nor silo, nor filter, then any SELECT queries, will return all objects. For those classes, AllowAllData() is useless.
  • Classes with filter category (which should be used alone and not be combined with bizmodel, silo or grant_by_profile!), will always apply a specific hardcoded filter for that class, but also consider that the user is always allowed to read those data, without an explicit read-access access to the class in his Grant Matrix.
  • \DBSearch::AllowAllData() is required for bizmodel and silo classes, when all objects must be returned regardless if the user is allowed to see them or not (He could be limited due to silo and/or Grant Matrix).

• Category: bizmodel, grant_by_profile
• Class: cmdbAbstractObject
• Where: \UserRights::IsActionAllowed and \UserRights::IsActionAllowedOnAttribute
• Feature: change class user rights if and only if this class is a child of cmdbAbstractObject

• Category: addon/userrights.
• Class: cmdbAbstractObject
• Where: \UserRights::IsActionAllowedOnAttribute
• Feature: change class user rights if the class isn't bizmodel nor grant_by_profile, and is a child of cmdbAbstractObject

• Category: view_in_gui.
• Class: cmdbAbstractObject
• Where: \UserRights::IsActionAllowed
• Feature:Bypass user rights and switch to read only if class is a child of cmdbAbstractObject

• Category: addon/userrights, application, bizmodel, core/cmdb, gui.
• Where: \MetaModel::MakeDictionaryTemplate called in ajax.toolkit.php
• Feature: add a dictionnary template for the class

• Organization
• Person
• FunctionalCI
• …

grant_by_profile allows to delegate edition of those classes, through Profiles to other user than iTop Administrators,
while silo allows to limit visibility on Users within the Allowed Organizations of the current user.

• User and most its sub-classes

grant_by_profile allows to delegate edition of those classes, through Profiles to other user than iTop Administrators,

• Trigger
• Action
• SyncroDataSource
• SyncroReplica
• MailInboxStandard
• EmailReplica
• …

grant_by_profile allows to delegate edition of those classes, through Profiles to other user than iTop Administrators,
while filter allows to limit visibility through custom filtering

• URP_Profile: Administrator Profile not visible to non Administrators users
• URP_UserProfiles Administrator Profile and User being Administrators are not visible to non Administrators users