Isn't always clear to me which role should be used in these cases. Here the payment request was created right before opening the dialog - so what could we "reject"? I think the most appropriate role is "accept" as there's no alternative operation, there's nothing you can do with it. - or is there some guidelines I'm not aware of?

So maybe change the button role and drop the connection from reject signal?

Either way concept ACK.

@promag

Here the payment request was created right before opening the dialog - so what could we "reject"?

Maybe there should be "OK" button, not "Close"?

Successfully tested by setting a breakpoint at ReceiveCoinsDialog::reject() (never reached).
I guess you should also remove the method and definition ReceiveCoinsDialog::reject() in receivecoinsdialog.h/.cpp`

Successfully tested by setting a breakpoint at ReceiveCoinsDialog::reject() (never reached).

Hhmm but doesn't this remove the slot setup for accept(), not reject()?

Successfully tested by setting a breakpoint at ReceiveCoinsDialog::reject() (never reached).

Hhmm but doesn't this remove the slot setup for accept(), not reject()?

Actually, ReceiveCoinsDialog and ReceiveRequestDialog are different classes ;)

And "yes", this PR removes connection to ReceiveRequestDialog::accept() slot.

Closed in favor of #17597.