lightmatter / django-hydra Goto Github PK

Right now it's all inside the repo

Reporting something interesting that blocks the template execution when run on Debian Linux with a fresh Postgres installation.

This report is essentially the inverse of this StackOverflow.

I appears as though one of the (reasonable) assumptions made by the setup_database.sh script is that the user executing the template can, out of the box, create a role via psql.

On Debian, the pre-installed roles and databases are postgres.

postgres=# \du
                                   List of roles
 Role name |                         Attributes                         | Member of 
-----------+------------------------------------------------------------+-----------
 postgres  | Superuser, Create role, Create DB, Replication, Bypass RLS | {}

postgres=# \l
                              List of databases
   Name    |  Owner   | Encoding | Collate |  Ctype  |   Access privileges   
-----------+----------+----------+---------+---------+-----------------------
 postgres  | postgres | UTF8     | C.UTF-8 | C.UTF-8 | 
 template0 | postgres | UTF8     | C.UTF-8 | C.UTF-8 | =c/postgres          +
           |          |          |         |         | postgres=CTc/postgres
 template1 | postgres | UTF8     | C.UTF-8 | C.UTF-8 | =c/postgres          +
           |          |          |         |         | postgres=CTc/postgres
(3 rows)

Not to belabor the report, but the current workaround is to su to user postgres, and add a role and database named after the user executing the template.

bibby=# \du
                                   List of roles
 Role name |                         Attributes                         | Member of 
-----------+------------------------------------------------------------+-----------
 bibby     | Superuser, Create role, Create DB                          | {}
 django-tpl| Superuser, Create DB                                       | {}
 postgres  | Superuser, Create role, Create DB, Replication, Bypass RLS | {}

bibby=# \l
                                  List of databases
   Name    |  Owner   | Encoding |   Collate   |    Ctype    |   Access privileges   
-----------+----------+----------+-------------+-------------+-----------------------
 bibby      | postgres   | UTF8     | en_US.UTF-8 | en_US.UTF-8 | 
 django-tpl | django-tpl | UTF8     | en_US.UTF-8 | en_US.UTF-8 | 
 postgres   | postgres   | UTF8     | en_US.UTF-8 | en_US.UTF-8 | 
 template0  | postgres   | UTF8     | en_US.UTF-8 | en_US.UTF-8 | =c/postgres          +
           |          |          |             |             | postgres=CTc/postgres
 template1 | postgres | UTF8     | en_US.UTF-8 | en_US.UTF-8 | =c/postgres          +
           |          |          |             |             | postgres=CTc/postgres
(5 rows)

There are likely several ways to resolve this cleanly, but I imagine an interruption to request privilege escalation (sudo) would be necessary at some point.

Consider making use of Vitest

Most of our shell scripts don't fail hard enough, we should probably set -o errexit for most, if not all of them.

fork existing library django-session-security to replace the html/js with jinja/alpine

Do a pass through the project and make sure everything is tested

I was thinking to convert a project with HTMX I started to this generator but I see that uses vite.
It isn't better to use a native python package in this way it is more simple for a django developer?

https://pypi.org/project/django-tailwind/

Should run a new test.sh on commit

psql (specifically /usr/bin/psql from a docker host) doesn't smoothly interact with a postgres container with the project database.

I'm creating this Issue to share a simple workaround: prepend setup_database.sh with a local override for psql that proxies to docker exec. When present, everything works as expected.

psql() {
    docker exec -it $DB_CONTAINER psql -U $DB_USER $DB_NAME "$@"
}

The above works with sidecar containers that are started in a similar fashion to those defined in this example docker-compose.yml

---

myproject-db:
  image: postgres
  container_name: myproject-db
  environment:
    POSTGRES_DB: $DB_NAME
    POSTGRES_PASSWORD: $DB_PASSWORD
    POSTGRES_USER: $DB_USER
    PGDATA: /var/lib/postgresql/data/pgdata
  volumes:
    - /opt/volumes/myproject/db:/var/lib/postgresql/data/pgdata
  ports:
    - 5432:5432

myproject-redis:
  image: redis
  container_name: myproject-redis
  ports:
    - 6379:6379

Check on https://github.com/MousaZeidBaker/poetryup it was archived on december 2022

New repo: https://github.com/MousaZeidBaker/poetry-plugin-up

When a password field is displayed in Django admin, show/hide doesn't work, and the show/hide icons aren't displayed correctly.

The show/hide eye icons do nothing when clicked, and text in the password field is always shown.

Source

https://github.com/Lightmatter/generic-django-conf/blob/develop/%7B%7Bcookiecutter.repo_name%7D%7D/%7B%7Bcookiecutter.repo_name%7D%7D/templates/django/forms/widgets/password.html

Screenshot

Fields that are defined as a ForeignKey get a dropdown in django admin and TomSelect is taking over currently. The dropdown box is getting cut off due to a couple of overflow hiddens.
I got around this by just using autocomplete_fields to leverage select2 which ships with django by default. IMO we should turn tom select off for django admin entirely.

It may be helpful to create an autosave primitive for forms.
This could potentially save to the DB or possibly even localstorage. This would be especially helpful if chaining forms (such as while using a formwizard), and allow a user to come back to a form with values already prefilled.

Things to think about:
If we do decide to use a DB for this, how would we generate a UUID to lookup responses? How would cleanup be implemented
Alternatively, if using localstorage (preferred IMO), do we want to invalidate the entry after a certain time?