Alter any code that does not allow for Redis to be accessed remotely, using only a Docker container.

During installation of ERPNext, certain code depends on the MySQL client being installed. For example:

../frappe-bench/apps/frappe/frappe/database/db_manager.py
Static Method restore_database

There appear to only be a few additional cases where this happens.

• Does it make sense for a server to have client software installed?
• Can this not be handled by the python-sql library?
• Maybe it does make sense for the MariaDB Client to be installed on the server, so that SysAdmins can perform backup, restore, and other maintenance...

...but maybe ERPNext using that client doesn't make sense, when it has its own library.

This is possibly related to ERPNext needing an ORM in the future.

ERPNext is leveraging a python library: pytz

We could try using Pendulum instead. It's a drop-in replacement for the standard date-time class. It behaves exactly like it but with many improvements:

https://pendulum.eustace.io/faq/#why-not-arrow

I've had several problems with Email Domains and Account setup.

• Inconsistent results. On the Email Domains doc type, changing port from 587 to 465 fails repeatedly. But then I restart Bench...and then my change is accepted. Until I try to make a second edit. Then it fails again.
• I'm unable to send an email, regardless of my settings. I have tried different ports. With/without TLS. Nothing makes a difference.
• I have found a situation where ERPNext fails to accept changes to an Email Account. But does not rollback the uncommitted SQL Transaction. You have to restart Bench to release the lock on the table.

1. Create tests in Python, that use SQL table data to send emails. Take the Web App out of the picture.
2. Allow saving on Email Domains and Email Accounts, regardless of results of email validation.
3. Add new Boolean field to DocType, "Email is Validated".
4. When fields are edited, automatically change to "No".
5. Add new button that performs validation, shows meaningful results, and then flips the boolean to "Yes" if everything is successful.
6. Add button "Send Test Email' to the DocType.

Spaces in table and column names is a very bad practice.

1. Modify the DocType create/edit code. Make sure it's impossible (going forward) to create DocType tables/columns with spaces inside. Either remove spaces (shorten the name). Or substitute underscore. Instead of choose one or the other, maybe give the DocType developer the option. (enter your preferred table/column name)
2. SQL script to rename all the existing tables.
3. Find/replace all the code that references the names with spaces, and make better names.

The current time-zone drop down is very confusing, has duplicates, and generally sucks.

Drupal had a nice, clean one.

• Continent
  • cities alphabetically
• Continent
  • cities alphabetically

If it doesn't exist already, let's get a SQL table with time zone codes, continent, country, UTC offset, etc. Then pull from that.

Command to synchronize the MariaDB database schema (tables, columns), with the values that Frappe believes "should" exist, based on the JSON definitions.

A good solution would warn about:

1. Tables that will be dropped.
2. Columns that will be dropped.
3. Columns that will be truncated.
4. Columns where the data type has changed (i.e. float to string).

This could be handled similar to a git merge or commit. A text file is created, containing a list of all the proposed changes. You have the option to comment-out or delete lines you don't want. This also gives you an opportunity to stop. Backup your database/tables. And then continue.

When this "New Updates are Available" screen pops up, be sure to indicate the current versions you are using.

Also, let's make sure we can disable this message using a Configuration File (TOML)

Requirement: Every database row should have a unique reference number.

• Does it need to be globally unique? No.
• Some programming languages such as Javascript cannot support numbers with > 53-bits
• Does it need to be a UUID (128bit number)? Not necessarily.

Hugely useful when you want to have a Reference column, pointing at another column in a table.

On Child tables, SQL column 'idx' is not unique per parent.
Because of the way the JS is coded, it cannot be. When you 'Move', it updates all the 'idx' values in the client. And then tries to update them in SQL. For a fraction of a second, things will be duplicated because of the re-sorting.

The solution is to NULL the 'idx' values for update.

• See if there's a way to enable/disable through Configuration, instead of obscure editing of site configs and Procfile.
• See if there's a way to have 1 Procfile for "production" mode and "development" mode.
• Refer to Development mode as "Developer" Mode.