kalyani ram | 7 Feb 09:15
Picon

[Trac-dev] regarding the forward feature

Hey Djangonauts,

I am searching for a option of providing a forward option on the
ticket with a reply. This might help the user to forward the tickets
without any copying by appending the Ticket ID to the subject.
Help me pls

--

-- 
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.

Chris Nelson | 7 Feb 13:52
Favicon

Re: [Trac-dev] regarding the forward feature

On 02/07/2012 03:15 AM, kalyani ram wrote:
> I am searching for a option of providing a forward option on the
> ticket with a reply. This might help the user to forward the tickets
> without any copying by appending the Ticket ID to the subject.
> Help me pls

When you say "forward" do you mean forward the ticket to some address 
that Trac monitors to get e-mail contents into ticket comments? 
email2trac (https://subtrac.sara.nl/oss/email2trac) does that.  You just 
forward to Trac with "#nnnn:" in the subject.  It even attaches e-mail 
attachments to the ticket.

                                                   Chris
-- 
Christopher Nelson, Software Engineering Manager
SIXNET - Solutions for Your Industrial Networking Challenges
331 Ushers Road, Ballston Lake, NY  12019
Tel: +1.518.877.5173, Fax: +1.518.877.8346 www.sixnet.com

--

-- 
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.

Chris Nelson | 7 Feb 13:56
Favicon

Re: [Trac-dev] Trac 0.12.3 released

On 02/06/2012 05:13 PM, Christian Boos wrote:
> Hello everyone,
>
> Our long due maintenance release is here at last ;-)
>
>
> Trac 0.12.3 Released
> ====================
>
> We're happy to announce the Trac 0.12.3 release.
>
> You will find this release at the usual place:
>
> http://trac.edgewall.org/wiki/TracDownload
>
> Trac 0.12.3 contains a quite a number of fixes (over 80 tickets)
> and among the important ones, you have:
> ...

Thank you all for your hard work on a great tool.  (Now if I could only 
get off 0.11.6 ....)

-- 
Christopher Nelson, Software Engineering Manager
SIXNET - Solutions for Your Industrial Networking Challenges
331 Ushers Road, Ballston Lake, NY  12019
Tel: +1.518.877.5173, Fax: +1.518.877.8346 www.sixnet.com

--

-- 
You received this message because you are subscribed to the Google Groups "Trac Development" group.
(Continue reading)

Rumi, Natasha | 15 Feb 10:23
Favicon

[Trac-dev] Using style sheet for egg pulgin

Dear Sirs,

 

I have created a new plugin in our trac system but I cannot load the external style sheet. I followed the steps in the url below but when I view the page and click on the href="/trac/icf/chrome/hw/css/PJ6CKanban.css"

I get internal error. The build contains the css file (PJ6CKanbanPlugin\build\lib\PJ6CKanban\htdocs\css\PJ6CKanban.css) but the egg in cache does not contain the css folder just html (C:\cache\trac\pj6ckanban-0.1-py2.6.egg-tmp\PJ6CKanban\templates).

 

http://trac-hacks.org/wiki/EggCookingTutorialTrac0.11

 

Can you please help me?

 

Thanks

 

Natasha Rumi

Software Engineer(Contractor)
Toshiba Medical Visualization Systems Europe, Ltd
Bonnington Bond, 2 Anderson Place, Edinburgh EH6 5NP, UK
Tel + 44 (0)131 472 4792 Fax + 44 (0) 131 472 4799
www.tmvse.com
NRumi <at> tmvse.com

 

 


______________________________________________________________________
This email has been scanned by the Symantec Email Security.cloud service.
For more information please visit http://www.symanteccloud.com
______________________________________________________________________

--
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.
Steffen Hoffmann | 15 Feb 20:02
Picon

Re: [Trac-dev] Using style sheet for egg pulgin


On 15.02.2012 10:23, Rumi, Natasha wrote:
> but the egg in cache does not contain the css folder

Posting at least your setup.py would help to rule out the most common
problems on egg build time.

Sincerely,

Steffen Hoffmann
(hasienda)
Rumi, Natasha | 16 Feb 16:12
Favicon

RE: [Trac-dev] Using style sheet for egg pulgin

Hi Steffen,

Thanks for your reply these are my files.

Regards

Natasha Rumi
Software Engineer(Contractor)
Toshiba Medical Visualization Systems Europe, Ltd
Bonnington Bond, 2 Anderson Place, Edinburgh EH6 5NP, UK
Tel + 44 (0)131 472 4792 Fax + 44 (0) 131 472 4799
www.tmvse.com 
NRumi <at> tmvse.com

-----Original Message-----
From: trac-dev <at> googlegroups.com [mailto:trac-dev <at> googlegroups.com] On Behalf Of Steffen Hoffmann
Sent: 15 February 2012 19:03
To: trac-dev <at> googlegroups.com
Subject: Re: [Trac-dev] Using style sheet for egg pulgin

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On 15.02.2012 10:23, Rumi, Natasha wrote:
> but the egg in cache does not contain the css folder

