The request was for the reference to look like:

  issue2345: title of issue

In Roundup, object designators like issue2345 are automatically hyperlinked to the corresponding object.

The code I recommended used a button to trigger this operation. It also used the clipboard API. When clicking on the button (or hitting space or return while focused on the button) the reference format above will be copied to the clipboard. Triggering the clipboard API must be done by a user interaction. For example: activating a button. If the browser does not support the clipboard API, a simple alert() is shown.

In addition to copying to the clipboard, the user gets feedback when the text of the button changes to “Reference copied”. Then it resets to the original message after 2 seconds. Since clicking the button multiple times is idempotent, there is no sense in disabling or debouncing the button. Note, this is unlikely to be a11y compliant as I don't think the change of button text is announced. If anybody has some ideas on how to make this more compliant, leave them in the comments. Maybe using aria-live="polite" or "assertive" on the button element would do the trick?

Here is the code I suggested:

<button id="copyreference" type="button"
            tal:condition="context/is_edit_ok">
   Copy Reference
</button>

<script tal:attributes="nonce request/client/client_nonce">
  (function () {
    "use strict";

    let crb = document.querySelector("#copyreference");
    if ( ! crb ) return
    crb.addEventListener("click", async (e) => {
        e.preventDefault()
        if ( ! navigator.clipboard ) {
            alert("Clipboard is not available")
            return
        }

        let issueDesignator = new URL(document.URL)
            .pathname
            .split("/")
            .pop()
        let issueTitleText = document.querySelector("#title").value;

        await navigator.clipboard.writeText(`${issueDesignator}: ${issueTitleText}`)

        let originalCrbInnerText = crb.innerText
        crb.innerText = "Reference copied"
        setTimeout(() => {
            crb.innerText = originalCrbInnerText}, 2000)
        }
    );
  })();

The flexibility of Roundup allows the administrator to rewrite all of the HTML used in the web interface. As a result, I based my guess of CSS selectors on the HTML generated by the classic issue.item.html TAL template.

The button could be placed anywhere on the page and the script (including the nonce required by the CSP) would be placed anywhere after the button. Probably at the end of the page so it doesn't block rendering.

The classic structure of the issue display page for users with editing capability included an input with the id title. This is retrieved using the id and included in the string written to the clipboard.

A user without editing capability for the issue (or without editing capability for the title attribute of an issue) does not have an input with id="title". In these cases, the admin would have to modify the issue.item.html template to add an id of title to the enclosing element. Then the code above would be modified to replace:

let issueTitleText = document.querySelector("#title").value;

with:

 let issueTitle = document.querySelector("input#title");
   if ( ! issueTitle ) {
     issueTitle = document.querySelector("#title");
     issueTitleText = issueTitle.innerText
   } else {
     issueTitleText = issueTitle.value
   }

In my original example, the button element is generated only if the user can edit the issue. Removing the tal:condition attribute would always display the button.

There is nothing with an id or CSS selector that contains the object designator. I use the final element of the path of the URL to get the designator.

I chose to use the IIFE code structure. This allows me to use the early return pattern if the button is not found. If anybody knows how to do the equivalent of an early return without an IIFE or other function in a script tag, leave your trick in the comments.

If you use the Roundup Issue Tracker and have your own enhancements, feel free to mention them in the comments. #WebDev, #opensource #RoundupTracker #DevTo

My background is in system administration. So I have built a tracker template designed for tracking system administration issues. Recently I redesigned the look of one of the more complex forms.

This is the (short) story of the decisions I made and the techniques I used.

The starting point

I have limited design experience. When I set this up many years ago, it looked ok to me.

Looking at it today, the bold color swatches behind the fieldset legends and grooved borders make it seem cluttered and busy. It needs a more modern look.

Step 1 – fewer borders

First I removed the borders from the fieldsets. This brought up an issue. Tabbing through the form moves you down the columns (divs) and not across the rows. The borders and the gap between them helped re-enforce this.

I decided to add a vertical rule between the columns. I set border-inline-end to 2 pixels (2px) on the first column. When the first column was longer than the second this looked great. But, the fieldset panes in the first column are collapsible. When the first column was shorter than the second column, the line between the columns didn't reach the bottom of the second column.

