Hello! I use Roundup for my personal tracker. Unfortunately, the current user interface is not suitable for use on mobile devices, and this is becoming increasingly critical.

Even Bootstrap based templates were created more than 10 years ago and still use HTML tables. The search and sorting forms are also complex and impossible to use on small displays.

I have updated my jinja2 based templates to use a modern version of Bootstrap and make them more mobile friendly. I suggest you consider replacing old templates with updated ones. 

I licensed my code under the MIT license, so it is fully compatible with the Roundup license. You can download the templates from my GitHub repository: <https://github.com/savchuk1985/roundup-jinja2-templates>. Also, I have attached some screenshots here.

If you have any suggestions, feel free to message me.

Hello. Thanks for your contribution.

I added this to the wiki earlier today: https://wiki.roundup-tracker.org/TrackerTemplates.

Usually an email is sent when a new issue is created. For this issue it's 460k while the
limit is 40k. So I am going to cancel the email.

Can you announce your template  on the roundup-users mailing list (roundup-
users@lists.sourceforge.net)? You can reference this issue: https://issues.roundup-
tracker.org/issue2551308 in your announcement for those who want to see the screenshots.

The templates could definitely use a refresh. As you noted the bootstrap is 10 years old and 
hasn't had a maintainer in most of that time. However there have been some updates
(bootstrap 4, jquery update).

The TAL based templates are in some cases over 20 years old and look it.

Just out of curiosity why did you switch from SimpleMDE to EasyMDE? Also which markdown 
renderer (markdown, markdown2, mistune) are you using with your tracker?

Being easy to reconfigure/change is one of the hallmarks of Roundup. I have to admit
I am totally stumped on how to autofocus the username field in the login dropdown. Using
google to try to resolve this issue didn't turn anything workable up after 45 minutes other 
than determining that adding "autofocus" was not expected to work 8-).

How the dropdown magically gets opened by clicking on the link (shouldn't it be a button
not a link for a11y even with the aria-role?) is confusing to me. Ideally changes should
be able to be made without requiring a high end web developer well versed in a framework.

However we only really provide info on modifying the TAL templates. We really need something 
similar for jinja2 (and whichever framework is used). Having somebody to answer questions
from users would be good as well.

Thanks for opening the issue. Let's see if people agree it can replace the existing jinja2
template (which I think is using the developer schema??). Then we can either add it to the
distributed trackers or replace the existing bootstrap based template. Also we can work out
how to handle maintenance and migrations/upgrades across releases.

Thank you. Yes, I will write to the user list later.

> Just out of curiosity why did you switch from SimpleMDE to EasyMDE?

The last commit to the SimpleMDE repository was 7 years ago. The last commit to the EasyMDE repository was 3 monts ago. SimpleMDE doesn't know anything about Bootstrap 5 and doesn't support dark themes.

> I am totally stumped on how to autofocus the username field in the login dropdown.

It seems that only JavaScript can help here. But I haven't tried to implement this yet.

> How the dropdown magically gets opened by clicking on the link 

As far as I understand, Bootstrap uses PopperJS for this. 

> shouldn't it be a button not a link

Unfortunately, it doesn't work otherwise. Initially I tried to implement a button, but ran into an issue with absolute/relative position of the dropdown and unexpected narrowing of the menu on "off-canvas". I didn't understand what was going on for almost a week. Let it be a link, at least it works.

> Ideally changes should be able to be made without requiring a high end web developer well versed in a framework.

Bootstrap sets its own rules. Some things get more complicated, but we don't have to write a complex stylesheets from scratch. Not all custom changes will work well with Bootstrap.

> However we only really provide info on modifying the TAL templates. We really need something similar for jinja2 (and whichever framework is used).

Yes. I even wanted to create an issue about this. 

Also, not many web applications use Zope TAL today. Jinja is widely known, and few people will want to learn another template engine. I believe that Jinja should be covered in the documentation first. And Zope TAL is only as an additional feature, so as not to scare potential users. I think we won't have a real alternative to Jinja in the next decade because Ansible uses it.

