#3915 closed defect (worksforme)
Link missing for folders in the Browser component
Reported by: | Owned by: | Christian Boos | |
---|---|---|---|
Priority: | normal | Milestone: | |
Component: | version control/browser | Version: | 0.10 |
Severity: | normal | Keywords: | browser access denied |
Cc: | aogier@…, robinbryce@… | Branch: | |
Release Notes: | |||
API Changes: | |||
Internal Changes: |
Description
In my Browser component, all the directories don't have any links, (and no images), but the files have. When I let my mouse on the space where there should be the image of a folder, I have a notice written "Access Denied".
I'll attach a portion of the generated HTML code.
I had a look to the browser.cs file and I don't understand how is it possible, because for each "folder" the title should be "Browse Directory".
Moreover, I have the rights to access to the folder and subfolders, because, if I add "/gestion_projet" in the URL, then the files of the folder "/trunk/gestion_projet" are listed… and once again, the sub-folders havn't got any link.
Attachments (2)
Change History (10)
by , 18 years ago
Attachment: | folder_bug.PNG added |
---|
by , 18 years ago
Attachment: | generated_code.zip added |
---|
Part of the generated HTML file (zip format because akismet kills the HTML)
comment:1 by , 18 years ago
Resolution: | → duplicate |
---|---|
Status: | new → closed |
See #3851, same issue (the "Access Denied" title is only present in the 0.9 browser.cs template)
comment:2 by , 18 years ago
Resolution: | duplicate |
---|---|
Status: | closed → reopened |
I'm already in 0.10 (I've executed the .exe installer, and also, after, the zip method with "python setup.py install")… Is there any cache or something ?
comment:3 by , 18 years ago
You must have a 0.9 browser.cs template loaded, as the "Access Denied" string can only be found there. Read again my last comment in ticket #3851, you should look in your trac.ini.
comment:4 by , 18 years ago
Resolution: | → fixed |
---|---|
Status: | reopened → closed |
Okay, you were right, the [trac] templates_dir
in my trac.ini was in another place in my filesystem. So I just copied the templates files (in the /templates folder of the zip) on the destination folder. Now it works.
Thanks.
comment:5 by , 18 years ago
Resolution: | fixed |
---|---|
Status: | closed → reopened |
(reopening to set resolution to worksforme)
follow-up: 7 comment:6 by , 18 years ago
Resolution: | → worksforme |
---|---|
Status: | reopened → closed |
we reserve fixed for issues that needed actual code changes
comment:7 by , 18 years ago
Replying to cboos:
we reserve fixed for issues that needed actual code changes
I ran into this one upgrading from 0.10dev to 0.10.3. I think the basic problem is that the rendering inteligence in browser.cs hides version skew issues in the case where a bad upgrade or re-install has resulted in mixed versions of trac being available for import. Once the permissions pass in browser.py, it pretty much just renders the content it gets from ClearSilver. In a lot of cases, even when it appears to call back into python, the ClearSilver stuff is agnostic to the semantics of the content. I would guess that the Genshi integration on the trunk will make this issue moot, or at least make it a lot more viable to detect.
The mixed version issue can happen within the same process, depending on if and when pkg_resources is imported. And it can happen in different trac processes depending on PYTHONPATH setup, trac-admin vs mod_python handler vs fast-cgi etc.
In my case it turned out I had both a bogus trac egg for version 0.10.3 and a vanilla distutils install of 0.10dev in my site-packages. The bogus egg did not contain any bytecode compiled python files (no .pyc's or .pyo's) whilst the distutils install contained .pyo's. I have an apache2/mod_python setup here: http://trac.wiretooth.com/public/.
It is important to note that my apache2/trac-*.logs, apache2/svn-*.logs and all other server logging showed NO errors. And the version string on the upgraded wiki pages all reported version 0.10.3.
When I realised that nothing in 0.10.3 contained the string 'Access Denied' (find ./trac-0.10.3 | xargs grep "Access Denied"
) I knew I had version skew.
Alarmingly, I have not been able to track down how I came to have the rotten egg on my path - one that did not contain pre byte compiled python files. The only clue is that during my somewhat haphazard upgrade I decided to install the spam and web administration plugins. In any case somewhere out there, or produceable as a result of prating around with easy_install during the upgrade, there exists a 0.10.3 distribution that creates an egg with no .pyc's and this can end up in site-packages beside the version you thought you just upgraded.
comment:8 by , 18 years ago
Cc: | added |
---|
The above comment, on stale installs and bad .egg dists, was from me
Screenshot