John Hampton | 1 Apr 10:17 2009

[Trac-dev] IAuthenticator -- what am I missing?


Ok, it's late, so please go easy on me.

I've been looking into the IAuthenticator[1][2] interface.  It's used to
"authenticate" the user.  Basically it checks if the REMOTE_USER env
variable is set or if the trac_auth cookie is set.  Not horribly
complicated.  Now, I'm working on merging the account manager plugin
into core[3] (most everything except registration and email verification)

As I'm digging into this, I'm questioning the way in which we use the
IAuthenticate interface.

First, AFAICT, we're only calling the authenticate() method on perm
requests and requests for the authname (req.perm and req.authname).
This seems kind of stupid to me.  Seems to me that we should be calling
authenticate once for each request.

Fortunately, due to the lazy evaluation code of the request[4], we
aren't constantly calling the authenticate() function.  However, we
generally make the call twice for every request (once for use of
req.authname[5], once for use of req.perm[6]).

Seems to me that it's better to simply call the authenticate method
explicitly at the beginning of every request and simply set req.authname.

Does anyone know why we're not doing so?  Is there some code path or
reason that I'm not seeing?  Again, I admit that it's a bit late, so if
anyone can help enlighten me I would be very grateful.

-John
(Continue reading)

Jesper Rønn-Jensen | 1 Apr 11:47 2009
Picon

[Trac-dev] Ticket change not updated if Tickets are moved using "retarget" when closing milestone


Hey there.

It kind of surprised me to see this behaviour in Trac 0.11.3:

I close a milestone and select to "Retarget associated open tickets to
milestone:"

After this, none of my open tickets reflect the milestone change in
ticket_change. How come?

Are there other inconsistencies in the use of ticket_change that I
should be aware of?

Is this a bug or a feature?

I'd like to hear your opinions before I file this as a bug.

/Jesper
www.justaddwater.dk

--~--~---------~--~----~------------~-------~--~----~
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 | 1 Apr 12:01 2009
Picon

[Trac-dev] Re: Ticket change not updated if Tickets are moved using "retarget" when closing milestone


Jesper Rønn-Jensen wrote:
> Hey there.
>
> It kind of surprised me to see this behaviour in Trac 0.11.3:
>
> I close a milestone and select to "Retarget associated open tickets to
> milestone:"
>
> After this, none of my open tickets reflect the milestone change in
> ticket_change. How come?
>
> Are there other inconsistencies in the use of ticket_change that I
> should be aware of?
>
> Is this a bug or a feature?
>   

http://trac.edgewall.org/ticket/5658

Nearly in the same terms as your summary ;-)

-- 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
-~----------~----~----~----~------~----~------~--~---
(Continue reading)

Christian Boos | 1 Apr 12:05 2009
Picon

[Trac-dev] Re: IAuthenticator -- what am I missing?


John Hampton wrote:
> Ok, it's late, so please go easy on me.
>
> I've been looking into the IAuthenticator[1][2] interface.  It's used to
> "authenticate" the user.  Basically it checks if the REMOTE_USER env
> variable is set or if the trac_auth cookie is set.  Not horribly
> complicated.  

> Now, I'm working on merging the account manager plugin
> into core[3] (most everything except registration and email verification)
>   
It would be interesting to know what's your approach for that. Do you 
plan to "merge" the AccountManager stuff into existing files or modules 
in Trac core, or to keep its current structure and have it like as an 
(optional) component?

Most importantly, is the BEER-WARE license used by the account manager 
compatible for inclusion in Trac core? ;-)

> As I'm digging into this, I'm questioning the way in which we use the
> IAuthenticate interface.
>
> First, AFAICT, we're only calling the authenticate() method on perm
> requests and requests for the authname (req.perm and req.authname).
> This seems kind of stupid to me.  Seems to me that we should be calling
> authenticate once for each request.
>
> Fortunately, due to the lazy evaluation code of the request[4], we
> aren't constantly calling the authenticate() function.  However, we
(Continue reading)

Jesper Rønn-Jensen | 1 Apr 12:34 2009
Picon

[Trac-dev] Re: Ticket change not updated if Tickets are moved using "retarget" when closing milestone


Thanks Christian!
http://trac.edgewall.org/ticket/5658

Actually, i ran into this for the same reasons that "mape" writes in a
comment to ticket:5658
a situation where you want to visualize the milestone over time can
actually only work when running through active tickets. This is
necessary because milestones don't have an explicit start date -- you
have to calculate it to show a burndown chart with a start date.

(and tickets that are active before they are retargeted should not
change the startdate of the new milestone)

With Trac's current domain model, what would be the smallest possible
change to make sure a milestone start date can be calculated.

/Jesper

On Apr 1, 12:01 pm, Christian Boos <cb... <at> neuf.fr> wrote:
> Jesper Rønn-Jensen wrote:
> > Hey there.
>
> > It kind of surprised me to see this behaviour in Trac 0.11.3:
>
> > I close a milestone and select to "Retarget associated open tickets to
> > milestone:"
>
> > After this, none of my open tickets reflect the milestone change in
> > ticket_change. How come?
(Continue reading)

John Hampton | 1 Apr 16:13 2009

[Trac-dev] Re: IAuthenticator -- what am I missing?


Christian Boos wrote:
> It would be interesting to know what's your approach for that. Do you 
> plan to "merge" the AccountManager stuff into existing files or modules 
> in Trac core, or to keep its current structure and have it like as an 
> (optional) component?

