This is the last RFC for today ;-)
Now that the context-refactoring branch is in trunk and that most ticket
have a patch ready, this is the last big task remaining before the beta1.
In this refactoring, the TimelineEvent class is gone, and instead the
ITimelineEventProvider.get_timeline_events() method has been changed to
return a tuple that can contain "private" data which the provider will
use in a second step in a ITimelineEventProvider.render_timeline_event()
method. The advantage being that the rendering is done only when
actually needed (some events might be skipped due to the limit
parameter) and a great degree of flexibility about the presentation of
the event is preserved.
Highlight on the interesting ITimelineEventProvider API changes:
def get_timeline_events(req, start, stop, filters):
"""Return a list of events in the time range given by the
The `filters` parameters is a list of the enabled filters, each item
being the name of the tuples returned by `get_timeline_filters`.
Since 0.11, the events are `(kind, date, author, data)` tuples,
where `kind` is a string used for categorizing the event, `date`
is a `datetime` object, `author` is a string and `data` is some
private data that the component will reuse when rendering the event.
When the event has been created indirectly by another module,
like this happens when calling
the tuple can also specify explicitly the provider by returning
of the following form: `(kind, date, author, data, provider)`.
Before version 0.11, the events returned by this function used to
be tuples of the form `(kind, href, title, date, author, markup)`.
This is still supported but less flexible, as `href`, `title` and
`markup` are not context dependent.
def render_timeline_event(context, field, event):
"""Display the title of the event in the given context.
:param context: the rendering `Context` object that can be used for
:param field: what specific part information from the event should
be rendered: can be the 'title', the 'description' or
:param event: the event tuple, as returned by `get_timeline_events`
See r6141 for the full changeset.
Please let me know if you see any problem with the merge of the above
The full set of changes is visible here:
Likewise, most of the remaining 0.11 tickets have now a patch ready, and
I'm going to apply them in the coming days if there's no further comment
After that, I think we'll be ready for a 0.11beta1 release
If there's no major issue uncovered till then, looks like it would be
doable for the end of this week.
This looks very nice Christian. Nice and clean.
> Likewise, most of the remaining 0.11 tickets have now a patch ready, and
> I'm going to apply them in the coming days if there's no further comment
> on them.
I'll try and have a look at those tonight.
Evolution: Taking care of those too stupid to take care of themselves.
Can anyone with a pgsql instance see if my reported
http://trac.edgewall.org/ticket/6348 also has the same issue there? I only
have SQLite instances at the moment.
Jeroen Ruigrok van der Werven <asmodai(-at-)in-nomine.org> / asmodai
イェルーン ラウフロック ヴァン デル ウェルヴェン
http://www.in-nomine.org/ | http://www.rangaku.org/
Your lunacy fits in neatly with my own, my very own...
Yeah, it's a "known" issue and there's probably several duplicate tickets.
Bottom line is that all backends have different ways to report
pysqlite2.dbapi2.IntegrityError: columns username, action are not unique
_mysql_exceptions.IntegrityError: (1062, "Duplicate entry
'cboos-TICKET_ADMIN' for key 1")
psycopg2.IntegrityError: duplicate key violates unique constraint
What we need is to trap that at the level of each backend and raise a
TracIntegrityError instead that we can handle in the upper levels.
That's not a blocker for 0.11, though.
Extended time for review, as I won't be able to do anything more till
... at which point, if there's no big concerns raised, I'm going to
commit like crazy and call that beta one ;-)
#153 Email address obfuscation/truncating
My only question is why you accumulate into email_cells rather than just
formatting the cell in the main loop?
#1440 Remove reached milestones from edit ticket list
No real opinion, +0
#2048 Wiki macros for generating `<div>`s and `<span>`s with classes
I like this style much better than the original proposed "}}}.class"
one. Only real question is do we need the ";" separators? It would
seem more in-keeping with normal HTML to simply have:
#!div class="foo" style="foo bar"
#2259 No notification email when adding an attachment to a ticket
#2914 would be nice to have optional automatic line breaks in ticket
descriptions and comments
#5651 [patch] Use 'inherit' 'file' config setting when creating a new
Environment (not loading defaults)
#6043 Trunk jQuery crashes safari 2.0 and older
I guess we check if there are any major changes in jQuery 1.1.4, do
some testing, and plonk it in.
#5954 Can't use prototype in plugins as $ conflicts with jquery
No opinion, +0.
#6278 remove unnecessary span tag
No opinion, +0.
#6211 IPermissionPolicy unable to grant WIKI_VIEW access
I've updated the ticket with comments, but the
summary is that I think we should do the opposite of what the
requestor suggests :)
- Some first paragraph in a point.
The second paragraph in a point.
Indentation is consistent, so I would expect the second paragraph
still to be in the <li>.
We need to know the resource for the formatting
(format_emails(context(resource), cell['value'])), in order to do a
fine-grained permission check for EMAIL_VIEW, and the row['id'] used for
getting the resource is only known after the iteration.
> #1440 Remove reached milestones from edit ticket list
> No real opinion, +0
> #2048 Wiki macros for generating `<div>`s and `<span>`s with classes
> I like this style much better than the original proposed "}}}.class"
> one. Only real question is do we need the ";" separators? It would
> seem more in-keeping with normal HTML to simply have:
> #!div class="foo" style="foo bar"
Well, given that #! can be followed by a mime-type, the more general
idea here was to pass arguments to wiki-processors using a syntax
similar to that of a Content-Type header. The use case for <div> came later.
Anyway, looking at the current regexp, it seems that it doesn't matter,
as either would work...
> #2259 No notification email when adding an attachment to a ticket
> #2914 would be nice to have optional automatic line breaks in ticket
> descriptions and comments
> +1, LGTM.
> #5651 [patch] Use 'inherit' 'file' config setting when creating a new
> Environment (not loading defaults)
> #6043 Trunk jQuery crashes safari 2.0 and older
> I guess we check if there are any major changes in jQuery 1.1.4, do
> some testing, and plonk it in.
Plus 1.1.4 is supposedly much faster. Ideally we should go with 1.2.1
> #5954 Can't use prototype in plugins as $ conflicts with jquery
> No opinion, +0.
> #6278 remove unnecessary span tag
> No opinion, +0.
> #6211 IPermissionPolicy unable to grant WIKI_VIEW access
> I've updated the ticket with comments, but the
> summary is that I think we should do the opposite of what the
> requestor suggests :)
I didn't see your comment but I'm definitely interested in your opinion
on the matter.
Ugh. No idea what happened to it :(
But effectively what you said, plus a mention of how 'WIKI_VIEW' in
req.perm('wiki') is used by the nav code to check whether the wiki nav
item should show up at all.
This also had the implication that plugins doing old-style checks may
not work correctly with policy plugins such as the one he mentioned,
and that we should make a note of that somewhere.
> -- Christian