{10} Assigned, Active Tickets by Owner (Full Description) (72 matches)

When creating a bug ticket, our customers oftentimes attach project files that illustrate the problems. It would save our developers time to be able to download these attachments with one click (instead of a click, a scroll down, another click, and a back-button press).

I would like trac to have basic time reporting as a module.

The (logged in) user should be able to add that he/she worked for X hrs with something and add a short description of what. This time report could refer to a ticket and/or a changeset.

I am not familiar with the internals of trac, but I think that this could just be a new table in the DB and some basic templates/function to add and view data.

I had some trouble with setting up a policy where the anonymous user could see only the front page of the wiki (wiki/WikiStart), but not the rest of the wiki without further authorisation through logging in. I used the authz_policy.py and had the following in the associated authz file:

[groups]
superdevs = me

[wiki:WikiStart]
anonymous = WIKI_VIEW

[wiki:*]
anonymous =

[*]
@superdevs = TRAC_ADMIN
anonymous = MILESTONE_VIEW, ROADMAP_VIEW, TIMELINE_VIEW

According to the docs in the authz_policy.py file, order of the directives mattered. The first directive should have allowed anonymous visitors access to the front page, while the second directive dissallowed anonymous browsing of the rest of the wiki. Instead, this resulted in an error:

No handler matched request to /wiki/WikiStart

I talked to "aat" on the IRC channel and he came up with the following:

the issue is that trac checks for access to AT LEAST ONE resource
in a realm by just checking if the user has the permission on <realm>

"aat" also provided a patch and stated that he would try and come up with something better soon.

Everyone seems to agree that someone should create a trac hack out of this. Anyone out there have copious amounts of free time for that?

It would be good for plugins if parsing of wiki text will be broken to two stages. first take the text and convert to some data object tree (ala DOM, but with wiki orientation, so nodes are 'text', 'macro', 'link' etc.), then different formatters can go over the tree and format it, and plugins can search it.

I still get way too many database is locked errors. This morning, I simply tried to log in and the server was not loaded (approx. half of the threads were "_" Waiting for connection).

Traceback (most recent call last):
  File "/usr/lib/python2.3/site-packages/trac/web/main.py", line 314, in dispatch_request
    dispatcher.dispatch(req)
  File "/usr/lib/python2.3/site-packages/trac/web/main.py", line 186, in dispatch
    req.session = Session(self.env, req)
  File "/usr/lib/python2.3/site-packages/trac/web/session.py", line 52, in __init__
    self.promote_session(sid)
  File "/usr/lib/python2.3/site-packages/trac/web/session.py", line 125, in promote_session
    "AND authenticated=0", (sid,))
  File "/usr/lib/python2.3/site-packages/trac/db/util.py", line 47, in execute
    return self.cursor.execute(sql_escape_percent(sql), args)
  File "/usr/lib/python2.3/site-packages/trac/db/sqlite_backend.py", line 44, in execute
    args or [])
  File "/usr/lib/python2.3/site-packages/trac/db/sqlite_backend.py", line 36, in _rollback_on_error
    return function(self, *args, **kwargs)
OperationalError: database is locked

Jonas/Christopher, can one of you attach a recent gzipped dump of the t.e.o Trac log here? I'd like to make some stats about the locks frequency. Ideally I'd like to understand why this still happens so frequently and find ways to improve the situation...

Beside locks, I'm also frequently seeing blank pages when going on the Markup Trac. But probably that's a different issue.

ie http://www.splitbrain.org/dokuwiki/wiki:dokuwiki

I am now able to use the non-image spam-filter-captcha handler. However, after resolving the equation, I have to start over with a new ticket. Assuming that the person spent a long time submitting the ticket, it would probably be preferable to submit the ticket that they were trying to fill out the first time.

This is a follow up to #7148

Some .doc files have an application/rdf mime type, e.g. Abiword export-as-doc actually saves a RTF file with a .doc filename. These files are not handled correctly by the Trac MIME viewer, since those RTF files are incorrectly shown as text. The special handling code for RTF (and PostScript and PDF) does not catch this case.

The fix is quite simple:

