You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
- issue1714899: Feature Request: Optional Change Note. Added a new
quiet=True/False option for all property types. When quiet=True
changes to the property will not be displayed in the::
confirmation banner (shown in green) when a change is made
property change section of change note (nosy emails)
web history display for an item.
Note that this may confuse users if used on a property that is
meant to be changed by a user. It is most useful on administrative
properties that are changed by an auditor as part of a user
generated change. Original patch by Daniel Diniz (ajaksu2)
discussed also at:
http://psf.upfronthosting.co.za/roundup/meta/issue249
Support for setting quiet when calling the class specifiers:
E.G. prop=String(quiet=True) rather than::
prop=String()
prop.quiet=True
support for anydb backend, added tests, doc updates, support for
ignoring quiet setting using showall=True in call to history()
function in templates by John Rouillard.
In addition to documenting quiet, I also documented required and
default_value additions to the hyperdb property classes. Only place I
could find is design.txt.
Note tests for history in web interface are not done. It was manually
checked but there are no automated tests. The template for setup is in
db_test_base.py::testQuietJournal but it has no asserts. I need
access to template.py::_HTMLItem::history() and I don't know how to do
that. test_templates.py isn't helping me any at all and I want to get
this patch in because it handles nicely an issue I have in the design
of my own tracker. The issue is:
The properties of an issue are displayed in framesets/subframes. The
user can roll up the frameset leaving only the title bar. When the
user saves the changes, the current state of the framesets
(collapsed/uncollapsed) is saved to a property in the user's
object. However there is no reason the user should see that this is
updated since it's an administrative detail.
Similarly, you could count the number of times an issue is reopened or
reassigned. Updates to properties that are an indirect result of a
user's change should not be displayed to the user as they can be
confusing and distracting.
0 commit comments