Rights - Revision history

Phanousk at 19:43, 13 June 2018

2018-06-13T19:43:07Z

← Older revision		Revision as of 15:43, 13 June 2018
Line 98:		Line 98:
	** [[Unprivileged]]		** [[Unprivileged]]
	** [[Privileged]]		** [[Privileged]]

	*** Team(group)		*** Team(group)
	**** SupportTeam(group)		**** SupportTeam(group)
Line 109:		Line 108:
	****** manager(user)		****** manager(user)
	****** ...		****** ...

	**** DevelopmentTeam(group)		**** DevelopmentTeam(group)
	***** team member(user)		***** team member(user)
Line 119:		Line 117:
	****** manager(user)		****** manager(user)
	****** ...		****** ...

	*** ExternalTeam		*** ExternalTeam
	*** Clients		*** Clients

Admin: 18 revisions imported

2016-04-06T20:36:19Z

18 revisions imported

← Older revision		Revision as of 16:36, 6 April 2016
(No difference)

54.77.146.59: /* Objects */

2014-09-16T06:58:51Z

Objects

← Older revision		Revision as of 02:58, 16 September 2014
Line 9:		Line 9:
	== Objects ==		== Objects ==

	RT manipulates different objects: [[Ticket]]s, [[Queue]]s, [[Scrip]]s, [[Template]]s, [[CustomField]]s, Users, [[Group]]s, etc. Each object takes a different place in the object tree. For example, scrips can either be global- or queue-specific, but tickets are always associated with a queue. Each object has a set of defined rights. To perform a particular action on an object, a user must have the appropriate rights. For example, if you want create a ticket in queue A, you should have the [[CreateTicket]] right on queue A (or on all queues). Other types of rights, such as [[AdminGroup]], are not queue-specific.		RT manipulates different objects: [[Ticket]]s, [[Queue]]s, [[Scrip]]s, [[Template]]s, [[CustomField]]s, Users, [[Group]]s, etc. Each object takes a different place in the object tree. For example, scrips can either be global- or queue-specific, but tickets are always associated with a queue. Each object has a set of defined rights. To perform a particular action on an object, a user must have the appropriate rights. For example, if you want to create a ticket in queue A, you should have the [[CreateTicket]] right on queue A (or on all queues). Other types of rights, such as [[AdminGroup]], are not queue-specific.

	In general, it is possible to grant each user rights on each small object like a scrip named 'foo' or a Template named 'bar.' But, such a setup would be difficult to maintain, and would require an overly-complex user interface. Instead, the RT user interface gives access to rights that are '''system-wide''', rights that can be assigned on a '''group by group''' basis, and other rights that can be assigned on a '''queue by queue''' basis. All objects have a context. For example, if Scrip A is a global scrip (system-wide), you can grant users rights on this object in the global context. Each right can be tied to more then one context and the interpretation of the right can be different in the different contexts. For example, the [[AdminQueue]] right in two different queues can be given to different groups of users.		In general, it is possible to grant each user rights on each small object like a scrip named 'foo' or a Template named 'bar.' But, such a setup would be difficult to maintain, and would require an overly-complex user interface. Instead, the RT user interface gives access to rights that are '''system-wide''', rights that can be assigned on a '''group by group''' basis, and other rights that can be assigned on a '''queue by queue''' basis. All objects have a context. For example, if Scrip A is a global scrip (system-wide), you can grant users rights on this object in the global context. Each right can be tied to more then one context and the interpretation of the right can be different in the different contexts. For example, the [[AdminQueue]] right in two different queues can be given to different groups of users.

150.101.52.20: /* Objects */

2012-05-25T05:05:29Z

Objects

