In:

  changeset:   4481:9bbf3758c16a
  user:        Stefan Seefeld <stefan@seefeld.name>
  date:        Thu Apr 14 12:47:48 2011 +0000
  files:       roundup/cgi/templating.py roundup/hyperdb.py
  description:
  Allow default value declaration in DB schema.

added the ability to invoke the hyperdb classes with
default_value=something.

E.G.

 prop=String(default_value="no value set")
 prop=Boolean(default_value=True)

It assigns self.__default_value to the value that is passed and
defines the get_default_value() method that can return that value, but
it looks like get_default_value() is only used in cgi/templating.py.

Is there some reason that only cgi/templating does this? I would think
email issue creation, issue creation by roundup_admin etc. should get
this default value as well.

So if a new (issue, user ...) class is created and there is no value
for the property, it should get that property automatically.

In any case we should probably document this option better. I added a
little bit of docs recently but....

Does anybody have more history on this?h

I don't have more history about this, but I was using it in a local
tracker and noticed the following:

status=Link("status", default_value=1), # 1=foo

resulted in the rendered HTML page having "foo" twice in the dropdown:

<option selected="selected" value="1">foo</option>
<option value="1">foo</option>

Regarding msg6074:

The entry in schema.py needs to use a string instead of a number to
prevent the duplicate entry:
status=Link("status", default_value="1"), # "1"=foo

When creating an issue via email, this is still not used (tested with
roundup 1.6.x)

Thomas,

If this was to work for email (and API interfaces), would you expect
to see the default value in an auditor or just in a detector?

My thought is:

  in web interface the user can see the default value and choose
    something different. So in the auditor we can see that the user
    chose the default value.

  in email or api/rest interfaces the user can't see the default
    so the auditor doesn't see the default value either.

however detectors see all values: user set and set by default. This way 
detectors can report all values.

Sensible??

* John Rouillard <issues@roundup-tracker.org> [20191103 02:04]:
> If this was to work for email (and API interfaces), would you expect
> to see the default value in an auditor or just in a detector?

By default both, email/api and web interface, should behave the
same, otherwise it would be too magical.

> My thought is:
> 
>   in web interface the user can see the default value and choose
>     something different. So in the auditor we can see that the user
>     chose the default value.
> 
>   in email or api/rest interfaces the user can't see the default
>     so the auditor doesn't see the default value either.

In some use cases (the user SHOULD do something) this might be
valid, in others (the user MUST do something) not.

If the author of an auditor script wants to relax the checks for
e.g. email, they could use db.tx_Source to make the script behave
differently, see "Restricting updates that arrive by email" in
customizing.txt for the opposite use case.

P.S.: It is auditor vs. reactor, both are detectors :)

Hi Thomas:

In message <20191103091713.178080640.thomas@intevation.de>,
Thomas Arendsen Hein writes:
>* John Rouillard <issues@roundup-tracker.org> [20191103 02:04]:
>> If this was to work for email (and API interfaces), would you expect
>> to see the default value in an auditor or just in a detector?
>
>By default both, email/api and web interface, should behave the
>same, otherwise it would be too magical.

Fair enough. Principle of least surprise by removing an exception
condition.

>> My thought is:
>> 
>>   in web interface the user can see the default value and choose
>>     something different. So in the auditor we can see that the user
>>     chose the default value.
>> 
>>   in email or api/rest interfaces the user can't see the default
>>     so the auditor doesn't see the default value either.
>
>In some use cases (the user SHOULD do something) this might be
>valid, in others (the user MUST do something) not.

I wonder if there needs to be some mechanism that indicates the
setting was a default and not a choice by the user.

I don't think we do, but...

>If the author of an auditor script wants to relax the checks for
>e.g. email, they could use db.tx_Source to make the script behave
>differently, see "Restricting updates that arrive by email" in
>customizing.txt for the opposite use case.

Hmm, somebody was smart adding the ability to figure out the source of
a transaction 8-).

>P.S.: It is auditor vs. reactor, both are detectors :)

Yes. Always getting detectors/reactors confused.

Thanks for your feedback.

I stumbled upon this issue when working with the REST API. Has there been any 
progress on this matter since it was last discussed?

Hello William:

There has not been any new activity.

How do you expect setting default_value will change how the REST
interface operates?

Thank you for letting me know.

> How do you expect setting default_value will change how the REST
> interface operates?

I'm currently working on integrating our roundup instance (that has been
around for close to 20 years) with an external service using the REST
API. After adding columns to the schema and setting the default_value
for these, values in these columns are still returned as null from the
REST API. This only happens for rows that are older than the
aforementioned schema changes.

My expectation here would be that the default value would be returned
instead of null. If not, one would have to duplicate the information
about any default values in both the roundup instance and all consumers
of the REST API.

From your perspective, would this be a feasible change somewhere down
the line? Is there some nuance here that I'm missing?