If someone deletes doctype and restores it back all customization are
lost, there's no "real" reason to delete all these customization. They
are only ever active if the doctype is being used.
Explanations:
- Custom field: is used by meta when doctype meta is requested, if meta
isn't requested then custom field is effectively inactive.
- Client script: loaded by meta when doctype is requested by desk. So
inactive in deleted state.
- Property setter: loaded by meta, so inactive when doctype isn't
present.
- Report: will break doctype isn't present, but user should delete them
manually to avoid loss of "scripts" or anything special they might
have done. Also report's doctype don't 100% indicate that it's based
solely on that doctype.
* feat: utility methods for docstatus
* refactor: use utility method for doctsatus
* refactor: enum for docstatus
* refactor: docstatus as property
* fix: set docstatus
* feat: docstatus extends int class
* test: docstatus of BaseDocument
* refactor: occurrences of docstatus
* fix: typo
* refactor: move docstatus to a separate file
* test: docstatus
* fix: sider
The license.txt file has been replaced with LICENSE for quite a while
now. INAL but it didn't seem accurate to say "hey, checkout license.txt
although there's no such file". Apart from this, there were
inconsistencies in the headers altogether...this change brings
consistency.
Use frappe.db.delete wherever possible. Get rid of all the frappe.db.sql ;)
This commit focuses on the pending modules that had relatively easier
DELETE statements.
* Remove six for PY2 compatability since our dependencies are not, PY2
is legacy.
* Removed usages of utils from future/past libraries since they are
deprecated. This includes 'from __future__ ...' and 'from past...'
statements.
* Removed compatibility imports for PY2, switched from six imports to
standard library imports.
* Removed utils code blocks that handle operations depending on PY2/3
versions.
* Removed 'from __future__ ...' lines from templates/code generators
* Used PY3 syntaxes in place of PY2 compatible blocks. eg: metaclass
link_name could potentially include an apostrophe and cause:
`"mysql.err.ProgrammingError: (1064, "You have an error in your SQL syntax; check the manual that corresponds to your MariaDB server version for the right syntax"`
Adjusted the query to parameterize it
