Modify

Opened 4 years ago

Closed 3 years ago

#7946 closed defect (fixed)

Problem with dynfield.js

Reported by: anonymous Owned by: robguttman
Priority: high Component: DynamicFieldsPlugin
Severity: major Keywords: needinfo
Cc: james@…, hasienda Trac Release: 0.11

Description (last modified by rjollos)

I use Trac 0.11.4 / Python 2.5.4 / JQuery 1.2.6

I installed the DynamicFieldsPlugin but it seems to be not functionnal on my trac project. The error i have is : spec.rule is not defined.

Did i miss something in the installation or configuration ?
Any idea to fix my problem ?

Regards


Attachments (0)

Change History (22)

comment:1 follow-up: Changed 4 years ago by hasienda

  • Keywords needinfo added

I'm curious: Are you sure, that you grabbed version from 0.11 branch?

If you don't have Babel installed at that system, and with Trac 0.11 chance are high, your plugin will fail, or even not compile/get packaged at all. I didn't test 0.12 branch code with Trac 0.11.x, but this may happen in the future.

comment:2 in reply to: ↑ 1 ; follow-up: Changed 4 years ago by anonymous

Replying to hasienda:
Thanks for the answer.
Yes, I used 0.11 branch.
You mean : use Trac 0.11 + this plugin without Babel will fail. Is it correct ?
It is not clear in the configuration that Babel is required for using the plugin.

I'm curious: Are you sure, that you grabbed version from 0.11 branch?

If you don't have Babel installed at that system, and with Trac 0.11 chance are high, your plugin will fail, or even not compile/get packaged at all. I didn't test 0.12 branch code with Trac 0.11.x, but this may happen in the future.

comment:3 in reply to: ↑ 2 Changed 4 years ago by hasienda

Replying to anonymous:

Replying to hasienda:
Thanks for the answer.
Yes, I used 0.11 branch.
You mean : use Trac 0.11 + this plugin without Babel will fail. Is it correct ?

No, I specifically meant the 0.12 branch. The 0.11 branch should still be fine, but I didn't test it.

It is not clear in the configuration that Babel is required for using the plugin.

Yes, after all Trac 0.12 is a lot about i18n - done with Babel. But situation for this plugin has changed againg with [9418]. That recent development has been driven by (negative) experience, like yours. I recommend to give it a try. Sorry for the inconvenience.

I'm curious: Are you sure, that you grabbed version from 0.11 branch?

If you don't have Babel installed at that system, and with Trac 0.11 chance are high, your plugin will fail, or even not compile/get packaged at all. I didn't test 0.12 branch code with Trac 0.11.x, but this may happen in the future.

comment:4 Changed 4 years ago by robguttman

  • Status changed from new to assigned

First be sure that all rules are enabled using the Admin > Plugins GUI or in the trac.ini file.

Is that a python or JavaScript error (in the browser). The more details you can provide, the easier it will be for me to diagnose. Can you share the trac.ini rules you're trying to use?

comment:5 Changed 4 years ago by robguttman

Also, it's always possible that there's plugin interference. You can try temporarily disabling other plugins and seeing if that fixes the problem. If you do find a plugin conflict, please let me know so I can try to address.

comment:6 Changed 4 years ago by james@…

I also have tried this plugin, but it does not work due to dynfields.js not being included in the release.

It seems someone forgot to check this file into Subversion, as I see no trace of it anywhere in the source, yet web_ui.py has contained a reference to /dynfields/dynfields.js since its initial import.

I'm thinking a simple checking of this file will fix this issue, since I can't see how anyone is able to use this plugin without that file.

comment:7 Changed 4 years ago by robguttman

  • Cc james@… hasienda added

James et al, the problem is not one of a missing file. You'll notice a /dynfields/dynfields.html file which contains the JS code - that's just how Trac plugins work.

Which version are you trying to use - the 0.11 or 0.12 branch? If the 0.12 branch, please instead try the 0.11 branch (if multi-language support is not required) and see if that alone fixes your problem. If that doesn't work, please try the suggestions I make above. If that still doesn't work, please let me know. I very much would like to figure out the root cause of this problem and I'm not able to repo it locally and several people appear to be having it. Thanks.

comment:8 Changed 4 years ago by anonymous

