Opened 16 years ago
Last modified 9 years ago
#6129 new defect
Strange behavior when custom defined menu item is not enabled
| Reported by: | Ryan J Ollos | Owned by: | |
|---|---|---|---|
| Priority: | normal | Component: | MenusPlugin |
| Severity: | normal | Keywords: | |
| Cc: | Trac Release: | 0.11 |
Description (last modified by )
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.
Attachments (1)
Change History (4)
Changed 16 years ago by
| Attachment: | MenusPluginError.png added |
|---|
comment:1 Changed 16 years ago by
Replying to rjollos:
I should briefly explain what may be a confusing aspect of my configuration.
Entries such as
svnandwebsvnare 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 15 years ago by
| Description: | modified (diff) |
|---|
comment:3 Changed 9 years ago by
| Owner: | Catalin BALAN deleted |
|---|




Screen capture of error.