seems like my proposed doctype variant feature, the equivalent of SAP’s configurable layout per transactions(doctype) type.
this is badly needed for complex transactions like payment, GL entry, stock ledger, various orders(purchase, work and sales) etc.
- Web Forms will be removed: The desk (app) interface will now be the common UI for all form based entries. Web Forms always had second class treatment, and the expectation from Web Form is of the full form. Also most of the code of Web Forms was patch work. Web Forms will now be accessible from the
/app/
interface, so all Web Forms will start with the url/app/form
. Next questions is, will all users have access to all the desk features?
The Web Forms were used in the Web View e.g. as contact forms embedded in web pages. How do you plan to support this use case going forward?
Web Frontend Architecture
It looks like that you are doing a quite large infrastructure update on the ERPNext frontend, did you consider moving to a more modern e.g. Vue and TypeScript based implementation for the core frontend functionality? I know that it is already possible to use Vue based components, so the transition could be an incremental one.
If the current Desk functionality would be (re)implemented as a set of Vue components the current server rendered Web frontend could also be transformed to become a Vue application (e.g. using Nuxt). This would have a lot of benefits:
- More code sharing between the Desk and the Web view (essentially the 2 code bases could be merged to have a set of components that can be used to build complex user experiences)
- A single Web frontend technology stack could be used (Vue, Nuxt, NodeJS) instead of the current hybrid (NodeJS for real time communication, Web view server rendered using Python and Jinja, JS SPA for the Desk, Python based APIs)
- The Python app would only provide an API, no regular web requests resulting in code simplification.
- The current webshop functionality could be easily replaced by e.g. Vue Storefront which provides a high quality experience out of the box (including offline PWA support and other goodies)
Obviously this is a large project that would take time and funding to develop, but the benefits would make it well worth it in my opinion.
What do you think?
All efforts are appreciated. You are going in a good direction.
@rmehta cloud users do not have permission to create apps ? It requires server access. Web forms was very good to create Job Application forms and some simple portals for our website users.
So do website users who sign-up become desk users with restricted UI.
Will standard website portals also go away ?
@dhananjay, no restricted users won’t become paid users in Frappe Support. Ability to create ad-hoc forms won’t be restricted, only the implementation is now via DocType Layout
and not Web Form
, also the code will be the same.
What would now be the value of the Portal?
I am especially thinking LMS.
@kisg you are proposing a big change. Here is my opinion. I don’t see any clear benefits in rewriting the desk, other than performance, which can also be fixed incrementally.
If you like a big VueJS project - checkout GitHub - frappe/books: Modern desktop accounting for freelancers and small-businesses.
Agree. Using as simple language and structure as possible (as existing) is one important value for non-programmer persons doing business (as most SMBs) to use ERPNext, and to customize it.
I’m not a programmer but I consider myself have gone quite far in customizing ERPNext for my use.
@rmehta I guess I am a little bit confused about how the outlined plans will work: we will no longer have web forms, but we can have a Restricted UI mode of the Desk SPA that will display the form (customisable using Doctype Layouts). But what happens if we have a web frontend with a customised look & feel. How will this Restricted Desk UI match that?
Is there a pull request or branch that we could review already?
My proposal would make this use case very easy: the components and frontend logic that are used in the Desk app to display form layouts could simply be used on the web frontend as well.
I already reviewed the Frappe Books project and I liked how it was structured, but I don’t see a reason why its frontend technology needs to be kept separate from the “real” Frappe and ERPNext. I would rather see a lot of benefits from having a single, modular, modern frontend stack that can be used for everything:
- The Frappe / ERPNext Desk SPA
- The Web UI (using server-side rendering, e.g. with Nuxt)
- Mobile UIs: either as PWA or even normal apps with web ui to provide better integration with mobile platforms for e.g. accessing the secure element on mobile for encryption or doing fingerprint / faceid auth for ERPNext)
- Desktop / Standalone UIs using Electron, for all-in-one projects like Frappe Books, or even a dedicated client for ERPNext that can better integrate with the desktop similar how e.g. Slack does it. This could also be used as a dedicated POS client.
You can take a look at what the Vue Storefront developers are doing, how they split out the frontend toolkit into the Storefront UI (https://www.storefrontui.io/) and how they are building a very modular solution with Vue Storefront Next (https://docs-next.vuestorefront.io/).
In my vision this way ERPNext could be used not only as a world class ERP, but also to act as a CMS system that can be used either headless, or use the provided Vue / Nuxt based frontend stack to create modern customer facing websites and portals.
I agree that this is a big change and the only way to achieve this would be through an incremental approach.
Does this mean that one can configure the order of fields as used to be long ago (v6 or so)???
This is great, moving for more flexibility and freedom for developers.
But I would not get rid of the view identifier in the url, It’s useful for debugging, routing, and is not really clutter. You could just redirect to a default when not provided.
Excited to see this coming! What would also be valuable is the ability to easily share every ERPNext view. Applied filters from report, list view, etc. could be immediately reflected in the query parameters.
This feature is already available with keyboard shortcut to share URL for listview with filters (based on OS). For MacOS its CMD+L
. Not yet available for report view though.
Relevant shortcut for your OS can be found from:
Help > Keyboard Shortcuts > Page Shortcuts > Share URL
The GET parameters are not shown by default to keep cleaner URLs in the browser address bar…
New routing changes have been merged with new UI design!
Is this implemented?
What type of “forms” should I use when trying the V13? Is there a guide on how to use the new form system? I would like to try it.
Thanks
I am interested in the same as @doca.
Is there any documentation, on how to make use of the doctype Layouts, to replace the webforms? Within my test-environment with the latest develop-branch, I couldn’t figure out, how to actually use the doctype layouts as a replacement…
Furthermore I have found the following question, where I couldn’t find an answer, yet (neither in the documentation, nor in this forum) → Will the customer portal be part of the V13?
→ Is it correct, that the “Customer Portal” will be removed, so that we will just go with the desk-UI, setting up Roles/Permissions for Customers and providing a slightly different UI based on the doctype Layout?
Hey @Patrick.St, my understanding is that portal will still be there. Just changes in the ways Web Forms and web pages in general are handled. MIght be wrong though
I have found this thread on Github Frappe with progress on the website pages building. Couldn’t find much about the portal though:
https://github.com/frappe/frappe/pull/12334
Hi @f_deryckel, thanks for sharing that.
I am just not sure, if that relates more to the regular Web Page feature itself - in that context the Web Page Builder Web Page Builder has been introduced.
I like the 2nd point, finally, the webforms are going away, desk UI works and could be reused.
Is this change already in v13? I’m not seeing it, any inputs, please!
V15.
I built a web form from a Doctype this Doctype with some custom scripts .py and .js
If I am working on the Doctype list and add new everything working fine .
But
From the web form some JavaScript works as when on the Doctype and some other JavaScript didn’t.
Why?
Thanks