Add QR Code Generation Support and Order Creation

[SudharakaP]

⚠️ Should only be merged after completing opencollective/opencollective#4484

Resolve opencollective/opencollective#4516

Related API PR: opencollective/opencollective-api#6378

[vercel]

This pull request is being automatically deployed with Vercel (learn more).
To see the status of your deployments, click below or on the icon next to each commit.

opencollective-frontend – ./

🔍 Inspect: https://vercel.com/opencollective/opencollective-frontend/vtrWjajJoEP3X8guUrzEEYfnNK6j
✅ Preview: https://opencollective-frontend-git-feat-add-qr-c-778272-opencollective.vercel.app

opencollective-styleguide – ./

🔍 Inspect: https://vercel.com/opencollective/opencollective-styleguide/nmHNPcVpYKqraXEAvKCuaNdgev9B
✅ Preview: https://opencollective-styleguide-git-feat-add-qr-dac3b1-opencollective.vercel.app

[SudharakaP]

Everything in this PR is contained in #6725 and thus I am closing this.

[znarf]

@SudharakaP why are you closing the PR and decided to mix up 2 PRs together? I'm afraid it's just making reviewing difficult. Also the title and description of the open PR doesn't make sense anymore.

[znarf]

Also, #6725 doesn't seem up to date, many things that were addressed are not fixed.

[SudharakaP]

@SudharakaP why are you closing the PR and decided to mix up 2 PRs together? I'm afraid it's just making reviewing difficult. Also the title and description of the open PR doesn't make sense anymore.

@znarf : Sorry, this is what happened. Initially, when I created the issues, I separated the issues into three parts mainly. 1) designing of the settings part of the crypto flow, 2) Adding crypto flow sections for the contribution flow, 3) adding the QR code and the final success screen. And then I opened the first PR, and rather than waiting for the completion of the code reviews I started working second and third parts as well.

Now maybe the best method was to add the whole Crypto flow in one PR. But my initial plan was to rebase the PRs and keep it in sync which is what I followed; although I couldn't keep up with syncing the PR everyday rather resorted to syncing them after the code reviews are done and the first PR is merged. Next time I should have a better separation of tasks or maybe explain my plan better in the beginning. 🙂

Also, #6725 doesn't seem up to date, many things that were addressed are not fixed.

This is rebased. Please check again, now it should be all updated. 🙂

[SudharakaP]

@znarf : Also I've changed the title and description of the other PR; #6725 has been updated. Sorry for the trouble, but I think it should be all good now. Let me know if you see any issues.

[znarf]

Splitting the work in multiple PRs is the way to go. We absolutely don't want giant PRs, they're impossible to review and lead to problems. I would even say that it's not normal that we're working on PRs that are in review for more than 1 week, where we're not keeping track of the number of review rounds. This shows that they're even too big themselves.

But my initial plan was to rebase the PRs and keep it in sync which is what I followed; although I couldn't keep up with syncing the PR everyday rather resorted to syncing them after the code reviews are done and the first PR is merged.

While potentially a bit painful, your original plan was the right one, it should normally be manageable, way to go.

[SudharakaP]

Splitting the work in multiple PRs is the way to go. We absolutely don't want giant PRs, they're impossible to review and lead to problems. I would even say that it's not normal that we're working on PRs that are in review for more than 1 week, where we're not keeping track of the number of review rounds. This shows that they're even too big themselves.

But my initial plan was to rebase the PRs and keep it in sync which is what I followed; although I couldn't keep up with syncing the PR everyday rather resorted to syncing them after the code reviews are done and the first PR is merged.

While potentially a bit painful, your original plan was the right one, it should normally be manageable, way to go.

@znarf : Surely, I'll keep these in mind, in addition for now I'll do re-basing only until we get this RFC clarified; opencollective/opencollective#4367