After https://github.com/wmde/FundraisingFrontend/pull/1214 we can move these things to the BC lib:

Ins't the subscription stuff unused at the moment? Or perhaps only used by the FF app? If so, perhaps leaving in in FF for now, rather than putting it into its own lib, makes sense. Could put it into src/ so contexts/ can get ditched, which then avoids potential confusion due to most contexts being elsewhere now.

FYI: I am planning to look into these leftovers soonish. Not cookie-licking this tough, so if you want to poke at it, by all means go ahead.

What is the name of the application used for creating these?

I poked at this stuff way back in 2013(?) and remember we had some problems with the default config. I believe one of the issues we had is that we could not manage the permissions ourselves. That is many years ago though, with presumably the default config having changed and the Wikibase workflow also no longer being the same (people now know how to use git, unlike at the start of the project).

I am not planning to do this

What is still missing is the UI for the "your info was anonimized but everything is OK" and "a technical error occurred" cases. For both of these it would be nice to have some kind of specification for that the page should look like. Is it fine to use a simple template that just takes a message and looks like the "access denied" one for both, or do things such as the links on the "success case" page also need to be shown?

First step https://github.com/wmde/fundraising-donations/pull/34

Prep PR at https://github.com/wmde/FundraisingFrontend/pull/1159

PS: such a review feedbacks https://github.com/wmde/FundraisingStore/pull/90

Talked to Kai and this is the plan for now: have the Doctrine repo throw an (ApplicationPurged) exception when the data was purged. This forces the 4 UCs retrieving an Application to add a try catch which will fix their current error out in case of purged data. It is not entirely clear if this solution will remain viable as we add more UCs, but since it is low effort to implement we decided to try it out for now and adjust if it turns out to not work well later.

@gabriel-wmde I'm not sure how to make the Null Object pattern work here. We'd need a null object for both Applicant and PaymentMethod. These Value Objects do not follow Tell Don't Ask at all, which is something I think you kinda need to make the Null Object Pattern work. If we simply create such an object with empty values we'll still going to need special handling for most access happening to the data, which is not good. Perhaps you thought of something I did not...

DB fields that get purged for memberships:

What is currently done looks structurally sane enough to me. Please outline your concerns if you have a different view. (Though better read the below first.)

Where should the error message go?

Error and success message style improvement: https://github.com/wmde/FundraisingFrontend/pull/1119

I did:

The comment form is now "working": https://github.com/wmde/FundraisingFrontend/pull/1096 & https://github.com/wmde/fundraising-frontend-content/pull/72

There still is some random blank space above the form, though this is not on the thing you linked, so presumably just some CSS issue we need to fix. Beyond that, is this what the form is expected to look like?

No validation of the field appears to happen on either the donation or membership form until all required fields are filled. With current master (61901bb290ef2092e3f62746bcf75b619ee48e1b) the donation form does show some error once all fields are filled:

Question: is it fine to just show "anonymous" and "using my name" as options in the comment form? In the old skin we show the name that will be used. In the new skin we do not have as easy access to this info, so it is slightly more work to show it.

The HTML that was delivered by the third party seems rather incomplete. It's just some form fields, some of which where not even inside the form, and no behavior. Some UX review would be nice. I created https://phabricator.wikimedia.org/T182126 for that.

users can (depending on the payment type they used) leave a comment

I take it this is not as simple as changing $app->get() into $app->post() ?

Should this not be on Doing?

The linked PR has been merged

PRs merged. Can this be moved out of review?

This is the form with the warning in the (presumably) wrong color (and still bad positioning):

PR merged. Can this be moved to done?

Donation form: https://github.com/wmde/FundraisingFrontend/pull/1060

A banner is displayed above the respective section header

Fix in https://github.com/wmde/FundraisingFrontend/pull/1044

Oh this is already on doing :)

so the construction of the parser construction would have to be moved somewhere else

Is this just an issue with the new layout? Seems fine using the old one:

moving the donation validation out of the use case in into the handler, like we did for memberships

I moved this back to "Ready" as apparently I did another task.

What validation fails? Client side or server side? (Just tried to find out myself but cannot get the new skin to work)

This probably "sufficiently fixes" the issue: https://github.com/wmde/FundraisingFrontend/pull/1027

The AddDonationValidator has this extra stuff:

• AJAX validation: split between ValidateAddressHandler (https://github.com/wmde/FundraisingFrontend/pull/1026), DonorValidator and DonorAddressValidator
• Submit validation: AddDonationValidator::validateDonorAddress

What is the issue/task? Should no validation violation be shown?

So the issue is that using auto-fill does not trigger re-validation?

If I'm not mistaken we talked about moving the PHP code of that package directly into Wikibase.git two years ago or so. I can't remember if there was a reason to not do that, or if simply no one got to it.

How about wikibase/data-types instead? Same for the package name.

https://github.com/wmde/FundraisingFrontend/pull/984

I'm working on this: https://github.com/wmde/fundraising-backend/pull/343

I was looking at what stuff to modify to tackle this task and then it occurred to me this might conflict with the new layout work. Does it? I don't want to implement this now for the old layout and then have to re-implement it for the new one before the first stuff even gets deployed.

Some more tests in https://gerrit.wikimedia.org/r/387159

All linked PRs are merged except the DNM one

So what still needs to be done? Adding more tests?

Merged https://gerrit.wikimedia.org/r/#/c/385991/ and https://gerrit.wikimedia.org/r/#/c/385983/

Are we following the Gerrit/Commit message guidelines to, amongst other benefits, link change sets here automatically?