I tried both branches (I'm running Trac 0.12 though). Every time the new ticket page loaded, I noticed it always threw a 404 error for dynfields.js. It never worked for either branch.

comment:9 Changed 4 years ago by robguttman

Ok. The 0.11 branch works with 0.12 - it just doesn't have the multi-language support (the only significant difference between the two versions). Others have had the 0.11 branch work for them when the 0.12 failed - I have not yet diagnosed why.

As for your 404, have you tried the troubleshooting steps above? Namely:

  • Are all rules enabled using the Admin > Plugins GUI or in the trac.ini file?
  • Where do you see the 404? For example, do ticket pages load at all? If so, do you have Firebug (or comparable) installed? If so, under the Net tab, can you see the 404 and then if so can you open it up and copy and paste the Response results here?

It's also possible, as explained above, that there's a plugin conflict. Can you list what other plugins are enabled?

Sorry you're having this problem, but hopefully with a little effort now we can get to the bottom of it once and for all. Thanks.

comment:10 Changed 4 years ago by james@…

Using Chrome, I inspected the new ticket screen, and noticed that it couldn't load dynfields.js. It loads the other two .js files fine, but always complains that dynfields.js does not load. Yes, all rules are enabled, of course.

I did set up the dynamic fields to try a very simple "enable custom field x when type is defect", and that did not work. I also tried doing it by having it hide field x by default, and it didn't work. I tried as many combinations of your configuration as I could, and nothing would make the field be hidden.

I have the following plugins installed:

  • BatchModify
  • HudsonTrac
  • CustomFieldAdmin
  • IniAdmin
  • TracStats
  • WikiPrint
  • XMLRPC

I do not think there is a conflict with other plugins. It simply cannot get the dynfields.js file from the server. Is there some sort of requirement for it to translate dynfields.html to dynfields.js on the fly? Do I have to set up my HTTP server (current Apache) to do so? Am I required to restart my web server after installing this plugin (I do not have access to do so).

I already uninstalled this plugin, so I can't give you any more details at the moment.

comment:11 Changed 4 years ago by james@…

Okay, so I was inspired to try again.

I renamed dynfields.html to dynfields.js, and removed the <script></script> tags from the file (so it's pure JavaScript). I rebuilt the egg and reinstalled the plugin (0.11 version). Guess what? It works!

So, yes, the problem is that the dynfields.js file is missing, or just isn't referenced properly. I'm not sure how you don't see this issue yourself; I'm thinking you must have some sort of auto-rewrite rule going on for yourself, or something that forces the interpretation of that html file as js. Either way, it's clear you just need to rename the file and remove the HTML from it, and it will work.

comment:12 Changed 4 years ago by anonymous

James, thanks for your persistence! At least now I can recommend a workaround for others that may have this problem.

However, converting the dynfields.html file to a dynfields.js file should not be required at all. There is no additional translation magic other than what Trac provides natively. Did you also modify the web_ui.py file (e.g., rename "dynfields.html" to "dynfields.js")?

comment:13 Changed 4 years ago by james@…

No, I did not modify web_ui.py, since it already references "dynfields.js" in there (there is no reference to dynfields.html in the file). Perhaps that's the problem? You have dynfields.html committed, but web_ui.py referenced dynfields.js - is it possible that you may not have committed changes to web_ui.py which change the reference to dynfields.html?

comment:14 Changed 4 years ago by anonymous

James, around line 48 you should see this:

    def process_request(self, req):
        data = {'triggers':self._get_triggers(req)}
        return 'dynfields.html', {'data': data},'text/javascript' 

Note the 'dynfields.html' being returned.

comment:15 Changed 4 years ago by anonymous

Interesting. I must have missed that; yes it's in the web_ui.py file. However, on line 38, there's:

add_script(req, '/dynfields/dynfields.js')

which clearly requires that the file be a .js file, and was the reason I kept getting a 404 on that file. I actually ended up just copying the file to the new extension, so technically my plugin egg file contains both files, which is why it works. I suppose the fix would be to rename all references to the same file.

comment:16 Changed 4 years ago by robguttman

Again, this is the way Trac is supposed to work. You will find that same pattern in many/all other plugins. I do not know why it's not working for you in this case. But at least you got it to work.

comment:17 Changed 4 years ago by robguttman

Actually, I'm curious - what web server are you using, James? Maybe it is blocking all html pages?

comment:18 Changed 4 years ago by rjollos

  • Description modified (diff)

comment:19 Changed 4 years ago by erne.castro@…

I've tried branches/0.12 and it did not work with trac 0.12, branches/0.11 works fine.

comment:20 Changed 3 years ago by robguttman

(In [9838]) refs #7946: renamed dynfields.js to dynfields.html to see if this solves the problem.

comment:21 Changed 3 years ago by anonymous

FYI, I experienced the same problem with Trac 0.12, DynamicFields 2.2.0dev, running on Ubuntu 10.04, Apache 2.2.14 under WSGI. Installing the 0.11 version of DynamicFields did the trick.

comment:22 Changed 3 years ago by robguttman

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

I believe that rev [9838] fixed this problem for the 0.11 branch. If you still exhibit this problem even after trying the latest version, please reopen this ticket.

Add Comment

Modify Ticket

Action
as closed .
as The resolution will be set. Next status will be 'closed'.
to The owner will be changed from robguttman. Next status will be 'closed'.
The resolution will be deleted. Next status will be 'reopened'.
Author


E-mail address and user name can be saved in the Preferences.

 
Note: See TracTickets for help on using tickets.