[rt-users] Multi tenancy Queue names

[aniket tripathy]

Hi,

Our organization is planning to have multiple tenants in the same RT
instance.

Say we are an organization X, our clients are businesses of similar types
X1, X2... Xn, who in turn have their customers.

We want to host X1, X2... X5 in one RT instance, with each client having
its own set of queues and we will be having several such RT instances
hosting multiple such clients.
We have to maintain queues(like Travel, Admin, HR etc) with the same names
for all the clients.
A single RT instance won't allow multiple queues with the same name.
So, we would be naming our queues as _HR,_Admin,
_Travel etc. But we don't want to display the tenantId in the
UI, we just want to display them as HR, Travel and Admin to the end-users.

Has anyone ever tried this approach or has suggestions how to go about it?

 Any other approaches to handle multi tenancy are most welcome.


Thanks!!!
-
RT 4.4 and RTIR Training Sessions https://bestpractical.com/training
* Los Angeles - September, 2016

[rt-users] Custom Role for Approval Mechanism

[Aniket Tripathy]

Hi Everybody,
Problem statement:

 In our organization, out of the 20 queues, few queues need the approval
mechanism. Approvals are required for specific tickets in the queue, based
on scenarios decided by the staff member of the queue. So approvers are not
added at the time of ticket creation. Example: the travel queue ticket needs
approval from the requestors' manager only when the travelling cost is high.
Approach

We are taking the following approach, would invite suggestions, enhancement
and problems(if any) with this approach1.We are adding a new CustomRole
called Approver(multiple values) to each of the queues. 2.The queue staff
adds the approver, if necessary, in the people's page after the ticket is
created3. A scrip to add ticket in the approval queue whenever an approver
is added.
Scenarios

We are handling 3 scenarios:
1. *Single approver*: Once the approver is added,in the user field, an
approval ticket is created and assigned to the approver.
2. *Multiple approvers(need approval from all of them)*. Similar to step 1.
add Multiple approvers and that many approval tickets are created, with each
approver being the owner of the ticket.
3. *Multiple approvers(approval from any one will do).* We have assumed, if
approval from any one will do , they should belong to a particular group,
and have equal say in matters. So we add them in the group field. In the
scrips the logic is, if the approver is a group, then all the members of the
group are added as the AdminCc of the single approval ticket created and any
one can approve and close that ticket.
Please suggest pros and cons of this approach.
Thanks!



--
View this message in context: 
http://requesttracker.8502.n7.nabble.com/Custom-Role-for-Approval-Mechanism-tp62003.html
Sent from the Request Tracker - User mailing list archive at Nabble.com.-
RT 4.4 and RTIR Training Sessions https://bestpractical.com/training
* Los Angeles - September, 2016