Dr. Bacon

Потому что ты программируешь методом тыка, надо перестать так делать и начать понимать смысл каждого действия.

Когда в модели views использую код " profile = request.user.profile_user"

потом что ты сделал ForeignKey, а у него может быть больше одной записи

Когда " profile = request.user.profile", то жалуется на юзера, который не имеет атрибут профиль.

при связи OneToOneField ее может и не быть, поэтому надо делать проверку на нее наличие, всё описано в доках

Когда использую " profile = request.user", то при попытке загрузить изображение в профиль оно не грузится.

потому что user тут не Profile, а User, у тебя же там нет никакого изображения. Кстати, зачем тебе в базе хранить пароль два раза? Кроме этого он вообще не так храниться

Почему бы тебе просто не добавить поле изображения в модель User?

Так тебе наверно Celery нужно? Ну или пишешь свои костыли, например, оформляешь свои хотелки через custom django-admin commands, которые и запускаешь в фоне.

потому что у forms.Form нет instance

1. всегда показывай полный traceback
2. а по какой причине ты делаешь в add request.user.id а не request.user (хотя вроде такое может и прокатывает, но лучше везде однообразно делать )?
PS с миграциями что-то делал? помню похожее было при не применении миграции.

https://docs.djangoproject.com/en/4.0/ref/forms/fi...

Т.к проблема чисто разработки, т.е можно решать топорно в лоб, пара вариантов что помню
1. тупо у вебсервера прописать заголовки, пример для nginx

add_header Access-Control-Allow-Origin * always;
add_header Access-Control-Allow-Methods GET,POST,PUT,PATCH,OPTIONS,DELETE always;

2. на front'е использовать прокси, чтобы сервер стал локальным, вроде вот этот подойдет https://github.com/chimurai/http-proxy-middleware

оптимальное ли здесь количество запросов в БД

а мы даже и не знаем сколько тут запросов, сколько они времени выполняются. Этот "скрипт который мигрирует данные", по описанию это редкая задача, можно не заморачиваться про оптимальность. Или у тебя с ним какие-то проблемы?

Например, ты смотришь один файл, а django другой. выполни manage.py dbshell и посмотри какие таблицы есть

как именно получен BASE_DIR? ну и если django с pathlib, то BASE_DIR / 'apps/xlsx/logic/template_sheet.xlsx'

Делал все в одной форме - получается баговано

да, нужна одна общая форма, только сделать не баговано. Ну и нет смысла делать два класса ProductList и ProductListFilter, можно всё в одном.

Что в итоге в p.likes.all, а то окажется что там только один like этого юзера или вообще пусто?

окей гугл "pip install offline", ладно ты это поставишь, а как пользоваться будешь? документация и гугл основные инструменты при разработки, я уже про обучении не говорю

но программист говорит что Джанга монолитная и исполнители получают доступ ко всему коду что не безопасно.

программист отмазывается, т.к. не умеет или боится работать еще с кем-то. Да Джанга монолитная, но проблема безопасности легко решается, да тем же stage сервером, только туда будет доступ у "дополнительных рук", главное чтобы все критичные доступы были вынесены из кода, "12 factor app" уже давно чуть ли не стандарт.

ЗЫ ну и "не умеет или боится" это нормально, все через это проходили, тут скорее всего уже нужны чисто организационные решения, "кнут - пряник" и т.п