Domain Separation for MSP and SLAs - email updates can result in a duplicate task_sla record being generated.

If your domain structure is set up so your IT staff is at a higher level in the hierarchy than the customers, and the customers are in a child domain (and don't have roles, either), you get the following behavior:
1. The IT staff can open incidents, and the incident will be in the IT staff domain, and so will the associated task_sla record.
2. They can then set the caller to a customer in the child domain.
3. When customer-visible comments are put into the incident, the customer will get an email that they can respond to.
4. When the email update is applied to the ticket, it cannot see the existing task_sla record so a new (duplicate) task_sla is generated in the global domain.

Note that this customer cannot see the incident directly in the client because it is in a parent domain; but updates via email are permitted.

It would make more sense if the update created the new task_sla in the child customer domain, but it is confusing when it is put in at the global domain level, because this implies that the update should have interpreted the task_sla record.

Steps to Reproduce

  1. Activate the Domain Separation for MSP plugin.
  2. Go to Domain Admin > Configuration, and set the following three properties to Yes and leave the others set to No.
  3. Enable domain separation. Select Yes.
  4. Enable delegated administration. Select Yes.
  5. Use the domain of the record being viewed instead of the user's own. Select Yes
  6. Under Domain Admin > Domains, create two new domains: TOP/HelpdeskTOP/Helpdesk/Customers.
  7. Create a new contract_sla definition for any incident: start condition is active is true, stop condition is incident is resolved/closed, retroactive start on created, schedule 8-5 weekdays excluding holidays, and put it in the TOP/Helpdesk domain.
  8. Set a base system ITIL user to TOP/Helpdesk, and set one of the non-role users to TOP/Helpdesk/Customers.
  9. Use Datacenter to enable the instance for email, and once it is enabled, ensure the Email properties are set up to send/receive emails.
  10. Impersonate the ITIL user, open a new incident, assign it to the ITIL user, and set the caller to the ITIL user. Note: This results in a new incident with an associated task_sla in the TOP/Helpdesk domain.
  11. Now, as the ITIL user, change the assignee to the non-role user, and put in customer-visible Additional Comments; this will cause the email to be sent to the non-role user.
  12. When you get the email, reply to it - the response will update the incident.

ERROR: Note that you will now have a duplicate task_sla record; it will be in the global domain, and the sys_created_by will be the non-role user and the sys_created_on will match the email update.


This issue was fixed in Fuji.

Related Problem: PRB597188

Seen In

Calgary Patch 2 Hot Fix 5
Calgary Patch 3 Hot Fix 1
Dublin EA 8
Eureka Patch 5
Eureka Patch 8
Fuji Patch 10

Fixed In


Associated Community Threads

There is no data to report.

Article Information

Last Updated:2016-07-11 14:23:58