Problem with Web Forms

Frappe Framework Bug
1

I had one of our customers, who’s helping us test the system out, reach out to us today to report a problem they are having when submitting a web form. This particular form was for the Issues form. The customer filled out all the needed information, and was presented with the following message:

These particular fields are not listed on the web form, for obvious reasons, and therefore the customer cannot fill them out. This form has worked fine for several weeks now, and the only thing that I am aware of that has changed recently was that we ran “Bench Update” last Friday, so I am assuming something messed up in the most recent update.

Another odd thing is that when I investigated the web form under the Website settings, I discovered that all the forms are not editable, even for Administrator. Please let me know if there is anything else I can provide to insure this issue is fixed.

2

There are some mapping issues between the webform and address, and for that reason the webforms are (temporarely) locked. Fix expected soon. The Msg seems to be an related bug (same here, cloud user)

3

Thanks! Glad that it is being looked into.

4

@dsslrbrandon this if fixed. Will be released later today.

5

Thanks, rmetha!

6

Uh oh… I just updated, and it looks like it replaced our form, where we had a few custom fields for the customer with the default one that only asks the customer for a Subject, Status and Description. Rebuilding the form is not a problem, but the Web Forms are still locked and non-editable.

Please advise.

7

You can only edit fields existing in web forms. If you want something more, create a new web form.

8

I would, but I am still getting the message saying that I do not have permission to create a web form, even while logged in as Administrator.

Please advise.

9

Check permissions for Web Form

10

Okay, I do not think that we are on the same page here.

I guess I am just trying to understand why we can no longer modify the standard web forms, which seemed to work perfectly until recently.

We have the Issues Form that we at the company access from the Desk view.

Within this form, we have a few custom fields that we’ve added, that allows for us to collect specific information concerning the issue (ex. Brand, Model, Serial Number, PO Number, etc). Nothing out of the ordinary.

There is also the Issues Web Form that the customers access.

Both of these are connected to the Issues doctype.

The Problem:
Originally, before a more recent update, I could include any of the custom fields from the Standard Issues Form (Make, Model, Serial) on the Web Form for the end user to fill out. Unfortunately, a recent update has locked the Issues Web form, as well as removed all the fields that were once on there, and so now I cannot include the fields that we need the customers to fill out.

I understand that I can create a new web form tied to the Issues doctype, which I have done (in my case I called the form “Tickets” with the weblink …/tickets), and it does work.

However, the problem is that when the customer clicks on the issue, even if they are on the /tickets page, it takes them to the standard form from the issues page, and not the new one.

Example:

I’m the customer, and I want to review and add a PO number to a ticket that I had previously opened.

I go to companyurl.com where I see all the tickets I have opened listed.

I then click on ISS-00001.

It then redirects me to /issues?name=ISS-00001 instead of /tickets?name=ISS-00001

I cannot add my PO number, because I do not see the PO Number field listed on there.

Instead, all I see are Subject, Status, and Description.

11

Changing the standard web forms can lead to problems as @becht_robert discovered.

Portal is not yet designed to be “customizable”. If you want to make changes that are generic and good design choices, you can send us pull-requests.

Edit: Or you can build a new portal in your app

12

I cannot attest to the types of problems he was having, but we experienced absolutely no issues until something was updated recently. As I’ve said before, this used to work fantastically, and now it doesn’t. You mentioned earlier that the issue had been “fixed,” but I really do not consider turning off existing features a fix at all.

While I am extremely tech savy, I’m unfortunately not a software dev, and do not have the time or resources to modify the software to do something that it was able to do a matter of a few weeks ago. I sincerely hope that you guys reconsider this recent change and revert the functionality back to the way it was originally. Until then, we will have to notify our customers that they will have to call their issues in directly, as opposed to submitting them online.

13

Yeah there should be a better way to handle standard web forms, but you can always create custom web forms for Issue. Why not do that?

14

I mentioned the problem this poses in my previous comment. This is an example of creating a new web form linked to the Issues doctype called “Tickets.”

For the initial creation of a document, custom web forms are great. However, when it comes to reviewing or modifying them, things become more difficult.

15

Can I make a suggestion here for a middle way.

Option 1) make the web adress page editable again but with carefull
instructions about the limitations, that are i believe linked to a mismatch
between webadress field and address fields (select fields, link fields)

Option 2) Make a copy that it editable, but allow the adress page to be
specified in the cart settings. Which than basically result again in option

  1. since the web adress should map into the adresses.

It is indeed a pity that even text on the screen can no longer be localized
(=translated)

rgds robert

17

I have exactly the same issue.

When I create a web form called ticket and use Issue as the doctype, it will have the issue. Clicking on the ISS-00001 will bring the page to /issues?name=ISS-00001 instead of /tickets?name=ISS-00001.

And I have done a test to make the ticket web form to use opportunity as doctype and it goes well. Clicking on the OPTY-00001 (created earlier) will bring the page to /tickets?name=OPTY-00001 and and everything goes well.

Why does it go wrong when we use doctype Issue?