Is there a way to extend an existing Doctype, but store the modification in an app? The most common solution is usually creating an inheritance between the new Doctype and an existing one.
Sample usage: a company sell wines, we could extend the “Item” Doctype to store dedicated data to the wine products (bottle size, package, region, alcohol level, …)
If it’s not possible to have a inherited new Doctype, is there a way to customize a Form / Fields, but store the changes in the custom app (and not in the original app “Stock”)? I mean the new custom fields in the Item Doctype would be managed and setup by installing the custom app.
Actually I was more thinking by “inheriting” => just keeping all the current base Doctype logic the same, but managing the code for the custom fields and logic inside the custom app.
For example in Odoo this can be done by creating a new “Model” (equivalent to Doctype), inherited from “Product” (equivalent to “Item”), and then this allows to extend the Product model by adding custom fields from the inherited model. This actually does not create a new SQL table, but adds custom fields in the source one.
When I add a custom field, is there a way to “attach” it to a custom app? What I’m looking for: the installation of the custom app should automatically add the custom fields to existing ERPnext Doctypes?
And more globally my question is also for scripts, or any other customization.
Let say I want to create a custom client script for the Item Doctype (which is a standard ERPnext Doctype from “Stock” module) to add buttons, or do other actions / display customization in Item form and list.
Is there a way to have this client script saved in my custom app to be easily maintained / deployed / updated with the custom app?
I am currently in a similar situation and would like to learn more.
I find it very hard to create a holistic development lifecycle around changes in ERPNext.
We only want to create some new DocTypes and use existing ones, but we haven’t found any way to extract those changes after development, manage them with git and introduce them into a ci pipeline.
We are now following a similar approach because we believe custom apps might the feature we have to use. However, we still want to use default ERPNext DocTypes as well.
What if I want to create new Item Groups, or new Item Templates and Variants? They will all live in the Stock module. But that’s not part of my custom app, it is part of the ERPNext app. How could I get those chances out of there? And sadly, this brings us back to square one.
You have the option to export customizations (custom fields) to a module (your custom app) which would add all the custom fields to the necessary doctypes when the custom app is installed (this is how hrms works).
This can be done in the customize form page under actions button.
As for scripts, if you write them as APIs in a python file within the custom app and call them via hooks, then you don’t need any fixtures.
But if you’re using client scripts and server scripts in the desk, then you need to add those in hooks as fixtures, and give “bench export-fixtures” in order to add them while installing the script. (Fixtures can be used for any other records in almost any other doctypes.)
Currently I believe fixtures is the only way to get all your workflows, notifications, role permissions, roles, property setters (modifications to the fields of standard doctypes) into new sites on installing a custom app.
