Fix New Account Wizard throws exception on empty payment method selected
ClosedPublic

Authored by rszczesiak on Fri, May 15, 2:27 PM.

Details

Summary

"Invalid payment type for schedule" was thrown when the user proceeded
through Credit Card Schedule Page leaving empty payment method
(default).

This commit:

  • sets default credit card payment method to "Direct debit",
  • fixes incorrect Next button tooltip messages on the Schedule page.

BUG: 421569

Diff Detail

Repository
R261 KMyMoney
Lint
Automatic diff as part of commit; lint not applicable.
Unit
Automatic diff as part of commit; unit tests not applicable.
rszczesiak requested review of this revision.Fri, May 15, 2:27 PM
rszczesiak created this revision.

What about just refusing to allow to complete the creation (instead of crashing) unless a payment method is selected, but not set a default type? That does raise the same issue we have elsewhere of how to inform the user of why the action is disabled - but I suggested in another bug using some sort of notification or status area, especially if there was only one remaining reason the action could not be completed.

rszczesiak added a comment.EditedFri, May 15, 2:57 PM

What about just refusing to allow to complete the creation (instead of crashing) unless a payment method is selected, but not set a default type?

It looks like an equally valid solution to me.
On the other hand, setting a default is how manual schedule creation via Edit Scheduled Transaction Dialog works. My patch conforms to this same UI behavior pattern.

especially if there was only one remaining reason the action could not be completed.

On that Page of the Wizard there is a few fields that require user input. Shall we notify on one / the last remaining?

In the end, this a design choice and I do not consider myself competent to decide so I am willing to comply to what the Core Team decides.

The patch also disallows the user to intentionally set empty payment method. Empty method is not listed. Therefore I consider the fix quite solid.

The Wizard Schedule Page after the fix:

I defer a decision to Thomas, and consistency across the app is good. The issue of how to notify the user what is blocking the desired action is a more widespread problem, and might be better deferred until it can be addressed in general, and not just in specific cases. (That has mostly arisen when trying to delete something, and it is not clear what is preventing that.)

I wondered who added the #if 0 / #endif and traced them back into 2009 but could not go back any further. They existed every since.
It certainly does not make sense to skip adding a method and then later on make it the current one (2nd last line of this method). That is simply wrong. So the fix to add those methods seems valid to me.

rszczesiak added a comment.EditedFri, May 15, 6:39 PM

@ostroffjh, I agree that your concerns are important. I have just skimmed through the code and came acrosss something that may render useful.
There is a virtual method isComplete() in KMyMoneyWizardPage class.

/**
  * This returns, if all necessary data for this page has been
  * filled. It is used to enabled the 'Next' or 'Finish' button.
  * The button is only enabled, if this method returns @p true,
  * which is the default implementation.
  *
  * @retval false more data required from the user before we can proceed
  * @retval true all data available, we allow to switch to the next page
  */
virtual bool isComplete() const;

The method is overridden in subclass CreditCardSchedulePage which is changed by this patch.
It seems this approach works as expected on the previous page:


For some reason tooltip message is not supported correctly on the Schedule page. This needs looking into more closely to find out why.

rszczesiak added a comment.EditedFri, May 15, 6:44 PM

@tbaumgart, That's right. I also investigated those #if 0/#endif lines to find out why they had been added before I decided to bring those two payment methods back and found no good reason. It might well have been only temporary and the author forgot to revert the change.

I suppose that the minimal fix to prevent the crash is the best approach here, and the issue of notifying the user of why an action is disabled can be deferred for later discussion of a consistent approach.

rszczesiak added a comment.EditedFri, May 15, 8:24 PM

OK, I found it.
The 2nd last line of the isComplete() method should be d->m_wizard->d_func()->m_nextButton->setToolTip(msg); instead of d->m_wizard->d_func()->m_finishButton->setToolTip(msg);
Now the tooltip message informs the user why the Next button is disabled.

Should I create a new bug report to fix it or just add the tooltip fix to this patch?

Of course this notification system only applies to wizards and should not be considered a robust and universal approach @ostroffjh is rightly seeking.

Simply add it here.

rszczesiak updated this revision to Diff 82988.Sat, May 16, 6:45 AM
rszczesiak edited the summary of this revision. (Show Details)

Added the fix for incorrect Next button tooltip messages on the Schedule page.

tbaumgart accepted this revision.Sat, May 16, 6:48 AM

I'll take care of landing it but this may only happen after the repository has been moved to its new location over the weekend.

This revision is now accepted and ready to land.Sat, May 16, 6:48 AM
This revision was automatically updated to reflect the committed changes.