I am working on a custom integration that imports sales orders that already have a number. But I can’t figure out how to name it before it is automatically named.
if use standard data import, simply fill the the number into ID field, the ID field has highest priority which will prevent autoname by naming series.
if create sales order via api, you can create before_insert server script with code like below
doc.name = f"{number}"
doc.flags.name_set = True
2 Likes
Thank you. That
doc.flags.name_set = True
was all I neded
1 Like
What is “flags” used for?
I guess that it transports dynamic properties of a document. How and where are they used (communicated from where to where)?
The plural suggests that there are more or many flags.
“name_set” means “set it next time”, or “is already set”, but where resp. how?
Is there a documentation link for these mechanisms?
doc.flags is for internal use, I simply followed the standard autonaming mechanism bypass autonaming by setting this flag.
1 Like
From a technical standpoint, flags can be used to store non-field parameters or data across lifecycle events. They’re useful for directing validation methods to behave in certain ways, like shown here. They’re never persisted anywhere outside the runtime memory.
They’re not specified by the framework and likewise not really documented, though several are used by core document methods. The most common ones I’m aware of are ignore_permissions, ignore_mandatory, and ignore_links. Use with caution!
1 Like
It’s not exactly easy juggling different DB normalizations anyway, and FF has its opinionated opinions of best practices to (re)build “foreign keys” and similar normalization artifacts, and particularly nasty ways of not easily importing addresses of such extremely rarely used business objects like customers and suppliers, e.g. when wanting to get rid of excel sheets with such data, which the framework is supposed to excel in.
So your “Use with caution!” naturally is justified, and another aka of “read lots of code” before confidently doing the simple thing to make life easier, at last.
Which these flags can help getting accomplished more easily – at last.
Sigh.
I love the creativity, though, and the people making this whole thing happen.
It’s funny in a way, that I finish saying such a thing, isn’t it?
But seeing people doing what they want for their reasons which are not always clear has something very enlightening and really loveable about it.
I guess this is because too many people in these times just go with the herd and do what they are told. This, here, is something entirely different, and thus refreshing and educating about diversity of approaches and people living in freedom, just near you, you can almost touch it.
Love you all!
If anyone wants to know more about how exactly naming and the flag name_set (and other flags) are working, look into these files:
~/frappe/bench/apps/frappe/frappe/model$ grep -R "flags.name_set" *
document.py: if self.flags.name_set and not force:
document.py: self.flags.name_set = True
document.py: self.flags.name_set = True
and:
~/frappe/bench/apps/frappe/frappe/model$ grep -R "set_new_name" *
base_document.py:from frappe.model.naming import set_new_name
base_document.py: set_new_name(self)
document.py:from frappe.model.naming import set_new_name, validate_name
document.py: self.set_new_name(set_name=set_name, set_child_names=set_child_names)
document.py: def set_new_name(self, force=False, set_name=None, set_child_names=True):
document.py: """Calls `frappe.naming.set_new_name` for parent and child docs."""
document.py: set_new_name(self)
document.py: set_new_name(d)
document.py: set_new_name(d)
naming.py:def set_new_name(doc):
Many things will become clear(er).
isn’t using autoname controller hook simpler?
1 Like
I guess that autoname hook would be good for the case when it’s a general rule for naming. But if I am building an integration where I am pulling document name from other service the flags seams simpler.