You are browsing the documentation for iTop 3.0 which is not the current version.

Consider browsing to iTop 3.1 documentation

Portal: Changing visible Tickets

Prerequisite: You must be familiar with the Syntax used in Tutorials, have already created an extension and be familiar with the XML portal logic.

learning:
Changing what users are able to view/modify in the Portal
level:
Intermediate
domains:
XML, Access rights, Portal
min version:
2.3.0

Let's modify the list of Tickets that a user can see in the portal:
Usecase: We want any users, to see not only the Ticket for which they are the caller, but also those for which they have been added as contact.

For that you will need to:

  • Have an iTop system with the enhanced portal installed,
  • Have access to an account having the Portal User profile,
  • Have a way to modify the datamodel definition (creating an extension or with ITSM Designer)

In order to achieve the above usecase, we will need to change the default settings of the Portal. This settings is purely defined in the XML structure, so we just need to alter it. For this:

  • Understand the XML portal logic
  • Retrieve the default Portal model in the file <itop>/data/datamodel-production.xml located on your installed iTop.
  • Check the Customer portal XML Reference for explanation on the XML structure and tags
  • Write XML code to alter the default Portal model

XML Portal Logic

For our usecase we will just need to modify the Ticket scopes.
A scope defines for a given class, the objects which can be viewed or modified, by users having or not a particular profile.

Existing Ticket Scopes

The default Ticket scopes are:

  • all: simple “Portal user” can only see the Ticket for which he is the “caller”.
  • portal-power-user: “Power Portal user” can see all all Tickets of his organization.
itop_design / module_designs
<module_design id="itop-portal">
  <classes>
    <class id="Ticket">
      <scopes>
        <scope id="all">
          <oql_view><![CDATA[
            SELECT Ticket AS T WHERE T.caller_id = :current_contact_id 
            AND T.finalclass IN ('UserRequest', 'Incident')]]>
          </oql_view>
          <!-- oql_edit is combined with oql_read -->
          <!-- you can never modify something that you cannot read -->
          <!-- the query below brings no further restriction to the read -->
          <oql_edit><![CDATA[SELECT Ticket AS T]]></oql_edit>
          <!-- No allowed profiles tag, so this scope applies to all users -->
        </scope>
        <scope id="portal-power-user">
          <oql_view><![CDATA[
            SELECT Ticket AS T WHERE T.org_id = :current_contact->org_id 
            AND T.finalclass IN ('UserRequest', 'Incident')]]>
          </oql_view>
          <oql_edit><![CDATA[SELECT Ticket AS T]]></oql_edit>
          <!-- This scope applies only to users having a particular Profile -->
          <allowed_profiles>
            <allowed_profile id="Portal power user"/>
          </allowed_profiles>
        </scope>
      </scopes>

Portal XML Tags

  • Read the comments in the XML examples to understand better the used tags and their purpose.
  • Check the Portal XML reference for all possible options.

Changed scope

Adding a new scope

Here is a new Ticket scope to allow: “Any portal user to see in the Portal, tickets they are linked to as contact.”

itop_design / module_designs / module_design@itop-portal
  <classes>
    <class id="Ticket" _delta="must_exist">
      <scopes>
        <scope id="all-in-contacts" _delta="define">
          <oql_view><![CDATA[
            SELECT Ticket AS T 
            JOIN lnkContactToTicket AS l ON l.ticket_id = T.id 
            WHERE l.contact_id = :current_contact_id 
            AND T.finalclass IN ('UserRequest', 'Incident')]]>
          </oql_view>
          <!-- no oql_edit tag mean no write access for this scope -->
        </scope>
      </...>

As-is this new scope:

  • Is available for all users.
  • Does not provide write access on Ticket for which I am a contact but not the Caller
Scopes which are applicable to the current User and the current class, are combined with a UNION. So as a simple Portal user, I will be allowed to view all Tickets which belongs to scopes all or all-in-contacts.

Changing an existing scope

I can also use this other method:

itop_design / module_designs / module_design@itop-portal
  <classes>
    <class id="Ticket" >
      <scopes>
        <scope id="all" _delta="must_exist">
          <oql_view _delta="redefine"><![CDATA[
            SELECT Ticket AS T 
            JOIN lnkContactToTicket AS l ON l.ticket_id = T.id 
            WHERE l.contact_id = :current_contact_id 
            AND T.finalclass IN ('UserRequest', 'Incident')
          UNION 
            SELECT Ticket AS T WHERE T.caller_id = :current_contact_id 
            AND T.finalclass IN ('UserRequest', 'Incident')]]>
            ]]>
          </oql_view>
        </scope>
      </...>

Then:

  • It still applies for all users.
  • But does provide write access on Ticket for which I am a contact or the Caller
  • With this implementation, I have no mean to prevent edition of ticket for which I am a contact but not the caller, unless I also deny the right to edit the Tickets for which I am the caller.

Other use cases

Limit to tickets of their team(s)

A similar usecase, would be to limit the Tickets visibility for a “Power Portal user” to those managed by his team(s).

SELECT Ticket AS T 
  JOIN Team AS G ON T.team_id = G.id 
  JOIN lnkPersonToTeam AS l ON l.team_id = G.id 
WHERE T.org_id = :current_contact->org_id 
  AND T.finalclass IN ('UserRequest', 'Incident') 
  AND l.person_id = :current_contact->id

Extend to Tickets of their sub-orgs

Another usecase, would be to extend the Tickets visibility for a “Power Portal user” to tickets of his sub-organizations as well.

SELECT Ticket AS T 
  JOIN Organization AS root AS T.org_id = root.id 
  JOIN Organization AS child ON child.parent_id BELOW root.id 
WHERE T.org_id = :current_contact->org_id 
  AND T.finalclass IN ('UserRequest', 'Incident') 
3_0_0/customization/portal_howto_change_scope.txt · Last modified: 2022/01/21 16:52 (external edit)
Back to top
Contact us