← Older revision		Revision as of 01:05, 25 May 2012
Line 9:		Line 9:
	== Objects ==		== Objects ==

	RT manipulates different objects: [[Ticket]]s, [[Queue]]s, [[Scrip]]s, [[Template]]s, [[CustomField]]s, Users, [[Group]]s, etc. Each object takes a different place in the object tree. For example, ~~scripts~~ can either be global- or queue-specific, but tickets are always associated with a queue. Each object has a set of defined rights. To perform a particular action on an object, a user must have the appropriate rights. For example, if you want create a ticket in queue A, you should have the [[CreateTicket]] right on queue A (or on all queues). Other types of rights, such as [[AdminGroup]], are not queue-specific.		RT manipulates different objects: [[Ticket]]s, [[Queue]]s, [[Scrip]]s, [[Template]]s, [[CustomField]]s, Users, [[Group]]s, etc. Each object takes a different place in the object tree. For example, scrips can either be global- or queue-specific, but tickets are always associated with a queue. Each object has a set of defined rights. To perform a particular action on an object, a user must have the appropriate rights. For example, if you want create a ticket in queue A, you should have the [[CreateTicket]] right on queue A (or on all queues). Other types of rights, such as [[AdminGroup]], are not queue-specific.

	In general, it is possible to grant each user rights on each small object like a scrip named 'foo' or a Template named 'bar.' But, such a setup would be difficult to maintain, and would require an overly-complex user interface. Instead, the RT user interface gives access to rights that are '''system-wide''', rights that can be assigned on a '''group by group''' basis, and other rights that can be assigned on a '''queue by queue''' basis. All objects have a context. For example, if Scrip A is a global scrip (system-wide), you can grant users rights on this object in the global context. Each right can be tied to more then one context and the interpretation of the right can be different in the different contexts. For example, the [[AdminQueue]] right in two different queues can be given to different groups of users.		In general, it is possible to grant each user rights on each small object like a scrip named 'foo' or a Template named 'bar.' But, such a setup would be difficult to maintain, and would require an overly-complex user interface. Instead, the RT user interface gives access to rights that are '''system-wide''', rights that can be assigned on a '''group by group''' basis, and other rights that can be assigned on a '''queue by queue''' basis. All objects have a context. For example, if Scrip A is a global scrip (system-wide), you can grant users rights on this object in the global context. Each right can be tied to more then one context and the interpretation of the right can be different in the different contexts. For example, the [[AdminQueue]] right in two different queues can be given to different groups of users.

142.150.193.67: /* Public support queue */

2012-01-11T23:49:21Z

Public support queue

← Older revision		Revision as of 19:49, 11 January 2012
Line 31:		Line 31:
	* We should grant all users with [[CreateTicket]] on queue 'support'.		* We should grant all users with [[CreateTicket]] on queue 'support'.
	* '''Important:''' It's a public queue and users often use different email addresses to reply to same ticket, so if you don't grant [[Everyone]] with [[ReplyToTicket]] right then your users would have problems in such a case.		* '''Important:''' It's a public queue and users often use different email addresses to reply to same ticket, so if you don't grant [[Everyone]] with [[ReplyToTicket]] right then your users would have problems in such a case.
	* You don't need grant other system [[Group]]s with same rights because [[Everyone]] includes all users.		* You don't need to grant other system [[Group]]s with same rights because [[Everyone]] includes all users.
	* If some of your internal groups shouldn't have [[ReplyToTicket]] right, then you can assign it to [[Unprivileged]] and some internal groups.		* If some of your internal groups shouldn't have [[ReplyToTicket]] right, then you can assign it to [[Unprivileged]] and some internal groups.

BillCole: Reverted edits by 74.55.175.27 (talk | block) to last version by BillCole

2011-04-06T08:16:53Z

Reverted edits by 74.55.175.27 (talk | block) to last version by BillCole

