ITSM Designer access
There are different profiles which can be provided to the ITSM Designer users. They are cumulative. Each profile provides particular functionalities within the ITSM Designer application.
Designer User
This is the profile you must have to be able to
connect to the ITSM Designer.
Users having this profile, can:
-
read all information related to the Datamodel,
Designer MTP Only
This profile must be combined with Designer
User.
Users having this profile, can:
-
execute a Move To Production of a revision on any instance
Designer Power User
This profile must be combined with Designer
User.
Users having this profile, can:
-
Enable the “Admin Mode”, in which they can modify class & fields defined as part of the Standard Datamodel.
Designer Portal Developer
This profile must be combined with Designer
User.
Users having this profile, can:
-
Edit the XML of the User Portal(s)
Designer PHP Developer
This profile must be combined with Designer
User.
Users having this profile, can:
-
Edit the PHP Methods: Create, Modify & Delete them
-
Create, Modify, Delete Snippets
-
Create, Modify, Reset or Delete Constants
-
Modify Module Parameters
Component Developer
This profile must be combined with Designer
User.
Users having this profile, can:
-
Upload new Extension and new versions of existing Extensions owned by the company of the Developer
Ask Combodo for enabling such extension on your Designer licence
Component Publisher
This profile must be combined with Designer
User.
Users having this profile, can:
-
Allow a customer license to use an extension/component owned by the company of the Publisher
Component User
This profile must be combined with Designer
User.
Users having this profile, can:
-
Activate, upgrade or remove an extension/component from the license, as long as the extension was published on his licence
Essential versus Professional
Rights which are not the same:
| Action | Essential | Professional |
|---|---|---|
Create a root class under
cmdbAstractObject |
No | Yes |
| Create a sub-class under an abstract class | under Functional CI tree and Typology | any abstract class |
| Manage an object lifecycle: add state, transitions, actions,… | No | Yes |
| Manage Profiles and Groups | No | Yes |
For those other actions there is no difference
| Action | Essential | Professional |
|---|---|---|
| Add fields on most classes (*) | Yes | Yes |
| Modify existing fields (**) | No | No |
| Modify Presentaion | Yes | Yes |
| Modify dictionary entries | Yes | Yes |
(*) There are a few frozen classes, such as Attachment,
ApprovalRule, CoverageWindow, Holiday, HolidayCalendar,
RequestTemplate, PrecannedReply, PrecannedReplyCategory and
every class which do not have the category BizModel.
For those classes users cannot add any field.
(**) That particular limitation is removed if you are Power user. But there are real risks behind some of the possible changes: Exemple of such dangereous change: Removing a value from the values of an AttributeEnum:
-
Enum values can be used within a method or an OQL (in a filter, a dashboard, an audit rule, a queryphrase), (eg. Ticket priority computed based on other enum), so removing such value will modify/break iTop standard behavior.
-
If existing objects in iTop instances can have the value that is removed from the Datamodel, this will stop the Move To Production (This limitation was removed in iTop 3.0.0, which handles this use case)