Posting at least your setup.py would help to rule out the most common problems on egg build time.

Sincerely,

Steffen Hoffmann
(hasienda)
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.10 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iEYEARECAAYFAk88ATsACgkQ31DJeiZFuHc0rQCfcKTFnhcXx00pmBeM/AQtV7VI
yXcAnRU2CSeLWQlb1EmeElXxsm/H39Xb
=WDT8
-----END PGP SIGNATURE-----

--
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.

______________________________________________________________________
This email has been scanned by the Symantec Email Security.cloud service.
For more information please visit http://www.symanteccloud.com
______________________________________________________________________

______________________________________________________________________
This email has been scanned by the Symantec Email Security.cloud service.
For more information please visit http://www.symanteccloud.com
______________________________________________________________________

--

-- 
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.

ÐÏ

Attachment (setup.py): application/octet-stream, 377 bytes
Steffen Hoffmann | 16 Feb 22:12
Picon

Re: [Trac-dev] Using style sheet for egg pulgin


Hello,

Am 16.02.2012 16:12, wrote Rumi, Natasha:
> Thanks for your reply these are my files.

You're welcome. Got your email, but message has been badly formatted,
maybe due to not standards-compliant email software? Try to stick to
ascii/plain-text whenever possible.

regarding setup.py:

change entry to a true dict like so

    entry_points = {
        'trac.plugins': [
            'PJ6CKanban = PJ6CKanban',
        ]
    },

but 'PJ6CKanban' really your directories name, where python scripts,
htdocs and template folder reside? - adjust as needed, please.

consider adding for completeness

    description = 'short desc about this great plugin',
    author='Natasha Rumi',
    author_email='NRumi <at> tmvse.com',
    url = 'http://www.tmvse.com',
    license = 'some licenses reference',

include and adapt, if applicable

    install_requires = ['Trac >= 0.11'],
    zip_safe = True,

regarding PJ6CKanban.html

appears to be a Genshi template, but space mingled, with wicked encoding
and embedded in more wired HTML? Just decoded an re-formatted a few
lines to get a first glance. Re-send inside ZIP archive or prevent
changes by your email program through other means, if reqired. Anyway,
here are my comments:

<!DOCTYPEhtmlPUBLIC"-//W3C//DTDXHTML1.0Strict//EN"http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd">
<html xmlns="http://www.w3.org/1999/xhtml"
      xmlns:py="http://genshi.edgewall.org"
      xmlns:xi="http://www.w3.org/2001/XInclude">
      <xi:include href="layout.html" />
 <head><link rel="stylesheet" href="'/css/mykanban.css" type"text/css"/>

----
Don't do that. Make sure you have an appropriately designed
ITemplateProvider (from trac.web.chrome) but use add_stylesheet method
(from trac.web.chrome too) before returning the template inside your
IRequestHandler like so:

from pkg_resources import resource_filename
from trac.web.api import IRequestFilter, IRequestHandler
from trac.web.chrome import ITemplateProvider, add_ctxtnav, \
                            add_stylesheet

    # ITemplateProvider methods

    def get_htdocs_dirs(self):
        """Return static resources for TracForms."""
        return [('PJ6CKanban', resource_filename(__name__, 'htdocs'))]

    def get_templates_dirs(self):
        """Return template directory for TracForms."""
        return [resource_filename(__name__, 'templates')]

    # IRequestHandler methods
    def match_request(self, req):
        ...

    def process_request(self, req):
        ...
        add_stylesheet(req, 'PJ6CKanban/css/mykanban.css')
        return 'PJ6CKanban.html', data, None
----

 <title>PJ6CKanban</title>
 <stylerel="stylesheet"type="text/css"></style>
 </head>
 <body>
 <div id="ctxtnav"class="nav">
 </div>
 <ivid="content"><h1>PJ6CKanban</h1>
 <table style="width:880px;">
  <tbody>
   <tr>
    <td style="vertical-align:top;width:220px border-style:outset;
border-width:2px; height:100%; border-radius:3px;">
     <table>
      <thead>
       <tr>
        <th id="header" style="horizontal-align:left;
backgroud-color:#c4c4b9; width:200px; min-width:200px; max-width:200px;
border:solid thin grey; border-radius:3px; box-shadow:black 0.5em 0.5em
0.3e;">
         <strong>New/Reopen</strong>
        </th></tr><tr><th
style="height:10px;">&nbsp;</th></tr></thead><tbody>

Uh, stop here. Well, I don't go for the table-inside-table design. Just
so much CSS inside XHTML is ugly. This file get's too messy to find
anything. Move all that out into separate CSS with appropriate
selectors. Watch spelling, i.e. "backgroud-color". Avoid very recent and
browser-specific things like "border-radius:3px", etc.

Hope this will get you started into a more successful direction.

Yours,

Steffen Hoffmann
Daniel França | 17 Feb 20:21
Picon

[Trac-dev] customize users list

Hi all,
I'm customizing the users field for tickets.
I added this patch:

But I want the user lists changes according to some ticket information.
I've already developed the code to handle this, but I need at least ticket id in this TicketSystem method.

