Error from Postgres:
ERROR: permission denied for schema public at character 14
Error from Frappe:
psql:/home/frappe/frappe-bench/apps/frappe/frappe/database/postgres/framework_postgres.sql:72: ERROR: permission denied for schema public
Error Causer:
Starting Postgres version >= 15, all users will have the `CREATE` permission revoked by default.
Fix:
Grant relevant privileges to the database in question for the user. In this case, DB owner privilege.
Note: the below two permission attempts were unsuccessful and still caused the same public schema permission error
GRANT USAGE, CREATE ON SCHEMA public TO {frappe.conf.db_name};
GRANT ALL ON SCHEMA public TO {frappe.conf.db_name}
References:
https://stackoverflow.com/questions/74110708/postgres-15-permission-denied-for-schema-publichttps://stackoverflow.com/questions/67276391/why-am-i-getting-a-permission-denied-error-for-schema-public-on-pgadmin-4
The database resource management including privileges granting can be
done by external secops. It can be undesirable to grant the grant option
to the framework user.
This commit implements the possibility to remove user resource
management from frappe entirely and only boostrap the database with its
target user.
* fix: procure db config from single authority
ensures that configuration is uniformely procured from local.conf
instead of making use of hard to audit multilevel fallback logic
Implementation Note:
- `get_db(host, port, user, password)` was stripped of any optional
argument and therefrom all errors where fixed.
- All occurances of `grep 'frappe.db.db_'` where changed to
`frappe.conf.db_`
* fix: revert unnecessary breaking changes
This avoids having to manipulate config files in brittle bash
entrypoints that need to react to dynamic service discovery.
This significantly improves the operability of various bench sites.
This has never worked since 2016... which can mean two things:
- No one really uses this.
- If I fix this now suddenly people will find different behaviour in
naming because `name_case` is selected in some doctypes (but never
tested)
db.default_port wil be available as a class attribute to hold defaults
for DB types.
Usage: frappe.conf.db_port or frappe.db.default_port
Why: I couldn't run the mariadb command because the defaults aren't set
for my system. server is remote / containerized. Setting port in
equivalent mysql command fixes this.
### BREAKING CHANGE
#### Datetime, Date and Time fields will always be cast to respective objects in `setattr`, this will ensure uniformity while accessing the values, no more `getdate`, `get_datetime`, `to_timedelta` wrapper.
- While importing data, the framework does check for `set_only_once`.
- In normal case scenarios, this will work flawlessly since most date fields might not be set_only_once.
- But in Subscription, the date field is set to `set_only_once` and in `after_insert`, `document.save` is called, and while doing so, `set_only_once` is checked [here](1944a547f9/frappe/model/document.py (L566)).
-This works fine if the data imported is in the correct format.
- If the date's data is not in the correct format, the framework throws an error.
- for eg `06-02-2022 00:00:00 != 06-02-2022`
- fixes [Issue/#15370](https://github.com/frappe/frappe/issues/15370)
> no-docs
