New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Form Builder #4137
Form Builder #4137
Conversation
be0bb6c
to
d085707
Compare
d085707
to
6c4fbde
Compare
@Kukks It'd be good to move the generic form definitions (email, address) out of the view code into C#, so that we can use them there as well and then serialize it to JSON for the view. Other than that I'd consider this PR done and would like to see it merged, so that I can use the forms in Checkout v2. |
done |
@Kukks Anything else that's left TODO here? Otherwise, let's get this in :) |
|
34f8374
to
da77d21
Compare
blob.CheckoutFormId = model.CheckoutFormId; | ||
if (blob.CheckoutType == Client.Models.CheckoutType.V2) | ||
{ | ||
blob.CheckoutFormId = model.CheckoutFormId; |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
What difference does this make? I put it into the if to prevent unintended changes in case Checkout v2 isn't used.
As the value is submitted every time with the form it wouldn't change, but I was wondering about the intention of pulling it out
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This is because forms are no longer tied to requiring checkout v2 - they work perfectly fine with old-style checkout too.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Ah ok, in that case we should also update the view to have the select dislayed in any case. I can update that.
|
||
[AllowAnonymous] | ||
[HttpGet("~/forms/{id}")] | ||
public async Task<IActionResult> ViewForm(string id, string redirectUrl) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This won't work, as the user can then manipulate the original data in the query string and the invoice might be created based on the modified data.
For the simple POS item list it works, because the price cannot be decreased (because the price is taken from the item), but for the cart view it can be manipulated — I think we should come up with a more resilient approach here.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The logic for the cart is still acted upon as before. If the user manipulated the form HTML values before submitting, it would have the same result
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I see; however that isn't ideal. It works as long as the merchant has most likely the control over the input device (as with the POS), but it'd be problematic for e.g. an online store.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
One idea here: We could hash the data (or amount) with a salt saved in the store settings and use that as a checksum on the receiving action. That way we can ensure that the data doesn't get tampered in the browser..
@Kukks @dennisreimann is this supposed to work with new checkout, because it doesn't? |
@pavlenex Keep in mind that not all invoice creation methods are covered yet. See this comment. |
I tried this PR again, but after some recent pushes I am experiencing a few problems, which are mostly do to me selecting default options. For example payment requests work with shipping address and email address but not with other options, explained below. Problem 1: Default store settings give 404 or crashed
Problem 2 When selecting
|
Thanks for testing, fixed a bunch of issues today that I found. Let me know if it's a bit better. |
@Kukks Thanks, the Payment request bug is no longer present, however I am still getting error when creating a POS with default settings, it gives 404. To replicate:
Note, it needs to have Screen.Recording.2022-11-21.at.11.32.21.movAlso these two options are kinda the same on POS view? Should we remove one? |
There are too many magic and rough edge in this code for me to be confident it is in a shippable state. For example, I found a bug during review: there is a few "pre-made" forms. Those doesn't have a storeId associated, and such routes such as |
This isn't ready yet.
|
Form response stores the response from the response if a formid is set Invoice level form was removed because we were overcomplicating things for a feature that is probably not very useful. We can add it later. Checkoutformid was removed along with the above point, for the same reason. Custom forms may not be very used for now, since we haven't built a UI for building a form. We can potentially just hide it behind an experimental flag for now |
Let's just use the preconfigured/generic forms (email and address) in the first iteration and add customizable forms later. |
I would not remove, just hide behind experimental flag.
…On Thu, Nov 24, 2022, 3:12 PM d11n ***@***.***> wrote:
Let's just use the preconfigured/generic forms (email and address) in the
first iteration and add customizable forms later.
—
Reply to this email directly, view it on GitHub
<#4137 (comment)>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/AAN357QBF2TLYUBKZSTNYX3WJ5ZV7ANCNFSM6AAAAAAQP4PRIA>
.
You are receiving this because you were mentioned.Message ID:
***@***.***>
|
Awkward question, but where can one find customizable forms. Are they even in the UI? The only forms I found so far were in the apps and pre-defined? |
Store settings, secondary nav
…On Thu, Nov 24, 2022, 4:15 PM Pavlenex ***@***.***> wrote:
Awkward question, but where can one find customizable forms. Are they even
in the UI? The only forms I found so far were in the apps and pre-defined?
—
Reply to this email directly, view it on GitHub
<#4137 (comment)>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/AAN357VBFSC3QKHTCRB5DALWJ6BAXANCNFSM6AAAAAAQP4PRIA>
.
You are receiving this because you were mentioned.Message ID:
***@***.***>
|
Oh wow, I was blind, totally didn't expect us to have customizable forms in this release. I think we should abstract it from the UI, how about we roll out with the predefined ones, and just see which forms people ask? I think in the next release we may have more time to thinker about the UI here, and the need for more forms. |
I would prefer to not entirely remove it and just hide it.
…On Thu, Nov 24, 2022, 4:31 PM Pavlenex ***@***.***> wrote:
Oh wow, I was blind, totally didn't expect us to have customizable forms
in this release. I think we should abstract it from the UI, how about we
roll out with the predefined ones, and just see which forms people ask? I
think in the next release we may have more time to thinker about the UI
here, and the need for more forms.
—
Reply to this email directly, view it on GitHub
<#4137 (comment)>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/AAN357TNJ7CE56EOPDDWOJDWJ6C4JANCNFSM6AAAAAAQP4PRIA>
.
You are receiving this because you were mentioned.Message ID:
***@***.***>
|
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Refactored it to remove the TempData usages. To me the flows for POS and payment requests seem to be clean and intuitive now.
Also trimmed off the parts where we had custom forms (from the UI, the code is still there) so that we‘ll only ship the generic forms (email and address).
@NicolasDorier I've added the index for |
I remove untested code and the database code. I will reopen a PR rebased with the stuff I just removed after this one so @Kukks can improve it in a separate PR. |
I've opened a PR adding back what I removed for supporting Generic Forms. We should do in a future PR after this release. |
Closes #505