#10914 closed defect (fixed)
Combine CustomFieldAdminPlugin, DateFieldPlugin and mine plugin for default values
Reported by: | Tomas Pelka | Owned by: | Ryan J Ollos |
---|---|---|---|
Priority: | normal | Component: | DateFieldPlugin |
Severity: | normal | Keywords: | |
Cc: | Trac Release: | 0.12 |
Description (last modified by )
Hi my issue seems to be similar to #5838, but not sure about that.
Here is the thing, I created plugin (1) for setting default due date out from the milestone due date. It is based on CustomFieldAdminPlugin and it is applied on date field (DateFieldPlugin)
But getting always:
Warning: The ticket field 'userstart' is invalid: Field userstart does not seem to look like a date. The correct format is YYYY-MM-DD.
even if I think the date format is correct.
Interesting is that if I debug it a bit and try to print out a value of the filed when date is entered manually in correct format the value
is empty, see line 38 in https://github.com/tompelka/TracDueDate/blob/master/duedate/__init__.py
log entry:
2013-03-07 06:34:15,413 Trac[__init__] DEBUG: **duedate plugin** due date - {'name': u'userfinish', 'format': 'plain', 'value': '', 'label': u'Due Date', 'type': u'text', 'order': 17}
Could somebody help? Not sure if my problem is an issue in CustomFieldAdminPlugin, DateFieldPlugin or my plugin.
Thanks Tom
Attachments (1)
Change History (8)
comment:1 Changed 12 years ago by
Component: | CustomFieldAdminPlugin → DateFieldPlugin |
---|---|
Owner: | changed from osimons to Robert Corsaro |
comment:2 Changed 12 years ago by
Description: | modified (diff) |
---|---|
Owner: | changed from Robert Corsaro to Ryan J Ollos |
Status: | new → assigned |
comment:3 Changed 12 years ago by
Hi tompelka:
I modified your plugin a bit. See attachment.
- From what you describe, you shouldn't need to utilize CustomFieldAdminPlugin in your plugin's code, though it can be useful for adding the custom field in your Trac instance.
- I'm not sure of your exact requirements, but I modified the plugin to set a ticket custom field of type text (using a default custom field name of duedate) to the milestone's due date at the time the ticket is created if the user hasn't entered a value for the due date. Therefore, the default due date won't be set if any of the following are true:
- You are modifying rather than creating a ticket.
- The ticket's milestone field is empty.
- The milestone associated with the ticket doesn't have a due date.
- The user enters some text in the ticket's due date custom field.
- I developed and tested the code with Trac 1.0.1.
- The custom field will not be created by the plugin, though it is possible to add that feature if you'd like. I used the following when testing:
[ticket-custom] duedate = text duedate.label = New Due Date
You can configure the plugin to point to a different custom field:
[ticket-custom] newduedate = text newduedate.label = New Due Date [ticket-duedate] field = newduedate
comment:4 Changed 12 years ago by
Resolution: | → fixed |
---|---|
Status: | assigned → closed |
I'm closing this, but please feel free to reply if you have any questions.
Changed 12 years ago by
Attachment: | __init__.py added |
---|
comment:5 follow-up: 6 Changed 12 years ago by
Dear rjollos,
thank you very much it is more or less working, only thing I observed is that notifications stoped working.
Getting
Warning: The ticket has been created, but an error occurred while sending notifications: 'datetime.datetime' object has no attribute 'find'
Tom
comment:6 Changed 12 years ago by
Replying to tompelka:
Dear rjollos,
thank you very much it is more or less working, only thing I observed is that notifications stoped working.
Getting
Warning: The ticket has been created, but an error occurred while sending notifications: 'datetime.datetime' object has no attribute 'find'Tom
Fixed just need to format the datetime.datetime a bit.
comment:7 Changed 12 years ago by
Glad it is sorted out for you. The datetime
import was removed from the __init__.py
module, so the issue must have been coming up due to modifications you made to this code, or modifications you made to another plugin?
I don't know the details of datefield or your plugin, but I'm quite sure anything derived from CustomFieldAdminPlugin should be safe. All that plugin does is write current field settings to trac.ini - as if you edited
trac.ini
manually. It has no code that runs as part of requests or any other means of impacting running code.So; it can't be the plugin if your
trac.ini
looks correct and things work just the same even if you manually edit the field configuration.