As a part of the new desk UI refresh, there are certain parts that are being planned on refactored on the roadmap for v13.
Routing: Currently the “desk” (admin) interface has hash based routing. Example the route for ToDo list is: /desk#List/ToDo. In v13 the routes will be full routes, beginning with app, so the url for to-do list will be /app/list/todo and all urls will be prettier, like /desk#List/Sales%20Order will become /app/list/sales-order. (Edit: will try and drop the view identifier, so app/form/sales-order becomes /app/sales-order/
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?
Restricted UI: Most of the standard desk elements will be optional and can be set via role. You can turn off the search bar, notifications, sidebars, timeline in forms. Most of the other features are already permission controlled.
DocType Layout: To allow for alternate layouts, there will be a new concept “DocType Layout” where you can arrange fields in different ways, these can be exposed to the user based on their preference. (PR)
Faster boot: There is also a plan to break up the current “boot” process inside the desk so it is much faster to load. This means that permissions and other objects will be fetched when required.
Why are we doing this? Web Forms is a half baked implementation of the Form object with a lot of features that are lacking. Instead of having two implementations, it seems a better idea to collapse it into one.
Why refactor routing? Since we are in the process eliminating Web Forms, it means that the “desk” which is a massive Single Page Application (SPA) needs to be opened up and made more modular. Also clean URLs are much nicer to read!
Is it worth it? Maybe. This seems like a risk, but these are all improvements in the overall architecture, capability and performance.
#1 is well understood #2 is true about second-class treatment. Where can we follow to figure out the changes done/test? #3 is super. #4 Desktop Layout. Are we planning to have desktop layouts assigned to user/roles or would it be site baesd? #5 would this mean that the fields permission-level would be checked after boot?
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.
@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.
@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.
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.
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.
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: