Currently if uncaught exception occurs on server side, there's no simple
way to find it out. Converting these console.log to console.error
simplifies this for UI tests.
Also converted `console.trace to` `console.error`; Both are practically same
and give stack trace too, `trace` expands tracebacks by default. This is
done to make spying on window.console.error easier.
When you create a Virtual DocType as a Child Table (which is possible without any warning), then it will lead to several errors when updating or deleting of the parent document.
This is because the following files just execute a SQL Statement for the doctype (which doesnt have a DB Table, as this is the nature of a virtual doctype ;-)
**apps/frappe/frappe/model/document.py**
```py
frappe.db.sql("""delete from `tab{0}` where parent=%s and parenttype=%s and parentfield=%s""".format(df.options), (self.name, self.doctype, fieldname))
```
**apps/frappe/frappe/model/delete_doc.py**
```py
frappe.db.sql(
"delete from `tab%s` where parenttype=%s and parent = %s" % (t, "%s", "%s"), (doctype, name)
)
```
So at these points, I added a check to not perform any sql command for virtual doctypes. With these changes, my affected situation is solved. Perhaps there are other situations, I didn't encounter yet.
As an additional feature, those virtual doctype models should also get an information about the parent is deleted, to propagate the deletion to the remote data pools; but for now I hope this bugfix can be approved.
This only affects OAuth clients that use `id_token` obtained from `frappe.integrations.oauth2.get_token`.
Doesn't affect OAuth clients that ignore id_token and explicitly use `frappe.integrations.oauth2.openid_profile` endpoint for getting user details. e.g. Frappe OAuth client.
A simple way to replicate this is to setup Frappe-Frappe OAuth client-server pair and use `login_via_oauth2_id_token` instead of `login_via_oauth2` in `login_via_frappe`.
This only affects OAuth clients that use `id_token` obtained from `frappe.integrations.oauth2.get_token`.
Doesn't affect OAuth clients that ignore id_token and explicitly use `frappe.integrations.oauth2.openid_profile` endpoint for getting user details. e.g. Frappe OAuth client.
A simple way to replicate this is to setup Frappe-Frappe OAuth client-server pair and use `login_via_oauth2_id_token` instead of `login_via_oauth2` in `login_via_frappe`.