Hello John.

I've added autofocus to the username field in the login dropdown. You can see the code here: https://github.com/savchuk1985/roundup-jinja2-templates/commit/3d3b8b4423de349fa2f67ed8095d8f36f642dae1

I've also improved the internationalization a bit and moved the script links to the page header element (inline scripts are still at the end of the page).

> Thanks for opening the issue. Let's see if people agree it can replace the existing jinja2
> template (which I think is using the developer schema??). Then we can either add it to the
> distributed trackers or replace the existing bootstrap based template. Also we can work out
> how to handle maintenance and migrations/upgrades across releases.

The current jinja2 template is based on the classic scheme, so updating it was much easier =)

I wrote to the Roudup-users list and asked for feedback. I'm thinking that if the templates get positive feedback and maybe some fixes, I might try to help port the template based on developer schema from TAL to Jinja using current work. Then we could have modern jinja2-devel and jinja2-classic templates in addition to TAL-based devel and classic templates. Additionally, while this work is ongoing, it will be easier to include information about Jinja2 in the documentation.

> Also which markdown
> renderer (markdown, markdown2, mistune) are you using with your tracker?

Sorry, I missed this in my previous reply. I use markdown library. Markdown2 works for me too. Mistune doesn't work for me, but I didn't look into it.

Hi Anton:

In message
<trinity-f763f1fc-314f-4c60-9a7b-0509a231dc9f-1703413880072@3c-app-m
ailcom-bs06>, Anton Savchuk writes:

Nice job on the improvements.

>> Thanks for opening the issue. Let's see if people agree it can
>> replace the existing jinja2
>> template (which I think is using the developer schema??). Then we
>> can either add it to the
>> distributed trackers or replace the existing bootstrap based template.
>> Also we can work out how to handle maintenance and migrations/upgrades
>> across releases.
>
> The current jinja2 template is based on the classic scheme, so updating
> it was much easier =)

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.

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.

>I wrote to the Roundup-users list and asked for feedback.

I saw that. They arrived the day before Christmas. Very nice
touch 8-).

> I'm thinking that if the templates get positive feedback and maybe
> some fixes, I might try to help port the template based on developer
> schema from TAL to Jinja using current work. Then we could have
> modern jinja2-devel and jinja2-classic templates in addition to
> TAL-based devel and classic templates.

That's a great idea. Having a jinja2-classic to compare with a
jinja2-devel is also great documentation.

>Additionally, while this work is ongoing, it will be easier to
>include information about Jinja2 in the documentation.

Very true since most of the customizing doc is based on the classic
template.

Ideally we could provide the same examples in both TAL and
jinja2. Unlike mapping the same structure in yaml and json, there may
not be an exact 1:1 mapping between TAL and Jinja2. We might need to
rewrite some of the customizing doc examples. However revising the doc
to follow diataxis has been on my plate for a few years.

However the current TAL example provide a framework on what to
document.  Ideally we could present the code examples in a widget that
allows the user to view the TAL or Jinja2 implementation.

I'm not sure if sphinx can handle that, but it seems like embedding an
HTML web component in a sphinx `.. raw:: html` directive might
work. One child of the component is TAL code and the other is jinja2
code. Worst case both examples are shown one after the other rather
than in a viewable tab.

I don't want to end up with separate customizing_with_tal and
customizing_with_jinja docs. That pretty much guarantees that one or
the other will be unmaintained.

>> Also which markdown
>> renderer (markdown, markdown2, mistune) are you using with your tracker?
>
>Sorry, I missed this in my previous reply. I use markdown
>library. Markdown2 works for me too. Mistune doesn't work for me, but

Thanks for the data point. It could be because mistune==0.8.4 is what
we support. Support for 2.x mistune has an open ticket
https://issues.roundup-tracker.org/issue2551198.

> Nice job on the improvements.

