Bug #93721 for RT-Extension-MandatoryOnTransition: Error display looks the same as success display

Mon Mar 10 17:04:29 2014 jblaine [...] kickflop.net - Ticket created

Subject:	Error display looks the same as success display
Date:	Mon, 10 Mar 2014 17:04:19 -0400
To:	bug-RT-Extension-MandatoryOnTransition [...] rt.cpan.org
From:	Jeff Blaine <jblaine [...] kickflop.net>

This extension (perhaps historically also in others that I just have not used yet) suffers from a message communication issue. Setup: '* -> resolved', ['CF.Whatever'], Action: I select "Comment" I select 'Status: resolved', type in some comment text, and submit the form without setting a value for the CF 'Whatever' Displayed Behavior: I am told that CF.Whatever must have a value before status can change state to 'resolved'. The message above is displayed in a *yellow box just like every other general RT notice/message indicating success* The form is redisplayed without *any* of my changes made. Suggested Behavior: I am told that CF.Whatever must have a value before status can change state to 'resolved'. The message above is displayed in a *pink or red box* and some text is added indicating that the form has been redisplayed with no changes saved yet and is awaiting re-submission. Reasoning: The 'errors' look just like normal historical RT 'info' messages. Additionally, historically, all RT page displays (to the best of my knowledge) reflect the data on disk. This extension (others?) deviates from that behavior in that is displaying the data again that HAS NOT been submitted yet.

Wed May 07 15:51:23 2014 cpan [...] jibsheet.com - Correspondence added

On Mon Mar 10 17:04:29 2014, jblaine@kickflop.net wrote: Show quoted text

> Action: > > I select "Comment" > > I select 'Status: resolved', type in some comment text, and > submit the form without setting a value for the CF 'Whatever' > > Displayed Behavior: > > I am told that CF.Whatever must have a value before status can > change state to 'resolved'. > > The message above is displayed in a *yellow box just like every > other general RT notice/message indicating success* > > The form is redisplayed without *any* of my changes made.

This is not the behavior I see in 4.2.4rc1 I see the yellow box (which I'll address below) however, my Status: change and the text typed in the Comment are both retained. Your error description implies this data was lost for you. Show quoted text

> The 'errors' look just like normal historical RT 'info' > messages. Additionally, historically, all RT page displays > (to the best of my knowledge) reflect the data on disk.

This is really a core RT problem. As such, i've opened a core RT ticket about it. http://issues.bestpractical.com/Ticket/Display.html?id=29893 Show quoted text

> This extension (others?) deviates from that behavior in that > is displaying the data again that HAS NOT been submitted yet.

Any RT page that can throw a validation error should redisplay with your data saved. Try creating a ticket with a mandatory custom field (there are other problems with mandatory CFs, but we're not discussing those). If you fail to fill in the CF, it'll error but any other CFs / Content / Status /Owner changes are retained when the error message is shown. As such, I'm not sure how this differs from the extension. If you're suggesting (and I hope I'm just misreading you) that this extension should revert all of your entered data when you have an error, that's just mean to the end user. I believe this ticket can be resolved or converted into a 'when possible, use new hooks in a future RT release to show better error messages' ticket. -kevin

Wed May 07 15:51:23 2014 The RT System itself - Status changed from 'new' to 'open'

Wed Mar 30 14:26:01 2016 cbrandt [...] cpan.org - Correspondence added

Hi again Jeff, I believe the behavior on this one is resolved. We're still working on better messaging on the other ticket, specifically making errors vs. status more clear. Given that that issue is a general RT issue, I'm going to resolve this ticket. If you have more thoughts, just respond and it will reopen. Thanks, Jim

Wed Mar 30 14:26:07 2016 cbrandt [...] cpan.org - Status changed from 'open' to 'resolved'