Skip Navigation

[Resolved] Visual form editor reset when adding or removing roles

This thread is resolved. Here is a description of the problem and solution.

Problem:

The customer reported that in user forms, if the visual form editor is being used and the target role is changed, the form fields are reset.

Solution:

Explained that this is known and expected behavior that if the user role is changed in user form or post type is changed in post form.

We've had some internal discussion on this matter before and this was implemented purposefully so that only relevant fields can be made available.

Also shared a workaround of switching to "Expert mode" before making a change to user role or post type and then switching back.

Relevant Documentation:
n/a

This support ticket is created 2 years, 3 months ago. There's a good chance that you are reading advice that it now obsolete.

This is the technical support forum for Toolset - a suite of plugins for developing WordPress sites without writing PHP.

Everyone can read this forum, but only Toolset clients can post in it. Toolset support works 6 days per week, 19 hours per day.

Sun Mon Tue Wed Thu Fri Sat
- 9:00 – 13:00 9:00 – 13:00 9:00 – 13:00 9:00 – 13:00 9:00 – 13:00 -
- 14:00 – 18:00 14:00 – 18:00 14:00 – 18:00 14:00 – 18:00 14:00 – 18:00 -

Supporter timezone: Asia/Karachi (GMT+05:00)

Author
Posts
#2254243

Hello,

I recently encountered problems editing a user with a Toolset user Form and discovered it was due to the user's role which was a custom role created after the form and thus not checked in section "Role of the user to create/edit".

In order to solve the problem I edited the form and checked the new role. Unfortunately it's only after saving the form that I noticed that the visual form editor had been reset with default user fields making me loose all field settings as well as previously added generic fields / HTML content.

I made a few tests before rebuilding my form and thus can confirm that the visual editor is instantly reset when changing roles no matter if adding one or removing one which means it's impossible to change roles without having to rebuild the form entirely.

As the concerned form is meant to be used for all existing roles, I also tried to uncheck all of them but this way the visual editor does not display anything in the form edit screen even though the form still displays default fields on frontend and can then be used to edit user with any role.

This behavior is very annoying in our case as new custom roles may be added frequently and the form has many custom and generic fields (which makes it quite long to rebuild) so it would be great if it could be fixed or if we could have a way to allow users of any role / all roles to be edited with the form so we are not forced anymore to set editable roles specifically and edit the form each time a new one is added.

Unfortunately, I can not let you access the project website administration due to confidentiality reasons but I could reproduce the issue on a testing website with only Toolset & WPML, so do not hesitate to tell me I you need access to this one.

In case the issue can not be fixed in the short term, we would really appreciate any workaround that would still allow us to use the visual editor, this even if it disables role check which is useless in our case.

Thanks in advance for your help and have a nice day.

#2254799

Waqar
Supporter

Languages: English (English )

Timezone: Asia/Karachi (GMT+05:00)

Hi,

Thank you for contacting us and I'd be happy to assist.

I've performed some tests and research and can confirm that form fields are reset in the visual editor if the user role is changed in user form or post type is changed in post form. However, fields are not reset if the form's type is changed (i.e. if an "add new" form is changed to "edit existing" form or vice versa) or if the form is using the "Expert mode".

We've had some internal discussion on this matter before and it was decided that since different user roles and post types can have different fields, it is important that the new fields are made available based on the new selection. And since evaluating individual field validity with the newly selected user role or post type would become too complicated, the fields are reset as a whole. It is also less likely to impact complex forms with custom HTML structure or generic fields, because that will require the use of "Expert mode".

I can understand that this behavior can be annoying for users who prefer to use the visual form editor and have to frequently change the user role or post type in the existing forms. But based on my tests, there is a simple workaround that can be used.

Whenever you need to change the form's role or post type, you can first switch on the "Expert mode" and save the form. After that, when you'll change the role or post type, the existing fields won't be lost. After the change, you can turn off the expert mode and save the form again, and despite the warning message, the fields will stay intact.

I hope this helps and please let me know if you need any further assistance around this.

regards,
Waqar

#2255415

Thanks for the feedback Waqar.

I tested the workaround but, when switching back to visual mode after the form has been saved in expert mode (this even if not changing roles), labels are still reset for core fields, some core fields are taken out of the form and the full shortcode is displayed for labels of Type and "managed with Type" fields. Maybe it's not the only issues I would encounter using this method but seeing them discouraged me to test more thoroughly.

Briefly said, it helps a bit but does not really solve the problem even assuming all of us will always remember we have to switch to expert mode before changing roles which will probably not be the case.

I understand that changing roles means the concerned fields may change but there really should be a way to keep the form state and have only the available fields (right column) updated / reset. Maybe the best approach would be to make the form reset optional and ask the user before running it so he can choose to allow it or not depending on his needs.

Post types often have different custom fields and a form cannot be used for several post types anyway so the reset is not really a problem for post forms. It's different for users for which it can makes sense to have a same form used for several roles (if not all of them) which in many cases will share same user fields.

For the same reasons, it would be useful to have a "all roles / any role" option or make the role filtering optional to avoid being forced to update forms to add new roles in case where roles are not really relevant.

That would also offer a good workaround for the reset problem even for those who need to restrict the form to specific roles as they can also achieve that through Access functionalities.

#2256051

Waqar
Supporter

Languages: English (English )

Timezone: Asia/Karachi (GMT+05:00)

Thanks for writing back and for sharing these suggestions and feedback.

Unfortunately, I don't have any other more useful workaround, for now, but, I'll pass this feedback about the form fields reset process, internally.

You're also welcome to share this directly through our feature request form:
https://toolset.com/home/contact-us/suggest-a-new-feature-for-toolset/

#2258153

Well, passing the feedback is already a good thing even if it does not help right now so thanks for that.

I hope this part of Toolset will be improved in the future and I'll do with it until then.

Have a nice day.

This ticket is now closed. If you're a WPML client and need related help, please open a new support ticket.