← Older revision		Revision as of 04:16, 6 April 2011
Line 61:		Line 61:
	Also you can consider next schema with watchers: Customer sends request. Supporter can't resolve problem(unknown yet) on his own. He does standard things(request for more info, report with spec tool and so on from user), when supporter thinks that user has provided all needed info, he comments on ticket and at the same time adds developer as [[CC]].		Also you can consider next schema with watchers: Customer sends request. Supporter can't resolve problem(unknown yet) on his own. He does standard things(request for more info, report with spec tool and so on from user), when supporter thinks that user has provided all needed info, he comments on ticket and at the same time adds developer as [[CC]].

	Special [[CustomField]] where supporter can setup value which means "awaiting reply from developer" helps a lot too, because developer can search all tickets where he is watcher and ticket wait for his reply/comment. This CF can be filled with other useful ticket states. ~~[http://www.moralesvsmaidana.co.cc/2011/02/morales-vs-maidana-live-streaming/ maidana vs morales live streaming]~~		Special [[CustomField]] where supporter can setup value which means "awaiting reply from developer" helps a lot too, because developer can search all tickets where he is watcher and ticket wait for his reply/comment. This CF can be filled with other useful ticket states.

	[[AdminCC]]s can have more rights, for example reply directly to user with correspondence or modify ticket. It can be other teams who know standard reply forms and can solve particular problems or this role can be given to support department managers. If necessary grant [[Group]]s with [[WatchAsAdminCc]] right.		[[AdminCC]]s can have more rights, for example reply directly to user with correspondence or modify ticket. It can be other teams who know standard reply forms and can solve particular problems or this role can be given to support department managers. If necessary grant [[Group]]s with [[WatchAsAdminCc]] right.

74.55.175.27: /* Tricks with [CC]s/[AdminCC]s */

2011-04-05T09:49:27Z

Tricks with [CC]s/[AdminCC]s

← Older revision		Revision as of 05:49, 5 April 2011
Line 61:		Line 61:
	Also you can consider next schema with watchers: Customer sends request. Supporter can't resolve problem(unknown yet) on his own. He does standard things(request for more info, report with spec tool and so on from user), when supporter thinks that user has provided all needed info, he comments on ticket and at the same time adds developer as [[CC]].		Also you can consider next schema with watchers: Customer sends request. Supporter can't resolve problem(unknown yet) on his own. He does standard things(request for more info, report with spec tool and so on from user), when supporter thinks that user has provided all needed info, he comments on ticket and at the same time adds developer as [[CC]].

	Special [[CustomField]] where supporter can setup value which means "awaiting reply from developer" helps a lot too, because developer can search all tickets where he is watcher and ticket wait for his reply/comment. This CF can be filled with other useful ticket states.		Special [[CustomField]] where supporter can setup value which means "awaiting reply from developer" helps a lot too, because developer can search all tickets where he is watcher and ticket wait for his reply/comment. This CF can be filled with other useful ticket states. [http://www.moralesvsmaidana.co.cc/2011/02/morales-vs-maidana-live-streaming/ maidana vs morales live streaming]

	[[AdminCC]]s can have more rights, for example reply directly to user with correspondence or modify ticket. It can be other teams who know standard reply forms and can solve particular problems or this role can be given to support department managers. If necessary grant [[Group]]s with [[WatchAsAdminCc]] right.		[[AdminCC]]s can have more rights, for example reply directly to user with correspondence or modify ticket. It can be other teams who know standard reply forms and can solve particular problems or this role can be given to support department managers. If necessary grant [[Group]]s with [[WatchAsAdminCc]] right.

BillCole: Reverted edits by 174.37.16.81 (talk | block) to last version by BillCole

2011-03-03T17:36:37Z

Reverted edits by 174.37.16.81 (talk | block) to last version by BillCole

← Older revision		Revision as of 13:36, 3 March 2011
Line 81:		Line 81:
	* SupportTeam		* SupportTeam
	* SalesTeam		* SalesTeam
	* ...~~[http://www.thediamondtrade.com professional diamond buyer]~~		* ...add your own

	Department groups should be member of the "Team" top-level group. This allow you to grant all in your team with particular set of rights. If you don't add department group to the top-level group, then you have to add your new users into two groups at least to mark that user is a team member and works in specific department.		Department groups should be member of the "Team" top-level group. This allow you to grant all in your team with particular set of rights. If you don't add department group to the top-level group, then you have to add your new users into two groups at least to mark that user is a team member and works in specific department.

174.37.16.81: minor edit

2011-03-03T09:20:44Z

minor edit

← Older revision		Revision as of 05:20, 3 March 2011
Line 81:		Line 81:
	* SupportTeam		* SupportTeam
	* SalesTeam		* SalesTeam
	* ...~~add your own~~		* ...[http://www.thediamondtrade.com professional diamond buyer]

	Department groups should be member of the "Team" top-level group. This allow you to grant all in your team with particular set of rights. If you don't add department group to the top-level group, then you have to add your new users into two groups at least to mark that user is a team member and works in specific department.		Department groups should be member of the "Team" top-level group. This allow you to grant all in your team with particular set of rights. If you don't add department group to the top-level group, then you have to add your new users into two groups at least to mark that user is a team member and works in specific department.

BillCole: Reverted edits by 173.208.45.178 (talk | block) to last version by Jibsheet

2011-02-06T05:22:37Z

Reverted edits by 173.208.45.178 (talk | block) to last version by Jibsheet

← Older revision		Revision as of 01:22, 6 February 2011
Line 138:		Line 138:

	We hope this small article can help you understand concepts which are used in RT to manage user's rights. Feel free to fix spelling, grammar and other glitches and of course add your own solutions and ideas. Good luck.		We hope this small article can help you understand concepts which are used in RT to manage user's rights. Feel free to fix spelling, grammar and other glitches and of course add your own solutions and ideas. Good luck.

	~~Useful Links:~~

	* [http://www.foxypropaganda.com/services/ printing Fort Worth]
	* [http://www.foxypropaganda.com/variable-data/ variable data printing]
	* [http://www.foxypropaganda.com/ Fort Worth printing companies]
	~~stunt~~