This queue is for tickets about the RT-Extension-MandatoryOnTransition CPAN distribution.

Report information
The Basics
Id:
93721
Status:
resolved
Priority:
Low/Low

People
Owner:
Nobody in particular
Requestors:
jblaine [...] kickflop.net
Cc:
AdminCc:

BugTracker
Severity:
(no value)
Broken in:
(no value)
Fixed in:
(no value)



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.
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
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


This service runs on Request Tracker, is sponsored by The Perl Foundation, and maintained by Best Practical Solutions.

Please report any issues with rt.cpan.org to rt-cpan-admin@bestpractical.com.