[Feature] Standardizing Customization: A Look into ERPNext 15 Beta's New Feature

ERPNext
1

Standardizing Customization: A Look into ERPNext 15 Beta’s New Feature

ERPNext has always been a popular choice for businesses seeking a comprehensive and customizable ERP solution. With the introduction of ERPNext 15 beta, a new customization feature has caught the attention of both developers and business users alike. This feature promises to revolutionize the way we approach customizations, making them more standardized and efficient than ever before.

Introducing the Custom_* Field Naming Convention

One of the highlights of ERPNext 15 beta is the new field naming convention for customizations. When you customize an existing doctype, any new field you add will now be prefixed with custom_, followed by the field name you provide. This might seem like a small change, but its implications are significant.

Benefits of the Custom_* Convention

  1. Standardization: The custom_ prefix ensures that all custom fields are immediately distinguishable from the original fields. This not only improves clarity but also standardizes the customization process across the board.

  2. Avoiding Duplication: In previous versions, users often faced challenges when updating ERPNext or Frappe due to conflicts with custom fields. The custom_* convention elegantly solves this issue by preventing custom fields from accidentally matching with new fields introduced in updates.

Streamlined Editing and Preview

ERPNext 15 beta goes a step further by enhancing the editing experience. The updates are designed to provide users with more control and a better understanding of the changes they’re making.

  1. Real-Time Previews: When you’re customizing a doctype, the system now provides a real-time preview of how the changes will appear. This eliminates the guesswork and allows you to fine-tune your customizations.

  2. In-Context Help: Each customization option comes with contextual help, ensuring that you know exactly what you’re modifying. This makes the customization process more user-friendly, even for those who might not be seasoned developers.

Leveraging the Power of Customization

With the new customization feature in ERPNext 15 beta, businesses can take full advantage of the customization potential without worrying about compatibility issues. The custom_ field naming convention aligns with best practices, enhancing collaboration between developers and business users. As a result, the ERPNext ecosystem becomes more cohesive and future-ready.

Conclusion

ERPNext 15 beta’s customization feature, with its custom_* field naming convention, marks a significant step forward in streamlining customizations and improving compatibility. This feature empowers businesses to harness the full potential of ERPNext’s customization capabilities while maintaining consistency and avoiding pitfalls during updates.

If you’re keen on staying ahead in the ERP game, exploring ERPNext 15 beta’s new customization feature is a must. Get ready to elevate your ERP experience with standardized customizations that empower your business to grow and adapt seamlessly.

Contact

Github : Antony-M1 · GitHub
Linkedin : Antony

9 Likes
2

@Antony_Praveenkumar Nice work. Quick question though: How does this affect existing customisations? will this change automatically apply to existing custom fields or are user actions required to migrate their existing custom fields to become compliant with V15 Beta’s requirement or will this be done automatically?

2 Likes
3

As per my understanding, it leaves the existing custom fields as it is. when you create a new feature through the UI editor that time it will automatically name converted.

4

That’s really a great thing to have custom fields clearly separated from standard fields. Not converting old custom fields seems likely to leave existing customizations in a messy state. If no conversion is done, maybe a description how to manually convert existing custom fields would be great. Also then a check if the database scheme is in line with the default scheme would be a great thing.
Right now it is quite difficult to determine whether the database structure is correct. A test that outputs the differences from standard database structure compared to the structure in place would be something great to check if the system is healthy.

1 Like
5

I can understood. but changing the previouse custome field in databse that will affect your custom bussiness logics. If you customized morethan 100 fields and if you used that field in the code. if the database automatically convert the naming for that custom field is not good acctually.

6

If you take, say, 10000 installations x the number of hours of work needed to migrate to v15 x the value of a migration hour, there might be some number X which, if a fraction of it was given to a small group of experts writing free and easily usable code for an automatic migration, might help solve the problem for everybody.

On the other hand, said number X is equivalent to the total burden imposed on current (or rather: migrating) customers by this improvement,

or, said differently again, the total value of hypothetical business opportunity/ies for people/organizations offering their services to other people/organizations,

who can’t / won’t simply start over with v15 and/or re-enter their (hopefully documented) adaptations manually.

Technically, this doesn’t seem that easy indeed. You might need some kind of a combined python - SQL - JS lexer which can compare field names to the v14 naming baseline and output it’s tree(s) in the new v15 format. Devs with compiler building experience might find this to be an interesting and not all too cumbersome task.

Once such an overall site tree is built, it might also serve to compile a whole site to, say, C, or JS, maybe Rust, etc. (or some combination of it as per executing node, e.g. Server vs. Browser), which could have other benefits not to discount too quickly.

1 Like