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.