Issue 2550911
Created on 2016-06-30 23:38 by rouilj, last changed 2019-11-03 16:31 by rouilj.
Messages | |||
---|---|---|---|
msg5690 | Author: [hidden] (rouilj) | Date: 2016-06-30 23:38 | |
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 |
|||
msg6074 | Author: [hidden] (ThomasAH) | Date: 2018-04-23 07:46 | |
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> |
|||
msg6786 | Author: [hidden] (ThomasAH) | Date: 2019-11-01 12:48 | |
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) |
|||
msg6787 | Author: [hidden] (rouilj) | Date: 2019-11-03 01:04 | |
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?? |
|||
msg6788 | Author: [hidden] (ThomasAH) | Date: 2019-11-03 08:30 | |
* 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 :) |
|||
msg6789 | Author: [hidden] (rouilj) | Date: 2019-11-03 16:31 | |
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. |
History | |||
---|---|---|---|
Date | User | Action | Args |
2019-11-03 16:31:47 | rouilj | set | messages: + msg6789 |
2019-11-03 08:30:03 | ThomasAH | set | messages: + msg6788 |
2019-11-03 01:04:06 | rouilj | set | messages: + msg6787 |
2019-11-01 12:48:22 | ThomasAH | set | messages: + msg6786 |
2018-06-06 23:42:58 | rouilj | set | type: rfe |
2018-04-23 07:46:05 | ThomasAH | set | nosy:
+ ThomasAH messages: + msg6074 |
2016-06-30 23:38:23 | rouilj | create |