Currently, most of the new stuff will end up in trac.accounts.  However,
the form based login will be merged with trac.web.auth.

The current idea is to respect server provided auth.  If none is
configured, then form based auth is used against the session store backend.

> Most importantly, is the BEER-WARE license used by the account manager 
> compatible for inclusion in Trac core? ;-)

Well, seeing as we can do whatever we want with is as long as we remain
the notice intact, I would say yes.  However, as Matt Good is the
original author, we can probably get him to re-license it.  What say ye,
Matt?

> I suppose the code could certainly be enhanced so that authenticate() 
> gets called only once, either by the authname or by the perm callbacks, 
> but not by both (should be as simple as using req.authname in 
> RequestDispatcher._get_perm).
> 
> But we don't want to authenticate every requests because of the Chrome 
> component which can serve static content from htdocs. For those, we want 
> as little overhead as possible.

(Continue reading)

jerry | 1 Apr 10:24 2009
Picon

[Trac-dev] Logging in the database api...


So I'm a newbie with trac, ...  When I have worked on other database
backed web applications, I have found it useful during debugging to
have every database query logged.  Logging the database queries during
actual production is an enormous privacy hole, but logging queries
during debugging is so so nice.

I can see that none of the files in the database api do any logging,
and some have commented out print statements.

I would like to change that, but before I do so, I am curious if there
is any specific reason the trac db does not use logging, or if it is
just an outcome of the trac class architecture.  That is, were I to
add query logging, would that be appreciated, or would it violate some
trac design principle?

If I do go ahead, I am looking to find what is hopefully the single
spot, or the few spots, through which all queries flow.  That would
seem to be in trac/db/util.py IterableCursor::execute() and
IterableCursor::executemany().

Now the log is kept in the Environ.  Is there any way in which code in
the database api can determine the current Environ?

If not, then what I think is possible is to add/modify some sort of
debug connection wrapper so that the connection wrapper keeps track of
the log and somehow (waives hands once more) makes that available to
the IterableCursor or a new debug subclass of IterableCursor.

But if anyone wants to provide any tips, hints, or warnings (don't
(Continue reading)

Malcolm Studd | 2 Apr 03:35 2009
Picon

[Trac-dev] Extending version functionality


Hi,

I started working on a patch to make the Trac concept of a version
more useful. A milestone may be targeted for a version, and a version
may have a due date. There is a page to view a version, attach files
to it, and (not yet implemented) to edit a version. Viewing a version
shows the milestones targeted to it, similar to the roadmap. The
roadmap displays "For version:???" after the milestone completion.

I have tried to make the patch as non-intrusive as possible. If there
are no versions, nothing changes. If milestones are not targeted to a
version, nothing changes other than a new drop-down on the edit
milestone view.

I will probably modify the roadmap to a) group milestones by version,
b) replace targeted milestones with the versions, or c) intersperse
versions in the milestones. Possibly as a plugin/alternate view.

What I'm wondering is if anyone is interested in such a patch. Would
there be a chance of it being applied to Trac core if I finished it?

Background:
I've always been slightly annoyed that a version is only visible as a
name in tickets. There's no relation to anything else, and the
description is only visible on the admin page. At $WORK, I am trying
to replace an ancient TWiki storyboard and Bugzilla with Trac, but we
would like a two-level hierarchy for iteration/story. We've looked at
a couple plugins, but they don't work (itteco), are overly-complex
(agile-trac), or don't really fit our use-case well.
(Continue reading)

Noah Kantrowitz | 2 Apr 15:37 2009
Picon

[Trac-dev] Re: Extending version functionality


It sounds like what you actually want is to have a second milestone  
field on tickets. I would do that instead.

--Noah

On Apr 1, 2009, at 8:35 PM, Malcolm Studd wrote:

>
> Hi,
>
> I started working on a patch to make the Trac concept of a version
> more useful. A milestone may be targeted for a version, and a version
> may have a due date. There is a page to view a version, attach files
> to it, and (not yet implemented) to edit a version. Viewing a version
> shows the milestones targeted to it, similar to the roadmap. The
> roadmap displays "For version:???" after the milestone completion.
>
> I have tried to make the patch as non-intrusive as possible. If there
> are no versions, nothing changes. If milestones are not targeted to a
> version, nothing changes other than a new drop-down on the edit
> milestone view.
>
> I will probably modify the roadmap to a) group milestones by version,
> b) replace targeted milestones with the versions, or c) intersperse
> versions in the milestones. Possibly as a plugin/alternate view.
>
> What I'm wondering is if anyone is interested in such a patch. Would
> there be a chance of it being applied to Trac core if I finished it?
>
(Continue reading)

Noah Kantrowitz | 2 Apr 17:47 2009
Picon

[Trac-dev] Trac's CSS and easy theming


So my big focus during the sprints this year was getting ThemeEngine  
whipped into shape, and I am pretty happy with how it has turned out.  
In the process of setting up the dynamic CSS for the default theme, I  
found we have very little in the way of color standardization in a lot  
of places. I already fixed up a few issues (mostly making the navbar  
gradients into transparencies so they can be recolored via CSS), but  
does anyone object to creating some classes for commonly used colors/ 
styles? The best example I found is the "small, light-gray text" which  
we use in many places (help text, footer, etc) but have little to no  
centralization of. This would result in some minor color changes as I  
combine some similar but not quite the same styles. Does this seem  
reasonable to everyone?

--Noah

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


Gmane