Edgewall Software
Modify

Ticket #3915 (closed defect: worksforme)

Opened 5 years ago

Last modified 5 years ago

Link missing for folders in the Browser component

Reported by: aogier@… Owned by: cboos
Priority: normal Milestone:
Component: version control/browser Version: 0.10
Severity: normal Keywords: browser access denied
Cc: aogier@…, robinbryce@…
Release Notes:
API 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

folder_bug.PNG (11.3 KB) - added by aogier@… 5 years ago.
Screenshot
generated_code.zip (559 bytes) - added by aogier@… 5 years ago.
Part of the generated HTML file (zip format because akismet kills the HTML)

Download all attachments as: .zip

Change History

Changed 5 years ago by aogier@…

Screenshot

Changed 5 years ago by aogier@…

Part of the generated HTML file (zip format because akismet kills the HTML)

comment:1 Changed 5 years ago by cboos

  • Resolution set to duplicate
  • Status changed from new to closed

See #3851, same issue (the "Access Denied" title is only present in the 0.9 browser.cs template)

comment:2 Changed 5 years ago by aogier@…

  • Resolution duplicate deleted
  • Status changed from closed to 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 Changed 5 years ago by cboos

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 Changed 5 years ago by aogier@…

  • Resolution set to fixed
  • Status changed from reopened to 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 Changed 5 years ago by cboos

  • Resolution fixed deleted
  • Status changed from closed to reopened

(reopening to set resolution to worksforme)

comment:6 follow-up: Changed 5 years ago by cboos

  • Resolution set to worksforme
  • Status changed from reopened to closed

we reserve fixed for issues that needed actual code changes

comment:7 in reply to: ↑ 6 Changed 5 years ago by anonymous

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 Changed 5 years ago by robinbryce@…

  • Cc robinbryce@… added

The above comment, on stale installs and bad .egg dists, was from me

View

Add a comment

Modify Ticket

Change Properties
<Author field>
Action
as closed
The resolution will be deleted. Next status will be 'reopened'
to The owner will be changed from cboos. Next status will be 'closed'
Author


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

 
Note: See TracTickets for help on using tickets.