support milestones

[GoogleCodeExporter]

Describe the enhancement in detail.
Implement support for milestones: view, create, edit. 

What files will be affected?
tracshell/shell.py
tracshell/trac.py

How will the enhancement benefit the project?
Will provide users another level of support for trac. 

What side-effects (if any) will the enhancement create?

None

Original issue reported on code.google.com by Krzysztof.Retel@gmail.com on 17 Feb 2009 at 8:20

[GoogleCodeExporter]

sounds good

Original comment by j.kennet...@gmail.com on 17 Feb 2009 at 8:29

• Changed state: Accepted

[GoogleCodeExporter]

Wanted to say as well, that it might be worth spliting milestones as a class 
itself
(?), or even seperate into another file, e.g., trac_milestones.py

Original comment by Krzysztof.Retel@gmail.com on 17 Feb 2009 at 8:39

[GoogleCodeExporter]

if you inspect the XML-RPC methods available, each module including milestones 
has
the same interface. They all provide get, create, update, and delete. We can 
probably
create an admin interface that just dispatches the requests to the appropriate 
rpc call.

for example from shell.py:

def do_admin(self, param_str):
    try:
        (module, action, param) = param_str.split(' ')
    except ValueError, e:
        print "Please see `help admin` for more information"

    response = self.trac.admin(module, action, param)
    print "Success: %s" % response

then in trac.py

@catch_errors
def admin(self, module, action, param):
    if hasattr(self._server.ticket, module):
        if hasatter(getattr(self._server.ticket, module), action):
            return getattr(getattr(self._server.ticket, module), action)(param)
        else:
            print "%s has no action: %s" % (module, action)
    else:
        print "No such module: %s" % module

Of course, there's probably a nicer way to write all this that isn't so 
gobbly-gook. :)

Also, there's the matter how to handle permissions in ticket 1 -- not all users 
will
be able to add milestones or edit tickets.

Original comment by j.kennet...@gmail.com on 17 Feb 2009 at 9:16

[GoogleCodeExporter]

[deleted comment]

[GoogleCodeExporter]

from a user perspective, would it be advantageous to have a "sub-shell" for 
admin stuff?

Original comment by j.kennet...@gmail.com on 17 Feb 2009 at 9:29

[GoogleCodeExporter]

hm, difficult to say. 
I would guess you can chose which parts you want to change. So if you want to 
make
any admin changes then probably it creates like a new session/sub-shell. 
Everything is worth testing from the user/admin point of view. If this is easy 
to
implement, then probably worth having. 

Original comment by Krzysztof.Retel@gmail.com on 17 Feb 2009 at 9:36

[GoogleCodeExporter]

i think i like the idea of keeping it simple.

let's add a command-line boolean which will fire up a seperate admin shell with
seperate admin class when the --admin option is present.

then we can add a TracAdminShell class to shell.py and a TracAdmin class to 
trac.py
and keep all the functionality seperate.

Original comment by j.kennet...@gmail.com on 17 Feb 2009 at 9:43

[GoogleCodeExporter]

sounds good 

Original comment by Krzysztof.Retel@gmail.com on 17 Feb 2009 at 9:45

[GoogleCodeExporter]

Did you start making these changes to the code? 

Original comment by Krzysztof.Retel@gmail.com on 18 Feb 2009 at 12:22

[GoogleCodeExporter]

No, but I have been thinking about it some more.

If you look at ticket 1, there's the issue of user permissions.

the xmlrpclib.ServerProxy.listMethods method allows us to grab all the 
functions that
an authenticated user has permission to call. I've been trying to think of a 
way to
write a cmd.Cmd subclass that acts as a dynamic dispatcher; generating the 
command
interface to the available XML-RPC commands at run time.

This is a tricky area, but has the advantage of keeping the shell free from 
commands
the user cannot run.

The disadvantage would be another radical change to the code.

Any thoughts?

Original comment by j.kennet...@gmail.com on 18 Feb 2009 at 2:43

[GoogleCodeExporter]

Didn't have deeper thoughts about it, mainly cause I can't see how this will 
work. 

Question really is, how many advantages do we get compared to disadvantages? 
In terms of "radical changes to the code", I wouldn't think about it as 
disadvantage.
Refactoring/rewriting code is or might be required at any stage of the project. 

Original comment by Krzysztof.Retel@gmail.com on 20 Feb 2009 at 1:18

[GoogleCodeExporter]

Lets just get moving ahead with this one. We'll worry about refactoring later.

:)

Original comment by j.kennet...@gmail.com on 20 Feb 2009 at 3:37

[GoogleCodeExporter]

this will be resolved by t34

Original comment by j.kennet...@gmail.com on 14 Apr 2009 at 8:18

[GoogleCodeExporter]

Hasn't been blocked for a while. The enhancement can go ahead. 

Original comment by j.kennet...@gmail.com on 19 Sep 2010 at 4:51