Try ERPNext Buy Support Partners Foundation

[v13] Some proposed big changes to desk, routing and Web Forms

Dear all,

As a part of the new desk UI refresh, there are certain parts that are being planned on refactored on the roadmap for v13.

  1. 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/

  2. 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?

  3. 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.

  4. 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)

  5. 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.

FAQ

  1. 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.

  2. 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!

  3. Is it worth it? Maybe. This seems like a risk, but these are all improvements in the overall architecture, capability and performance.

23 Likes

Welcome changes

#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?

Hi,
Is it proposed or final?

Agree :+1:, it was limitation in V12 since we cannot move seeded fields around.

Thanks
Nofal

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.

1 Like
  1. 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?

5 Likes

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.

1 Like

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 https://github.com/frappe/books

CC @netchampfaris

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.

1 Like

@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.

4 Likes

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.