roundup-users — Go here to ask questions about how to use Roundup

Re: [Roundup-users] Reactor functions get all old values, not just changed old values. (possible breaking change)

[John R. <ro...@ie...>]

Hi Ralf:

I have opened https://issues.roundup-tracker.org/issue2551433

My plan unless we get more feedback (hello anybody besides Ralf??) is
to force upgrading of
reactors by changing oldvalues to contain the values only for
properties that have changed.

-- rouilj

On Mon, Oct 5, 2026 at 12:18 PM Ralf Schlatterbeck <rs...@ru...> wrote:
>
> On Mon, Oct 05, 2026 at 10:52:44AM -0400, John Rouillard wrote:
> > > > is ok but a bare:
> > > >    oldvalues['some_unchanged_prop']
> > > > will fail if I strip unchanged properties.
> ...
> > I see three options:
> >
> >   1) update the docs to indicate the current code
> >   2) change the code to only include changed database items and
> > everybody needs to audit their reactors.
> >   3) provide two paths with/without unchanged props and a switch(in
> > config.ini or interfaces.py) to remove
> >        unchanged props (default is to include them).
> >
> > 1 is easiest, but I really want "'unchanged prop' in oldvalues" to
> > work because it reduces cognitive load by matching
> >     auditors and eliminates unneeded database accesses to compare values.
> >
> > 2 is preferred but makes upgrading more difficult.
> >
> > 3 adds another switch that most people won't know about, clutters
> > config.ini and increases testing burden.
>
> I would prefer 2)
> In the past we have often had some docs on upgrading.
>
> I *think* that I would be one of the persons with lots of new reactors.
> And I think it is doable: I can simply grep for oldvalues (I'm pretty
> sure I've never called this parameter of my reactors differently) and
> check all occurrences.
>
> And since nobody complained so far that the docs are wrong on the
> contents of oldvalues, I *think* that not too many people have written
> their own reactors using that feature...
>
> And future reactors can become easier...
>
> Kind regards
> Ralf
> --
> Dr. Ralf Schlatterbeck                  Tel:   +43/2243/26465-16
> Open Source Consulting                  www:   www.runtux.com
> Reichergasse 131, A-3411 Weidling       email: of...@ru...

Re: [Roundup-users] Reactor functions get all old values, not just changed old values. (possible breaking change)

[Ralf S. <rs...@ru...>]

On Mon, Oct 05, 2026 at 10:52:44AM -0400, John Rouillard wrote:
> > > is ok but a bare:
> > >    oldvalues['some_unchanged_prop']
> > > will fail if I strip unchanged properties.
...
> I see three options:
> 
>   1) update the docs to indicate the current code
>   2) change the code to only include changed database items and
> everybody needs to audit their reactors.
>   3) provide two paths with/without unchanged props and a switch(in
> config.ini or interfaces.py) to remove
>        unchanged props (default is to include them).
> 
> 1 is easiest, but I really want "'unchanged prop' in oldvalues" to
> work because it reduces cognitive load by matching
>     auditors and eliminates unneeded database accesses to compare values.
> 
> 2 is preferred but makes upgrading more difficult.
> 
> 3 adds another switch that most people won't know about, clutters
> config.ini and increases testing burden.

I would prefer 2)
In the past we have often had some docs on upgrading.

I *think* that I would be one of the persons with lots of new reactors.
And I think it is doable: I can simply grep for oldvalues (I'm pretty
sure I've never called this parameter of my reactors differently) and
check all occurrences.

And since nobody complained so far that the docs are wrong on the
contents of oldvalues, I *think* that not too many people have written
their own reactors using that feature...

And future reactors can become easier...

Kind regards
Ralf
-- 
Dr. Ralf Schlatterbeck                  Tel:   +43/2243/26465-16
Open Source Consulting                  www:   www.runtux.com
Reichergasse 131, A-3411 Weidling       email: of...@ru...

Re: [Roundup-users] Reactor functions get all old values, not just changed old values. (possible breaking change)

[John R. <ro...@ie...>]

Hi Ralf and all the people at their inboxes:

On Mon, Oct 5, 2026 at 10:22 AM Ralf Schlatterbeck <rs...@ru...> wrote:
> On Mon, Oct 05, 2026 at 10:00:30AM -0400, John Rouillard wrote:
> > For example:
> >      "some_unchanged_prop" in oldvalues and oldvalues['some_unchanged_prop']
> > is ok but a bare:
> >    oldvalues['some_unchanged_prop']
> > will fail if I strip unchanged properties.
> >
> > Currently the second case is fine and returns the same value as a database lookup.
>
> Right, I'm not sure I'm doing it correctly everywhere. I *think* I'm
> using oldvalues.get in most cases but I probably should go over all uses
> of oldvalues...
>
> Thanks for pointing this out

Yeah, that's kind of what I was worried about. I see three options:

  1) update the docs to indicate the current code
  2) change the code to only include changed database items and
everybody needs to audit their reactors.
  3) provide two paths with/without unchanged props and a switch(in
config.ini or interfaces.py) to remove
       unchanged props (default is to include them).

1 is easiest, but I really want "'unchanged prop' in oldvalues" to
work because it reduces cognitive load by matching
    auditors and eliminates unneeded database accesses to compare values.

2 is preferred but makes upgrading more difficult.

3 adds another switch that most people won't know about, clutters
config.ini and increases testing burden.

Anybody with thoughts?

How big a burden would it be for you to fix all your reactors?

-- rouilj

Re: [Roundup-users] Reactor functions get all old values, not just changed old values. (possible breaking change)

[Ralf S. <rs...@ru...>]

On Mon, Oct 05, 2026 at 10:00:30AM -0400, John Rouillard wrote:
> 
> You said you have checks to see if oldvalue and newvalue are different.
> 
> Is each of your oldvalue checks guarded to make sure the property you are
> comparing exists in oldvalues?
> 
> For example:
> 
>      "some_unchanged_prop" in oldvalues and oldvalues['some_unchanged_prop']
> 
> is ok but a bare:
> 
>    oldvalues['some_unchanged_prop']
> 
> will fail if I strip unchanged properties.
> 
> Currently the second case is fine and returns the same value as a
> database lookup.

Right, I'm not sure I'm doing it correctly everywhere. I *think* I'm
using oldvalues.get in most cases but I probably should go over all uses
of oldvalues...

Thanks for pointing this out.

Kind regards
Ralf
-- 
Dr. Ralf Schlatterbeck                  Tel:   +43/2243/26465-16
Open Source Consulting                  www:   www.runtux.com
Reichergasse 131, A-3411 Weidling       email: of...@ru...

Re: [Roundup-users] Reactor functions get all old values, not just changed old values. (possible breaking change)

[John R. <ro...@ie...>]

Hi Ralf:

On Mon, Oct 5, 2026 at 3:55 AM Ralf Schlatterbeck <rs...@ru...> wrote:
> On Sun, Oct 04, 2026 at 10:39:25PM -0400, John Rouillard via Roundup-users wrote:
> [Documented behavior of which properties are in oldvalues differs from
> what is documented]
>
> Yes, I noticed that a long time ago but didn't look into what is
> documented. A lot of my code has additional checks if the current value
> is the same/differs from the one in oldvalues. But I do not think fixing
> this will break anything, so I guess it's a good idea to finally fix it,
> thanks for taking the time to take a detailed look!

You said you have checks to see if oldvalue and newvalue are different.

Is each of your oldvalue checks guarded to make sure the property you are
comparing exists in oldvalues?

For example:

     "some_unchanged_prop" in oldvalues and oldvalues['some_unchanged_prop']

is ok but a bare:

   oldvalues['some_unchanged_prop']

will fail if I strip unchanged properties.

Currently the second case is fine and returns the same value as a
database lookup.

-- rouilj

Re: [Roundup-users] Reactor functions get all old values, not just changed old values. (possible breaking change)

[Ralf S. <rs...@ru...>]

On Sun, Oct 04, 2026 at 10:39:25PM -0400, John Rouillard via Roundup-users wrote:
> Hello All:
> 
[Documented behavior of which properties are in oldvalues differs from
what is documented]

Yes, I noticed that a long time ago but didn't look into what is
documented. A lot of my code has additional checks if the current value
is the same/differs from the one in oldvalues. But I do not think fixing
this will break anything, so I guess it's a good idea to finally fix it,
thanks for taking the time to take a detailed look!

Thanks, Ralf
-- 
Dr. Ralf Schlatterbeck                  Tel:   +43/2243/26465-16
Open Source Consulting                  www:   www.runtux.com
Reichergasse 131, A-3411 Weidling       email: of...@ru...

[Roundup-users] Reactor functions get all old values, not just changed old values. (possible breaking change)

[John R. <ro...@ie...>]

Hello All:

I was working on getting some additional info put in place for
a reactor detector issue and discovered a mismatch between what is
documented and how the reactor is called.

The reactor signature is:

    def reactor(db, cl, nodeid, oldvalues):

 Currently the expression:

   "interesting_prop" in oldvalues

is always true even if interesting_prop wasn't changed in this transaction.

The spec (references.txt) for reactors says olddata (usually named
oldvalues in actual code) says:

    For a ``set()`` operation, ``olddata`` contains the names and previous
    values of properties that were changed.

oldvalues has the previous value for *all* properties of the object, not
just changed properties. This differs from an auditor where:

  "propname" in newdata

is a useful statement since newdata only has keys for properties being changed.

I think this is an old bug. It has been this way since at least version
0.5.0 AFAICT.

 I suggest changing the roundup core so that olddata has exactly the
same keys that newdata has so that I can use:

  if 'prop' not in oldvalues:
     return

successfully to return from a reactor if the props that trigger the
reactor are missing.

To do this I can change set() in class Class and class FileClass in hyperdb.py
to add:

  oldvalues = {prop: val for prop, val in oldvalues.items() if prop in
propvalues}

where oldvalues is a copy.deepcopy() of the object lookup before
anything is changed. propvalues is the newdata passed to an auditor.
The assignment above will be done after the auditor returns so it
picks up new values added to newdata. Then pass the filtered oldvalues
to the reactor.

Is anybody's reactor expecting olddata/oldvalues to have every value
for the object even those that have not changed? If the value is
unchanged it can be
looked up in the database.

I seem to remember a discussion about this a long time ago, but I can't
find it.

If this is considered a bad idea, I will update the reference.txt doc
to indicate
all of the properties of the object are passed to the reactor.

Thoughts?

-- rouilj

[Roundup-users] Roundup 2.6.0 released

[John R. <ro...@ie...>]

Hello all:

I have uploaded 2.6.0 to pypi and a new docker image is also released.

I don't have access to the main web site at the moment. A ticket is
open with sourceforge. So hopefully the new docs will be deployed
sometime later today (July 13th).

Once the new docs are up I'll do another announcement. There are 14
items in the upgrading doc none of which are required. However the
first two items are
fixes for CVE's if you are running an older version of Roundup. Until
the new web site is up, you can look at the security page on the
current website to get the fixes.

I'm proud to release version 2.6.0 of the Roundup issue
tracker.  This release is a bugfix and feature release, so
make sure to read the upgrading doc at
https://www.roundup-tracker.org/docs/upgrading.html to
bring your tracker up to date.

The 49 changes, as usual, include some new features and many
bug fixes.

Version 2.6.0 requires Python version 3.10 or newer.

Note that you should run ``roundup-admin ... migrate`` to
update the database schema version. Do this before you use
the web, command-line or mail interface and before any users
access the tracker.

You can install it with::

   pip install roundup

(preferably in a virtual environment). To download it, use::

   pip download roundup

then unpack and test/install from the tarball.

Among the significant enhancements in version 2.6.0 compared to
the 2.5.0 release are:

* Fix old CSRF prevention for PATCH method

  The PATCH method was not covered by the old CSRF protection method.

* Filter history entries where permissions are handled by check function

  When a property's permission uses a check command, the history
  of changes for that property were shown. The permissions are now
  properly checked using the check function.

* Modern CSRF prevention method available

  This release implements CSRF protection using `Cross-Site Request
  Forgery by Filippo Valsorda <https://words.filippo.io/csrf/>`_.  This
  is an effective method for CSRF protection and is much simpler as
  well. There are no configurable options unlike the 8 options for the
  older method. This can be opted into using config.ini.

* Require reauthentication when making changes to sensitive fields

  You can trigger a reauthentication when the user changes particular
  fields. For example you can require a password be entered before the
  user changes their password.

* Classic UI interface modernization.

  The classic tracker has basic responsive support for mobile.  The
  table based layout was removed and HTML 5 landmarks (main, nav ...)
  are used along with flex and grid layouts.  The left hand menu now
  collapses to a grid layout in a single column when on a smaller
  display. This can be retrofitted to existing classic trackers.

  When you moved from one page to the next on an index, the
  query/search name was lost. This release now preserves the search
  name.

  Queries triggered from the query edit page now include the query
  name in the index view.

  The web UI now allows users to log in without a password. Before the
  password field was required which prevented completing the login
  action.

  The user.item.html template now generates valid javascript.

  The jinja2 template got an updated copy of bootstrap.

Other miscellaneous fixes include:

* Multiple internal cleanups:
  * remove some Python2 support code
  * reformat
  * refactor code replacing with faster/pythonic code
  * restructuring exception handling to stop ignoring important exceptions

* Documentation: wsgi updates replacing uwsgi (abandoned) with waitress
  (which also works on windows).

* rest updates with a null value no longer cause update failures.

The file CHANGES.txt has a detailed list of feature
additions and bug fixes for each release. You can view it at:
https://sourceforge.net/p/roundup/code/ci/default/tree/CHANGES.txt

-- rouilj

[Roundup-users] A little over 1 week for roundup release 2.6

[John R. <ro...@ie...>]

Hi all:

Just a reminder that a new release is due out on 7/13.

it's just a "pip roundup==2.6.0b1" away.

If you have any problems, now is the time to raise them.

-- rouilj

[Roundup-users] Roundup 2.6.0b1 release (and security notice)

[John P. R. <ro...@cs...>]

Hello all:

I have released roundup-2.6.0b1 for evaluation. I plan on a 2.6.0
release mid July. Release 2.6.0 requires Python version 3.10 or newer.

The announcement is at:

   https://www.roundup-tracker.org/dev_docs/docs/announcement.html

This fixes two CVE's (no numbers assigned yet by Mitre, still waiting
for them to respond to my request from a month ago, if anybody has a
contact there let me know.)

  1) The PATCH method is not properly protected from CSRF. This
     affects all versions since 2.0.0 when rest support was added and
     the PATCH verb became meaningful.

  2) The item history display does not use the check function of
     permissions. As a result some property changes are shown when
     they should not be. The current value of the property is still
     protected, only prior values are displayed.

