Opened 6 years ago

Closed 6 years ago

ini fields seem to be "hard coded" and/or unicode issues

Reported by: Owned by: yoheeb ChrisNelson normal TracJsGanttPlugin normal 0.11

Description

First off, awesome plugin. this combined with your ValuePropagationPlugin will make some of my things a lot more viable in Trac.

However,

I am encountering some issues with this one. I was hoping to use a couple of the configurable options. Specifically "percent" and "parent" however, I have found they only work when the field they are configured to, match the option's expected (with the exception of percent, which just won't work for me).

the first one seems more like a unicode issue the second one actually errors out down the line on the 'level' request.

i.e:
fields.percent= pct_complete
#gives an error
fields.percent = percent
# still fails
fields.parent = parent
#gives and error
fields.parent = parents
#works, if I change my parent field to parents instead of parent, which breaks my child-tickets usage. (an upgrade to subtickets with the child-tickets patches will adresss that issue, however...)

it's as if the configured field is not actually passing the valued it is configured to, but if it is present, it's looking it up based on a predetermined value.

I am on 0.12 which might have something to do with it. trace after the break

#percent error:
2010-12-08 10:31:57,289 Trac[formatter] ERROR: Macro TracJSGanttChart(milestone=PM tools) failed:
Traceback (most recent call last):
File "C:\usr\bin\Python26\lib\site-packages\trac\wiki\formatter.py", line 710, in _macro_formatter
return macro.process(args, in_paragraph=True)
File "C:\usr\bin\Python26\lib\site-packages\trac\wiki\formatter.py", line 304, in process
text = self.processor(text)
File "C:\usr\bin\Python26\lib\site-packages\trac\wiki\formatter.py", line 291, in _macro_processor
text)
File "build\bdist.win32\egg\tracjsgantt\tracjsgantt.py", line 508, in expand_macro
File "build\bdist.win32\egg\tracjsgantt\tracjsgantt.py", line 445, in _format_ticket
KeyError: u'pct_complete'


#parent error
2010-12-08 10:44:39,180 Trac[formatter] ERROR: Macro TracJSGanttChart(milestone=PM tools) failed:
Traceback (most recent call last):
File "C:\usr\bin\Python26\lib\site-packages\trac\wiki\formatter.py", line 710, in _macro_formatter
return macro.process(args, in_paragraph=True)
File "C:\usr\bin\Python26\lib\site-packages\trac\wiki\formatter.py", line 304, in process
text = self.processor(text)
File "C:\usr\bin\Python26\lib\site-packages\trac\wiki\formatter.py", line 291, in _macro_processor
text)
File "build\bdist.win32\egg\tracjsgantt\tracjsgantt.py", line 508, in expand_macro
File "build\bdist.win32\egg\tracjsgantt\tracjsgantt.py", line 455, in _format_ticket
if t['level'] < options['openLevel']:
KeyError: 'level'


comment:1 Changed 6 years ago by ChrisNelson

(In [9644]) Handle percent complete field name configuration. Refs #8289.

comment:2 Changed 6 years ago by ChrisNelson

• Status changed from new to assigned

I think I fixed the percent complete issue.

I'm not sure I understand the parent issue. What plugin are you using for subtickets?

comment:3 follow-up: ↓ 4 Changed 6 years ago by yoheeb

I am using ChildTicketsPlugin The version I have uses the filed "parent" where SubticketsPlugin uses the field "parents". if I understood the intent of the .ini setting however, I would of thought I could use a field called booglie_dooda in ticket-custom if I wanted as the parent field, and defined under [trac-jsgantt] fields.parent=booglie_dooda.

However, looking closely at this plugin description, and the snippet in the error code, I get the feeling my assumption of the way it works is wrong. Upon further review I think it automatically uses "parents" if it is defined in [ticket-custom] If that is correct, then I should of logged a separate enhancement request to make the "parent" field a configurable parameter of [trac-jsgantt].

that said I am going to move to the SubticketsPlugin with the patches anyway, so this might be a moot point.

and wow on the quick response time!

Again thanks, this plugin plus a few of your others has enabled me to push trac to a level I need it for a lot my daily stuff. Now if the author just picks back up on the EvidenceSchedulingPlugin plugin :D Maybe it's time I learn to write plugins..

comment:4 in reply to: ↑ 3 Changed 6 years ago by ChrisNelson

I am using ChildTicketsPlugin The version I have uses the filed "parent" where SubticketsPlugin uses the field "parents". if I understood the intent of the .ini setting however, I would of thought I could use a field called booglie_dooda in ticket-custom if I wanted as the parent field, and defined under [trac-jsgantt] fields.parent=booglie_dooda.

That is the intent and I just combed through my code again to make sure that I'm using it as intended. I think I am.

However, as I recall, ChildTicketsPlugin set the custom field value to "#nnnn", not "nnnn" and "#nnnn" clearly isn't a valid integer. Perhaps I should strip a leading "#" from the parent field, if found, to be more flexible.

However, looking closely at this plugin description, and the snippet in the error code, I get the feeling my assumption of the way it works is wrong.

No, what I intend is that the parent field name be configurable just like estimate and worked and pred and succ.

that said I am going to move to the SubticketsPlugin with the patches anyway, so this might be a moot point.

But I'd like to have this working.

and wow on the quick response time!

I wanted to get this plugin in as good shape as possible before I forget how it works. ;-)

Again thanks, this plugin plus a few of your others has enabled me to push trac to a level I need it for a lot my daily stuff.

Same for me which is why I'm writing them.

Now if the author just picks back up on the EvidenceSchedulingPlugin plugin :D Maybe it's time I learn to write plugins..

It's not that hard. I've only been doing it a few weeks and I seem to have accomplished something.

comment:5 Changed 6 years ago by yoheeb

Verified the percent works now. additionally, it works with both text and select options, which is a nice bonus. (~36.5%) or (almost) doesn't help with a text field :D

However, as I recall, ChildTicketsPlugin set the custom field value to "#nnnn", not "nnnn" and "#nnnn" clearly isn't a valid integer. Perhaps I should strip a leading "#" from the parent field, if found, to be more flexible.

ahh yes, forgot about that, not only that, it is wiki formatted, so I am not sure exactly how it is stored in the ticket database. might be more than just stripping a leading '"#"' if it exists, but I bet that works.

And wow, I was way of on my initial analysis on both these issues. not sure what is up with that.

comment:6 Changed 6 years ago by ChrisNelson

(In [9645]) Handle leading # in parent field. Refs #8289.

This is specifically for ChildTicketsPlugin but may affect others, too. Tested by forcing leading "#" since I don't have ChildTickets installed.

comment:7 Changed 6 years ago by ChrisNelson

(In [9646]) Compute percent complete in format routine, not preprocessing. Refs #8289.

By setting self.fieldspercent? in format, other logic which depended on whether the user had configured percent complete or not failed. This is cleaner, though perhaps still not optimal.

comment:8 Changed 6 years ago by yoheeb

The original 2 issues in this ticket I have verified have been fixed. I have done so in the latest version [9646] actually a later repository version.

However, I did create a new issue, which might be related to the 9646 comment above. see #8309

Thanks. this plugin is coming in quite handy.

My usage scenario. %complete is evaluated by the developer after updating the task, irrespective of the initial estimate (estimated hours) and hours worked thus far. : i.e. estimatedhours = 5, worked=5, pct_complete=50% "oops, I under estimated"

comment:9 Changed 6 years ago by ChrisNelson

• Resolution set to fixed
• Status changed from assigned to closed