gmane.comp.version-control.subversion.trac.devel

[Trac-dev] Re: Semi-intelligent column removal in ticket query

Erik Bray — 2008-12-01T16:42:03

On Sat, Nov 29, 2008 at 4:18 AM, Remy Blank pobox.com> wrote: Not really at the moment, though there is a patch I'm about to go work on concerning default values for enum fields. But I'll attach that to a ticket when it's done. Sounds like a good compromise. --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Trac Development" group. To post to this group, send email to trac-dev< at >googlegroups.com To unsubscribe from this group, send email to trac-dev+unsubscribe< at >googlegroups.com For more options, visit this group at http://groups.google.com/group/trac-dev?hl=en -~----------~----~----~----~------~----~------~--~---

[Trac-dev] Re: Semi-intelligent column removal in ticket query

Remy Blank — 2008-11-29T09:18:26

I came to the same conclusion. It's not the first time that you mention having removed or changed something in your installations and that has been requested later independently. Any other good ideas that I could implement? I'm good at cleaning up :-) I have implemented something slightly different: I have removed the algorithm from get_all_columns(), which is used to create the list of check boxes, so all checkboxes are always present. And I have moved it into get_default_columns(), which is used when no columns are specified in the query or URL (i.e. when coming to the query page from a [query:...] link that has no column specification). That way, existing queries should not change too much.

[Trac-dev] Re: Semi-intelligent column removal in ticket query

Erik Bray — 2008-11-28T18:12:31

On Wed, Nov 26, 2008 at 7:12 PM, Remy Blank pobox.com> wrote: +1 here. I've already removed it in my own Trac instances for the reasons you've described. At one point I spent some time trying to make this a little more dynamic so that columns would be re-added if the grouping column was changed, but then you had to keep track of whether or not that column was enabled or disabled to begin with, and it just becomes too cumbersome. Easier to just remove the restriction and allow users to add a column even if the results are already grouped by that column. Some of my users actually wanted to be able to do that so that they could include a column when doing a CSV export, but still view the results grouped by that column. --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Trac Development" group. To post to this group, send email to trac-dev< at >googlegroups.com To unsubscribe from this group, send email to trac-dev+unsubscribe< at >googlegroups.com For more options, visit this group at http://groups.google.com/group/trac-dev?hl=en -~----------~----~----~----~------~----~------~--~---

[Trac-dev] Semi-intelligent column removal in ticket query

Remy Blank — 2008-11-27T00:12:14

#7659 reports that on the ticket query page, a page update is required to display the column checkbox for the "resolution" field. That is, as long as the query constraints do not include closed tickets, the column can't be selected. The same applies to the grouping field: if the currently-displayed query includes grouping, the field used for grouping cannot be displayed, even if the grouping is removed, without a page update. This is due to a column removal algorithm prefixed with the following comment: # Semi-intelligently remove columns that are restricted to a single # value by a query constraint. This section dates from [1162] and has not been modified (much) since then. I suppose that at that point, an update was required anyway to add or remove filters, and the whole filter selection was less dynamic than it is today. Long story short, does anybody have anything against removing this "semi-intelligent" column removal algorithm altogether?

[Trac-dev] Re: Trunk and Genshi 0.5.1.

Remy Blank — 2008-11-26T22:33:50

I have set up a 2.4 test environment, and the only difference with 2.5 is that I hit #7684 with Genshi 0.5.1 even though I have not installed Babel (with 2.5, this combination works). If I upgrade to Genshi trunk, all tests pass.

[Trac-dev] Re: How to add link with add_ctxtnav() with non-ASCII characters

Christian Boos — 2008-11-26T09:16:01

watho wrote: You've hit a problem with Python, not with Trac. If you have non-ascii character in your source file, you need to define an encoding for that file, as the error message above says (and you'll find the details in the linked document). Assuming you're past the first error, you need to give a backtrace here. Anyway, that's not the way to localize your plugin. Original strings in the source code must be language neutral (english here). Right, that's because support for localizing plugins has only been added a few days ago. Some documentation will follow. Another difficulty in your case (for the add_ctxtnav) is that the API will slightly change in the coming days as well, in order to better support localization, so be patient ;-)

[Trac-dev] Re: How to add link with add_ctxtnav() with non-ASCII characters

watho — 2008-11-26T07:24:10

