[Trac] Re: Master / Sub-Tickets

Dan <[email protected]> Mon, 15 Dec 2025 08:38:29 -0800 (PST)
Newsgroups gmane.comp.version-control.subversion.trac.general
Message-ID <[email protected]>
------=_Part_508384_391147545.1765816709719
Content-Type: multipart/alternative; 
	boundary="----=_Part_508385_320766713.1765816709719"

------=_Part_508385_320766713.1765816709719
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

I'm not sure if I can help out a lot with this, but FYI my group is using=
=20
child tickets plugin.  It does check for open child tickets and prevent=20
closing the parent if so.

Yes, we've been using Python 3 version for for quite a few years.  I ported=
=20
a few plugins myself, but it's been a while lol ... the data is not in=20
cache right now ...

- Dan

On Monday, December 15, 2025 at 9:53:50=E2=80=AFAM UTC-6 ichthyo wrote:

>
> Hello all,
>
> Trac accomplished the step to Python-3, which is good.
> I am a long term Trac user and Open-Source developer;
> Trac just works and provides everything I need.
>
> Now I'm considering how best to proceed regarding *Mastertickets*,
> which was an essential feature I'm heavily relying on: I have a
> huge amount of tickets with a complex DAG of relationships,
> which are essential for me to manage the work.
>
> Mastertickets has a rather bare-bones UI, which relied on
> post-processing of trac's template output.
> So it seems this plug-in is broken beyond repair.
>
>
> What are other people using for similar requirements?
>
>
> There seem to be the
>
> - SubTickets plugin
>
> - ChildTickets plugin
>
>
> As far as I can see, both support a DAG structure,
> i.e. one ticket can be attached below several parents.
>
> So it looks like it might be possible to cook up a SQL migration script.
>
>
> Does anyone have experience with those plugins? are they still in use?
> Both seem to have recent changes in the history. Are they ported to
> python-3 and do they work with the new template engine, going forward?
>
> Ideally I'd want to avoid putting much work into a migration
> just to find out some time ahead that no one else is using
> the plug-in and that it's unmaintained.
>
> I do not have special requirements for the ticket workflow or for
> reporting, yet I'd appreciate if a new solution performs a
> dependency cycle check; mastertickets did that, and that was
> quite helpful at times.
>
> -- Hermann
>
>
>

--=20
You received this message because you are subscribed to the Google Groups "=
Trac Users" group.
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to trac-users+unsubscribe-/JYPxA39Uh5TLH3MbocFF+G/[email protected]
To view this discussion visit https://groups.google.com/d/msgid/trac-users/=
05fcf7dc-fcb2-4d8e-8058-55e2a69d3ab2n%40googlegroups.com.

------=_Part_508385_320766713.1765816709719
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

<div>I'm not sure if I can help out a lot with this, but FYI my group is us=
ing child tickets plugin.=C2=A0 It does check for open child tickets and pr=
event closing the parent if so.</div><div><br /></div><div>Yes, we've been =
using Python 3 version for for quite a few years.=C2=A0 I ported a few plug=
ins myself, but it's been a while lol ... the data is not in cache right no=
w ...</div><div><br /></div><div>- Dan</div><br /><div class=3D"gmail_quote=
"><div dir=3D"auto" class=3D"gmail_attr">On Monday, December 15, 2025 at 9:=
53:50=E2=80=AFAM UTC-6 ichthyo wrote:<br/></div><blockquote class=3D"gmail_=
quote" style=3D"margin: 0 0 0 0.8ex; border-left: 1px solid rgb(204, 204, 2=
04); padding-left: 1ex;">
<br>Hello all,
<br>
<br>Trac accomplished the step to Python-3, which is good.
<br>I am a long term Trac user and Open-Source developer;
<br>Trac just works and provides everything I need.
<br>
<br>Now I&#39;m considering how best to proceed regarding *Mastertickets*,
<br>which was an essential feature I&#39;m heavily relying on: I have a
<br>huge amount of tickets with a complex DAG of relationships,
<br>which are essential for me to manage the work.
<br>
<br>Mastertickets has a rather bare-bones UI, which relied on
<br>post-processing of trac&#39;s template output.
<br>So it seems this plug-in is broken beyond repair.
<br>
<br>
<br>What are other people using for similar requirements?
<br>
<br>
<br>There seem to be the
<br>
<br>  - SubTickets plugin
<br>
<br>  - ChildTickets plugin
<br>
<br>
<br>As far as I can see, both support a DAG structure,
<br>i.e. one ticket can be attached below several parents.
<br>
<br>So it looks like it might be possible to cook up a SQL migration script=
.
<br>
<br>
<br>Does anyone have experience with those plugins? are they still in use?
<br>Both seem to have recent changes in the history. Are they ported to
<br>python-3 and do they work with the new template engine, going forward?
<br>
<br>Ideally I&#39;d want to avoid putting much work into a migration
<br>just to find out some time ahead that no one else is using
<br>the plug-in and that it&#39;s unmaintained.
<br>
<br>I do not have special requirements for the ticket workflow or for
<br>reporting, yet I&#39;d appreciate if a new solution performs a
<br>dependency cycle check; mastertickets did that, and that was
<br>quite helpful at times.
<br>
<br>-- Hermann
<br>
<br>
<br></blockquote></div>

<p></p>

-- <br />
You received this message because you are subscribed to the Google Groups &=
quot;Trac Users&quot; group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:trac-users+unsubscribe-/[email protected]">trac-use=
rs+unsubscribe-/[email protected]</a>.<br />
To view this discussion visit <a href=3D"https://groups.google.com/d/msgid/=
trac-users/05fcf7dc-fcb2-4d8e-8058-55e2a69d3ab2n%40googlegroups.com?utm_med=
ium=3Demail&utm_source=3Dfooter">https://groups.google.com/d/msgid/trac-use=
rs/05fcf7dc-fcb2-4d8e-8058-55e2a69d3ab2n%40googlegroups.com</a>.<br />

------=_Part_508385_320766713.1765816709719--

------=_Part_508384_391147545.1765816709719--