Sidebar

Using iTop

Creating your iTop

iTop Customization

"How to" examples
DataModel

User Interface

Automation & Ticket management

Portal Customization

:: Version 3.2.0 ::

DBObject "category" values

Introduction

Declaration

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>

Purpose

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.

Use cases

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

"I want a Standard behavior class"

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

"I want a read only class" (no edit form)

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.

Warning, in such a class you will get :
  • change history
  • importable (we cannot forbid that ☹ )

"I want a class hidden in UI" (only accessible through code)

That means a class that would be :

  • no change history: extends DBObject

Create a DBObject child, without any categories.

It is dangerous to add categories.
For example, with searchable, the class will be available in the Global Search !

Categories doing nothing

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.

Features & categories

Dashlets

  • 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
bizmodel has no effect on this specific feature, whereas it is used for many other ones

User rights behaviors

Beware almost all behaviors are triggered by the bizmodel category, but not all of them!

CSV import

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

CSV import for admin users

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

Select

  • 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).

IsActionAllowed and IsActionAllowedOnAttribute

  • 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

IsActionAllowedOnAttribute

  • 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

Objects read

  • 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

Toolkit

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

Category and classes

bizmodel

  • Organization
  • Person
  • FunctionalCI

grant_by_profile + silo

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

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 + filter

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
3_2_0/customization/dbobject-categories.txt · Last modified: 2024/09/10 10:25 (external edit)
Back to top
Contact us