Roundup Tracker - Issues

Issue 1408570

classification
Title: let forms preserve values after submission failed
Type: Severity: normal
Components: Web interface Versions:
process
Status: fixed Resolution: fixed
Dependencies: Superseder:
Assigned To: schlatterbeck Nosy List: richard, rouilj, schlatterbeck, stefan
Priority: normal Keywords:

Created on 2006-01-17 22:36 by stefan, last changed 2016-09-02 00:14 by rouilj.

Messages
msg2106 Author: [hidden] (stefan) Date: 2006-01-17 22:36
The roundup web interface looses content of form fields
if submission triggers an error (such as from auditors).

It should be possible for roundup to preserve the state
a form was in when it was submitted, and send it back
for correction (possibly with wrong entries highlighted).
msg2107 Author: [hidden] (richard) Date: 2006-02-08 04:43
Logged In: YES 
user_id=6405

Yes, with better form generation / handling this might be 
an option. It's not at the moment though, sorry. 
msg3890 Author: [hidden] (schlatterbeck) Date: 2009-10-20 08:18
This is a very old issue -- still probably one of the topmost usability
problems of roundup. See issue712084 for a still older bug-report about
the same problem (why was that one closed, there is no log about it and
no close message)
msg5523 Author: [hidden] (rouilj) Date: 2016-04-11 00:43
I know some changes were made to make this work better.
Is this still an issue?
msg5528 Author: [hidden] (schlatterbeck) Date: 2016-04-11 09:42
On Mon, Apr 11, 2016 at 12:43:19AM +0000, John Rouillard wrote:
> 
> I know some changes were made to make this work better.
> Is this still an issue?

Yes, I'm quite sure it is.
Reason is that roundup (as far as I remember) processes fields until an
error occurs and leaves the other fields unprocessed. The result is that
some fields revert back to the original version before editing when an
auditor exception occurs (or similar).

I guess the first step would be to code up a test for this...

I may have some interest to fix this myself...

Ralf
-- 
Dr. Ralf Schlatterbeck                  Tel:   +43/2243/26465-16
Open Source Consulting                  www:   http://www.runtux.com
Reichergasse 131, A-3411 Weidling       email: office@runtux.com
msg5894 Author: [hidden] (schlatterbeck) Date: 2016-08-16 13:40
I've now traced this a little further, it turns out that
- Form values *are* preserved internally. The whole form is present in
  the cgi client used to render an issue
- But: The database wins. Only if a field is empty in the database
  (return None but for Number a 0 will probably also be overridden) the
  form will override this value.

Code is in cgi/templating.py notably the HTMLProperty class (from which
all the special classes like DateHTMLProperty inherit) does a lookup of
the form value only if it is passed an empty value in the constructor.

This in turn is called from __getitem__ of _HTMLItem which looks up the
value from the database.

Now to fix this we need some way to pass information to HTMLProperty to
indicate that it should prefer the form contents over the database contents.

I don't know if this would be a security risk to *always* prefer the
form values...
msg5895 Author: [hidden] (schlatterbeck) Date: 2016-08-23 07:17
Finally fixed in commit 232c74973a56
msg5896 Author: [hidden] (rouilj) Date: 2016-08-28 00:04
Hi Ralf:

It looks like your change to tests/test_cgi.py broke a couple of tests.

=================================== FAILURES
===================================

___________________ FormTestCase.testCSVExportBadColumnName
____________________

self = <test.test_cgi.FormTestCase testMethod=testCSVExportBadColumnName>

    def testCSVExportBadColumnName(self):

        cl = self._make_client({'@columns': 'falseid,name'}, nodeid=None,

            userid='1')

        cl.classname = 'status'

        output = StringIO.StringIO()

        cl.request = MockNull()

        cl.request.wfile = output

        self.assertRaises(exceptions.SeriousError,

>           actions.ExportCSVAction(cl).handle)

test/test_cgi.py:1155: 

_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
_ _ _ _ 

self = <roundup.cgi.actions.ExportCSVAction instance at 0x7f1d05f56c20>

    def handle(self):

        ''' Export the specified search query as CSV. '''

        # figure the request

        request = templating.HTMLRequest(self.client)

        filterspec = request.filterspec

        sort = request.sort

        group = request.group

        columns = request.columns

        klass = self.db.getclass(request.classname)

    

        # check if all columns exist on class

        # the exception must be raised before sending header

        props = klass.getprops()

        for cname in columns:

            if cname not in props:

                # use error code 400: Bad Request. Do not use

                # error code 404: Not Found.

                self.client.response_code = 400

                raise exceptions.NotFound(

                    self._('Column "%(column)s" not found in %(class)s')

>                   % {'column': cgi.escape(cname), 'class':
request.classname})

E               NotFound: Column "falseid" not found in status

roundup/cgi/actions.py:1264: NotFound

___________________ FormTestCase.testCSVExportFailPermission
___________________

