Page MenuHomePhabricator

[WMDE-Fundraising] Add use case and services for Membership application
Closed, ResolvedPublic20 Estimate Story Points


Call the validation methods and refuse insertion of data if integrity check fails, set status to pending on irregularities (bad words).

Create new MembershipApplication entity, store it and notify the new member and the membership team via mail.

POST request

Request Body:

Request model parameters: All from request body except back_form, wikilogin, go_contact, membership_fee_custom and member_agree:

  • PersonalInfo
    • PersonName
      • adresstyp=person
      • anrede=Herr
      • titel=Kein+Titel
      • vorname=blah
      • nachname=blub
      • firma=
    • PhysicalAddress
      • strasse=cnkevhwnw
      • plz=11207
      • ort=Berlin
      • country=DE
  • BankData
    • bank_name=ING-DiBa
    • iban=DE12500105170648489890
    • account_number=0648489890
    • bank_code=50010517
  • personal info not in PersonalInfo (do we want to put this in PersonalInfo as nullable?)
    • dob=30.02.9999
    • phone=1234555
  • membership fee stuff
    • membership_type=(active|sustaining)
    • membership_fee_interval=12
    • membership_fee=25%2C00
  • debit-type=sepa (This is not used. It was introduced to be able to compare the number of users entering the actual SEPA data (BIC/IBAN) vs. the number of users still using the national bank data format (account no. and bank code).)
  • purpose=membership-full (which values can this be (found: membership, membership-full, membership-binding), and what should be done with it? Seems like it does not need to be in the domain object and just get to the UC. Is that correct?)
    • Its only purpose is for application flow control. It is actually obsolete now, since the only case that can occur is membership-full.
  • account_holder=blank (not in BankData, do we want to put it there as nullable?)

Mail templates:

Event Timeline

gabriel-wmde updated the task description. (Show Details)
JeroenDeDauw updated the task description. (Show Details)Mar 21 2016, 1:08 PM
JeroenDeDauw updated the task description. (Show Details)Mar 21 2016, 1:20 PM


looked at this account_holder for a bit and I am confused. So unless someone else of folks in the office today knows the meaning of this I'd say only Kai can save us. It looks like it is set to "Blank" and never changed? And the backed tool indeed references it but the export script from the backend tool actually generates the value of it itself from person's name etc. I am suspecting some legacy field

@WMDE-leszek is right: This is a legacy field. The fundraising team decided to drop it from the forms and export the donor's name in that case. Since the management tool and the export script is using that field it is probably best to generate the value for it rather than inserting "Blank".

kai.nissen updated the task description. (Show Details)Mar 23 2016, 11:37 AM
JeroenDeDauw added a comment.EditedApr 20 2016, 5:24 PM

Status: the repository and authorization services exist. Still need an authorization updater and validation stuff. And the UC itself.

JeroenDeDauw changed the point value for this task from 10 to 20.Apr 21 2016, 9:41 PM

What's the deal with the adresstyp field? This makes no sense to have it here right? Only a private person can become a member... So it seems to not make sense to even put this in the request model.

WMDE-leszek added a comment.EditedApr 25 2016, 8:18 AM

So is it really impossible for organisations to be members? If so, the field is indeed pointless.
Anonymous membership applications should definitely NOT be allowed.

kai.nissen added a comment.EditedApr 25 2016, 8:55 AM

Organizations and companies can indeed (and also do) apply for a membership. The minimum membership fee is 100 EUR per year in those cases.

Anonymous membership is not possible, though. I'm sure, that's what Leszek actually wanted to say.

yeah, I meant that, thanks for noticing. Editing the post above so it does not confuse others

JeroenDeDauw added a comment.EditedApr 25 2016, 4:23 PM

Ok, thanks for answering. We'll have the update the request model then, as I did not put the company stuff in there.

Edit: done in

Two other things that still need doing:

  • Add $data support in the DoctrineMembershipApplicationRepository
  • Build the request in the route handler and invoke the UC with it

I'm going to close this and create two new subtasks of this tasks parent. The 20 points here where way to low anyway.

JeroenDeDauw renamed this task from [WMDE-Fundraising] Add route and use case for Membership application to [WMDE-Fundraising] Add use case and services for Membership application.May 3 2016, 11:54 PM
JeroenDeDauw closed this task as Resolved.
JeroenDeDauw claimed this task.
JeroenDeDauw moved this task from Doing to Done on the WMDE-Fundraising-Frontend-Release board.