I found my problem. I need brackets instead of the parens in
mypermissions.py
I changed it to have brackets and placed the mypermissions.py in the
plugins directory.
The Trac / Admin / Permission now has it included.
Now I can install the modified trac.ini file.
On Feb 13, 10:34 am, gctrekker <gctrek...@gmail.com> wrote:
> I am trying to add TICKET_CLOSE as a new permission. I tried what was
> listed in this thread from the archive (shown at end of this posting)
> but it does not work for me.
> The thread said it was a bad idea to "hack" the database with the
> "INSERT INTO permission" commands and said to use a simple plugin.
>
> -------------------------------------------
> I stopped our apache2 driver.
> I added a mypermissions.py into our <track environment>/plugins
> directory, here is the contents:
>
> # mypermissions.py
> #
> # Use to add other permissions.
> #
> # Using to add a TICKET_CLOSE permission.
> #
> # Drop this file in the plugins directory, restart the server,
> # and the permission(s) should be available. According to
> # what I have found in the Trac Users group under Google groups.
>
> from trac.core import Component, implements
> from trac.perm import IPermissionRequestor
>
> class MyPermissions(Component):
> implements(IPermissionRequestor)
>
> def get_permission_actions(self):
> # return ('MY_FIRST_PERM', 'MY_SECOND_PERM')
> return ('TICKET_CLOSE')
>
> -------------------------------------
> I modified the trac.ini [components] and [ticket-workflow]; here are
> the diffs:
>
> > diff trac.ini trac_TICKET_CLOSE.ini
> 34a35
> > mypermissions.* = enabled
>
> 181c182
> < close.permissions = TICKET_ADMIN
> ---> close.permissions = TICKET_CLOSE
>
> 186c187
> < close_new.permissions = TICKET_ADMIN
> ---
>
> > close_new.permissions = TICKET_CLOSE
>
> -----------------------------------------
> I restarted apache2 and things did not work.
> I got an "Oops... " when trying to view an issue that said, "Trac
> detected an internal error: IndexError: string index out of range"
>
> The trac.log file had this added after attempting to view the issue:
>
> 2009-02-13 07:23:27,291 Trac[main] ERROR: string index out of range
> Traceback (most recent call last):
> File "/usr/local/lib64/python2.5/site-packages/Trac-0.11.2-py2.5.egg/
> trac/web/main.py", line 432, in _dispatch_request
> dispatcher.dispatch(req)
> File "/usr/local/lib64/python2.5/site-packages/Trac-0.11.2-py2.5.egg/
> trac/web/main.py", line 204, in dispatch
> resp = chosen_handler.process_request(req)
> File "/usr/local/lib64/python2.5/site-packages/Trac-0.11.2-py2.5.egg/
> trac/ticket/web_ui.py", line 181, in process_request
> return self._process_ticket_request(req)
> File "/usr/local/lib64/python2.5/site-packages/Trac-0.11.2-py2.5.egg/
> trac/ticket/web_ui.py", line 530, in _process_ticket_request
> get_reporter_id(req, 'author'), field_changes)
> File "/usr/local/lib64/python2.5/site-packages/Trac-0.11.2-py2.5.egg/
> trac/ticket/web_ui.py", line 1168, in _insert_ticket_data
> fields = self._prepare_fields(req, ticket)
> File "/usr/local/lib64/python2.5/site-packages/Trac-0.11.2-py2.5.egg/
> trac/ticket/web_ui.py", line 1080, in _prepare_fields
> TicketSystem(self.env).eventually_restrict_owner(field, ticket)
> File "/usr/local/lib64/python2.5/site-packages/Trac-0.11.2-py2.5.egg/
> trac/ticket/api.py", line 320, in eventually_restrict_owner
> .get_users_with_permission('TICKET_MODIFY'):
> File "/usr/local/lib64/python2.5/site-packages/Trac-0.11.2-py2.5.egg/
> trac/perm.py", line 384, in get_users_with_permission
> for child in action[1]:
> IndexError: string index out of range
>
> ---------------------------------
> When I used Trac / Admin / Permission and looked at the permission
> selections, I saw things like:
>
> BROWSER_VIEW
> C
> C
> CHANGESET_VIEW
> CONFIG_FILE
> E
> E
> EMIAL_VIEW
> FILE_VIEW
> I
> K
> L
> LOG_VIEW
> and it goes on
>
> ---------------------------------------
> I quickly stopped apache2, restored the trac.ini to what it had been,
> and removed mypermissions.py and .pyc files from the plugin directory
> and restarted apache2.
>
> I do not understand what the mypermissions.py file is doing.
>
> What am I missing or doing wrong? Is the mypermissions.py script
> correct? Is my entry in the script for 'TICKET_CLOSE' correct? Do I
> need brackets instead of parens since I am only adding one value?
>
> Thanks in advance.
>
> On Oct 8 2008, 7:36 am, yoh...@gmail.com wrote:
>
> > On Oct 8, 7:19 am, Jean Marie <jeanmari...@gmx.net> wrote:
>
> > > > > First you need to create new permission, e.g. TICKET_CLOSE.
>
> > > > How can i do this?
>
> > > I found an intermediate solution by "hacking" the database:
>
> > > INSERT INTO permission (username, action) VALUES ("group_qa",
> > > "TICKET_CLOSE");
>
> > > After this, the manuall added permissions assignment is visible in the
> > > admin section and also the trac-admin shows me this assignment.
>
> > > In trac.ini i've set:
> > > [ticket-workflow]
> > > close.permissions = TICKET_CLOSE
>
> > > Now only users that are members of group "group_qa" are able to close
> > > a ticket.
>
> > > For the moment this solution is fine by me. Are there any doubts about
> > > this solution?
>
> > > Maybe there'll be a more elegant way of adding user defined
> > > permissions.
>
> > > Best regards
> > > Jean Marie
>
> > AHH, bad idea.
>
> > stated about 3 responses up :
>
> > >And to create your own permissions :
> > >http://nil.checksite.co.uk/post.cfm/trac-0-11-creating-your-own-permi...
>
> > again, note his code isn't formatted properly for python on that web
> > site.
>
> > in this
> > thread:http://groups.google.com/group/trac-users/browse_thread/thread/79b118...
> > I posted a copy of it, which "should" be formatted. however, it is
> > a google email group, so ymmv
>
> > create that python file (modified for your permission(s) , drop it in
> > your plugins directory, restart your server, and you should be good
> > to go. you may need to enable the plugin in the web admin, I forget.
>
> > additionally, you MAY want to take a look at the "enterprise-workflow"
> > in the contrib directory, which has a resloved->verfied type workflow,
> > plus a special ticket handler to prevent the person that resolved a
> > ticket from verifying it. Maybe combine the 2.
>
> > we implement a custom workflow with resolved->verified. but we don't
> > enforce who verifies, since this step is basically author testing/
> > verification it was merged into the trunk. we have a separate qa step
> > that tests irrespective of tickets.
--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups "Trac
Users" group.
To post to this group, send email to trac-users@googlegroups.com
To unsubscribe from this group, send email to
trac-users+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/trac-users?hl=en
-~----------~----~----~----~------~----~------~--~---
