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.

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

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.

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>

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

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

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.

A similar usecase, would be to limit the Tickets visibility for a “Power Portal user” to those managed by his tea🤦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

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') 

How to prevent a Portal User with Allowed Organizations to see Tickets belonging to sub-organizations of his Allowed Organizations.

• Out of the box, iTop cascade the access rights on sub-organizations of a User Allowed Organizations, and in 3.1.0 there are no way to prevent this.
• The below OQL scope is a workaround for Portal users to be strictly limited to their Allowed Organizations owned objects.
• Cautious: doing this will prevent a Portal User without Allowed Organizations to see any Tickets

SELECT Ticket AS T
  JOIN Organization AS O ON T.org_id=O.id
  JOIN URP_UserOrg AS AO ON AO.allowed_org_id=O.id
  JOIN USER AS U ON AO.userid = U.id
WHERE U.contactid = :current_contact_id
  AND T.finalclass IN ('UserRequest', 'Incident')