1 Mar 2005 04:44
1 Mar 2005 09:24
RE: Ticket #1005: Implemented work hour reporting for tick ets
Hi,
> -----Original Message-----
> From: trac-bounces-DNOXQ1Wj7szh91C2ulQeWdBPR1lH4CV8@public.gmane.org
> [mailto:trac-bounces <at> lists.edgewall.com] On Behalf Of Felix Collins
> Sent: Monday, February 28, 2005 9:57 PM
> To: trac-DNOXQ1Wj7szh91C2ulQeWdBPR1lH4CV8@public.gmane.org
> Subject: Re: [Trac] Ticket #1005: Implemented work hour
> reporting for tickets
>
> Kis Gergely wrote:
> > Hi,
> >
> > I created a patch for the 0.8-stable branch which implements work
> > hour reporting for the tickets. For details look at:
> > http://projects.edgewall.com/trac/ticket/1005
> >
> > What do you think?
>
> Below are my comments (somewhat modified) from
> http://projects.edgewall.com/trac/ticket/710
>
> I've done this very successfully using the custom fields. I use an
> initial estimate field, a current estimate (changed to reflect the
> updated idea of how long the ticket will take) and a cumulative time
> spent. I've even written a sync utility to allow us to
> synchronise with
> an xml gantt chart program for reporting.
How do you specify a cumulative custom field? This was the only thing missing for me.
First, I wanted to implement it with custom fields too.
>
> I don't think this needs a plugin module or anything like
> that as that
> will only restrict the flexibility needed to support multiple
> different
> development processes. i.e. your patch does not have two estimate
> fields for "initial" and "current" estimate.
If you need the "initial" estimate, you can get it from the ticket_change table.
But of course I see your point about flexibility.
>
> The only change I'd like to see to trac to support this sort
> of thing is
> some additions to the types of custom fields to support
> Numerics - read
> only, cumulative, read/write etc. And enforcing of numeric
> only input.
> I looked into doing this myself but I wasn't quite confident of
> understanding trac enough to do it.
So in your current version you need to "cumulate" the actual work yourself.
This was the thing I wanted to avoid.
<at> Christopher: What do you think about a patch that adds support for cumulative / numeric
custom fields? Would you apply such patch? Maybe for trac 0.9?
Best Regards,
Gergely
_______________________________________________ Trac mailing list Trac@... http://lists.edgewall.com/mailman/listinfo/trac
1 Mar 2005 09:38
Problem with trac on mod_python
[Tue Mar 01 09:11:21 2005] [error] [client 66.249.64.6] PythonHandler trac.web.modpython_frontend: Traceback (most recent call last): [Tue Mar 01 09:11:21 2005] [error] [client 66.249.64.6] PythonHandler trac.web.modpython_frontend: File "C:\\PROGRA~1\\Python\\Lib\\site-packages\\mod_python\\apache.py", line 299, in HandlerDispatch\n result = object(req) [Tue Mar 01 09:11:21 2005] [error] [client 66.249.64.6] PythonHandler trac.web.modpython_frontend: File "C:\\PROGRA~1\\Python\\lib\\site-packages\\trac\\web\\modpython_frontend.py", line 201, in handler\n send_pretty_error(e, env, mpr) [Tue Mar 01 09:11:21 2005] [error] [client 66.249.64.6] PythonHandler trac.web.modpython_frontend: File "C:\\PROGRA~1\\Python\\lib\\site-packages\\trac\\web\\main.py", line 337, in send_pretty_error\n if env and env.log: [Tue Mar 01 09:11:21 2005] [error] [client 66.249.64.6] PythonHandler trac.web.modpython_frontend: TypeError: __nonzero__ should return an int what's wrong ?
1 Mar 2005 11:18
Re: Problem with trac on mod_python
> [Tue Mar 01 09:11:21 2005] [error] [client 66.249.64.6] PythonHandler > trac.web.modpython_frontend: Traceback (most recent call last): > [Tue Mar 01 09:11:21 2005] [error] [client 66.249.64.6] PythonHandler > trac.web.modpython_frontend: File > "C:\\PROGRA~1\\Python\\Lib\\site-packages\\mod_python\\apache.py", line > 299, in > HandlerDispatch\n result = object(req) > [Tue Mar 01 09:11:21 2005] [error] [client 66.249.64.6] PythonHandler > trac.web.modpython_frontend: File > "C:\\PROGRA~1\\Python\\lib\\site- packages\\trac\\web\\modpython_frontend.py", > line 201, in handler\n send_pretty_error(e, env, mpr) > [Tue Mar 01 09:11:21 2005] [error] [client 66.249.64.6] PythonHandler > trac.web.modpython_frontend: File > "C:\\PROGRA~1\\Python\\lib\\site-packages\\trac\\web\\main.py", line 337, > in > send_pretty_error\n if env and env.log: > [Tue Mar 01 09:11:21 2005] [error] [client 66.249.64.6] PythonHandler > trac.web.modpython_frontend: TypeError: __nonzero__ should return an int > > what's wrong ? Good catch! I've fixed this problem in http://projects.edgewall.com/trac/ changeset/1299. Note though that this error is hiding a different exception, which will probably pop up next after you upgrade :-P Thanks, Chris -- -- Christopher Lenz cmlenz at gmx.de http://www.cmlenz.net/
1 Mar 2005 12:24
Re: Problem with trac on mod_python
Christopher Lenz <cmlenz <at> ...> writes: > > > [Tue Mar 01 09:11:21 2005] [error] [client 66.249.64.6] PythonHandler > > trac.web.modpython_frontend: Traceback (most recent call last): > > [Tue Mar 01 09:11:21 2005] [error] [client 66.249.64.6] PythonHandler > > trac.web.modpython_frontend: File > > "C:\\PROGRA~1\\Python\\Lib\\site-packages\\mod_python\\apache.py", line > > 299, in > > HandlerDispatch\n result = object(req) > > [Tue Mar 01 09:11:21 2005] [error] [client 66.249.64.6] PythonHandler > > trac.web.modpython_frontend: File > > "C:\\PROGRA~1\\Python\\lib\\site- > packages\\trac\\web\\modpython_frontend.py", > > line 201, in handler\n send_pretty_error(e, env, mpr) > > [Tue Mar 01 09:11:21 2005] [error] [client 66.249.64.6] PythonHandler > > trac.web.modpython_frontend: File > > "C:\\PROGRA~1\\Python\\lib\\site-packages\\trac\\web\\main.py", line > 337, > > in > > send_pretty_error\n if env and env.log: > > [Tue Mar 01 09:11:21 2005] [error] [client 66.249.64.6] PythonHandler > > trac.web.modpython_frontend: TypeError: __nonzero__ should return an int > > > > what's wrong ? > > Good catch! I've fixed this problem in http://projects.edgewall.com/trac/ > changeset/1299. > > Note though that this error is hiding a different exception, which will > probably pop up next after you upgrade :-P > > Thanks, > Chris > That's true, this is a real error: ClearSilver not installed (No module named neo_cgi) Traceback (most recent call last): File "C:\PROGRA~1\Python\lib\site-packages\trac\web\modpython_frontend.py", line 179, in handler dispatch_request(mpr.path_info, mpr, env) File "C:\PROGRA~1\Python\lib\site-packages\trac\web\main.py", line 301, in dispatch_request req.hdf = HDFWrapper(loadpaths=[env.get_templates_dir(), File "C:\PROGRA~1\Python\lib\site-packages\trac\web\clearsilver.py", line 132, in __init__ raise TracError, "ClearSilver not installed (%s)" % e TracError: ClearSilver not installed (No module named neo_cgi) I have "neo_cgi.pyd" in "C:\Program Files\Python\Lib\site-packages\trac" and i don't have problems with ClearSilver before HDFWrapper update.
1 Mar 2005 12:44
Re: Re: Problem with trac on mod_python
On Mar 2, 2005, at 12:24 AM, Sija wrote: > That's true, this is a real error: > > ClearSilver not installed (No module named neo_cgi) > Traceback (most recent call last): > File > "C:\PROGRA~1\Python\lib\site-packages\trac\web\modpython_frontend.py", > line 179, in handler > dispatch_request(mpr.path_info, mpr, env) > File "C:\PROGRA~1\Python\lib\site-packages\trac\web\main.py", line > 301, in > dispatch_request > req.hdf = HDFWrapper(loadpaths=[env.get_templates_dir(), > File "C:\PROGRA~1\Python\lib\site-packages\trac\web\clearsilver.py", > line 132, > in __init__ > raise TracError, "ClearSilver not installed (%s)" % e > TracError: ClearSilver not installed (No module named neo_cgi) > > I have "neo_cgi.pyd" in "C:\Program > Files\Python\Lib\site-packages\trac" > and i don't have problems with ClearSilver before HDFWrapper update. The neo_cgi module shouldn't be inside the trac folder, it should be at the top level of site-packages (C:\Program Files\Python\Lib\site-packages in your case). Hope this helps, Mark Rowe <http://bdash.net.nz/>
1 Mar 2005 12:56
Re: Re: Problem with trac on mod_python
> ClearSilver not installed (No module named neo_cgi) > Traceback (most recent call last): > File "C:\PROGRA~1\Python\lib\site-packages\trac\web\modpython_frontend.py", > line 179, in handler > dispatch_request(mpr.path_info, mpr, env) > File "C:\PROGRA~1\Python\lib\site-packages\trac\web\main.py", line 301, in > dispatch_request > req.hdf = HDFWrapper(loadpaths=[env.get_templates_dir(), > File "C:\PROGRA~1\Python\lib\site-packages\trac\web\clearsilver.py", line 132, > in __init__ > raise TracError, "ClearSilver not installed (%s)" % e > TracError: ClearSilver not installed (No module named neo_cgi) > > I have "neo_cgi.pyd" in "C:\Program Files\Python\Lib\site-packages\trac" > and i don't have problems with ClearSilver before HDFWrapper update. Copying neo_cgi.pyd to "C:\Program Files\Python\Lib\site-packages\trac\web" should fix the problem. - Markus
1 Mar 2005 13:51
1 Mar 2005 20:55
Re: Ticket #1005: Implemented work hour reporting for tick ets
> > some additions to the types of custom fields to support > > Numerics - read > > only, cumulative, read/write etc. And enforcing of numeric > > only input. > > I looked into doing this myself but I wasn't quite confident of > > understanding trac enough to do it. > So in your current version you need to "cumulate" the actual work yourself. > This was the thing I wanted to avoid. Yeah, I wanted to avoid this sort of thing too. Luckily we have a small team of highly skilled developers so it is not to difficult to enforce conventions in the use of the system. I would prefer the system to enforce the business logic. > > <at> Christopher: What do you think about a patch that adds support for > cumulative / numeric > custom fields? Would you apply such patch? Maybe for trac 0.9? Please say yes... please say yes!It wouldn't be a major change to Trac after all. It would simply mean extending an already existing mechanism. It would be a backward and forward compatible change that would introduce no new dependencies. While we are at it we could provide support for currency fields (including support for specifying the symbol in the ini file) and date fields (smart fields that supports entry in multiple formats and detects the format used?). Anyone think of anything else useful? The "cumulative" field could be implemented as a general "operation" field where the operation to be performed on the existing data could be specified in the ini file. The ini file entry for the numeric fields could include specification of the precision, read/write status and radix. Trac could enforce this when numbers are entered. I propose the following: write once - field is only editable when the ticket is created (this could be useful for text fields too. read only - for fields where the value is generated some external way read write - fully editable field operation - field is not writable directly but can be modified by way of a math. operation (specified in the ini file) I propose storing it all as strings as I think that is what SQLite does anyway. Trac would convert it to strings and simply ignore values in the DB that didn't convert back to number correctly. What about my idea of making the Roadmap page customisable in the same way that the ticket reports are? Any comments? Regards, Felix
1 Mar 2005 21:47
Re: Ticket #1005: Implemented work hour reporting for tick ets
On Wed, 2005-03-02 at 08:55 +1300, Felix Collins wrote: > operation - field is not writable directly but can be modified by way of > a math. operation (specified in the ini file) Or perhaps, an SQL operation? That probably gives you a certain amount of math ability, and allows other fields/tables to be consulted. Basically, it's a type of trigger, implemented in the application instead of the SQL manager ... -jim
RSS Feed