Hi Anton:

In message
<trinity-3b67a2c8-b4c3-47a2-b7c1-5633414f5d4b-1703596531061@3c-app-mailcom-bs04>,
Anton Savchuk writes:

>I also thought of adding more information about the messages (similar
>to what is implemented for files). For example, displaying
>information about the message type (text/plain, text/x-rst or
>text/>markdown) can be useful for troubleshooting.

The additional file info is for people who are trying to download or
use the attached file. Messages are generally not downloaded or used
outside of the issue's message river. Even clicking through to the
underling msg### page (which would show the message type etc.) is much
less likely. The type info should be accessible from roundup-admin
which you will need access to for troubeshooting anyway.

>I also have a problem with the markdown editor. initEasyMde() no
>longer seems to work without adding an event for the input field,
>since deferred scripts now run after the page has loaded and
>therefore after inline scripts.
>
>It seems to me that the ideal option would be to replace all the
>inline scripts with script files.

See https://issues.roundup-tracker.org/issue2551270. I think this is
along the same idea. It also passes the javascript through the
templating system so it can pick up values.

>This could also simplify the CSP rules when using Roundup behind a
>reverse proxy.

CSP can be served by roundup. See
https://wiki.roundup-tracker.org/AddingContentSecurityPolicy.  I run
my demo tracker using a reverse proxy, but the CSP comes from Roundup.

Javascript <script> tags inline aren't an issue for CSP as roundup
provides a client_nonce for this purpose that can be used to add a
"nonce" attribute to the script tag that is matched against the CSP.

However all the onX (onclick etc.) javascript needs to go.
I'm not sure if this is what you are calling "inline scripts".

>other than templating a JSON object and reading the editor
>configuration from that object.

Yeah templating a JSON object is all I have come up with. Hence
issue2551270.

>At the moment, the problem with the order of scripts can be solved by
>always calling the fuction from the inline script on an event. But
>maybe better to think about a more correct solution right now. Maybe
>you have thoughts on this?

Not really. Progressive eahancement is what I have used. See:
https://wiki.roundup-tracker.org/UseSelect2andRestForIssueMultilink so
you always have a functional plain input and then if the script loads
and runs successfully you get the enhanced experience.

>> We will need to figure out a way to sync your github repo into the
>> Roundup mercurial repo. This way the Roundup code base will reflect
>> your changes.

>I suggest using mercurial subrepositories for Roundup templates. They
>can also be added as submodules for a synchronized Github
>repository. The only inconvenience I see is the need to add two files
>with lists of submodules and subrepositories. But this adds the
>ability to mantain them separately from the main code. What do you
>think?

Having worked with submodules/repositories I prefer a monorepo
8-). A monorepo also reduces mistakes when the tracker repo needs to be
coupled to releases of Roundup.

That said, it might be a way to do it. We do have the roundup-tracker
org on github. I'll have to check to see what sourceforge
supports. AFAIK they are the only major name mercurial repo provider
and we use a number of their services.

>Just out of curiosity, have you considered moving Roundup development
>entirely to git? This could attract more developers to contribute to
>the project.

There was an svn -> git migration a decade or so ago. There was some
outcry and we ended up on mercurial which is IMO a saner
VCS. Personally, I am a fossil SCM fan.

Also I had a discussion with a few PSF folks when we were migrating
the bugs.python.org issue tracker from Roundup to GitHub. The general
takeaway was they got more contributions but not neccessarity high
quality contributions. While I would like more contributors, I don't
need the noise. We have quite a few examples of good quality changes
where interest by the contributor withered (e.g. the schema patch for
postgresql).  If the added friction of using mercurial reduces drive
by low-quality changes, I'm ok with that as we only have 6 or so
people with direct commit access, most of them work on changes that
scratch their itch.

IMO we should never use github issues. We should eat our own dogfood.

>> It may be the case that changes in Roundup require changes to your
>> tracker template to work with the newest unreleased Roundup. We would
>> need to document these in upgrading.txt and figure out when they can
>> get published in your repo if they are not compatible with earlier
>> roundup releases.
>
>It might be easier to mantain separate template repositories in a
>single Github organization. Unfortunately, I don't know how this can
>be organized on SourceForge.

Agreed.

>I'm guessing most new installations will use Jinja, I've seen almost
>no other templating engines used in the Python world at the
>moment.

Even sphinx uses jinja2.

>But I agree, it's more convenient to have examples for both
>engines in one place.

Yeah we will need to continue to support the TAL based templates in
the wild. Similar to how I'm trying to support Python2 for a couple of
more releases.

>Also, one more question: have you considered mirroring the Roundup
>documentation on readthedocs?

I have. I have a conf file for RTD but am having issues with getting
the docs to build using the newer sphinx toolchain.

>But another problem arises: Roundup currently provides a template
>based on the classic schema called jinja2. Should we instead provide
>something like a symlink to jinja2-classic in the next release?

Did you create your template using jinja2 as the base? If not, I would
suggest we should either remove the existing jinja2 and replace with
jinja2-classic, or keep both under separate names.

The released trackers all show up in roundup-admin as a possible
template tracker. Having a single template under two different names
(jinja2 and jina2-classic) in the list of templates would be confusing
and redundant since they are identical.

If your template is an upgraded jinja2 where a diff of a current
tracker against a released jinja2 could be easily applied to your
jinja2 tracker, replacing jinja2 with a link might make
sense. Otherwise I think the link would just be confusing.