These are fixed in version 2.6.0. Directions on fixing earlier
versions are linked from:

    https://www.roundup-tracker.org/docs/security.html.

The full set of 2.6.0b1 docs is at:

    https://www.roundup-tracker.org/dev_docs/

highlights fixes/features:

  issue2551413 - Broken MultiLink columns in CSV export. CSV export of
  a multilink to a class that does not have a ‘name’ property causes a
  crash.

  the classic tracker has basic responsive layout. There is more work
  to do, but even this basic page.html change makes things better.
 
  add support for authorized changes. User can be prompted to enter
  their password to authorize a change. If the user’s password is
  properly entered, the change is committed.

  the default log template includes an identifier unique for a
  request. This identifier (trace_id) can be use to identify all logs
  for a specific transaction. Also add support for dictConfig style
  logging configuration.

  add support for tokenless/nonceless CSRF prevention following
  https://words.filippo.io/csrf/. This will become the default in the
  future.

  add readline command to roundup-admin to list history, control input
  mode etc. Also support bang (!) commands to rerun commands in
  history or put them in the input buffer for editing.

Use the user's mailing list or open issues for any problems.

Thanks for testing.
--

John Rouillard
===========================================================================
My employers don't acknowledge my existence much less my opinions.

Re: [Roundup-users] Looking for a howto on encrypting email inbound to Roundup

[John R. <ro...@ie...>]

Hi Ralf (and others) :

I just committed some verbage on PGP/GPG setup. Can you look at:

https://github.com/roundup-tracker/roundup/commit/5c79282f52b53a9f7cf6e8bf4d1f8413befd3156

and see if anything looks wrong?

Thanks.

-- rouilj

On Mon, Nov 10, 2025 at 2:29 AM Ralf Schlatterbeck <rs...@ru...> wrote:
>
> On Sun, Nov 02, 2025 at 08:08:18PM -0500, John P. Rouillard via Roundup-users wrote:
> > Hi all:
> >
> > Does anybody have a howto on sending gpg/pgp encrypted email to an
> > Roundup instance?
>
> I had used this a *long* time ago but the details have vanished in the
> mists of time .-)
> The setup has a private PGP key for decrypting incoming PGP mails. And
> it is supposed to have a bunch of public keys to verify incoming mails.
> For this the 'homedir' in the [pgp] section is used, it has a public and
> a private keyring. It plays the same role as the ~/.pgp directory of a
> user. You can enforce incoming emails to be signed with the
> 'require_incoming = signed' setting. You can force outgoing mails to be
> encrypted and you can define roundup roles for which PGP is used.
> Incoming mails are always pgp-handled when it is turned on.
>
> That's as far as I ever used this... but as said it is a long time ago.
>
> > Frankly any docs on setting up Roundup for use with pgp/gpg would be
> > useful as this feature is kind of useless without proper docs.
>
> Yes I think so, too. These days pgp isn't used much...
> When writing docs it might make a lot of sense to also update the tests
> to really support what is written in the docs, last time I looked pgp
> test coverage was minimal.
>
> Kind regards
> Ralf
> --
> Dr. Ralf Schlatterbeck                  Tel:   +43/2243/26465-16
> Open Source Consulting                  www:   www.runtux.com
> Reichergasse 131, A-3411 Weidling       email: of...@ru...

[Roundup-users] Fwd: rich text editor to allow for formatted input

[John R. <ro...@ie...>]

I sent this to Norbert without including the list apparently.

---------- Forwarded message ---------
From: John Rouillard <ro...@ie...>
Date: Tue, Nov 11, 2025 at 12:27 PM
Subject: Re: [Roundup-users] rich text editor to allow for formatted input


Norbert asked:

> I would like to replace the "Note" field with a rich text editor to allow for
> formatted input (Markdown or HTML).

The jinja template uses simplemde so you can look there for ideas.
See: https://issues.roundup-tracker.org/issue2550856

As far as adding that to the classic template, there are no plans for
that at this time.
One issue with markdown is that it is not standardized. So the same
markup can have different presentation in a client side editor or the
server side rendered note.
See: https://issues.roundup-tracker.org/issue2551105 for one example.

However using a text input box with a preview button powered by server
side rendering could be suitable. Se
https://issues.roundup-tracker.org/msg6814 which is part of
issue2550856.

https://issues.roundup-tracker.org/issue2551176 mentions markdown-it
and markdown-py use. which are related implementations of what one
hopes is a single markdown understanding. Something like:
https://markdown-it.github.io/ for editing might work.

-- rouilj

[Roundup-users] rich text editor to allow for formatted input

[SCHLEMMER N. <Nor...@pd...>]

Hello everyone,

Now that I have successfully upgraded to version 2.5.0, I would like to replace the "Note" field with a rich text editor to allow for formatted input (Markdown or HTML).
My question is: Are there already any considerations or plans to use TinyMCE, EasyMDE, or a similar editor for the Note field?

Thank you very much and best regards
Norbert

Re: [Roundup-users] Looking for a howto on encrypting email inbound to Roundup

[Ralf S. <rs...@ru...>]

On Sun, Nov 02, 2025 at 08:08:18PM -0500, John P. Rouillard via Roundup-users wrote:
> Hi all:
> 
> Does anybody have a howto on sending gpg/pgp encrypted email to an
> Roundup instance?

I had used this a *long* time ago but the details have vanished in the
mists of time .-)
The setup has a private PGP key for decrypting incoming PGP mails. And
it is supposed to have a bunch of public keys to verify incoming mails.
For this the 'homedir' in the [pgp] section is used, it has a public and
a private keyring. It plays the same role as the ~/.pgp directory of a
user. You can enforce incoming emails to be signed with the
'require_incoming = signed' setting. You can force outgoing mails to be
encrypted and you can define roundup roles for which PGP is used.
Incoming mails are always pgp-handled when it is turned on.

That's as far as I ever used this... but as said it is a long time ago.

> Frankly any docs on setting up Roundup for use with pgp/gpg would be
> useful as this feature is kind of useless without proper docs.

Yes I think so, too. These days pgp isn't used much...
When writing docs it might make a lot of sense to also update the tests
to really support what is written in the docs, last time I looked pgp
test coverage was minimal.

Kind regards
Ralf
-- 
Dr. Ralf Schlatterbeck                  Tel:   +43/2243/26465-16
Open Source Consulting                  www:   www.runtux.com
Reichergasse 131, A-3411 Weidling       email: of...@ru...

Re: [Roundup-users] Docker Container 2.5.0 / UniqueViolation: duplicate key value violates unique constraint "_issue_pkey"

[Ralf S. <rs...@ru...>]

On Tue, Nov 04, 2025 at 08:56:50AM +0000, SCHLEMMER Norbert wrote:
> Hello
> 
> Well, I performed the following steps:
[...]

Apart from the additional import/export to PostgreSQL 17 this looks like
the process I also would use.


> I then compared the tracker directory with one from version 2.5.0 and
> noticed a few changes, apart from the message files, which I still
> want to look at in detail.

Hmm, there should be no changes in the db directory.

On Mon, Nov 03, 2025 at 09:31:04PM -0500, John Rouillard via Roundup-users wrote:

> Also one thing I thought of. If you are using the same tracker home,
> you can export just the database with no files using roundup-admin.
> Then import just the database data. That should speed up the process.
> My guess is the 6 hours load time was spent shuffling those 85000
> messages.

I don't think the messages would be the problem, In the past I noticed
that for large database tables our import code can take a long time...

Also glad it worked :-)

Kind regards
Ralf
-- 
Dr. Ralf Schlatterbeck                  Tel:   +43/2243/26465-16
Open Source Consulting                  www:   www.runtux.com
Reichergasse 131, A-3411 Weidling       email: of...@ru...

Re: [Roundup-users] Docker Container 2.5.0 / UniqueViolation: duplicate key value violates unique constraint "_issue_pkey"

[SCHLEMMER N. <Nor...@pd...>]

Hello

Well, I performed the following steps:

.) On the source system running Debian 12, I performed a database export from PostgreSQL and compressed the file.
.) On the source system, the tracker directory was also zipped.
.) Both zip files and the docker-compose.yml file were copied to the destination system running Debian 13 / Trixie and unzipped there.
.) The Roundup image has now been updated to version 2.5.0.
.) A PostgreSQL 17 container was started, and the export file was imported. Subsequently, another export was created, which was then imported into a PostgreSQL 18 container.
.) The PostgreSQL 17 container has now been deleted, and the PostgreSQL 18 container is being used as a service in the compose file.
.) Both services in the Docker Compose file, the PostgreSQL and the Roundup issue tracker, are now running, all previous data is present and appears to be intact.

I then compared the tracker directory with one from version 2.5.0 and noticed a few changes, apart from the message files, which I still want to look at in detail.

Br
Norbert


-----Ursprüngliche Nachricht-----
Von: John Rouillard <ro...@ie...> 
Gesendet: Dienstag, 04. November 2025 03:31
An: SCHLEMMER Norbert <Nor...@pd...>
Cc: rou...@li...
Betreff: Re: [Roundup-users] Docker Container 2.5.0 / UniqueViolation: duplicate key value violates unique constraint "_issue_pkey"

*EXTERNAL source*


How did you do it? What procedure worked?

Also one thing I thought of. If you are using the same tracker home, you can export just the database with no files using roundup-admin. Then import just the database data. That should speed up the process. My guess is the 6 hours load time was spent shuffling those 85000 messages.

The export/import method is really meant for changing between back end databases (e.g. anydbm or sqlite to postgres) and the export format is not guaranteed to work between roundup versions. However I don't know of any breaking issues between 2.2.0 and 2.5.0 releases.

Glad to hear you have it working.

-- rouilj