The solution I came up with was to add a 2px border-inline-start on the second column. Then I moved the second column back by 2px (the width of the line) using margin-inline-start. These overlapped border lines always span the entire height of the longest column.

The layout uses the Gridiculous grid system rather than display: grid. This requires one last tweak. On narrower screens (e.g. a cell phone), the two side-by-side columns stack. Adding an @media query to remove the borders when on a narrow display completed the tweak.

How to make a vertical rule with css grid

I plan to use display: grid at some point for this layout. It would reduce the amount of CSS I need to serve and provide a more flexible layout. But, there is no mechanism for creating a rule in the gaps of a grid layout. I found a trick for doing that, but I haven't committed to using it yet. There is one nice advantage to using this trick. When the columns stack, grid removes the gap and also the (pseudo) vertical rule. No need for an @media cleanup.

To create the rule, I created a div (the base div) with the background-color set to the vertical rule's color. I set the CSS for that div to display: grid and the gap: 0 2px. I placed two divs inside the base div. They form the columns. Set their background-color to that of the rest of the page. Now the 2px column gap in the grid exposes the darker rule color of the base div. You can only emulate a solid border, but it works for my use case. Could linear gradients emulate a grooved, ridged, dotted, or dashed border?

My eyes, my eyes

The second change was to remove the banners of color behind the fieldset legends. With the more colorful themes, it's a bit bright on the eyes 8-). A simple underline matching the monochromatic theme replaces it. The HTML for the legend is <legend><span>Title Goes Here</span></legend>. Removing the background color from legend > span cleared the banner. Since the span is set to use display: block, adding a 2px border-block-end completed the work.

The final look

This is a significant improvement.

But it's still (a) bad form...

One question that you may ask is why tab order moves down the first/left column rather than across the form. As forms go this breaks a few rules:

1. use a single column for forms. In this case, I have not only two primary columns, but the basic fieldset has 2 subcolumns.
2. put labels above their control, or right-aligned labels to the left of the control (for ltr languages). Here, I use left-aligned labels to the left of the controls.

To justify my decisions, let's look at the use cases. As with most trackers, there are two types of users of this tracker. The:

1. people who need something done, and
2. the people doing the work.

There is also a third user, the person modifying the tracker for use at their site.

The left-hand column provides information for the people who need something done. Tabbing down the column moves the page like there was only one column. Ideally, these users would scan down the left column of the page. Using left-aligned labels provides this scan line.

Since Roundup can look at the user's role and remove/hide/collapse the second column we can get even closer to rule 1. This would make it a simpler form for these users. Still, displaying key status info above the fold requires packing a lot of fields in a small area. Following the “one column”, “label on top” guidelines would increase scrolling.

There is one more tweak for this redesign. With the second column displayed, a skip link will be added at the bottom of the first column. The skip link will jump to the update textarea where the user can add a change note/update. This bypasses all the tab stops in the second column.

Adding a skip link at the top of the page to target the update textarea area is an idea. However, a skip link already exists at the top of the page. It jumps to the main section, bypassing the left-hand navigation column (not shown in the images). Would adding a second top-of-page skip link be confusing clutter? I'm not sure.

For people doing the work, references to the schedule and linked tickets are more useful. The second column provides access to them. The “All Fields” tab provides even more information hidden from view. For example:

1. summaries of related tickets
2. a graph of relationships among tickets
3. extra fields for scheduling automatic actions.

This brings us to the third user. I tried to set up a form that the Roundup admin could adapt for their workflows. The admin should not have to be an HTML/CSS expert. The idea of Roundup is that it is customizable for many use cases. I have tried to use clean semantic HTML and simple CSS to support that idea.

