Frappe Core DocTypes can't be customized in Version 11

Hi.

I have just checked my system Hub User and Hub Users docTypes allow custom fields. User docType which has all the users data unfortunately cannot have custom fields.

In this case, the alternative is to have a new DocType “Users2” if you really need additional fields…

Sorry.

Hello @lasalesi

Have you tried to put ERPNext into developer mode and then tried the customization?

Reagards
Bilal

Hi @bghayad,
thanks, yes, I am in developer mode.

Actually, I was able to resolve the issue using fixtures of a custom app. Only trying to figure out the reason, why this is locked (and to be honest, I would much like to have this back)!

1 Like

Hello @lasalesi, thank you too.

So it is confirmed that it is locked?
Like what doctype that this is locked? Is it also locked for customer doctype as example?
Can you please let me know how you used the fixtures of the custom app to resolve it?

Regards
Bilal

Hi @lasalesi,

yes, the Frappe Core DocTypes are locked by this “feature”, most prominently User.

You can manually edit the fixtures file and add the required additional fields there, this will create the custom field record (which in the front-end will still be locked). For example like this:

{
  "allow_on_submit": 0,
  "bold": 0,
  "collapsible": 0,
  "collapsible_depends_on": null,
  "columns": 0,
  "default": null,
  "depends_on": null,
  "description": null,
  "docstatus": 0,
  "doctype": "Custom Field",
  "dt": "User",
  "fetch_from": null,
  "fieldname": "signature",
  "fieldtype": "Attach Image",
  "hidden": 0,
  "ignore_user_permissions": 0,
  "ignore_xss_filter": 0,
  "in_global_search": 0,
  "in_list_view": 0,
  "in_standard_filter": 0,
  "insert_after": "section_signature_cost_center",
  "label": "Signature",
  "modified": "2019-03-06 21:52:14.685977",
  "name": "User-signature",
  "no_copy": 0,
  "options": "",
  "permlevel": 0,
  "precision": "",
  "print_hide": 0,
  "print_hide_if_no_value": 0,
  "print_width": null,
  "read_only": 0,
  "report_hide": 0,
  "reqd": 0,
  "search_index": 0,
  "translatable": 0,
  "unique": 0,
  "width": null
},  

Hope this helps as a workaround.

1 Like

What other doctype that might also be locked other than User doctype? How can I know that this doctype is Frappe Core DocTypes?

What you will do if you upgrade ERPNext? This will be removed.

Regards
Bilal

You can check which doctypes are “Frappe Core”: frappe/frappe/core/doctype at develop · frappe/frappe · GitHub

Fixtures and also earlier customisations are maintained during upgrades (tested in v11).

Great.
I know that you can do customization for the documents using customize form and it will not be affected by upgrade. But how do you protect your fixtures?

One more thing: if you need to do a new installation for ERPNext and you need your customized forms and your fixtures to be installed at the new installation (fresh installation), what is the method that you use it for this?

Regards
Bilal

Thank you @lasalesi
Regards
Bilal

Hi @bghayad,

I have tested the fixtures in v11 (on a new installation) and it works fine. It is only the “Customize Form” which is affected… You can check that the custom field record is created properly.

@lasalesi @rmehta I am a little lost with the convo above. I have tested “Customize Form” on Frappe Core doctypes and never had a problem (v11) until now with “User” which I have existing customizations for.

Why is the statement that “We don’t allow you to customize Frappe core doctypes,” but in fact you can customize most of them, just not “User”.

Is this in fact a bug that needs fixed?

Too many people shoot themselves in the foot by being too creative and customising core features. Ideally there must be a customisable check on each doctype and field at design level.

SAP’s practice is to strictly control the modification to standard feature/code, on code level enhancement via user exit( the hooks in ERPNext), on user interface level via transaction variant or field status configuration settings.

if it is really needed to change the standard code, it is possible to apply a developer access code, with this developer access code registered in the system, it is possible to change the code!

1 Like

…but you already have restrictions on the standard fields which users cannot edit or even re-arrange without being in developer mode. Why restrict custom fields? Is restricting creativity really the way to go?

Kind regards,

2 Likes

If we need to associate other information with user accounts, is there another approach you would suggest? If we need users to have an “Employee ID number”, for example, is there a way to do that without, as you say, shooting ourselves in the foot?

@peterg

try this custom script:

function ID () {
var Employee ID number = “”
frappe.call({
method: “frappe.client.get_value”,
args: {
doctype: “Employee”,
fieldname: “Employee ID number”,
filters: {
user_id: frappe.session.user
}
},
async: false,
callback: function(r) {
Employee ID number = r.message.Employee ID number
}
})
return company
}

1 Like

Thanks Eli,

It’s a handy workaround, but mostly I’m trying to understand the change.

Are more documents likely to become “core” in the future? Custom fields had been working great for us, because they allowed us to integrate with other systems effectively without needing to make unsustainable customizations to code.

From the mixed messages in this thread, it’s not clear to me whether custom fields are still a recommended approach.

@peterg

I think core documents are quite limited . The list will not grow exponentially. To get an idea of what they mean by core documents, simply install the frappe framework and DON’T install the ERPNext app. Login to the system and you’ll see what they mean by core documents.

Custom fields are without a doubt handy and are in no way going away soon. Custom fields and custom docs are the essence of an agile solution.

I understand it can be annoying when something is changed, but I’m pretty confident the Frappe team have got their valid reasons for tweaking the system.

2 Likes

Hi @lasalesi , may I ask you about the procedure you followed to resolve the issue using fixtures of a custom app, because I’m having a similar problem.

Thanks

Hi @youssef,

sure, I used a custom app with fixtures enabled: in your hooks.py file, add “Custom Fields”

fixtures = ["Custom Field"]

Then, run

$ bench --site mysite export-fixtures

This will create the base fixture file. You can effectively remove the content. What I did was copy one variable section and manually entered the definition for my core doctype field:

{
  "allow_on_submit": 0,
  "bold": 0,
  "collapsible": 0,
  "collapsible_depends_on": null,
  "columns": 0,
  "default": null,
  "depends_on": null,
  "description": null,
  "docstatus": 0,
  "doctype": "Custom Field",
  "dt": "User",
  "fetch_from": null,
  "fieldname": "section_signature_cost_center",
  "fieldtype": "Section Break",
  "hidden": 0,
  "ignore_user_permissions": 0,
  "ignore_xss_filter": 0,
  "in_global_search": 0,
  "in_list_view": 0,
  "in_standard_filter": 0,
  "insert_after": "mute_sounds",
  "label": "Signature and Cost Center",
  "modified": "2019-03-06 21:52:14.685977",
  "name": "User-section_signature_cost_center",
  "no_copy": 0,
  "options": "",
  "permlevel": 0,
  "precision": "",
  "print_hide": 0,
  "print_hide_if_no_value": 0,
  "print_width": null,
  "read_only": 0,
  "report_hide": 0,
  "reqd": 0,
  "search_index": 0,
  "translatable": 0,
  "unique": 0,
  "width": null
 },

I then saved the fixture file, checked in the changes and ran

$ bench migrate

This will load the changes in the database and you will have your customisation of a core doctype. Hope this helps.

3 Likes

Thank you, it was very helpful .