I forgot: Trac: 0.12dev-r2 trunk rev. 7715 Python: 2.5.2 (r252:60911, Jul 31 2008, 17:28:52) [GCC 4.2.3 (Ubuntu 4.2.3-2ubuntu7)] setuptools: 0.6c8 MySQL: server: "5.0.51a-3ubuntu5.4", client: "5.0.51a", thread-safe: 1 MySQLdb: 1.2.2 Genshi: 0.6dev jQuery:1.2.6 On 25 Nov., 16:19, watho gmx.net> wrote: --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Trac Development" group. To post to this group, send email to trac-dev< at >googlegroups.com To unsubscribe from this group, send email to trac-dev+unsubscribe< at >googlegroups.com For more options, visit this group at http://groups.google.com/group/trac-dev?hl=en -~----------~----~----~----~------~----~------~--~---

[Trac-dev] How to add link with add_ctxtnav() with non-ASCII characters

watho — 2008-11-25T15:19:49

In my plugin I want to add a navigation-item with the add_ctxtnav()- method in my foreign language (german) which contains non-ASCII characters like ä,ö and ü. I get the following error-message: SyntaxError: Non-ASCII character '\xc3' in file ../src/systemsdb/ web_ui.py on line 86, but no encoding declared; see http://www.python.org/peps/pep-0263.html for details (web_ui.py, line 86) I looked at http://trac.edgewall.org/wiki/TracDev/UnicodeGuidelines and tried every combination of to_unicode, to_utf8(), unicode.decode (), unicode.encode() i can think of. I have successfully created Unicode-Links with tag.a(to_unicode ('zurück'), href=self.env.href.systemsdb())) but i cant call: add_ctxtnav(req, tag.a(to_unicode('zurück'), href=self.env.href.systemsdb())). I have looked for a common way to write localized plugins, but didn't find any useful. MfG WaTho --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Trac Development" group. To post to this group, send email to trac-dev< at >googlegroups.com To unsubscribe from this group, send email to trac-dev+unsubscribe< at >googlegroups.com For more options, visit this group at http://groups.google.com/group/trac-dev?hl=en -~----------~----~----~----~------~----~------~--~---

[Trac-dev] Re: Trunk and Genshi 0.5.1.

Remy Blank — 2008-11-25T07:23:58

Considering that it works on 2.5, it must be something that changed from 2.4 to 2.5, or a difference in build environment. [7713] imported functools, which was introduced in 2.5, but I fixed it in [7714]. I went through [7700-7715] but couldn't find any "suspect" import. It would be useful to have the part of the tracd logfile where the exception is shown, or to connect to the tracd server, which should normally show an exception (at least that's what I had yesterday with [7713]).

[Trac-dev] Re: Trunk and Genshi 0.5.1.

Jonas Borgström — 2008-11-25T06:14:13

Remy Blank wrote: I just noticed that since [7714] the linux-py24 build deadlocks for some reason. I tried restarting the build but the same thing happened again. The log seems to indicate that some test fail but the build is never aborted by bitten. The standalone web server process also seems to still be running. I'm away traveling today so I can't look at right now but if anyone is interested the interesting part of the log is available here: http://pastebin.ca/1266442 / Jonas --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Trac Development" group. To post to this group, send email to trac-dev< at >googlegroups.com To unsubscribe from this group, send email to trac-dev+unsubscribe< at >googlegroups.com For more options, visit this group at http://groups.google.com/group/trac-dev?hl=en -~----------~----~----~----~------~----~------~--~---

[Trac-dev] Re: Trunk and Genshi 0.5.1.

Remy Blank — 2008-11-24T22:50:43

Ah, that's why [7708] built ok on 2.5. I was wondering about that. Yes, with [7714] it should work again.

[Trac-dev] Trunk and Genshi 0.5.1.

Jonas Borgström — 2008-11-24T22:09:45

Hi all, I just wanted to give everyone a heads up that I've moved the linux-py25 build slave to the advanced-i18n branch of Genshi. the linux-py24 slave is still using Genshi 0.5.1 for now. Trunk is still supposed to work with Genshi 0.5.1, right? / Jonas --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Trac Development" group. To post to this group, send email to trac-dev< at >googlegroups.com To unsubscribe from this group, send email to trac-dev+unsubscribe< at >googlegroups.com For more options, visit this group at http://groups.google.com/group/trac-dev?hl=en -~----------~----~----~----~------~----~------~--~---