On Mon, Nov 3, 2025 at 2:03 AM SCHLEMMER Norbert <Nor...@pd...> wrote:
>
> Hi John
>
> I successfully upgraded to PostgreSQL 18.
> We have approximately 12,000 issues with 85,000 messages.
>
> Br
> Norbert
>
> -----Ursprüngliche Nachricht-----
> Von: John Rouillard <ro...@ie...>
> Gesendet: Samstag, 01. November 2025 02:51
> An: SCHLEMMER Norbert <Nor...@pd...>
> Cc: rou...@li...
> Betreff: Re: [Roundup-users] Docker Container 2.5.0 / UniqueViolation: duplicate key value violates unique constraint "_issue_pkey"
>
> *EXTERNAL source*
>
>
> Hi Norbert:
>
> Sorry, I'm kind of tied up with other things.
>
> On Wed, Oct 29, 2025 at 5:00 AM SCHLEMMER Norbert <Nor...@pd...> wrote:
> > What is the recommended upgrade path from Docker "2.3.0 / PostgreSQL 17" to "2.5.0 / PostgreSQL 18"
> > and for migrating to a different host with Debian 13 / Trixie?
>
> I suggest:
>
>    dump/restore the database from postgresql 17 to 18 using pg_dump etc.
>
>    then copy over the tracker home directory and follow the steps in upgrading.txt
>    (https://www.roundup-tracker.org/docs/upgrading.html) from 2.3.0 to 2.4.0 and then 2.5.0.
>    The required steps need to be done. If you omit the rest, it should still allow Roundup to work, but there may be security or other issues.
>
> > Can the Docker image simply be changed from roundup:2.3.1a0 to roundup:2.5.0-1?
> > I did this and didn't find any problems during testing. Is this procedure permissible and recommended?
> > If so, I can then upgrade to PostgreSQL 18 in the next step using SQL dump/restore.
>
> That should work provided you do the changes in upgrading.txt.
>
> Ralf said on Mittwoch, 29. Oktober 2025 09:29
> > On Wed, Oct 29, 2025 at 07:31:32AM +0000, SCHLEMMER Norbert wrote:
> > > An export was created from the productive Roundup instance 2.3.0.
> > > After importing in version 2.5.0, new messages can be added to an 
> > > existing issue but creating a new issue result in this violation; 
> > > see logs attached (the import process takes approximately 6 hours...).
>
> How many issues do you have?
>
> > Note that using the roundup-export / roundup-import is not 
> > recommended for version upgrade, that should happen in-place. This might be the reason of the error-message you're seeing.
>
> > > UniqueViolation: duplicate key value violates unique constraint 
> > > "_issue_pkey" DETAIL: Key (id)=(3)
> >  >       already exists.    Python 3.13.5
> > > /usr/local/bin/python3.13
>
> > Hmm, this might be because a retired node (e.g. an issue) is first 
> > created and then retired, it could produce a duplicate primary key if a non-retired node *with the same key* already exists.
> > But under normal circumstances duplicate primary keys should not occur (even including retired nodes).
>
> This is happening post import, correct Norbert?
>
> We fixed an import issue with duplicate keys back in the 2.1.0 release. it was caused when a user was created with the name "A". Then it was retired. Later a new user with the name "A" was created. When the export/import was done if the retired entry was imported after the non-retired entry the name "A"
> which is a pkey conflicted.
>
> However for issues, the title is not a primary key so I am not sure how you would get this conflict.
>
> It almost looks like the sequence used to number (id) the issues isn't set properly.
> Can you connect to the database and run:
>
>   select * from _issue_ids;
>
> you should see something like:
>
>  last_value | log_cnt | is_called
> ------------+---------+-----------
>             1 |         0 |          f
>
> where last_value is one more than the largest id number in the _issues table.
> Something like `select max(id) from _issue;` might do the trick to find the current max id number.
>
> If the last_value is wrong, check the rest of the sequences (use \ds to list sequences and select like above to see the value).
>
> I haven't seen an issue like that in my (limited) postgres testing of import/export.
>
> -- rouilj

Re: [Roundup-users] Docker Container 2.5.0 / UniqueViolation: duplicate key value violates unique constraint "_issue_pkey"

[John R. <ro...@ie...>]

How did you do it? What procedure worked?

Also one thing I thought of. If you are using the same tracker home,
you can export just the database with no files
using roundup-admin. Then import just the database data. That should
speed up the process. My guess is the 6 hours
load time was spent shuffling those 85000 messages.

The export/import method is really meant for changing between back end
databases (e.g. anydbm or sqlite to postgres)
and the export format is not guaranteed to work between roundup
versions. However I don't know of any breaking
issues between 2.2.0 and 2.5.0 releases.

Glad to hear you have it working.

-- rouilj

On Mon, Nov 3, 2025 at 2:03 AM SCHLEMMER Norbert
<Nor...@pd...> wrote:
>
> Hi John
>
> I successfully upgraded to PostgreSQL 18.
> We have approximately 12,000 issues with 85,000 messages.
>
> Br
> Norbert
>
> -----Ursprüngliche Nachricht-----
> Von: John Rouillard <ro...@ie...>
> Gesendet: Samstag, 01. November 2025 02:51
> An: SCHLEMMER Norbert <Nor...@pd...>
> Cc: rou...@li...
> Betreff: Re: [Roundup-users] Docker Container 2.5.0 / UniqueViolation: duplicate key value violates unique constraint "_issue_pkey"
>
> *EXTERNAL source*
>
>
> Hi Norbert:
>
> Sorry, I'm kind of tied up with other things.
>
> On Wed, Oct 29, 2025 at 5:00 AM SCHLEMMER Norbert <Nor...@pd...> wrote:
> > What is the recommended upgrade path from Docker "2.3.0 / PostgreSQL 17" to "2.5.0 / PostgreSQL 18"
> > and for migrating to a different host with Debian 13 / Trixie?
>
> I suggest:
>
>    dump/restore the database from postgresql 17 to 18 using pg_dump etc.
>
>    then copy over the tracker home directory and follow the steps in upgrading.txt
>    (https://www.roundup-tracker.org/docs/upgrading.html) from 2.3.0 to 2.4.0 and then 2.5.0.
>    The required steps need to be done. If you omit the rest, it should still allow Roundup to work, but there may be security or other issues.
>
> > Can the Docker image simply be changed from roundup:2.3.1a0 to roundup:2.5.0-1?
> > I did this and didn't find any problems during testing. Is this procedure permissible and recommended?
> > If so, I can then upgrade to PostgreSQL 18 in the next step using SQL dump/restore.
>
> That should work provided you do the changes in upgrading.txt.
>
> Ralf said on Mittwoch, 29. Oktober 2025 09:29
> > On Wed, Oct 29, 2025 at 07:31:32AM +0000, SCHLEMMER Norbert wrote:
> > > An export was created from the productive Roundup instance 2.3.0.
> > > After importing in version 2.5.0, new messages can be added to an
> > > existing issue but creating a new issue result in this violation;
> > > see logs attached (the import process takes approximately 6 hours...).
>
> How many issues do you have?
>
> > Note that using the roundup-export / roundup-import is not recommended
> > for version upgrade, that should happen in-place. This might be the reason of the error-message you're seeing.
>
> > > UniqueViolation: duplicate key value violates unique constraint
> > > "_issue_pkey" DETAIL: Key (id)=(3)
> >  >       already exists.    Python 3.13.5
> > > /usr/local/bin/python3.13
>
> > Hmm, this might be because a retired node (e.g. an issue) is first
> > created and then retired, it could produce a duplicate primary key if a non-retired node *with the same key* already exists.
> > But under normal circumstances duplicate primary keys should not occur (even including retired nodes).
>
> This is happening post import, correct Norbert?
>
> We fixed an import issue with duplicate keys back in the 2.1.0 release. it was caused when a user was created with the name "A". Then it was retired. Later a new user with the name "A" was created. When the export/import was done if the retired entry was imported after the non-retired entry the name "A"
> which is a pkey conflicted.
>
> However for issues, the title is not a primary key so I am not sure how you would get this conflict.
>
> It almost looks like the sequence used to number (id) the issues isn't set properly.
> Can you connect to the database and run:
>
>   select * from _issue_ids;
>
> you should see something like:
>
>  last_value | log_cnt | is_called
> ------------+---------+-----------
>             1 |         0 |          f
>
> where last_value is one more than the largest id number in the _issues table.
> Something like `select max(id) from _issue;` might do the trick to find the current max id number.
>
> If the last_value is wrong, check the rest of the sequences (use \ds to list sequences and select like above to see the value).
>
> I haven't seen an issue like that in my (limited) postgres testing of import/export.
>
> -- rouilj

Re: [Roundup-users] Docker Container 2.5.0 / UniqueViolation: duplicate key value violates unique constraint "_issue_pkey"

[SCHLEMMER N. <Nor...@pd...>]

Hi John

I successfully upgraded to PostgreSQL 18.
We have approximately 12,000 issues with 85,000 messages.

Br
Norbert

-----Ursprüngliche Nachricht-----
Von: John Rouillard <ro...@ie...> 
Gesendet: Samstag, 01. November 2025 02:51
An: SCHLEMMER Norbert <Nor...@pd...>
Cc: rou...@li...
Betreff: Re: [Roundup-users] Docker Container 2.5.0 / UniqueViolation: duplicate key value violates unique constraint "_issue_pkey"

*EXTERNAL source*


Hi Norbert:

Sorry, I'm kind of tied up with other things.

On Wed, Oct 29, 2025 at 5:00 AM SCHLEMMER Norbert <Nor...@pd...> wrote:
> What is the recommended upgrade path from Docker "2.3.0 / PostgreSQL 17" to "2.5.0 / PostgreSQL 18"
> and for migrating to a different host with Debian 13 / Trixie?

I suggest:

   dump/restore the database from postgresql 17 to 18 using pg_dump etc.

   then copy over the tracker home directory and follow the steps in upgrading.txt
   (https://www.roundup-tracker.org/docs/upgrading.html) from 2.3.0 to 2.4.0 and then 2.5.0.
   The required steps need to be done. If you omit the rest, it should still allow Roundup to work, but there may be security or other issues.

> Can the Docker image simply be changed from roundup:2.3.1a0 to roundup:2.5.0-1?
> I did this and didn't find any problems during testing. Is this procedure permissible and recommended?
> If so, I can then upgrade to PostgreSQL 18 in the next step using SQL dump/restore.

That should work provided you do the changes in upgrading.txt.

Ralf said on Mittwoch, 29. Oktober 2025 09:29
> On Wed, Oct 29, 2025 at 07:31:32AM +0000, SCHLEMMER Norbert wrote:
> > An export was created from the productive Roundup instance 2.3.0.
> > After importing in version 2.5.0, new messages can be added to an 
> > existing issue but creating a new issue result in this violation; 
> > see logs attached (the import process takes approximately 6 hours...).

How many issues do you have?

> Note that using the roundup-export / roundup-import is not recommended 
> for version upgrade, that should happen in-place. This might be the reason of the error-message you're seeing.

> > UniqueViolation: duplicate key value violates unique constraint 
> > "_issue_pkey" DETAIL: Key (id)=(3)
>  >       already exists.    Python 3.13.5
> > /usr/local/bin/python3.13

> Hmm, this might be because a retired node (e.g. an issue) is first 
> created and then retired, it could produce a duplicate primary key if a non-retired node *with the same key* already exists.
> But under normal circumstances duplicate primary keys should not occur (even including retired nodes).

This is happening post import, correct Norbert?

We fixed an import issue with duplicate keys back in the 2.1.0 release. it was caused when a user was created with the name "A". Then it was retired. Later a new user with the name "A" was created. When the export/import was done if the retired entry was imported after the non-retired entry the name "A"
which is a pkey conflicted.

However for issues, the title is not a primary key so I am not sure how you would get this conflict.

It almost looks like the sequence used to number (id) the issues isn't set properly.
Can you connect to the database and run:

  select * from _issue_ids;

you should see something like:

 last_value | log_cnt | is_called
------------+---------+-----------
            1 |         0 |          f

where last_value is one more than the largest id number in the _issues table.
Something like `select max(id) from _issue;` might do the trick to find the current max id number.

If the last_value is wrong, check the rest of the sequences (use \ds to list sequences and select like above to see the value).

I haven't seen an issue like that in my (limited) postgres testing of import/export.

-- rouilj

[Roundup-users] Looking for a howto on encrypting email inbound to Roundup

[John P. R. <ro...@cs...>]

Hi all:

Does anybody have a howto on sending gpg/pgp encrypted email to an
Roundup instance?

I have a couple of use cases where that would be useful/required along
with an encrypted database/filesystem.

It looks like the method decrypt is meant for this in mailgw.py but I
don't see any docs anywhere on how to set up/maintain/use pgp/gpg with
the gateway.

Frankly any docs on setting up Roundup for use with pgp/gpg would be
useful as this feature is kind of useless without proper docs.

Thanks.

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

Re: [Roundup-users] Docker Container 2.5.0 / UniqueViolation: duplicate key value violates unique constraint "_issue_pkey"

[John R. <ro...@ie...>]

Hi Norbert:

Sorry, I'm kind of tied up with other things.

On Wed, Oct 29, 2025 at 5:00 AM SCHLEMMER Norbert
<Nor...@pd...> wrote:
> What is the recommended upgrade path from Docker "2.3.0 / PostgreSQL 17" to "2.5.0 / PostgreSQL 18"
> and for migrating to a different host with Debian 13 / Trixie?

I suggest:

   dump/restore the database from postgresql 17 to 18 using pg_dump etc.

   then copy over the tracker home directory and follow the steps in
upgrading.txt
   (https://www.roundup-tracker.org/docs/upgrading.html) from 2.3.0 to
2.4.0 and then 2.5.0.
   The required steps need to be done. If you omit the rest, it should
still allow Roundup to
   work, but there may be security or other issues.

> Can the Docker image simply be changed from roundup:2.3.1a0 to roundup:2.5.0-1?
> I did this and didn't find any problems during testing. Is this procedure permissible and recommended?
> If so, I can then upgrade to PostgreSQL 18 in the next step using SQL dump/restore.

That should work provided you do the changes in upgrading.txt.

Ralf said on Mittwoch, 29. Oktober 2025 09:29
> On Wed, Oct 29, 2025 at 07:31:32AM +0000, SCHLEMMER Norbert wrote:
> > An export was created from the productive Roundup instance 2.3.0.
> > After importing in version 2.5.0, new messages can be added to an
> > existing issue but creating a new issue result in this violation; see
> > logs attached (the import process takes approximately 6 hours...).

How many issues do you have?

> Note that using the roundup-export / roundup-import is not recommended for version upgrade, that
> should happen in-place. This might be the reason of the error-message you're seeing.

> > UniqueViolation: duplicate key value violates unique constraint "_issue_pkey" DETAIL: Key (id)=(3)
>  >       already exists.    Python 3.13.5
> > /usr/local/bin/python3.13

> Hmm, this might be because a retired node (e.g. an issue) is first created and then retired, it could
> produce a duplicate primary key if a non-retired node *with the same key* already exists.
> But under normal circumstances duplicate primary keys should not occur (even including retired nodes).

This is happening post import, correct Norbert?

We fixed an import issue with duplicate keys back in the 2.1.0
release. it was caused when a user was
created with the name "A". Then it was retired. Later a new user with
the name "A" was created. When
the export/import was done if the retired entry was imported after the
non-retired entry the name "A"
which is a pkey conflicted.

However for issues, the title is not a primary key so I am not sure
how you would get this conflict.

It almost looks like the sequence used to number (id) the issues isn't
set properly.
Can you connect to the database and run:

  select * from _issue_ids;

you should see something like:

 last_value | log_cnt | is_called
------------+---------+-----------
            1 |         0 |          f

where last_value is one more than the largest id number in the _issues table.
Something like `select max(id) from _issue;` might do the trick to
find the current max id number.

If the last_value is wrong, check the rest of the sequences (use \ds
to list sequences and select like above
to see the value).

I haven't seen an issue like that in my (limited) postgres testing of
import/export.

-- rouilj

Re: [Roundup-users] Docker Container 2.5.0 / UniqueViolation: duplicate key value violates unique constraint "_issue_pkey"

[Ralf S. <rs...@ru...>]

On Wed, Oct 29, 2025 at 08:59:46AM +0000, SCHLEMMER Norbert wrote:
> Hi Ralf
> 
> What is the recommended upgrade path from Docker "2.3.0 / PostgreSQL 17" to "2.5.0 / PostgreSQL 18" and for migrating to a different host with Debian 13 / Trixie?
> 
> Can the Docker image simply be changed from roundup:2.3.1a0 to roundup:2.5.0-1?
> I did this and didn't find any problems during testing. Is this
> procedure permissible and recommended?

Yes, this should work. Note that the postgres version is of minor
concern.

> If so, I can then upgrade to PostgreSQL 18 in the next step using SQL
> dump/restore.

Yes, if you're installing postgres on the same machine postgres comes
with a pg_upgradecluster command that should be even faster than
dump/restore (and it is much easier if you have several databases), but
it needs both postgres versions to be installed at the same time (then
next you would pg_dropcluster the old cluster after having verified that
everything is in the new cluster and then you can uninstall the old
postgres version).

Thanks + kind regards
Ralf
-- 
Dr. Ralf Schlatterbeck                  Tel:   +43/2243/26465-16
Open Source Consulting                  www:   www.runtux.com
Reichergasse 131, A-3411 Weidling       email: of...@ru...

Re: [Roundup-users] Docker Container 2.5.0 / UniqueViolation: duplicate key value violates unique constraint "_issue_pkey"

[SCHLEMMER N. <Nor...@pd...>]

Hi Ralf

What is the recommended upgrade path from Docker "2.3.0 / PostgreSQL 17" to "2.5.0 / PostgreSQL 18" and for migrating to a different host with Debian 13 / Trixie?

Can the Docker image simply be changed from roundup:2.3.1a0 to roundup:2.5.0-1?
I did this and didn't find any problems during testing. Is this procedure permissible and recommended?
If so, I can then upgrade to PostgreSQL 18 in the next step using SQL dump/restore.

Thanks
Norbert


-----Ursprüngliche Nachricht-----
Von: Ralf Schlatterbeck <rs...@ru...> 
Gesendet: Mittwoch, 29. Oktober 2025 09:29
An: rou...@li...
Betreff: Re: [Roundup-users] Docker Container 2.5.0 / UniqueViolation: duplicate key value violates unique constraint "_issue_pkey"

*EXTERNAL source*


On Wed, Oct 29, 2025 at 07:31:32AM +0000, SCHLEMMER Norbert wrote:
> Hello All
>
> Running the Roundup Docker container 2.5.0-1 with PostgreSQL 18 and 
> Debian 13 / Trixie as host
>
> An export was created from the productive Roundup instance 2.3.0.
> After importing in version 2.5.0, new messages can be added to an 
> existing issue but creating a new issue result in this violation; see 
> logs attached (the import process takes approximately 6 hours...).

Umm, how much data do you have in that database?
If you're migrating between the same version of roundup *and* the same database, an SQL dump/restore should be *much* faster.

Note that using the roundup-export / roundup-import is not recommended for version upgrade, that should happen in-place. This might be the reason of the error-message you're seeing.

> UniqueViolation: duplicate key value violates unique constraint "_issue_pkey" DETAIL: Key (id)=(3) already exists.    Python 3.13.5
> /usr/local/bin/python3.13

Hmm, this might be because a retired node (e.g. an issue) is first created and then retired, it could produce a duplicate primary key if a non-retired node *with the same key* already exists.

But under normal circumstances duplicate primary keys should not occur (even including retired nodes).

Kind regards
Ralf
--
Dr. Ralf Schlatterbeck                  Tel:   +43/2243/26465-16
Open Source Consulting                  www:   www.runtux.com
Reichergasse 131, A-3411 Weidling       email: of...@ru...


_______________________________________________
Roundup-users mailing list
Rou...@li...
https://lists.sourceforge.net/lists/listinfo/roundup-users

Re: [Roundup-users] Docker Container 2.5.0 / UniqueViolation: duplicate key value violates unique constraint "_issue_pkey"

[Ralf S. <rs...@ru...>]

On Wed, Oct 29, 2025 at 07:31:32AM +0000, SCHLEMMER Norbert wrote:
> Hello All
> 
> Running the Roundup Docker container 2.5.0-1 with PostgreSQL 18 and Debian 13 / Trixie as host
> 
> An export was created from the productive Roundup instance 2.3.0.
> After importing in version 2.5.0, new messages can be added to an
> existing issue but creating a new issue result in this violation; see
> logs attached (the import process takes approximately 6 hours...).

Umm, how much data do you have in that database?
If you're migrating between the same version of roundup *and* the same
database, an SQL dump/restore should be *much* faster.

Note that using the roundup-export / roundup-import is not recommended for
version upgrade, that should happen in-place. This might be the reason
of the error-message you're seeing.

> UniqueViolation: duplicate key value violates unique constraint "_issue_pkey" DETAIL: Key (id)=(3) already exists. 	Python 3.13.5
> /usr/local/bin/python3.13

Hmm, this might be because a retired node (e.g. an issue) is first
created and then retired, it could produce a duplicate primary key if a
non-retired node *with the same key* already exists.

But under normal circumstances duplicate primary keys should not occur
(even including retired nodes).

Kind regards
Ralf
-- 
Dr. Ralf Schlatterbeck                  Tel:   +43/2243/26465-16
Open Source Consulting                  www:   www.runtux.com
Reichergasse 131, A-3411 Weidling       email: of...@ru...

[Roundup-users] Docker Container 2.5.0 / UniqueViolation: duplicate key value violates unique constraint "_issue_pkey"

[SCHLEMMER N. <Nor...@pd...>]

Hello All

Running the Roundup Docker container 2.5.0-1 with PostgreSQL 18 and Debian 13 / Trixie as host

An export was created from the productive Roundup instance 2.3.0.
After importing in version 2.5.0, new messages can be added to an existing issue but creating a new issue result in this violation; see logs attached (the import process takes approximately 6 hours...).
It makes no difference whether PostgreSQL 17 or 18 is used.

I will test the import with version 2.3.0 later today.

Thank you in advance for your support.
Br
Norbert



UniqueViolation: duplicate key value violates unique constraint "_issue_pkey" DETAIL: Key (id)=(3) already exists. 	Python 3.13.5
/usr/local/bin/python3.13

A problem occurred while running a Python script. Here is the sequence of function calls leading up to the error, with the most recent (innermost) call first. The exception attributes are:
      __cause__ = None
      __class__ = <class 'psycopg2.errors.UniqueViolation'>
      __context__ = None
      __delattr__ = <method-wrapper '__delattr__' of UniqueViolation object>
      __dict__ = {}
      __dir__ = <built-in method __dir__ of UniqueViolation object>
      __doc__ = None
      __eq__ = <method-wrapper '__eq__' of UniqueViolation object>
      __format__ = <built-in method __format__ of UniqueViolation object>
      __ge__ = <method-wrapper '__ge__' of UniqueViolation object>
      __getattribute__ = <method-wrapper '__getattribute__' of UniqueViolation object>
      __getstate__ = <built-in method __getstate__ of UniqueViolation object>
      __gt__ = <method-wrapper '__gt__' of UniqueViolation object>
      __hash__ = <method-wrapper '__hash__' of UniqueViolation object>
      __init__ = <method-wrapper '__init__' of UniqueViolation object>
      __init_subclass__ = <built-in method __init_subclass__ of type object>
      __le__ = <method-wrapper '__le__' of UniqueViolation object>
      __lt__ = <method-wrapper '__lt__' of UniqueViolation object>
      __module__ = 'psycopg2.errors'
      __ne__ = <method-wrapper '__ne__' of UniqueViolation object>
      __new__ = <built-in method __new__ of type object>
      __reduce__ = <built-in method __reduce__ of UniqueViolation object>
      __reduce_ex__ = <built-in method __reduce_ex__ of UniqueViolation object>
      __repr__ = <method-wrapper '__repr__' of UniqueViolation object>
      __setattr__ = <method-wrapper '__setattr__' of UniqueViolation object>
      __setstate__ = <built-in method __setstate__ of UniqueViolation object>
      __sizeof__ = <built-in method __sizeof__ of UniqueViolation object>
      __str__ = <method-wrapper '__str__' of UniqueViolation object>
      __subclasshook__ = <built-in method __subclasshook__ of type object>
      __suppress_context__ = False
      __traceback__ = <traceback object>
      __weakref__ = None
      add_note = <built-in method add_note of UniqueViolation object>
      args = ('duplicate key value violates unique constraint "_issue_pkey"\nDETAIL: Key (id)=(3) already exists.\n',)
      cursor = <cursor object at 0x7f32fc58ea70; closed: 0>
      diag = <psycopg2.extensions.Diagnostics object>
      pgcode = '23505'
      pgerror = 'ERROR: duplicate key value violates unique cons...ssue_pkey"\nDETAIL: Key (id)=(3) already exists.\n'
      with_traceback = <built-in method with_traceback of UniqueViolation object>

/usr/local/lib/python3.13/site-packages/roundup/backends/rdbms_common.py in sql(self=<roundpsycopgsql 0x7f32fc1f49e0>, sql='insert into _issue (_activity,_actor,_assignedto...us,_title,id) values (%s,%s,%s,%s,%s,%s,%s,%s,%s)', args=('2025-10-29 07:16:36.917', 4, 4, '2025-10-29 07:16:36.917', 4, 4, 8, 'Roundup 2.5.0 : Layout Modifications', '3'), cursor=<cursor object at 0x7f32fc58ea70; closed: 0>)
  260             cursor = self.cursor
  261         if args:
  262             cursor.execute(sql, args)
      cursor = <cursor object at 0x7f32fc58ea70; closed: 0>, global execute = undefined, sql = 'insert into _issue (_activity,_actor,_assignedto...us,_title,id) values (%s,%s,%s,%s,%s,%s,%s,%s,%s)', args = ('2025-10-29 07:16:36.917', 4, 4, '2025-10-29 07:16:36.917', 4, 4, 8, 'Roundup 2.5.0 : Layout Modifications', '3')
  263         else:
  264             cursor.execute(sql)

/usr/local/lib/python3.13/site-packages/roundup/backends/rdbms_common.py in addnode(self=<roundpsycopgsql 0x7f32fc1f49e0>, classname='issue', nodeid='3', node={'assignedto': '4', 'files': [], 'keyword': ['18'], 'messages': [], 'nosy': ['4'], 'priority': '4', 'status': '8', 'superseder': [], 'title': 'Roundup 2.5.0 : Layout Modifications'})
 1078         # perform the inserts
 1079         sql = 'insert into _%s (%s) values (%s)' % (classname, cols, s)
 1080         self.sql(sql, vals)
      self = <roundpsycopgsql 0x7f32fc1f49e0>, sql = 'insert into _issue (_activity,_actor,_assignedto...us,_title,id) values (%s,%s,%s,%s,%s,%s,%s,%s,%s)', vals = ('2025-10-29 07:16:36.917', 4, 4, '2025-10-29 07:16:36.917', 4, 4, 8, 'Roundup 2.5.0 : Layout Modifications', '3')
 1081 
 1082         # insert the multilink rows

/usr/local/lib/python3.13/site-packages/roundup/backends/rdbms_common.py in create_inner(self=<hyperdb.Class "issue">, **propvalues={'assignedto': '4', 'files': [], 'keyword': ['18'], 'messages': [], 'nosy': ['4'], 'priority': '4', 'status': '8', 'superseder': [], 'title': 'Roundup 2.5.0 : Layout Modifications'})
 1860 
 1861         # done
 1862         self.db.addnode(self.classname, newid, propvalues)
      self = <hyperdb.Class "issue">, global db = undefined, global addnode = undefined, global classname = undefined, newid = '3', propvalues = {'assignedto': '4', 'files': [], 'keyword': ['18'], 'messages': [], 'nosy': ['4'], 'priority': '4', 'status': '8', 'superseder': [], 'title': 'Roundup 2.5.0 : Layout Modifications'}
 1863         if self.do_journal:
 1864             self.db.addjournal(self.classname, newid, ''"create", {})

/usr/local/lib/python3.13/site-packages/roundup/backends/rdbms_common.py in create(self=<hyperdb.Class "issue">, **propvalues={'assignedto': '4', 'keyword': ['18'], 'nosy': ['4'], 'priority': '4', 'status': '8', 'title': 'Roundup 2.5.0 : Layout Modifications'})
 1708         """
 1709         self.fireAuditors('create', None, propvalues)
 1710         newid = self.create_inner(**propvalues)
      newid = undefined, self = <hyperdb.Class "issue">, global create_inner = undefined, propvalues = {'assignedto': '4', 'keyword': ['18'], 'nosy': ['4'], 'priority': '4', 'status': '8', 'title': 'Roundup 2.5.0 : Layout Modifications'}
 1711         self.fireReactors('create', newid, None)
 1712         return newid

/usr/local/lib/python3.13/site-packages/roundup/cgi/actions.py in _createnode(self=<roundup.cgi.actions.NewItemAction object>, cn='issue', props={'assignedto': '4', 'keyword': ['18'], 'nosy': ['4'], 'priority': '4', 'status': '8', 'title': 'Roundup 2.5.0 : Layout Modifications'})
  743         # create the node and return its id
  744         cl = self.db.classes[cn]
  745         return cl.create(**props)
      cl = <hyperdb.Class "issue">, global create = undefined, props = {'assignedto': '4', 'keyword': ['18'], 'nosy': ['4'], 'priority': '4', 'status': '8', 'title': 'Roundup 2.5.0 : Layout Modifications'}
  746 
  747     def isEditingSelf(self):

/usr/local/lib/python3.13/site-packages/roundup/cgi/actions.py in _editnodes(self=<roundup.cgi.actions.NewItemAction object>, all_props={('issue', None): {'assignedto': '4', 'keyword': ['18'], 'nosy': ['4'], 'priority': '4', 'status': '8', 'title': 'Roundup 2.5.0 : Layout Modifications'}}, all_links=[('issue', None, 'messages', [('msg', '-1')])])
  686                 else:
  687                     # make a new node
  688                     newid = self._createnode(cn, props)
      newid = undefined, self = <roundup.cgi.actions.NewItemAction object>, global _createnode = undefined, cn = 'issue', props = {'assignedto': '4', 'keyword': ['18'], 'nosy': ['4'], 'priority': '4', 'status': '8', 'title': 'Roundup 2.5.0 : Layout Modifications'}
  689                     if nodeid is None:
  690                         self.nodeid = newid

/usr/local/lib/python3.13/site-packages/roundup/cgi/actions.py in handle(self=<roundup.cgi.actions.NewItemAction object>)
  896         try:
  897             # when it hits the None element, it'll set self.nodeid
  898             messages = self._editnodes(props, links)
      messages = undefined, self = <roundup.cgi.actions.NewItemAction object>, global _editnodes = undefined, props = {('issue', None): {'assignedto': '4', 'keyword': ['18'], 'nosy': ['4'], 'priority': '4', 'status': '8', 'title': 'Roundup 2.5.0 : Layout Modifications'}}, links = [('issue', None, 'messages', [('msg', '-1')])]
  899         except (ValueError, KeyError, IndexError, Reject) as message:
  900             escape = not isinstance(message, RejectRaw)

/usr/local/lib/python3.13/site-packages/roundup/cgi/actions.py in execute(self=<roundup.cgi.actions.NewItemAction object>)
   48         """Execute the action specified by this object."""
   49         self.permission()
   50         return self.handle()
      self = <roundup.cgi.actions.NewItemAction object>, global handle = undefined
   51 
   52     def examine_url(self, url):

/usr/local/lib/python3.13/site-packages/roundup/cgi/client.py in handle_action(self=<roundup.cgi.client.Client object>)
 2406                 return getattr(self, action_klass)()
 2407 
 2408             return action_klass(self).execute()
      action_klass = <class 'roundup.cgi.actions.NewItemAction'>, self = <roundup.cgi.client.Client object>, global execute = undefined
 2409         except (ValueError, Reject) as err:
 2410             escape = not isinstance(err, RejectRaw)

/usr/local/lib/python3.13/site-packages/roundup/cgi/client.py in inner_main(self=<roundup.cgi.client.Client object>)
  907                 # It can change self.classname and self.template,
  908                 # and may also append error/ok_messages.
  909                 html = self.handle_action() if csrf_ok else None
      html = undefined, self = <roundup.cgi.client.Client object>, global handle_action = undefined, csrf_ok = True
  910 
  911                 if html:

 
Environment Variables
CONTENT_LENGTH	'1792'
CONTENT_TYPE	'multipart/form-data; boundary=----geckoformboundary22d88e55123b32825148a07d5667ae74'
HTTP_ACCEPT_LANGUAGE	'de,en-US;q=0.7,en;q=0.3'
HTTP_AUTHORIZATION	None
HTTP_COOKIE	'roundup_session_Roundupissuetracker=yTP8g7rLjQp0JIPplS/xCUslpb2PeMkU3wB/Nx5lABY; _pk_id.1.28af=d4ef3913f72d42f0.1759845249.'

Re: [Roundup-users] Docker Container 2.5.0 / roundup_healthcheck

[SCHLEMMER N. <Nor...@pd...>]

As workaround I use the healthcheck defined by the compose file

    healthcheck:
      test: ["CMD", "wget", "-q", "-O", "/dev/null", "http://127.0.0.1:8080/${tracker:-issues}/"]
      interval: 30s
      timeout: 5s
      retries: 3
      start_period: 1m

now the container is "healthy"