Nov 13, 2012:

Now EmailDistributor cares for the preferred format, that is configured per
user in the subscription db table, obsoleting related
'announcer_email_format_<realm>' entries stored in session_attribute db
table before.

While this is yet another regression, because this setting has been per target
(resource) realm before, in theory it could even be more fine-grained.
In fact, its possible to store the preferred format per subscriber insubscription. Only it is unified per transport for now, and I see no real
value in changing this, yet.

This fixes inappropriate alternative text display of non-ascii characters inHTML emails, that get sent out as multi-part message in MIME format.

This has been reported by g1itch, who did investigations and patch as well.
Works like a breeze, but this must have been much harder to fix than one would
expect at first glance onto this one-liner. It's a pleasure to follow your
footsteps, thanks a bunch.

We augment TracPM to provide a query() function which encapsulates
those steps. The return value is now also pruned so there are no
"dangling" references to external tickets. If A is a parent of B is
a parent of C and you query root=B, the list is cleaned up so asking
for the parent of B says there isn't one.

And the same bad filter code even got replicated in [12312]. Sorry for not
checking compiler errors earlier. Finally I discovered an UnboundLocalError
for resource_id hidden behind the first error. Obviously unit tests are
a blessing and needed here too.

Custom field names must start with a letter and have only letters,
digits, and underscores. By adding a leading underscore to "calc_start"
and "calc_finish", we avoid a potential conflict if the user used those
as custom field names for their own purposes or even for fields.start
and fields.finish values.

Mostly reuses logic from pred-succ relation so there isn't really any
work for relation handling beyond adding the relation to the list of
configurable relations; the rest is data-driven.

However, the relation handling builds lists and we previously handled
parent as a singleton so some parent field handling needed tweaking:

TracPM.parent() now returns None if there is no parent field or

relation configured or if there is no parent. Internal code was
adjusted. The only user outside this module, tracjsgantt.py, works with
this change.

When creating a pseudo-ticket for milestones, set the parent list to

empty, not the previous place-holder ID 0.

When normalizing and parsing a configured parent field, make a

one-element list of the parent ID

When testing for children, check if the child ID is in the parent

list rather than the parent field is the child ID

Also fix a bug where parent/child field handling assumed the value of
fieldName left over from a previous loop.

Note this was tested with a parent field, with a parent-child relation,
and with no parent configuration.

Some plugins that support parent-child relationships may allow multiple
parents (Subtickets does). Doing PM-ish things on projects broken down
into phases broken down into deliverables broken down into tasks, etc.
all assumes a tree structure which excludes multiple parents. If
someone creates multiple parents, this will blow up. I'm OK with that.

This is a late follow-up to changeset [9813] after more in-deep discussion on
permission checking for whole Trac realms and specific Trac resources in #8458.
With my original patch proposal from 04-Feb-2011 in mind I call this an aged
and really matured changeset, and that's not so bad after all.
Furthermore code from [12304] gets improved here as well.

Special thanks to Odd Simon Simonsen, Ryan J. Ollos and Christian Boos for
their help on my way towards better understanding Trac permissions.

The chosen implementation should be slightly more efficient than what has
been proposed in #7976, but I agree, that this is a pre-reqisite for making
some subscribers effective, i.e. AccountManagerPlugin notifications.