Opened 7 years ago

Strange behavior when custom defined menu item is not enabled

Reported by: Owned by: rjollos cbalan normal MenusPlugin normal 0.11

Below is a partial view of my configuration, which defines an entire menu hierarchy with top-level name Code. Notice that BROWSER_VIEW is the only permissions referenced in this menu hierarchy.

The menu hierarchy looks like this:

# Code: Repos: {Browser, SVN, WebSVN}, RevTree, Review, Tags
codegroup.label = Code
codegroup.enabled = 1
codegroup.hide_if_no_children = 1
codegroup.order = 3
codegroup.parent = top
repositorygroup.label = Repos
repositorygroup.enabled = 1
repositorygroup.hide_if_no_children = 1
repositorygroup.order = 301
repositorygroup.parent = codegroup
browser.label = Browser
browser.order = 302
browser.parent = repositorygroup
svn.parent = none
svnx.label = SVN
svnx.enabled = 1
svnx.href = /tractab/svn
svnx.order = 303
svnx.parent = repositorygroup
svnx.perm = BROWSER_VIEW
websvn.parent = none
websvnx.label = WebSVN
websvnx.enabled = 1
websvnx.href = /tractab/websvn
websvnx.order = 304
websvnx.parent = repositorygroup
websvnx.perm = BROWSER_VIEW
revtree.label = Rev Tree
revtree.order = 305
revtree.parent = codegroup
codereview.parent = none
codereviewx.enabled = 0
codereviewx.label = Review
codereviewx.href = /tractab/codereview
codereviewx.order = 306
codereviewx.parent = codegroup
codereviewx.perm = BROWSER_VIEW
codetags.enabled = 1
codetags.order = 307
codetags.parent = codegroup


I should briefly explain what may be a confusing aspect of my configuration.

Entries such as svn and websvn are created using the TracTabPlugin. We have found that when using the TracTabPlugin with the MenusPlugin, it is necessary to hide the buttons created by the TracTabPlugin and create new buttons that point to the URLs created by the TracTabPlugin. If one simply tries to set properties for the navbar entries created by the TracTabPlugin, the properties seem to be ignored. I have seen this behavior for buttons created by other plugins as well (e.g. HudsonTracPlugin). However, that is a separate issue from what I am reporting here.

In the configuration above, I initially did not have codegroup.enabled = 1. With that configuration, a user that did not have the BROWSER_VIEW permission was not able to access any part of Trac. The MenusPlugin did not seem to work at all for a user without BROWSER_VIEW permissions. The menus would be arranged in a flat structure rather than hierarchically. I will attach a screen capture of the error, which was:

Trac detected an internal error:
KeyError: 'children'


When the BROWSER_VIEW permission was granted, the menus appears correctly (a screen capture of the functioning configuration can be seen in this ticket).

Also, I could not find anything significant in the log file with the log level set to DEBUG, other than:

2009-10-30 14:00:00,485 Trac[main] DEBUG: 40 unreachable objects found.
2009-10-30 14:00:00,486 Trac[main] DEBUG: 956 unreachable objects found


These errors were not present when Trac is accessed with a user having BROWSER_VIEW permissions.

Although the initial configuration was not valid (it is well documented that self defined entries require enabled = 1: MenusPlugin#Configuration) and I have a solution to this issue, the behavior was very odd and somewhat difficult to track down, so it would be worthwhile to improve the behavior.

Changed 7 years ago by rjollos

Screen capture of error.

comment:1 in reply to: ↑ description Changed 7 years ago by rjollos

I should briefly explain what may be a confusing aspect of my configuration.

Entries such as svn and websvn are created using the TracTabPlugin. We have found that when using the TracTabPlugin with the MenusPlugin, it is necessary to hide the buttons created by the TracTabPlugin and create new buttons that point to the URLs created by the TracTabPlugin. If one simply tries to set properties for the navbar entries created by the TracTabPlugin, the properties seem to be ignored. I have seen this behavior for buttons created by other plugins as well (e.g. HudsonTracPlugin). However, that is a separate issue from what I am reporting here.

I report this behavior in a separate ticket, #6130.

comment:2 Changed 6 years ago by rjollos

• Description modified (diff)