Thanks for reading this. I hope you enjoyed it and learned something. You can find more information on Roundup using the link below. {% embed https://www.roundup-tracker.org?ref=dev.to-modern_form_update %}

#RoundupTracker #DevDotTo #WebDev

I have a B.S. in Physics which included some advanced computer science courses. But, my career ended up in system administration. I have taught and published a few peer-reviewed papers at conferences over the years. Trying to reduce toil and improve operations, lead to my interest in ticketing systems. Tools from LEAN and Six Sigma have proven valuable in analyzing ticketing and real-time logging data.

Issues Need Tracking

In 2002, I ran a lab that installed a system monitoring solution on Sun computers. We needed to track requests that came to the lab. I evaluated ticketing systems across a few dimensions. The Roundup Issue Tracker scored the highest.

Five minutes after downloading the software, I had a classic tracker running in demo mode. After entering a few tickets and adding a few keywords (tags), my co-worker and I decided it could work. It was flexible and looked like we could extend it to support our future growth. Little did I know that this was the start of a 20+ year relationship.

Roundup Basics

Roundup tracker has two components: the Roundup core and the tracker instance. The core is written in Python. The tracker instance supports one of two HTML templating engines: (Zope Page Templates or Jinja2). It is programmed in Python. The tracker instance controls the look/feel/functionality of the tracker. It:

• defines the database schema/data model,
• provides the web interface (with customizable HTML and CSS),
• executes Python code to validate entered data and react to a change (e.g. by emailing notification messages),
• can hook into the core code to control how the core operates.

One instance of the Roundup core can run many trackers. Each tracker can have a very different presentation and function.

Getting My Feet Wet

When I started, Roundup was still very new. I started developing my customized tracker to learn Python and experiment with Roundup. My tracker implemented several ideas from Request Tracker (RT). I developed the key components, replies/comments, dependencies, and grouping (parent/child), in less than 40 hours of effort over a few weeks. Roundup's implementation and documentation made building these significant features easy.

The other advantage was that Richard Jones, the developer, was in Australia. We set up a “follow the sun” development cycle. I emailed him a problem when I went to bed. By the time I got up the next morning, he would have a fix ready for me to use when I got home after work. This fast feedback is something I try to maintain in the Roundup community.

I never deployed my custom tracker, but the classic tracker worked well for the lab. As a result, the sales engineering group requested (and got) a tracker. After I left the company in 2005, they upgraded the Roundup core and converted the database to MySQL (from a dbm key/value store).

Back in a More Active Role

My next IT job used Request Tracker. I followed Roundup development but didn't contribute much. In 2012, there was some interest at work in setting up a customer-facing portal based on Roundup. I started development on my tracker again and re-joined the Roundup community. Over the next few years, I developed code to add:

• a transaction source property for data changes. Makes changes from the web interface but prevents the same change if it originated from (unsigned) email.
• the filter command to the roundup-admin command line interface makes data searching easier.
• nofollow relationships to links which makes Roundup less useful to spammers.
• CSRF protection using synchronizer tokens makes Roundup more secure.

Releasing Roundup

By 2018, Richard had stepped back, the last release was January 2016. I took over as a lead developer and release engineer. I released version 1.6.0 in July of 2018. This merged several existing patches, cleaning up Roundup's issue tracker.

Since 2018, there were two major changes added by other developers:

• support for both Python 2 and Python 3 (which required a 2.0.0 release)
• addition of a REST interface beside the XML-RPC interface

On July 13th, 2022, I made my fifth annual release.

Since Roundup deployments are on-prem, I established a yearly release cadence. Other issue trackers have more frequent releases. But, many of those releases address UI or workflow issues. In Roundup these are implemented in the (customized) tracker instance. So the user is not dependent on the fixes pushed from upstream. Each release includes upgrading instructions. These instructions can include changes for the tracker instance to bring it up to date.

The slower release cadence has an advantage for the users. It reduces the need to update tracker instances to once a year rather than every few months. However, the yearly cadence results in less public visibility for Roundup.

I plan more articles on developing and maintaining an open-source application. Some future topics I am considering include (in no particular order):

• The Customisability Trap
• Kitchen Sink Development
• Accessibility
• Responsive Design
• The Problem with Selects
• What?? No Javascript!
• Docker All the Things
• Colors and Themes
• The Bus Factor
• Evaluating Tracking Software

The Roundup 20^th anniversary article on lwn.net includes more information on Roundup.

I hope you enjoyed this article. Thanks for reading.

tags: #Python, #WebDev, #opensource #RoundupTracker #seriesRoundupTrackerNotesFromAnOpenSourceDeveloper #DevDotTo