[Trac-dev] Re: Getting error on passing values to python to Genshi

Erik Bray — 2008-11-19T18:14:30

If you're going to insist on top posting then I will too, just for the sake of consistency. It looks like you're implementing an admin panel somewhere whose render_admin_panel() method is returning an int for data instead of a dict like it should be. It has nothing directly to do with the code you posted though. Check your render_admin_panel() method. On Tue, Nov 18, 2008 at 11:26 PM, velappan velappan gmail.com> wrote: --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Trac Development" group. To post to this group, send email to trac-dev< at >googlegroups.com To unsubscribe from this group, send email to trac-dev+unsubscribe< at >googlegroups.com For more options, visit this group at http://groups.google.com/group/trac-dev?hl=en -~----------~----~----~----~------~----~------~--~---

[Trac-dev] MySQLUnicodeCursor and blob data

Dalius — 2008-11-19T07:47:02

Hello, I think I have found bug in trac 0.11.2.1. I have upgraded to it and my AuthOpenIdPlugin stopped to work. After little analysis I have found that problem is in trac's mysql_backend: http://svn.edgewall.org/repos/trac/trunk/trac/db/mysql_backend.py The problem is that it tries to decode BLOB data column and naturally fails to do that. Regards, Dalius --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Trac Development" group. To post to this group, send email to trac-dev< at >googlegroups.com To unsubscribe from this group, send email to trac-dev+unsubscribe< at >googlegroups.com For more options, visit this group at http://groups.google.com/group/trac-dev?hl=en -~----------~----~----~----~------~----~------~--~---

[Trac-dev] Re: Getting error on passing values to python to Genshi

velappan velappan — 2008-11-19T04:26:43

