Opened 12 years ago
Closed 9 years ago
#10468 closed enhancement (wontfix)
[patch] Compatibility with 0.11
Reported by: | Chris Nelson | Owned by: | thomasd |
---|---|---|---|
Priority: | high | Component: | GroupTicketFieldsPlugin |
Severity: | normal | Keywords: | |
Cc: | Ryan J Ollos, falkb | Trac Release: | 0.11 |
Description
As for SimpleMultiProject, add_script_data()
is the major obstacle to using this plugin in 0.11.
Attachments (2)
Change History (16)
comment:1 Changed 12 years ago by
Type: | defect → enhancement |
---|
Changed 12 years ago by
Attachment: | add_script_data.patch added |
---|
Patch to add add_script-data() to 0.11.6
comment:2 Changed 12 years ago by
With the attached patch applied to 0.11.6 and my Trac configured with:
[group-ticket-fields] relationships = Relationships relationships.fields = parents,blockedby,blocking group_order = relationships,main
I get a "Relationships" frame on my ticket form and the label for parents
moves to it but group_ticket_fields.js
goes out to lunch at line 58 trying to find the parents field. At that point, my Relationships frame looks like:
<fieldset class="property_group" id="properties_relationships"><legend>Relationships</legend><table id="table_relationships"><tbody><tr><th style="display: table-cell;" class="col1"> <label for="field-parents">Parent Ticket:</label> </th></tr></tbody></table></fieldset>
and my main field set contains:
... <tr> <td style="d!splay: table-cell;" class="col1"> <input class="" id="field-parents" name="field_parents" value="232" type="text"> </td> </tr>
(I can't give you more context without running into T-H's spam filter.)
comment:3 Changed 12 years ago by
http://api.jquery.com/category/selectors/ tells me that the line:
var value_td = $('td').has('#' + field_id); // get the <td>
Is looking for something with the ID in field_id
. It's not clear to me if that's a child of the TD or a TD with that ID. Clearly from the HTML above the TD doesn't have an ID.
comment:4 Changed 12 years ago by
Are you planning to patch Trac or is that just for experimentation purposes? I would suggest that the better approach is to add all of the functionality to the plugin, rather than have the plugin rely on a patched instance of Trac.
Changed 12 years ago by
Attachment: | Trac0.11.6.patch added |
---|
Patch to plugin to work with Trac 0.11.6
comment:5 Changed 12 years ago by
Resolution: | → fixed |
---|---|
Status: | new → closed |
Summary: | Compatibility with 0.11 → [patch] Compatibility with 0.11 |
I don't know enough jQuery to know why the attached patch makes a difference but it works for me.
Full disclosure, I'm using Trac 0.11.6 on Ubuntu 10.04 and viewing with Firefox 16.0. Firebug reveals jQuery 1.2.6. I assume that comes with Trac and may be updated in later versions. Hopefully my patch works in later versions of Trac, also.
comment:6 follow-up: 7 Changed 12 years ago by
I see. I thought you were trying to make the plugin compatible with Trac 0.11, not just patch your local version. jQuery is provided by Trac. The version in Trac 0.12 is 1.4.x. The version didn't change in Trac 0.11.7 from 0.11.6.
comment:7 follow-up: 8 Changed 12 years ago by
Replying to rjollos:
Are you planning to patch Trac or is that just for experimentation purposes? I would suggest that the better approach is to add all of the functionality to the plugin, rather than have the plugin rely on a patched instance of Trac.
For my purposes, yes, I'm going to patch the Trac core. We have quite a few patches and managing one more isn't a big deal.
If someone wants to cram this compatibility shim into the plugin, they are welcome to the concepts and code for whatever good it does. I don't quite know how you'd do that but I suppose it could all be done by handling the template in the plugin but I'm uninspired to do that. Sorry. (I might note that patching the core will allow SimpleMultiProject to work, too, and maybe others.)
comment:8 Changed 12 years ago by
Replying to ChrisNelson:
For my purposes, yes, I'm going to patch the Trac core. We have quite a few patches and managing one more isn't a big deal.
Pretty soon you will have patched your way to Trac 1.0. I guess there are multiple ways to get there ;)
I had, for some time, tried to get as many possible plugins working with Trac 0.11. It is becoming less interesting to me though, since there are so many other things to work on, and hopefully people will start moving away from 0.11 now. I'm starting to focus more on 0.12+ compatibility, which is far less challenging.
comment:9 Changed 12 years ago by
Resolution: | fixed |
---|---|
Status: | closed → reopened |
I guess this patch won't show up in the list of tickets if it is closed so others won't be able to find it.
comment:10 Changed 12 years ago by
Sometimes people make a note on the main wiki page describing compatibility patches and pointing to closed tickets, but plugin authors seem to like to handle the issue in various ways, depending on how aggressive they are in managing the list of tickets.
comment:11 Changed 12 years ago by
Cc: | falkb added |
---|
Thanks very much so far. We just install/update_to the latest Bitnami Trac stack (and this just takes 10 minutes for a new system) and its Trac core is just an .egg file, so a plugin patch is what we need. Well, thomasd and me are very busy atm, but although I was hoping for a plugin patch I think these patches are a good start point for it anyway...
comment:12 Changed 12 years ago by
falkb: I made a little change so that you'd always get CC'ed (at least when the ticket is created starting from the project wiki page #9959): wiki/GroupTicketFieldsPlugin. Hopefully that is what you want ;)
comment:13 Changed 12 years ago by
Very good... well, I didn't noticed that because my private email isn't registered here :)
comment:14 Changed 9 years ago by
Resolution: | → wontfix |
---|---|
Status: | reopened → closed |
Re-closing since 0.11 is obsolete by now, and we are close to a release of Trac 1.2.
There are several levels to this issue:
ticket.py
in this plugin attempts to importadd_script_data()
fromchrome
but it was added in 0.12.add_script_data()
relies data handling inlayout.html
which is not present in 0.11layout.html
relies onto_json
frompresentation.py
which is not present in 0.11.chrome.py
must exposeto_json
to the templateThe attached patch solves all of these problems with small, safe point fixes to several core files.