Re: [Trac] TICKET_MODIFY permission acting like TICKET_ADMIN
On Thursday, November 20, 2014 12:13:35 PM UTC-8, RjOllos wrote: > > > On Nov 20, 2014 12:11 PM, "Ryan Ollos" wrote: > > > > > > On Nov 20, 2014 11:57 AM, "Shawn Baker" wrote: > > > > > > I suppose it is possible that the Agilo plugin (which we are no longer > using) had permissions to not allow anyone but TICKET_ADMIN or the owner of > the ticket to change the status of the tickets. I really thought that Trac > would have something like this out of the box. It seems odd to me that > anyone who is authenticated in the system can change the status of any > ticket as they see fit. > > > > Right, with the default data that ships with trac authenticated users will > have TICKET_MODIFY and therefore be able to change tickets in the default > workflow . The aim is to impose as little on the user as possible, and let > users customize it for their needs. Usually it is simple to customize, but > it does get more complex with specialized requirements such as permissions > depending on ticket properties. If we receive repeated requests for certain > requirements we might try to bundle the functionality into tracopt or > sample-plugins. > > I'll probably add this permissions policy to the CookbBook pages in the > meantime. > Did a quick write-up in the CookBook: http://trac.edgewall.org/wiki/CookBook/PermissionPolicies Please add to or comment on it based on your experience using the permission policy. -- You received this message because you are subscribed to the Google Groups "Trac Users" group. To unsubscribe from this group and stop receiving emails from it, send an email to trac-users+unsubscr...@googlegroups.com. To post to this group, send email to trac-users@googlegroups.com. Visit this group at http://groups.google.com/group/trac-users. For more options, visit https://groups.google.com/d/optout.
Re: [Trac] TICKET_MODIFY permission acting like TICKET_ADMIN
On Thursday, November 20, 2014 12:24:07 PM UTC-8, Shawn Baker wrote: > > > > On Thursday, November 20, 2014 3:13:35 PM UTC-5, RjOllos wrote: >> >> >> On Nov 20, 2014 12:11 PM, "Ryan Ollos" wrote: >> > >> > >> > On Nov 20, 2014 11:57 AM, "Shawn Baker" wrote: >> > > >> > > I suppose it is possible that the Agilo plugin (which we are no >> longer using) had permissions to not allow anyone but TICKET_ADMIN or the >> owner of the ticket to change the status of the tickets. I really thought >> that Trac would have something like this out of the box. It seems odd to >> me that anyone who is authenticated in the system can change the status of >> any ticket as they see fit. >> > >> >> Right, with the default data that ships with trac authenticated users >> will have TICKET_MODIFY and therefore be able to change tickets in the >> default workflow . The aim is to impose as little on the user as possible, >> and let users customize it for their needs. Usually it is simple to >> customize, but it does get more complex with specialized requirements such >> as permissions depending on ticket properties. If we receive repeated >> requests for certain requirements we might try to bundle the functionality >> into tracopt or sample-plugins. >> >> I'll probably add this permissions policy to the CookbBook pages in the >> meantime. >> > > Do I just put the restrict_actions.py file in my plugins directory? I > don't need to do anything else with it? > Yes, that's all that is needed if you are running a single Trac environment. If you have multiple Trac environments (i.e. projects), then you might want to use the shared plugins directory: http://trac.edgewall.org/wiki/TracIni#inherit-section -- You received this message because you are subscribed to the Google Groups "Trac Users" group. To unsubscribe from this group and stop receiving emails from it, send an email to trac-users+unsubscr...@googlegroups.com. To post to this group, send email to trac-users@googlegroups.com. Visit this group at http://groups.google.com/group/trac-users. For more options, visit https://groups.google.com/d/optout.
Re: [Trac] TICKET_MODIFY permission acting like TICKET_ADMIN
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 20.11.2014 20:57, Shawn Baker wrote: > It seems odd to me that anyone who is authenticated in the system can > change the status of any ticket as they see fit. Less restriction doesn't yield a mess automatically. Fact remains, that this is how it works for a good number of projects. Personally I know community-driven as well as commercial ones, but the number of authenticated users varies a lot between all of them. The critical point is, that you can track changes all the time. Trac (timeline with RSS feed, individual change ticket/wiki/.. history) also with RSS feed, these are powerful ways of social control in good wiki common sense that work. Steffen Hoffmann -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.12 (GNU/Linux) iEYEARECAAYFAlRuTtcACgkQ31DJeiZFuHf6ngCdFw6oisLgXwvW/52EySIzXgRp 5PEAnjTAYvuZE2qrK7N8++NSowgfzsKx =lVpy -END PGP SIGNATURE- -- You received this message because you are subscribed to the Google Groups "Trac Users" group. To unsubscribe from this group and stop receiving emails from it, send an email to trac-users+unsubscr...@googlegroups.com. To post to this group, send email to trac-users@googlegroups.com. Visit this group at http://groups.google.com/group/trac-users. For more options, visit https://groups.google.com/d/optout.
Re: [Trac] TICKET_MODIFY permission acting like TICKET_ADMIN
On Thursday, November 20, 2014 3:13:35 PM UTC-5, RjOllos wrote: > > > On Nov 20, 2014 12:11 PM, "Ryan Ollos" > > wrote: > > > > > > On Nov 20, 2014 11:57 AM, "Shawn Baker" > wrote: > > > > > > I suppose it is possible that the Agilo plugin (which we are no longer > using) had permissions to not allow anyone but TICKET_ADMIN or the owner of > the ticket to change the status of the tickets. I really thought that Trac > would have something like this out of the box. It seems odd to me that > anyone who is authenticated in the system can change the status of any > ticket as they see fit. > > > > Right, with the default data that ships with trac authenticated users will > have TICKET_MODIFY and therefore be able to change tickets in the default > workflow . The aim is to impose as little on the user as possible, and let > users customize it for their needs. Usually it is simple to customize, but > it does get more complex with specialized requirements such as permissions > depending on ticket properties. If we receive repeated requests for certain > requirements we might try to bundle the functionality into tracopt or > sample-plugins. > > I'll probably add this permissions policy to the CookbBook pages in the > meantime. > Do I just put the restrict_actions.py file in my plugins directory? I don't need to do anything else with it? -- You received this message because you are subscribed to the Google Groups "Trac Users" group. To unsubscribe from this group and stop receiving emails from it, send an email to trac-users+unsubscr...@googlegroups.com. To post to this group, send email to trac-users@googlegroups.com. Visit this group at http://groups.google.com/group/trac-users. For more options, visit https://groups.google.com/d/optout.
Re: [Trac] TICKET_MODIFY permission acting like TICKET_ADMIN
On Nov 20, 2014 12:11 PM, "Ryan Ollos" wrote: > > > On Nov 20, 2014 11:57 AM, "Shawn Baker" wrote: > > > > I suppose it is possible that the Agilo plugin (which we are no longer using) had permissions to not allow anyone but TICKET_ADMIN or the owner of the ticket to change the status of the tickets. I really thought that Trac would have something like this out of the box. It seems odd to me that anyone who is authenticated in the system can change the status of any ticket as they see fit. > Right, with the default data that ships with trac authenticated users will have TICKET_MODIFY and therefore be able to change tickets in the default workflow . The aim is to impose as little on the user as possible, and let users customize it for their needs. Usually it is simple to customize, but it does get more complex with specialized requirements such as permissions depending on ticket properties. If we receive repeated requests for certain requirements we might try to bundle the functionality into tracopt or sample-plugins. I'll probably add this permissions policy to the CookbBook pages in the meantime. -- You received this message because you are subscribed to the Google Groups "Trac Users" group. To unsubscribe from this group and stop receiving emails from it, send an email to trac-users+unsubscr...@googlegroups.com. To post to this group, send email to trac-users@googlegroups.com. Visit this group at http://groups.google.com/group/trac-users. For more options, visit https://groups.google.com/d/optout.
Re: [Trac] TICKET_MODIFY permission acting like TICKET_ADMIN
I did not post the entire workflow in my original email, only the workflow sufficient for a ticket in the "new" state. I definitely have states to move tickets out of accepted and any other state. On Thursday, November 20, 2014 10:34:21 AM UTC-5, RjOllos wrote: > > > First a side note. Your "new_accepted" action seems to be a "dead-end". > You don't show any actions that could move your ticket out of the accepted > state. Insert [[Workflow]] into a wiki page and you can see that there are > no transitions out of the accepted state with your workflow. There also > aren't any actions to move a ticket out of the closed state, e.g. reopen. > Thanks a lot for the permission policy. I will take a look at it and see how it works out. On Thursday, November 20, 2014 10:34:21 AM UTC-5, RjOllos wrote: > With the permission policy I'll propose, you'll need to define additional > workflow actions that would allow someone with higher permissions to deal > with tickets that don't have an owner, or have an owner that won't do any > work on the ticket. That is, unless you've configured your system to avoid > every one of these situations. For example, you may want to also allow > someone with TICKET_ADMIN to perform all the workflow action. Just append > TICKET_ADMIN to the permissions attribute of each workflow action you want > to allow, e.g. > > new_reassign.permissions = TICKET_CHANGE_STATE, TICKET_ADMIN > > To implement the permissions policy: > > Add RestrictTicketActionsPolicy to the permission_policies in the [trac] > section of trac.ini: permission_policies = RestrictTicketActions, > DefaultPermissionPolicy, LegacyAttachmentPolicy > > If you are using finer-grained policies such as AuthzPolicy, they may need > to go before RestrictTicketActions. > > Grant TICKET_CHANGE_STATE to users that should be able to change the > states of tickets that they own. This might be all authenticated users. > > > Copy the following into a file named restrict_actions.py in your > environment or shared plugins directory: > > # -*- coding: utf-8 -*- > # > # Copyright (C) 2014 Edgewall Software > # All rights reserved. > # > # This software is licensed as described in the file COPYING, which > # you should have received as part of this distribution. The terms > # are also available at http://trac.edgewall.org/wiki/TracLicense. > # > # This software consists of voluntary contributions made by many > # individuals. For the exact contribution history, see the revision > # history and logs, available at http://trac.edgewall.org/log/. > > from trac.core import * > from trac.perm import IPermissionPolicy, IPermissionRequestor > from trac.ticket.model import Ticket > > > class RestrictTicketActionsPolicy(Component): > """Provides a permission for restricting ticket actions to the > ticket owner. > """ > > implements(IPermissionPolicy, IPermissionRequestor) > > # IPermissionRequestor methods > > def get_permission_actions(self): > return ['TICKET_CHANGE_STATE'] > > # IPermissionPolicy methods > > def check_permission(self, action, username, resource, perm): > if action == 'TICKET_CHANGE_STATE' \ > and resource is not None \ > and resource.realm == 'ticket' \ > and resource.id is not None: > ticket = Ticket(self.env, resource.id) > return ticket['owner'] == username > return None > > > > > > -- You received this message because you are subscribed to the Google Groups "Trac Users" group. To unsubscribe from this group and stop receiving emails from it, send an email to trac-users+unsubscr...@googlegroups.com. To post to this group, send email to trac-users@googlegroups.com. Visit this group at http://groups.google.com/group/trac-users. For more options, visit https://groups.google.com/d/optout.
Re: [Trac] TICKET_MODIFY permission acting like TICKET_ADMIN
On Thursday, November 20, 2014 10:34:21 AM UTC-5, RjOllos wrote: > > First a side note. Your "new_accepted" action seems to be a "dead-end". > You don't show any actions that could move your ticket out of the accepted > state. Insert [[Workflow]] into a wiki page and you can see that there are > no transitions out of the accepted state with your workflow. There also > aren't any actions to move a ticket out of the closed state, e.g. reopen. > I did not post the entire workflow in my original email, only the workflow sufficient for a ticket in the "new" state. I definitely have states to move tickets out of accepted and any other state. On Thursday, November 20, 2014 10:34:21 AM UTC-5, RjOllos wrote: > With the permission policy I'll propose, you'll need to define additional > workflow actions that would allow someone with higher permissions to deal > with tickets that don't have an owner, or have an owner that won't do any > work on the ticket. That is, unless you've configured your system to avoid > every one of these situations. For example, you may want to also allow > someone with TICKET_ADMIN to perform all the workflow action. Just append > TICKET_ADMIN to the permissions attribute of each workflow action you want > to allow, e.g. > > new_reassign.permissions = TICKET_CHANGE_STATE, TICKET_ADMIN > > To implement the permissions policy: > > Add RestrictTicketActionsPolicy to the permission_policies in the [trac] > section of trac.ini: permission_policies = RestrictTicketActions, > DefaultPermissionPolicy, LegacyAttachmentPolicy > > If you are using finer-grained policies such as AuthzPolicy, they may need > to go before RestrictTicketActions. > > Grant TICKET_CHANGE_STATE to users that should be able to change the > states of tickets that they own. This might be all authenticated users. > > > Copy the following into a file named restrict_actions.py in your > environment or shared plugins directory: > > # -*- coding: utf-8 -*- > # > # Copyright (C) 2014 Edgewall Software > # All rights reserved. > # > # This software is licensed as described in the file COPYING, which > # you should have received as part of this distribution. The terms > # are also available at http://trac.edgewall.org/wiki/TracLicense. > # > # This software consists of voluntary contributions made by many > # individuals. For the exact contribution history, see the revision > # history and logs, available at http://trac.edgewall.org/log/. > > from trac.core import * > from trac.perm import IPermissionPolicy, IPermissionRequestor > from trac.ticket.model import Ticket > > > class RestrictTicketActionsPolicy(Component): > """Provides a permission for restricting ticket actions to the > ticket owner. > """ > > implements(IPermissionPolicy, IPermissionRequestor) > > # IPermissionRequestor methods > > def get_permission_actions(self): > return ['TICKET_CHANGE_STATE'] > > # IPermissionPolicy methods > > def check_permission(self, action, username, resource, perm): > if action == 'TICKET_CHANGE_STATE' \ > Thanks a lot, I will take a look at this. I will let you know how it works out. > and resource is not None \ > and resource.realm == 'ticket' \ > and resource.id is not None: > ticket = Ticket(self.env, resource.id) > return ticket['owner'] == username > return None > > > > > > -- You received this message because you are subscribed to the Google Groups "Trac Users" group. To unsubscribe from this group and stop receiving emails from it, send an email to trac-users+unsubscr...@googlegroups.com. To post to this group, send email to trac-users@googlegroups.com. Visit this group at http://groups.google.com/group/trac-users. For more options, visit https://groups.google.com/d/optout.
Re: [Trac] TICKET_MODIFY permission acting like TICKET_ADMIN
I suppose it is possible that the Agilo plugin (which we are no longer using) had permissions to not allow anyone but TICKET_ADMIN or the owner of the ticket to change the status of the tickets. I really thought that Trac would have something like this out of the box. It seems odd to me that anyone who is authenticated in the system can change the status of any ticket as they see fit. On Thursday, November 20, 2014 9:16:30 AM UTC-5, RjOllos wrote: > > The behavior you are seeing looks like what I'd expect for the > configuration you've shown. There's nothing to limit the ticket workflow > actions to tickets for which the user is the owner. That would require a > plugin with a custom permissions policy. Nothing has changed in that regard > since 0.11 as far as I know. I'll post an example shortly. > -- You received this message because you are subscribed to the Google Groups "Trac Users" group. To unsubscribe from this group and stop receiving emails from it, send an email to trac-users+unsubscr...@googlegroups.com. To post to this group, send email to trac-users@googlegroups.com. Visit this group at http://groups.google.com/group/trac-users. For more options, visit https://groups.google.com/d/optout.
Re: [Trac] TICKET_MODIFY permission acting like TICKET_ADMIN
On Thu, Nov 20, 2014 at 6:16 AM, Ryan Ollos wrote: > > On Nov 20, 2014 5:49 AM, "Shawn Baker" wrote: > > > > I recently upgraded from a Trac 0.11 server to 1.0.2. I am seeing what > I think is weird behavior for ticket permissions. > > > > I have a "new" ticket that my user submitted (user1). Trac is setup to > default the ticket ownership to a specific user (user2). So user1 is the > reporter, but and user2 is currently owner of this ticket. However, I have > the following ticket modification options available to user1: > > Leave as new The owner will remain user2. > > Accept. Next status will be 'accepted'. > > Reassign to . The owner will be changed from user2 to > the selected user. Next status will be 'new'. > > Requires more information and assign to . The owner will > be changed from user2 to the selected user. Next status will be 'needinfo'. > > Close as . The resolution will be set. Next status > will be 'closed'. > > > > These are the permissions for user1: > > TICKET_APPEND, TICKET_CHGPROP, TICKET_CREATE, TICKET_MODIFY, TICKET_VIEW > > > > This is the workflow for a ticket in this status: > > new_accepted = new,needinfo, reopened -> accepted > > new_accepted.default = 3 > > new_accepted.name = Accept. > > new_accepted.permissions = TICKET_MODIFY > > new_needinfo = new -> needinfo > > new_needinfo.default = 1 > > new_needinfo.name = Requires more information and assign > > new_needinfo.operations = set_owner > > new_needinfo.permissions = TICKET_MODIFY > > new_reassign = new -> new > > new_reassign.default = 2 > > new_reassign.name = Reassign > > new_reassign.operations = set_owner > > new_reassign.permissions = TICKET_MODIFY > > leave = * -> * > > leave.default = 4 > > leave.name = Leave > > leave.operations = leave_status > > closed = new,needinfo,reopened,open -> closed > > closed.default = 0 > > closed.name = Close > > closed.operations = set_resolution > > closed.permissions = TICKET_MODIFY > > closed.set_resolution = wontfix,invalid,duplicate,limitation > > > > So, my question, am I missing something with Trac 1.0.2 to disallow > users from changing the status of tickets other than their own? > > > > Thanks for any help, > > Shawn > > The behavior you are seeing looks like what I'd expect for the > configuration you've shown. There's nothing to limit the ticket workflow > actions to tickets for which the user is the owner. That would require a > plugin with a custom permissions policy. Nothing has changed in that regard > since 0.11 as far as I know. I'll post an example shortly. > First a side note. Your "new_accepted" action seems to be a "dead-end". You don't show any actions that could move your ticket out of the accepted state. Insert [[Workflow]] into a wiki page and you can see that there are no transitions out of the accepted state with your workflow. There also aren't any actions to move a ticket out of the closed state, e.g. reopen. With the permission policy I'll propose, you'll need to define additional workflow actions that would allow someone with higher permissions to deal with tickets that don't have an owner, or have an owner that won't do any work on the ticket. That is, unless you've configured your system to avoid every one of these situations. For example, you may want to also allow someone with TICKET_ADMIN to perform all the workflow action. Just append TICKET_ADMIN to the permissions attribute of each workflow action you want to allow, e.g. new_reassign.permissions = TICKET_CHANGE_STATE, TICKET_ADMIN To implement the permissions policy: Add RestrictTicketActionsPolicy to the permission_policies in the [trac] section of trac.ini: permission_policies = RestrictTicketActions, DefaultPermissionPolicy, LegacyAttachmentPolicy If you are using finer-grained policies such as AuthzPolicy, they may need to go before RestrictTicketActions. Grant TICKET_CHANGE_STATE to users that should be able to change the states of tickets that they own. This might be all authenticated users. Copy the following into a file named restrict_actions.py in your environment or shared plugins directory: # -*- coding: utf-8 -*- # # Copyright (C) 2014 Edgewall Software # All rights reserved. # # This software is licensed as described in the file COPYING, which # you should have received as part of this distribution. The terms # are also available at http://trac.edgewall.org/wiki/TracLicense. # # This software consists of voluntary contributions made by many # individuals. For the exact contribution history, see the revision # history and logs, available at http://trac.edgewall.org/log/. from trac.core import * from trac.perm import IPermissionPolicy, IPermissionRequestor from trac.ticket.model import Ticket class RestrictTicketActionsPolicy(Component): """Provides a permission for restricting ticket actions to the ticket owner. """ implements(IPermissionPolicy, IPermissionRequestor) # IPermissionRequestor methods def get_permission_actions(self):
Re: [Trac] TICKET_MODIFY permission acting like TICKET_ADMIN
On Nov 20, 2014 5:49 AM, "Shawn Baker" wrote: > > I recently upgraded from a Trac 0.11 server to 1.0.2. I am seeing what I think is weird behavior for ticket permissions. > > I have a "new" ticket that my user submitted (user1). Trac is setup to default the ticket ownership to a specific user (user2). So user1 is the reporter, but and user2 is currently owner of this ticket. However, I have the following ticket modification options available to user1: > Leave as new The owner will remain user2. > Accept. Next status will be 'accepted'. > Reassign to . The owner will be changed from user2 to the selected user. Next status will be 'new'. > Requires more information and assign to . The owner will be changed from user2 to the selected user. Next status will be 'needinfo'. > Close as . The resolution will be set. Next status will be 'closed'. > > These are the permissions for user1: > TICKET_APPEND, TICKET_CHGPROP, TICKET_CREATE, TICKET_MODIFY, TICKET_VIEW > > This is the workflow for a ticket in this status: > new_accepted = new,needinfo, reopened -> accepted > new_accepted.default = 3 > new_accepted.name = Accept. > new_accepted.permissions = TICKET_MODIFY > new_needinfo = new -> needinfo > new_needinfo.default = 1 > new_needinfo.name = Requires more information and assign > new_needinfo.operations = set_owner > new_needinfo.permissions = TICKET_MODIFY > new_reassign = new -> new > new_reassign.default = 2 > new_reassign.name = Reassign > new_reassign.operations = set_owner > new_reassign.permissions = TICKET_MODIFY > leave = * -> * > leave.default = 4 > leave.name = Leave > leave.operations = leave_status > closed = new,needinfo,reopened,open -> closed > closed.default = 0 > closed.name = Close > closed.operations = set_resolution > closed.permissions = TICKET_MODIFY > closed.set_resolution = wontfix,invalid,duplicate,limitation > > So, my question, am I missing something with Trac 1.0.2 to disallow users from changing the status of tickets other than their own? > > Thanks for any help, > Shawn The behavior you are seeing looks like what I'd expect for the configuration you've shown. There's nothing to limit the ticket workflow actions to tickets for which the user is the owner. That would require a plugin with a custom permissions policy. Nothing has changed in that regard since 0.11 as far as I know. I'll post an example shortly. -- You received this message because you are subscribed to the Google Groups "Trac Users" group. To unsubscribe from this group and stop receiving emails from it, send an email to trac-users+unsubscr...@googlegroups.com. To post to this group, send email to trac-users@googlegroups.com. Visit this group at http://groups.google.com/group/trac-users. For more options, visit https://groups.google.com/d/optout.
[Trac] TICKET_MODIFY permission acting like TICKET_ADMIN
I recently upgraded from a Trac 0.11 server to 1.0.2. I am seeing what I think is weird behavior for ticket permissions. I have a "new" ticket that my user submitted (user1). Trac is setup to default the ticket ownership to a specific user (user2). So user1 is the reporter, but and user2 is currently owner of this ticket. However, I have the following ticket modification options available to user1: Leave as new The owner will remain user2. Accept. Next status will be 'accepted'. Reassign to . The owner will be changed from user2 to the selected user. Next status will be 'new'. Requires more information and assign to . The owner will be changed from user2 to the selected user. Next status will be 'needinfo'. Close as . The resolution will be set. Next status will be 'closed'. These are the permissions for user1: TICKET_APPEND, TICKET_CHGPROP, TICKET_CREATE, TICKET_MODIFY, TICKET_VIEW This is the workflow for a ticket in this status: new_accepted = new,needinfo, reopened -> accepted new_accepted.default = 3 new_accepted.name = Accept. new_accepted.permissions = TICKET_MODIFY new_needinfo = new -> needinfo new_needinfo.default = 1 new_needinfo.name = Requires more information and assign new_needinfo.operations = set_owner new_needinfo.permissions = TICKET_MODIFY new_reassign = new -> new new_reassign.default = 2 new_reassign.name = Reassign new_reassign.operations = set_owner new_reassign.permissions = TICKET_MODIFY leave = * -> * leave.default = 4 leave.name = Leave leave.operations = leave_status closed = new,needinfo,reopened,open -> closed closed.default = 0 closed.name = Close closed.operations = set_resolution closed.permissions = TICKET_MODIFY closed.set_resolution = wontfix,invalid,duplicate,limitation So, my question, am I missing something with Trac 1.0.2 to disallow users from changing the status of tickets other than their own? Thanks for any help, Shawn -- You received this message because you are subscribed to the Google Groups "Trac Users" group. To unsubscribe from this group and stop receiving emails from it, send an email to trac-users+unsubscr...@googlegroups.com. To post to this group, send email to trac-users@googlegroups.com. Visit this group at http://groups.google.com/group/trac-users. For more options, visit https://groups.google.com/d/optout.
