TypeError: iteration over non-sequence when open timeline via a user with non trac-admin permission (a user with trac-admin is ok, no error)

[solarxie@…]

如何重现

当进行 GET 操作于 /timeline, Trac产生内部错误.

(请在此附加详细情况)

系统信息

Trac	0.12b1
Babel	0.9.5
Docutils	0.6
FullBlog	0.1.1-r0
Genshi	0.6
mod_python	3.2.8
psycopg2	2.0.13 (dt dec ext pq3)
Pygments	1.3.1
Python	2.4.3 (#1, Sep 3 2009, 15:37:37) [GCC 4.1.2 20080704 (Red Hat 4.1.2-46)]
pytz	2010h
setuptools	0.6c9
Subversion	1.6.5 (r38866)

已启用插件

Python Traceback

Traceback (most recent call last):
  File "/usr/lib/python2.4/site-packages/trac/web/main.py", line 512, in _dispatch_request
    dispatcher.dispatch(req)
  File "/usr/lib/python2.4/site-packages/trac/web/main.py", line 233, in dispatch
    resp = chosen_handler.process_request(req)
  File "/usr/lib/python2.4/site-packages/trac/timeline/web_ui.py", line 135, in process_request
    available_filters += event_provider.get_timeline_filters(req)
TypeError: iteration over non-sequence

[Remy Blank]

Mmh, so here's one danger of localizing automatic error reports…

I see you have FullBlogPlugin installed, are there any others? Does the issue still happen with all plugins disabled?

[Remy Blank]

I can view the timeline correctly even in the situation you describe, so there must be something else.

[anonymous]

Replying to rblank:

I can view the timeline correctly even in the situation you describe, so there must be something else.

yes, very surprised.

1. there is multiple trac projects, only one project has such error, others ok.
2. this error happens after i upgrade my trac from 0.11 to 0.12b1.
3. for the project with error, if I login in with permission of TRAC-ADMIN, no error.
4. here are the projects:

​http://lzwsy1.gnway.net:8088/trac/his-mz/timeline ​http://lzwsy1.gnway.net:8088/trac/his-zy/timeline

[Remy Blank]

You didn't answer the question about plugins: do you use any others besides FullBlogPlugin?

[anonymous]

Replying to rblank:

You didn't answer the question about plugins: do you use any others besides FullBlogPlugin?

there are some other plugins:

[components]
acct_mgr.admin.accountmanageradminpage =disabled
acct_mgr.api.accountmanager = disabled
acct_mgr.htfile.htpasswdstore = disabled
acct_mgr.web_ui.accountmodule = disabled
acct_mgr.web_ui.loginmodule = dissabled
iniadmin.iniadmin.iniadminplugin = disabled
svnauthz.* = disabled
trac.web.auth.loginmodule = disabled
tracdiscussion.admin.discussionwebadmin = disabled
tracdiscussion.api.discussionapi = disabled
tracdiscussion.wiki.discussionwiki = disabled
tracfullblog.* = disabled
tracfullblog.admin.fullblogadminpanel = disabled
tracfullblog.core.fullblogcore = disabled
tracfullblog.db.fullblogsetup = disabled
tracfullblog.macros.bloglistmacro = disabled
tracfullblog.web_ui.fullblogmodule = disabled
tractags.* = disabled
tracusermanager.* = disabled
tracwysiwyg.* = disabled

tested, disabled all plugins, it did still happen.

[Remy Blank]

Got it: this happens when the user doesn't have CHANGESET_VIEW. It's fixed in [9645].

Thanks for testing and insisting!

[Christian Boos]

Glad you found the exact reason, but what about doing in addition:

trac/timeline/web_ui.py

@@ -132 +132 @@
 
         available_filters = []
         for event_provider in self.event_providers:
-            available_filters += event_provider.get_timeline_filters(req)
+            available_filters += event_provider.get_timeline_filters(req) or []
 
         filters = []
         # check the request or session for enabled filters, or use default

to make that code a bit more robust? (be lenient in what you accept…)

[anonymous]

Replying to rblank:

Got it: this happens when the user doesn't have CHANGESET_VIEW. It's fixed in [9645].

Thanks for testing and insisting!

if i want to fix the bug, just to update the file of …/trac/versioncontrol/web_ui/changeset.py as [9645], right? after i updated the file of changeset.py, [9136] disappeared, but a new bug appeared when i "browse source", as below:

==== 如何重现 ====

当进行 GET 操作于 `/browser`, Trac产生内部错误.

''(请在此附加详细情况)''


请求参数:
{{{
{'path': '/'}
}}}


==== 系统信息 ====

|| '''`Trac`''' || `0.12b1` ||
|| '''`Babel`''' || `0.9.5` ||
|| '''`Docutils`''' || `0.6` ||
|| '''`FullBlog`''' || `0.1.1-r0` ||
|| '''`Genshi`''' || `0.6` ||
|| '''`mod_python`''' || `3.2.8` ||
|| '''`psycopg2`''' || `2.0.13 (dt dec ext pq3)` ||
|| '''`Pygments`''' || `1.3.1` ||
|| '''`Python`''' || `2.4.3 (#1, Sep  3 2009, 15:37:37) ` [[br]] `[GCC 4.1.2 20080704 (Red Hat 4.1.2-46)]` ||
|| '''`pytz`''' || `2010h` ||
|| '''`setuptools`''' || `0.6c9` ||
|| '''`Subversion`''' || `1.6.5 (r38866)` ||

==== 已启用插件 ====


==== Python Traceback ====
{{{
Traceback (most recent call last):
  File "/usr/lib/python2.4/site-packages/trac/web/main.py", line 512, in _dispatch_request
    dispatcher.dispatch(req)
  File "/usr/lib/python2.4/site-packages/trac/web/main.py", line 255, in dispatch
    content_type)
  File "/usr/lib/python2.4/site-packages/trac/web/chrome.py", line 828, in render_template
    template = self.load_template(filename, method=method)
  File "/usr/lib/python2.4/site-packages/trac/web/chrome.py", line 799, in load_template
    return self.templates.load(filename, cls=cls)
  File "/usr/lib/python2.4/site-packages/Genshi-0.6-py2.4.egg/genshi/template/loader.py", line 246, in load
TemplateNotFound: Template "browser.html" not found

}}}

[Remy Blank]

Replying to cboos:

to make that code a bit more robust? (be lenient in what you accept…)

Why not? The docstring explicitly mentions that a list must be returned, but I have nothing against making the code more robust.

If you commit the change, you may want to revert my fix.

[lkraav <leho@…>]

hmmm, this fix could possibly have a helping effect on comment:11:ticket:6644, going to debug now.

[Remy Blank]

Replying to cboos:

Glad you found the exact reason, but what about doing in addition:

Then again, why not make all "enumeration" methods in our interfaces more robust? The following patch does just that.

Thoughts?

[Remy Blank]

Make enumerations from interfaces more robust.

[Christian Boos]

Replying to rblank:

Replying to cboos:

Glad you found the exact reason, but what about doing in addition:

Then again, why not make all "enumeration" methods in our interfaces more robust? The following patch does just that.

Thoughts?

Looks like a good thing to do, yes.

[Remy Blank]

Patch applied in [9665].