Re: task 8833 -- proposed steps

[Federico Gimenez Nieto]

> Hmm. Maybe we could just rename the R1_Donations2JobOffersJoins table to
> D1_Donations.  We could think a week more about such renaming. If we follow
> thinking that the next Saturday then we can do such renaming.
>
Ok,  we could even keep the R1_Donations2JobOffersJoins for the
Donations-JobOffers join information and the D1_Donations for the
Donations-only information...

> Proposal:  "Development rules"
>
>   When we are not 100% sure, letting us a week more to think we avoid
>   adding non-so-much-good patches to production.
>

I agree, it's better to sleep on it :)

>
> Interesting, about having a Donations class. Methods to move to such
> Layer-5__DB_operation/Donation.php class:
>
>   * getDonators($JobOfferId)
>   * getDonationsForPledgeGroup($JobOfferId)
>   * addDonation($JobOfferId)
>   * cancelSelectedDonations()
>   * getMyDonations()
>   * IsAlreadyDonator($EntityId,$JobOfferId)
>
> Let us wait a week more, and if all is right we could write a patch for such
> table-renaming and class-addition the next Saturday.
>

Ok

>
> The entity-email verification link is:
>   https://gnuherds.org/entity?action=register&email=&magic=
>
> Verification link for donations could be: I am not sure.
>   https://gnuherds.org/pledges?action=donate&email=&magic=
>

Ok, we could follow the entity registration process.

> Proposal:
>
>   Shows too non-verified donations. So the webapp will give immediate
>   feedback to who add a donation, even if [s]he is not logged.
>
>   If it is not verified it will just deleted. So no problem.
>
> IMHO, the webapp giving feedback to users is good. When I donate I want to
> see
> my donation listed immediately, even if I will verify tomorrow.
>

For the user which makes the donation is good to see his not-yet confirmed
donations as soon as possible, but, what about the rest of users? They could see
a donation one day and not the next day, because for any reason it has not been
confirmed.

>
> Note right now the getEntityId method is used for two JobOffer methods:
>
>  * getEntityId(trim($_POST['Email']),'REQUEST_TO_ADD_NOTICE');
>  * getEntityId(trim($_POST['Email']),'REQUEST_TO_ADD_DONATION_TO_NOTICE');
>
> If we move out the code which send the email we will have duplicate it. And
> duplication is not good for maintenance neither for code readability.
>
> Additionally, note if we keep it inside such method we could use a common
> text
> for all email. A more abstract and common text will do the translator task
> easier due to they will have less msgid to translate.
>
> Proposed "policy":
>
>   Try to reduce the number, length and complexity of msgid to translate if
>   it is possible, but without damage the webapp. Just use the common sense.
>

I totally agree, we should avoid code duplication as much as possible, along
with other benefits, this leads to less msgids. In this case i think that there
could be alternative options, without code duplication and without violating the
separation of concerns: what do you think about a separate mailing class?

Best regards
Federico