self = <test.test_cgi.FormTestCase testMethod=testCSVExportFailPermission>

    def testCSVExportFailPermission(self):

        cl = self._make_client({'@columns': 'id,email,password'},
nodeid=None,

            userid='2')

        cl.classname = 'user'

        output = StringIO.StringIO()

        cl.request = MockNull()

        cl.request.wfile = output

        # used to be self.assertRaises(exceptions.Unauthorised,

        # but not acting like the column name is not found

        self.assertRaises(exceptions.SeriousError,

>           actions.ExportCSVAction(cl).handle)

test/test_cgi.py:1167: 

_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
_ _ _ _ 

self = <roundup.cgi.actions.ExportCSVAction instance at 0x7f1d05c4c050>

    def handle(self):

        ''' Export the specified search query as CSV. '''

        # figure the request

        request = templating.HTMLRequest(self.client)

        filterspec = request.filterspec

        sort = request.sort

        group = request.group

        columns = request.columns

        klass = self.db.getclass(request.classname)

    

        # check if all columns exist on class

        # the exception must be raised before sending header

        props = klass.getprops()

        for cname in columns:

            if cname not in props:

                # use error code 400: Bad Request. Do not use

                # error code 404: Not Found.

                self.client.response_code = 400

                raise exceptions.NotFound(

                    self._('Column "%(column)s" not found in %(class)s')

>                   % {'column': cgi.escape(cname), 'class':
request.classname})

E               NotFound: Column "email" not found in user

roundup/cgi/actions.py:1264: NotFound

I grabbed the from the travis0-ci test run, but

./run_tests.py test/test_cgi.py

looks like it's reporting the same.

It's not obvious to me that the changes in the test harness are the
problem. Can you take a look at it.

-- rouilj
msg5897 Author: [hidden] (schlatterbeck) Date: 2016-08-29 09:25
On Sun, Aug 28, 2016 at 12:04:37AM +0000, John Rouillard wrote:
> 
> John Rouillard added the comment:
> 
> Hi Ralf:
> 
> It looks like your change to tests/test_cgi.py broke a couple of tests.

Hmm, I think I ran all the tests before commit.
I'll look into this later this week I'm on a trip currently.

Ralf
msg5898 Author: [hidden] (schlatterbeck) Date: 2016-09-01 08:44
On Sun, Aug 28, 2016 at 12:04:37AM +0000, John Rouillard wrote:
> 
> Hi Ralf:
> 
> It looks like your change to tests/test_cgi.py broke a couple of tests.
> 
> ___________________ FormTestCase.testCSVExportBadColumnName
> ___________________ FormTestCase.testCSVExportFailPermission

Both tests fail already when I check out a86860224d80 (before my form
patch). I don't know why I missed this, I think all tests passed before
I checked this in.
Seems the problem was introduced with your commit a86860224d80,
the commit 114d9628fd77 before this passes the tests for me.

Is there a possibility that these tests were skipped when I tried to run
all tests (running the test-script without arguments)?

(I'm now running all tests and it seems the test_cgi.py doesn't skip
tests and also fails the two tests above, maybe there is something in
the reporting of failures so I missed these failing tests???).

Ralf
-- 
Dr. Ralf Schlatterbeck                  Tel:   +43/2243/26465-16
Open Source Consulting                  www:   http://www.runtux.com
Reichergasse 131, A-3411 Weidling       email: office@runtux.com
msg5899 Author: [hidden] (rouilj) Date: 2016-09-02 00:14
Hi Ralf:

In message <20160901084410.GB14758@runtux.com>,
Ralf Schlatterbeck writes:
>Ralf Schlatterbeck added the comment:
>On Sun, Aug 28, 2016 at 12:04:37AM +0000, John Rouillard wrote:
>> It looks like your change to tests/test_cgi.py broke a couple of tests.
>> ___________________ FormTestCase.testCSVExportBadColumnName
>> ___________________ FormTestCase.testCSVExportFailPermission
>
>Both tests fail already when I check out a86860224d80 (before my form
>patch).

Yup looks like that is my bug (in hindsight export bad column name
failing makes perfect sense). I thought I had been keeping git up to
date, but it looks like I forgot to push a8686 to git and run it
through travis ci to get the whole suite tested.

So I missed that my change required tweaking the tests.

Sorry about that. I am closing this ticket.
History
Date User Action Args
2016-09-02 00:14:13rouiljsetstatus: open -> fixed
messages: + msg5899
2016-09-01 08:44:14schlatterbecksetmessages: + msg5898
2016-08-29 09:25:07schlatterbecksetmessages: + msg5897
2016-08-28 00:04:36rouiljsetstatus: closed -> open
messages: + msg5896
2016-08-23 07:17:09schlatterbecksetstatus: open -> closed
assignee: richard -> schlatterbeck
resolution: fixed
messages: + msg5895
2016-08-16 13:40:27schlatterbecksetmessages: + msg5894
2016-04-11 09:42:46schlatterbecksetmessages: + msg5528
2016-04-11 00:43:19rouiljsetnosy: + rouilj
messages: + msg5523
2009-10-20 08:18:55schlatterbecklinkissue712084 superseder
2009-10-20 08:18:07schlatterbecksetnosy: + schlatterbeck
messages: + msg3890
2006-01-17 22:36:41stefancreate