Opinions posted here are my own, unless stated otherwise
- User Since
- Oct 7 2014, 4:56 PM (185 w, 1 d)
- IRC Nick
- LDAP User
- MediaWiki User
- Jeroen De Dauw
Thu, Apr 19
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.
Tue, Apr 17
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.
Mar 23 2018
What is the name of the application used for creating these?
Mar 6 2018
Feb 7 2018
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).
Jan 29 2018
Jan 22 2018
I am not planning to do this
Jan 12 2018
Jan 8 2018
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?
Jan 1 2018
Dec 26 2017
Dec 22 2017
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:
Dec 20 2017
Dec 18 2017
Dec 17 2017
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?
Dec 15 2017
Error and success message style improvement: https://github.com/wmde/FundraisingFrontend/pull/1119
Dec 14 2017
Dec 13 2017
The comment form is now "working": https://github.com/wmde/FundraisingFrontend/pull/1096 & https://github.com/wmde/fundraising-frontend-content/pull/72
Dec 11 2017
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.
Dec 10 2017
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.
Dec 5 2017
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() ?
Dec 4 2017
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?
Dec 3 2017
Nov 30 2017
Donation form: https://github.com/wmde/FundraisingFrontend/pull/1060
Nov 28 2017
A banner is displayed above the respective section header
Nov 27 2017
Oh this is already on doing :)
so the construction of the parser construction would have to be moved somewhere else
Nov 26 2017
Nov 23 2017
Nov 22 2017
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.
Nov 21 2017
What validation fails? Client side or server side? (Just tried to find out myself but cannot get the new skin to work)
Nov 20 2017
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?
Nov 17 2017
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.
Nov 7 2017
Nov 6 2017
Nov 5 2017
I'm working on this: https://github.com/wmde/fundraising-backend/pull/343
Nov 1 2017
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.
Oct 30 2017
Some more tests in https://gerrit.wikimedia.org/r/387159
All linked PRs are merged except the DNM one
Oct 27 2017
So what still needs to be done? Adding more tests?
Oct 19 2017
Oct 17 2017
Are we following the Gerrit/Commit message guidelines to, amongst other benefits, link change sets here automatically?