• Detect .doc and .dot files as application/msword
• Add application/msword to the TREAT_AS_BINARY list

Trivial patch below:

--- trac/mimeview/api.py.orig	2008-04-03 23:24:33.000000000 +0200
+++ trac/mimeview/api.py	2008-04-03 23:24:40.000000000 +0200
@@ -76,6 +76,7 @@
     'application/pdf':        ['pdf'],
     'application/postscript': ['ps'],
     'application/rtf':        ['rtf'],
+    'application/msword':     ['doc', 'dot'],
     'application/x-sh':       ['sh'],
     'application/x-csh':      ['csh'],
     'application/x-troff':    ['nroff', 'roff', 'troff'],
@@ -674,7 +675,8 @@
     TREAT_AS_BINARY = [
         'application/pdf',
         'application/postscript',
-        'application/rtf'
+        'application/rtf',
+        'application/msword',
     ]
 
     def get_quality_ratio(self, mimetype):

Please include this in your upcoming releases.

Sincerely,

Wouter Bolsterlee <uws@…>

Problem

Trac provides a fast, easy and flexible way to relate Trac objects together, by the use of TracLinks in the WikiFormatting.

However, there's no automatic support for back-linking. This lack has been noticed in several circumstances:

• BackLinks for Wiki pages (tickets #611 and #646, the latter containing a [http:/trac/ticket/646#change_4 note] which also highlights the genericity of the problem)
• Related Changesets for a given Ticket (ticket #508)
• Ticket dependencies and other relationships (tickets #31 and #226)

Instead, the backlinking is done manually. For example, when closing a ticket with a resolution of duplicate, the convention is to comment the closing of the ticket by saying this is a duplicate of #xyz and to mention the existence of the duplicate ticket on the original #xyz ticket. With a generalized backlinking facility, this would cease to be necessary.

Solution

What I would propose is that every relationship that gets detected while parsing new wiki content is recorded. Then, each wiki, changeset and ticket page could contain a See also: section at the end, listing the other objects that contain TracLinks targeting it, along with a bit of context, to catch the semantic of the link as well.

Example given:

Consider the following wiki OutstandingPatches page:

= Outstanding Patches page = 

I think that the patches #187, #909, #919, #944 and #948 are great!

Then, each time this page is edited, the content of an XREF (source, target, context table would be cleared for this page:

delete from XREF where source = 'wiki:OutstandingPatches'

and when the content is processed, each time a TracLink is detected, the table would be filled:

insert into XREF values ('wiki:OutstandingPatches',
                         'ticket:187',
                         'I think that the patches #187, #909, #919, #944 and #948 are great!')

Then, while browsing #187, one could easily get the backlinks:

select source, context from XREF where target='ticket:187'

in order to create the following output at the end of the ticket page:

Of course, I'm willing to provide a patch for that, but I would like to get some feedback before.

-- Christian

It would be good to have a list of pages that aren't linked to from anywhere.

Example: http://moinmoin.wikiwikiweb.de/OrphanedPages

At the moment when you copy-n-paste code snippets from Trac's source browser (I often do) it also copies the line numbers, which is almost never what you want. To get code without the line numbers, you have to scroll down and click the "Plain Text" version, find your place again, and then do the copy and paste.

It'd be nice if the Trac source file browser had a little JavaScript link, called "Toggle line numbers", that toggled the line numbers on and off, making copy-n-paste really clean and simple. (The toggle link could be placed in the table cell to the right of the "Line" heading cell at the top-left of the table.)

See the further discussion (agreement?) on the trac-users group: http://groups.google.com/group/trac-users/browse_frm/thread/71da6e9b5554b89c

It shouldn't be much code, especially with jQuery -- Ted Gifford posted one possible solution: http://groups.google.com/group/trac-users/msg/846b21eb4e550e0a?dmode=source

Also see a somewhat related discussion on ticket:5779 about a "toggle line numbers" link in the diff viewer. They decided against it there, as normally you shouldn't need to copy-n-paste just a few lines of a diff or patch. (I find it's much more common with full source files, so believe the arguments against it for the diff viewer don't hold for the source viewer.)

BTW, not that I'd use it much, but I really like the operation of the "Tabular/Unified" button for the diff viewer in the new version of Trac. See an example of it at changeset:6599.

---Ben Hoyt (benhoyt.com)

Attached is a patch (against the sandbox/wsgi branch) that implements a Paste Deploy entry point for trac. Using the sample deployment file (in the patch in docs/sample_deploy.ini) you can do:

paster serve docs/sample_deploy.ini

To get a working server. The configuration in that file just points to the Trac project directory, it doesn't put any of Trac's configuration in that file. The server in the sample is WSGIUtils, but any server can be used (e.g., flup's FastCGI or SCGI servers). The sample file also wraps the app in paste.lint, which checks for WSGI compliance (you wouldn't use this normally, but for testing and development it is useful).

This also changes setup.py to use setuptools, because that is needed for entry points. Strictly speaking this would not be necessary (you can just put paste.app_factory = trac.web.main:paste_app_factory in the deployment configuration instead of use = egg:Trac). But, eh. I'm a little surprised Trac isn't using setuptools already. Just changing the import from distutils.core to setuptools seems to work well enough for me.

Also two bugs are fixed; one when subdirectories of parent_dir are not loadable, and one for parent_dirs itself.

I haven't implemented env_paths in this patch -- it would probably mean collecting all the configuration variables and parsing them a bit (but would certainly be doable). I'm not sure what the threadsafety of Trac is, but if dispatch_request could be entered from multiple threads with different trac.env_path values and work that way, other dispatchers (like Paste#urlmap) could be used in addition to env_paths. It looks like Trac is probably already ready to be used like this (if it doesn't use globals to communicate configuration).

Basically, Trac sends (if configured properly) emails to the users each time a ticket is modified. In my case, I wanted to filter the tickets a bit, to identify tikets being closed or assigned to me.

Unfortunately, if your mail goes to an IMAP server without server filters, most email clients can't filter on the contents of the body, where the specific field changes are enumerated. Plus that would be, well, ugly.

This change adds additional X-Trac email headers each time a ticket is changed.

These headers are of the format:

X-Trac-Ticket-Change-<field>

with the new value of the field as the header value.

This allows for easy client side filtering, nd handles the case when multiple changes are made in one submission (you get multiple headers in the email, 1 per field)

Thanks for watching!

I have an Trac 0.11b1 installation and want to subscribe to RSS feed for tickets i need to monitor. But RSS feed is not visible within NetNewsWire? Lite (v3.1b4). But its visible in Vienna (v.2.2.2.2212)... So i make a decicion that RSS feed have some "not-fatal" error within ('cause NNW is know as strict RSS reader) while Vienna allow and display this feed. I can't check feed with online validator - i have intraweb Trac so can't say exactly where is error is. Feed from this site is displayed well in NNW (i try this link http://trac.edgewall.org/report/20?format=rss&USER=anonymous)

I have trac 0.11b1 running with mod_python on Apache 2.2. I have installed trac to a different location than default, since in our /usr/lib/python2.4/site-packages is another trac installation present.

Now a problem arises when using the plugin TimingAndEstimation?. The plugins version is 0.6.2.

It seems it cannot be installed under the location which differs from the default python site-packages dir. We have put it into /usr/local/trac/trac-0.11b1/lib/python2.4/site-packages where also the desired trac installation resides. But then the plugin won't be shown up in the admin/plugins page on trac webui.

We can't put the plugin up to /usr/lib/python2.4/site-packages due to some interference with the other installation of trac on that system, though everything works fine then.

So have you got ideas how we could tell our mod_python/Apache to have a look into /usr/local/trac/trac-0.11b1/lib/python2.4/site-packages to recognize the plugin?

Let trac be the first-ever multi-lingual wiki on the market! Have the ability to translate wiki articles into different languages. A user can select their language when they view the wiki. We have looked around and there isnt a wiki out there that handles this. And if you dont have time to do it, do you mind having some volunteers help you out? :)

The first time any of my bugzilla2trac-ed tickets was changed in any way, the description showed as spuriously changed - this was because all the LFs were translated to CRLFs somewhere in doing the round-trip between the web-browser and server.

To prevent this, bugzilla2trac should convert descriptions (and probably comments too) from LF line endings to CRLF line endings before storing them in the trac database.

This ticket should be used to coordinate the translation to Spanish.

This ticket should be used to coordinate the translation to Japanese/日本語.

This ticket should be used to coordinate the translation to Dutch.

This ticket should be used to coordinate the translation to German.

This ticket should be used to coordinate the translation to Russian/Русский. See also TracTermsRu.

This ticket should be used to coordinate the translation to Polish. See also TracTermsPl.

This ticket should be used to coordinate the translation to Traditional Chinese/正體中文. See also TracTermsZhTw.

This ticket should be used to coordinate the translation to Swedish/Svenska. See also TracTermsSv.

This ticket should be used to coordinate the translation to Italian. See also TracTermsIt.

This ticket should be used to coordinate the translation to Czech.

This ticket should be used to coordinate the translation to Welsh/Cymraeg. See also TracTermsCy.

This ticket should be used to coordinate the translation to Thai/ไทย.

This property is per-attachment in bugzilla, but the script imports it per-ticket. A change of the isobsolete field of two attachments at the same time in bugzilla will lead to a unique constraint violation on the trac side, causing the import to fail.

Adding the field to IGNORED_ACTIVITY_FIELDS solves the problem and allows the import to continue.

Since I am more familiar with Elixir (and thus the new SQLAlchemy declarative language as well) I have produced an Elixir declared model for Trac with minimal relations. I assumed a 'User' class and table as well for some of the relations to demonstrate its use. I will be submitting a revised edition with relations defined in the top SQLAlchemy section hopefully this afternoon.

This ticket should be used to coordinate the translation to Finnish/suomi.

See source:sandbox/i18n/trac/locale/fi_FI/LC_MESSAGES/messages.po

I just managed to import my bugs from Bugzilla version 2.18.4 into Trac Version 0.10.4.

However, some changes were necessary to the original Bugzilla DB contents as well as to the import script itself:

Trac needs unique product names

I used the option in the conversion script:

COMPONENTS_FROM_PRODUCTS = False

This caused the script to fail because my Bugzilla DB contained the same component name for various products.

After renaming the duplicate components, the script managed to import them.

DB schema problem

The import of attachments failed because of a wrong check for the Bugzilla version in the script (line 824):

The correct select statement from tables attachments and attach_data depends on the Bugzilla version. The script uses the table attach_data for versions greater or equal than 2180. However, this table was introduced in version 2211 (see http://www.ravenbrook.com/project/p4dti/tool/cgi/bugzilla-schema/).

After changing the condition to

        if BZ_VERSION >= 2210:

the import succeeded.

Multiple attachments.isobsolete at the same time

My bugzilla DB contained three changes of type "attachments.isobsolete" for the same bug at the same time.

This caused a duplicate primary key error in table ticket_change.

See my comments on Ticket #6753 for details.

I use trac trunk from 22 april 2005 with settings

always_notify_reporter = true always_notify_owner = true

If reporter not specified email address in settings, then trac fails to send emails:

Trac[Ticket] ERROR: Failure sending notification on change to ticket #25: iteration over non-sequence Traceback (most recent call last): 
  File "/usr/lib/python2.4/site-packages/trac/Ticket.py", line 434, in save_changes     tn.notify(ticket, newticket=0, modtime=now)
  File "/usr/lib/python2.4/site-packages/trac/Notify.py", line 217, in notify     NotifyEmail.notify(self, ticket['id'], subject
) 
  File "/usr/lib/python2.4/site-packages/trac/Notify.py", line 117, in notify     Notify.notify(self, resid) 
  File "/usr/lib/python2.4/site-packages/trac/Notify.py", line 56, in notify     self.send(to) 
  File "/usr/lib/python2.4/site-packages/trac/Notify.py", line 356, in send     NotifyEmail.send(self, rcpt, hdrs)   File "/usr/lib/python2.4/site-packages/trac/Notify.py", line 150, in send     sel