I can't reproduce in this order, I can only reproduce it by deleting in the order IBAN, BIC, account number, bank code.

What should be the expected behavior? All fields red?

Hint for why currently only the BIC field is red: It's the only field that has a validator in createBankDataComponent. Why it's the only field with a validator I don't know anymore. The patterns for validating the other fields are there.

Postponed until later, removing parent task.

I can suggest two solutions:

Radio-Buttons.

Select one kind of entry, the other will just reflect what you type. If it successfully and fully recognizes the format, the reflected input is available if you switch and you can continue editing it.
I think this is current behavior, but we would just blank the "reflection" if we don't recognize, so no strange in between state.

Auto-Recognize:

Auto recognize would check if the first two characters are letters. If they are, it assumes IBAN and reflects an uneditable BIC
If the first characters are numbers it assumes KtNr and BLZ and you get the BLZ field added.
There is no conversion.

• The auto-recognize would need a simple prototype to test.
• The auto-recognize would need an additional behavior that displays the label below the field at least while editing. We should have that anyway, since if you add some data, you don't know which type the data should be (So you type "John Doe" into "City". It just stays there, and you never see again that the field is supposed to be of the "type" "city") An antipattern.

@Jan_Dittrich

Thanks for pointing out the "missing label" issue. I created T194889 to follow up on that.

I'd prefer the auto-recognition approach. The BIC field should be editable in cases of non-German IBANs, though. It could be set to read-only when the server returns a BIC value in the validation response or based on the first two characters of the IBAN being "DE".

@kai.nissen mentioned that non-DE-IBAN users would not get their BIC reflected.

1. We could offer them an editable BIC field (which is reassuring, but not needed)
2. We reflect the BIC for DE and display a "Bic not needed" for non DE
3. Neither DE nor non-DE get Bic, everyone gets the hint "not needed"

@Jan_Dittrich Prototype is being developed in T195749.

I guess it is better here "@kai.nissen is this done or still in the pipeline?"

@kai.nissen @Jan_Dittrich Here is a list of behaviors that Gabriel and I came up with to account for all different combinations of data input. Maybe you can glance over it to see if we missed anything or if there is anything wrong with it:

Given a valid German IBAN and the IBAN field loses focus,
    validation is triggered,
    the BIC field gets auto-completed,
    the name of the bank is displayed,
    user input will be not be writable.

Given an invalid German IBAN and the IBAN field loses focus,
    validation is triggered,
    the BIC field is emptied and user input for the BIC field will not be writable,
    the IBAN field is marked as faulty.

Given a valid international IBAN and the IBAN field loses focus,
    validation is triggered,
    the BIC field is not changed and is writable.

Given an invalid international IBAN and the IBAN field loses focus,
    validation is triggered,
    the IBAN field is marked as faulty,
    the BIC field retains its previous state and is writable.

Given one of the two classic German bank account number fields is filled with an valid value and loses focus
    validation is not triggered,
    the BIC is not changed and is writable.

Given one of the two classic German bank account number fields is filled with an invalid value and loses focus,
    validation is not triggered,
    the IBAN field is not marked as faulty,
    the BIC field retains its previous state and is writable.

Given both of the two classic German bank account number fields are filled with a valid value and one loses focus,
    validation is triggered,
    the values of the IBAN and BIC fields are not changed and both remain writable.

Given both of the two classic German bank account number fields are filled with an invalid value and one loses focus,
    validation is triggered,
    both fields are marked as faulty,
    the values of the IBAN and BIC fields are not changed and both remain writable.

Fields being marked as valid on successful validation is not described above. Apart from that, the description looks fine.

Status update: There are three things left be done

• Unit-testing how the component displays validity changes, https://github.com/wmde/FundraisingFrontend/pull/1371, can be reviewed
• Making the component translatable and unit-testing the IBAN-dependent label change behavior, https://github.com/wmde/FundraisingFrontend/pull/1372/commits, in doing
• Integrating the component on the membership page (when the two other tasks are done)

Status update:

• Showing bank name and error messages can be reviewed
• The branch is also deployed and can be tested at https://test-spenden-2.wikimedia.de/
• TODO: Integrating the component on the membership page (when the two other tasks are done)

Looks good to me.

The field behaviour regarding validity indication is inconsistent when removing the field values (still indicating "invalid" when the IBAN value is removed, but indicating "neutral" when the account number and bank code are removed; the latter being the desired behaviour). This is an edge case, though, and shouldn't block us from deploying.

Also, the bank data is not complemented before persisting the data. We actually neither need it nor export it, so I'm fine with that.

This goes back to doing because the bank data fields need to be added to the membership page.

The adoption of the membership form also looks fine. Deployment to production can wait until tomorrow, though.