Thank you =) 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.

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. This could also simplify the CSP rules when using Roundup behind a reverse proxy.

But in the case of the markdown editor loader, there is a problem with getting the parameter value from the Roundup configuration. Javascript is not my strong point and I have no ideas other than templating a JSON object and reading the editor configuration from that object.

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?

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

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

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

> I don't want to end up with separate customizing_with_tal and
> customizing_with_jinja docs. That pretty much guarantees that one or
> the other will be unmaintained.

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. But I agree, it's more convenient to have examples for both engines in one place.

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

I'm glad you liked my proposal to provide Jinja-based Classic/Devel templates in addition to TAL-based templates.

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?

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.

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

Hello John. I did some searching online and found an old answer on StackOverflow about creating multiple mercurial repositories for a project: https://stackoverflow.com/questions/17307189/how-do-i-set-up-a-second-mercurial-respository-on-sourceforge

There is also another answer about multiple git repositories: https://stackoverflow.com/questions/64921561/how-to-create-multiple-git-repositories-in-one-sourceforge-project

Both answers indicate that there are errors in the SourceForge documentation.

Hope this helps.

Hi Anton:

Thanks for the sourceforge pointers. I found the proper page:

  https://sourceforge.net/projects/roundup/

when I am logged in as an admin, I get the "Add New" button. That provides
me with actions git, mercurial, svn a few more (blog...) and also "Sub Project".
The latter may be the best alternative. I've got a question in to SF support
about this.

Hi Anton:

IIRC you don't have any classhelper popups to assist with filling in fields like nosy or 
keywords. I just fixed an issue with the user classhelper on issue2551320. Just wanted
to give you a heads up in case you have something similar.

Thank you, John. I used existing jinja2 templates as a base and they don't seem to use classhelpers either. I'll see how I can add them.

Have you been able to add additional repositories to the project on Sourceforge?

I also found free Gitlab mercurial hosting at https://foss.heptapod.net/

It seems like it hosted by the same company that works on the Tryton software. If I remember correctly, these guys used Roundup for issue tracking and published several plugins a few years ago.

Take a closer look at this service. I also think that it might be easier to negotiate with them if something special is needed for a Roundup project.

Hi Anton:

In message <1716952130.38.0.27006231215.issue2551308@roundup.psfhosted.org>,
Anton Savchuk writes:
>Anton Savchuk added the comment:
>
>Thank you, John. I used existing jinja2 templates as a base and they
>don't seem to use classhelpers either. I will see how I can add them.

I noticed that when I was working on integrating the new classhelper
code into the templates. I planned on updating the classic and jinja2
templates, but there was nothing to do for jinja2, which made my job
easier 8-).

>Have you been able to add additional repositories to the project on
>Sourceforge?

Yes there is an empty 'templates' mercurial repo at:
https://sourceforge.net/p/roundup/templates/ref/default/.
I have done nothing with it. Further work with this repo is
will be on a different ticket.

  https://issues.roundup-tracker.org/issue2551354

>I also found free Gitlab mercurial hosting at https://foss.heptapod.net/
>
>It seems like it hosted by the same company that works on the Tryton
>software. If I remember correctly, these guys used Roundup for issue
>tracking and published several plugins a few years ago.
>
>Take a closer look at this service. I also think that it might be
>easier to negotiate with them if something special is needed for a
>Roundup project.

Thanks for the pointer. They don't seem to provide the other services
that Sourceforge provides. Sourceforge hosts our mailing lists (such as
they are 8-)) and main web site. So we would have a presence there
even if we were to move the VCS component to a third site.

At this time I don't want to add another site to the mix. We are
currently managing multiple external resources: Sourceforge, GitHub,
wiki, IRC, issues, CI, code coverage providers (see
https://rouilj.github.io/RoundupAssets/ for the list.)

Moving just the VCS component is quite a bit of work with little gain
for the project.

Have a great day.
--
				-- rouilj
John Rouillard
===========================================================================
My employers don't acknowledge my existence much less my opinions.