I'm glad roundup has been working for you for 20 years.

>This only happens for rows that are older than the aforementioned schema changes.

Gotcha. Do all issues created after the schema change get the default value set by
an auditor, or do you reject submissions without the field defined.

> My expectation here would be that the default value would be returned
> instead of null. [...]
>
> From your perspective, would this be a feasible change somewhere down
> the line? Is there some nuance here that I'm missing?

I am including Ralf S. another developer as well in this as he did much of
the REST integration.

Regarding nuance, perhaps. I saw default_value as a shortcut way to
make sure the value is defined when the user does not choose a value.
E.G. email or xmlrpc submission don't have an interactive way
to reject/update the request like the web interface does. Hence the
discussion surrounding detectors above.

You have brought up another use case that applies only during retrieval
(which I realized is what templating.py is doing).
I think your suggestion is fine IF we can guarantee that a null value
is never valid for that property. If the property can be set to null/None/empty
explicitly, I don't see how we can determine which case is correct:

  the null value was unset

  the null value was explicitly set

when we retrieve the item. In the first case, we want a default_value
returned but not in the second case. Since this ticket is to define
how this should work, we could make the rule that a null/None value will
never be returned if a default_value is set in the schema.

Looking at cgi/templating.py in HTMLPropert::__init__, it seems to always
return default_value if the value is None. So explicitly setting the value
to None means whatever default value is current for the schema. This matches
what you desire and I think is reasonable.

There is another call in templating.py = HTMLClass::properties but I have no
clue what that does and if it might conflict.

For your specific case (adding a new property in the schema), you could use
roundup-admin to set the new property. The downside is that it will update
last changed times for all the tickets that existed before the schema change.
This is unhelpful.

A better way to do this is to use the underlying database (sqlite3, psql ...)
tools to set the new property. This will set the proper value without changing
the history of the issues. If you are using a SQL backend something like (warning
my SQL is rusty):

   update _issues set  newprop = "1" where newprop is NULL;

should work. Usual caveats on making backups and checking that you can restore
it before making changes apply.

Ralf, thoughts?