Generic Doctype Update/Insert/Delete hooks

Hi Team :slight_smile:

I am researching what I need to do to build an address normalization app for erpnext.

My current plan is to either use current hooks or create new ones for doctype create/update/delete procedures in base_document so that I may execute normalization tasks when an specific doctype is created or modified.

I am wondering if there are any hooks I’ve might have missed which already do this before I go and create new hooks.

I am thinking generic hooks at the base_document level would be best as it would also allow for other doctypes to be hookable at create/update/insert time.

If these hooks are available I could watch for those create/update/delete events for the Address doctype, process it through a normalization service either realtime or a as task.

Any thoughts?

The best way to implement this would be to extend the Address DocType and add the validations in the product itself.

Maybe add an Address Settings where you can set validation for various fields.

@rmehta Ah, I though you could only extend doctype through custom form, I didn’t realize you could extend an existing doctype class.

I did just find a post someone asked a similar question and you gave them this link: https://github.com/frappe/shopping_cart/blob/develop/shopping_cart/hooks.py#L20

Actually, that is probably exactly what I need.

Going to experiment a bit and see how it works out.

Cheers! Thanks!

What I meant was that if you are making changes to a core doctype like address, it should be contributed back to the product (else you always run the risk of fixes getting overritten!)

Ah, understood

I’ve been looking at gisgraphy server as well as usps and fedex(for usa) address verification services. I am now thinking maybe the better approach would be to override the Address doctype form “Save” button to fetch matching addresses with these services and present the user with the address options. There has to be user interaction to select the right address if there are multiple matches.

I am thinking updating the Address form(frontend and backend) to allow for this behaviour is the cleaner approach than modifying the core Address doctype. Do you think this kind of contribution is the way to go?

I would have to spec it out and think about how to allow third party apps to provide address normalization services as an api. I would be happy to work on this.

What do you think?