Hi , This is the trace back yo that error Traceback (most recent call last): File "/usr/local/lib/python2.5/site-packages/Trac-0.11.1-py2.5.egg/ trac/web/main.py", line 423, in _dispatch_request dispatcher.dispatch(req) File "/usr/local/lib/python2.5/site-packages/Trac-0.11.1-py2.5.egg/ trac/web/main.py", line 197, in dispatch resp = chosen_handler.process_request(req) File "/usr/local/lib/python2.5/site-packages/Trac-0.11.1-py2.5.egg/ trac/admin/web_ui.py", line 132, in process_request data.update({ AttributeError: 'int' object has no attribute 'update' On Nov 17, 11:04 pm, "Erik Bray" gmail.com> wrote: --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Trac Development" group. To post to this group, send email to trac-dev< at >googlegroups.com To unsubscribe from this group, send email to trac-dev+unsubscribe< at >googlegroups.com For more options, visit this group at http://groups.google.com/group/trac-dev?hl=en -~----------~----~----~----~------~----~------~--~---

[Trac-dev] Re: Custom Ticket priority property

Greg Troxel — 2008-11-19T01:38:51

We've recently deployed Trac at our office. Part of that I would like to change the priority field for tickets as follows: - priorities will be assigned a numerical value from 1 to 100 - 100 is the highet priority and 1 the lowest (or the other way around can work as well) - the top 50 (or trac.ini controlled value) prioritised tickets must have uniqe priorities (ie: if 100 is the highest priority, there can only be one ticket with a priority of 100, only one ticket with 90, etc, but multiple priority 50 or below tickets can exist). - default priority is 50 - the system must adjust ticket priorities in case of a conflict Any other pointers, warnings, concerns appreciated. My advice is to stick to some number of priorities for which you can articulate definitions, and just assign them. My project is using trivial/minor/major/critical/blocker working towards a demonstration and that's been good. If you really think you need an ordering like that, I suggest writing a plugin to give you an extra field in each ticket, which is basically sort order, and let that be separate, and thus allow manual sorting of tickets. This lets whoever wants to set the ordering set it, while not confusing it with an absolute priority.

[Trac-dev] Custom Ticket priority property

Mike Mazur — 2008-11-18T22:25:36

Hi, I'm new to using Trac beyond the occasional visit to a Trac-powered website. Also new to Trac development. We've recently deployed Trac at our office. Part of that I would like to change the priority field for tickets as follows: - priorities will be assigned a numerical value from 1 to 100 - 100 is the highet priority and 1 the lowest (or the other way around can work as well) - the top 50 (or trac.ini controlled value) prioritised tickets must have uniqe priorities (ie: if 100 is the highest priority, there can only be one ticket with a priority of 100, only one ticket with 90, etc, but multiple priority 50 or below tickets can exist). - default priority is 50 - the system must adjust ticket priorities in case of a conflict I'll elaborate on that last point a little. If there already exist tickets with priorities 90-95, and a new ticket with priority 95 must be added, the existing ticket priorities are adjusted to be 89-94 automatically. The same would happen when a ticket is edited. In effect, a sort of cascading priority decrement until there are no longer any conflicts above 50. Is anybody already working on something similar? Maybe this already exists as part of another plugin I haven't yet found? If not, I plan to work on a plugin that does this. What would be the best approach, to modify the existing priority field that tickets have? or maybe add a custom field that behaves this way? Any other pointers, warnings, concerns appreciated. Thanks, Mike --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Trac Development" group. To post to this group, send email to trac-dev< at >googlegroups.com To unsubscribe from this group, send email to trac-dev+unsubscribe< at >googlegroups.com For more options, visit this group at http://groups.google.com/group/trac-dev?hl=en -~----------~----~----~----~------~----~------~--~---

[Trac-dev] Re: rename repository, automatically resync

Emmanuel Blot — 2008-11-18T21:47:50

As a side note: resync is required when you change your environment/repository configuration. It is not a "maintenance" task so it is not expected to happen on a regular basis. Cheers, Manu --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Trac Development" group. To post to this group, send email to trac-dev< at >googlegroups.com To unsubscribe from this group, send email to trac-dev+unsubscribe< at >googlegroups.com For more options, visit this group at http://groups.google.com/group/trac-dev?hl=en -~----------~----~----~----~------~----~------~--~---

[Trac-dev] Re: rename repository, automatically resync

Evan Dower — 2008-11-18T15:12:48

A stack trace and a timeout are certainly not the only options. One could start the resync in another thread or process and display an informative message ("Due to a recent configuration change, we're busily resynchronizing with the repository. Unfortunately, some functionality may be unavailable until we have finished."), or even bypass the cache and go directly to the repository during the resync. Certainly this is a better experience for end-users. The opposing viewpoint is that the only people who can cause this are people who can do something about it: admins. Resyncs are partial outages, and if you're doing something that requires one, you need to message your users appropriately, possibly scheduling it in advance. Resyncs only happen in fairly rare circumstances when you're making major disruptive changes. I should note that a feature being a better experience for end-users doesn't necessarily mean you should implement it. There is some possibility that admins will do resyncs more frequently if they know that they're handled automatically. Resyncs are inherently disruptive to users, even if we do a good job of making them automated. A good admin will try to avoid the sorts of disruptive changes that lead to them. Also, it may be that this feature would just be nice to have, while other features are critically important. That is, this feature may be low priority, in which case the developers should be working on higher priority stuff. --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Trac Development" group. To post to this group, send email to trac-dev< at >googlegroups.com To unsubscribe from this group, send email to trac-dev+unsubscribe< at >googlegroups.com For more options, visit this group at http://groups.google.com/group/trac-dev?hl=en -~----------~----~----~----~------~----~------~--~---

[Trac-dev] Re: rename repository, automatically resync

Christian Boos — 2008-11-18T17:59:08

rupert.thurner< at >gmail.com wrote: Well, no real problem, I just wanted to put that thread to rest ;-) Sorry if I came up too harsh. Expect a 10% slowdown for Genshi without _speedups. But Genshi in general is slow, with or without the speedups, so 0.11 is and will probably always be slower than equivalent 0.10 Trac, as we traded speed for flexibility and ease of maintenance of the templates.

[Trac-dev] Re: rename repository, automatically resync

2008-11-18T15:40:44

On Nov 13, 12:43 pm, "Emmanuel Blot" gmail.com> wrote: and the problem would be what? the "of course i like stack trace much more, it is so helpful. i know immediately something is broken and i can better bother the admin who then has to log in and start it on the command line. and of course other users as well should get this informative stack trace until the resync has completed" ? --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Trac Development" group. To post to this group, send email to trac-dev< at >googlegroups.com To unsubscribe from this group, send email to trac-dev+unsubscribe< at >googlegroups.com For more options, visit this group at http://groups.google.com/group/trac-dev?hl=en -~----------~----~----~----~------~----~------~--~---