What's the best way to achieve that?

--
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.
Christian Boos | 19 Feb 23:36
Picon
Favicon

[Trac-dev] New release policy of trunk

Hi list,

It just occurred to me that it would be a good thing to try out a
new release policy. Since a while, we have this awfully long
major release cycle, together with a more frequent minor release
cycle on the -stable branch. This is how it is, we already tried
to make major releases more frequent but apparently this goes
against the natural pace of the project, so this message won't be
a plea for changing this. Quite the contrary, I think that a
somewhat long release cycle has also its advantages, as it gives
time to the plugin ecosystem to mature around new versions and
also gives us enough room to polish the features or the API we
want to maintain in the long term. But of course the disadvantage
is that a lot of the good work that appears on trunk takes a very
long time to reach the users, at least the vast majority not
comfortable with the idea of using the latest commit on trunk of
the day. Making the new cool features also available on -stable
would somehow defeat the very idea of having a -stable branch. It
would put too much at risk the API stability we try to guarantee
to plugin authors, as big new features often come together with
API clean-ups and evolution.

So how to preserve the advantages of this model while at the same
time making the new features more readily available to a greater
number of users? Simple. Make some "checkpoints" on trunk. Long
time readers of this list already now about that old idea of mine
of making "pre"- releases. Those would be well tested, stable
versions which we are confident people could use (no big deal,
that's how we already feel about trunk, at least most of the
time, so this would just help other people "identify" such
times!). What's the difference then we a real release or even a
beta release? A non-binding feature set and API. We won't make
the guarantee that what's in a pre-release will be the same in
the final release, we reserve the right to change our mind. Of
course, from pre-release to pre-release, we'll document what has
changed, in order to make it easier for plugin authors who which
to support these pre-releases. I believe this is worth trying,
now. I'm all for making a 0.13pre1 release by the end of this
month (knowing we're not yet done with 0.13 even for a beta, but
it's nevertheless already good and stable enough to start to get
people using it more broadly).

-- Christian

--

-- 
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.

Remy Blank | 20 Feb 10:50
Picon
Favicon

Re: [Trac-dev] New release policy of trunk

I know we have already discussed this, and you have already heard my
arguments, but as the discussion was private, I will still repeat them here.

Christian Boos wrote:
> It just occurred to me that it would be a good thing to try out a
> new release policy. Since a while, we have this awfully long
> major release cycle, together with a more frequent minor release
> cycle on the -stable branch. This is how it is, we already tried
> to make major releases more frequent but apparently this goes
> against the natural pace of the project, so this message won't be
> a plea for changing this.

I agree with the first part, but disagree with the latter: we haven't
really tried to do more frequent major releases. I see two major reasons
that have held this back:

 - A lack of time to dedicate to the project.

 - Our feeling that a major release must contain something radically new
/ improved / shiny / (insert your pet characteristic here), and
therefore our unwillingness to "let go" of something that we think is
only an incremental improvement.

I have hopes that our new team members will help with the former. But
the latter is only a question of mindset, and nothing prevents us from
changing it today.

I understand the argument that API changes must have some kind of
"incubation phase" for plugin maintainers to catch up, but I'm not sure
this is actually how it works. Isn't it rather that plugin maintainers
don't do anything until their plugin breaks, which only happens when
their users start using the new major version? And this in turn only
starts happening when we actually release the new version (except for
those few users living on the edge).

(I fully expect Simon to jump on this one ;)

> So how to preserve the advantages of this model while at the same
> time making the new features more readily available to a greater
> number of users? Simple. Make some "checkpoints" on trunk. Long
> time readers of this list already now about that old idea of mine
> of making "pre"- releases. Those would be well tested, stable
> versions which we are confident people could use (no big deal,
> that's how we already feel about trunk, at least most of the
> time, so this would just help other people "identify" such
> times!).

If the -pre releases are already well-tested and stable, why not just
call them "major" releases? The "non-binding feature set and API"
doesn't hold, as we don't guarantee that between major releases either.

Frankly, I don't think that making our release process more complex (by
introducing one more type of release) is going to be any help. If
anything, we should rather try and make it simpler.

> I'm all for making a 0.13pre1 release by the end of this
> month (knowing we're not yet done with 0.13 even for a beta, but
> it's nevertheless already good and stable enough to start to get
> people using it more broadly).

I'd actually be all for making a 0.13b1 release by the end of this month :)

Here's my counter-proposal:

 - One minor release every 3 months, or as needed (e.g. security fixes,
blockers).
 - One major release every 6 months.
 - The ~2 weeks prior to each release are used to stabilize the code.
Unfinished code is either completed or reverted (the latter case should
be infrequent: very experimental features should be implemented in a
Mercurial or git branch).
 - When a release deadline arrives, we release what we have. Whether we
have 1 or 10 or 100 new features and fixes is irrelevant. The goal is to
get the code out to our users.

Time intervals could be adapted, but I wouldn't make them much longer
than that. I find it depressing enough to think that a cool new feature
will have no users for 6 months (and 21 months already in the case of 0.13).

-- Remy


Gmane