Sidebar

Using iTop

Creating your iTop

iTop Customization

"How to" examples
DataModel

User Interface

Automation & Ticket management

Portal Customization

:: Version 3.2.0 ::

Changing what can be seen on Portal

Question: How to change the default display mode for the Service catalog

  <module_design id="itop-portal" _delta="must_exist">
    <bricks>
      <brick id="services" xsi:type="Combodo\iTop\Portal\Brick\BrowseBrick" _delta="must_exist">
        <browse_modes>
          <default _delta="redefine">mosaic</default>
        </browse_modes>
      </brick>
    </bricks>

Question: How to allow a Support Agent to handle Tickets in the Portal?

See also this other tutorial: Allow to see more or less Tickets

The usecase is the following: You have a main provider organization, offering services, and multiple organizations buying those services, out of those clients, some do have teams and agents which do contribute to the Delivery Model of the main organization Services, but limited to tickets created for their organization as the client. We don't want to let those agents see other customers, nor see all tickets of the Main organization.

If they use the console only, they are unable to create Ticket for their organization as they don't see the Services. If they use the Portal, it needs to be modified for them to see the Delivery Model teams and agents, in order to be able to dispatch and assign the tickets outside of their organization

First part to allow them to be able to create a Ticket in New state without being forced to Dispatch or Assign it directly

  <module_design id="itop-portal" _delta="must_exist">
    <forms>
      <form id="ticket-create" _delta="must_exist">
        <properties _delta="define_if_not_exists">
          <always_show_submit _delta="force">true</always_show_submit>
        </properties>
      </form>
    </forms>
    <classes>
      <class id="Contact" _delta="must_exist">
        <scopes>
          <scope id="agents" _delta="define">
            <oql_view><![CDATA[SELECT Contact ... ]]></oql_view>
            <ignore_silos _delta="force">true</ignore_silos>
            <allowed_profiles>
              <allowed_profile id="Support Agent"/>
            </allowed_profiles>
          </scope>
        </scopes>
      </class>
    </classes>
  </module_design>

Query to use to enable agents to see teams and persons required to Dispatch and Assign tickets to the Delivery Model teams and agents when they aren't all part of the user organization. If they are all, this scope is useless, the standard would work:

SELECT Contact AS c 
  JOIN lnkPersonToTeam AS l2 ON l2.person_id = c.id
  JOIN Team AS t ON l2.team_id=t.id 
  JOIN lnkDeliveryModelToContact AS l1 ON l1.contact_id=t.id 
  JOIN DeliveryModel AS dm ON l1.deliverymodel_id=dm.id 
  JOIN Organization AS o ON o.deliverymodel_id=dm.id 
  WHERE o.id = :current_contact->org_id 
UNION SELECT Contact AS c 
  JOIN lnkDeliveryModelToContact AS l1 ON l1.contact_id=c.id 
  JOIN DeliveryModel AS dm ON l1.deliverymodel_id=dm.id 
  JOIN Organization AS o ON o.deliverymodel_id=dm.id 
  WHERE o.id = :current_contact->org_id

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

Tickets of Allowed org without cascading

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')
3_2_0/customization/portal_howto_changescope.txt · Last modified: 2024/06/20 17:28 (external edit)
Back to top
Contact us