Василий Банников

Название и тот факт, что он лежит в кэше браузера намекают, что он видимо может подменять сайт собой для кражи твоих данных.

Скрыть нельзя - только удалить. Ибо аккаунт считается как персональный

однако в CRUD-функциях будут разные SQL-запросы

Вынеси код со всеми CRUD-операциями в отдельный класс с интерфейсом. Передавай экземпляр этого класса в форму.

Сами формы можно в рантайме через рефлексию попробовать генерировать.

Создать 1 домен, но указать 10 префикстов типа .com/en, .com/ru и тд. Здесь я вижу плюс в том, что не нужно создавать много доменов. Но минус в том, что SEO будет хорошее только для того языка, какой язык имеется у главной страницы. И что-то мне подсказывает, что через поисковые системы меня другие страны не найдут...

Всё нормально индексируется и ищется - никакие дополнительные домены не нужны (и в некоторых случаях могут быть даже вредны, тк два разных домена = два разных сайта)
Главное чтобы корректно были расставлены метаданные на всех страницах.

Отображать юзерам содержимое исходя из ИП адреса пользователя.

Вот так вообще не надо делать. Но если у тебя всё ок с метаданными, то ты можешь по первому посещению нового клиента попробовать предложить ему нужный перевод.
Поисковым роботам предлагать такого не надо.

Как это сделано у ютуба например, или тиктока

У них так не сделано.

От опытных программистов хочу узнать: что делать дальше, куда и как развиваться, что попробовать.

1. Посмотри как у других оформлены проекты.
2. Посмотри на современные стандарты C# и попробуй обновить свой проект.
3. Смотри вакансии и изучай технологии, которые требуются.
4. Погугли, что изучают в вузах и поизучай фундаментальные вещи.

Самый главный навык, который тебе нужно получить, - это навык самостоятельного поиска информации, тк в реальном мире не факт, что у тебя рядом будет опытный ментор, который даст всё в разжеванном виде

Видимо метод __leaderboard, который обращается к таблице users был вызван до того, как был вызван метод on_ready.

Вот цитата из документации, в которой говорится, что не гарантируется, что этот метод будет вызван раньше всех:
https://discordpy.readthedocs.io/en/stable/api.htm...

This function is not guaranteed to be the first event called. Likewise, this function is not guaranteed to only be called once. This library implements reconnection logic and thus will end up calling this event whenever a RESUME request fails.

Как вариант решения - инициализируй базу данных до того как бот будет запущен.
Например объяви функцию prepare_database с вот таким кодом:

@client.event
async def on_ready():
    prepare_database()

    for guild in client.guilds:
        for member in guild.members:
            if cursor.execute(f"SELECT id FROM users WHERE id = {member.id}").fetchone() is None:
                cursor.execute(f"INSERT INTO users VALUES ('{member}', {member.id}, 0, 0, 1, {guild.id})")
            else:
                pass

    connection.commit()
    print('client connected')

def prepare_database():
    cursor.execute("""CREATE TABLE IF NOT EXISTS users (
 name TEXT,
 id INT,
 cash BIGINT,
 rep INT,
        lvl INT,
        server_id INT
    )""")

    cursor.execute("""CREATE TABLE IF NOT EXISTS shop (
        role_id INT,
        id INT,
        cost BIGINT
    )""")

И вызывай её перед запуском бота:

prepare_database()
client.run(settings['TOKEN'])

Укажи конкретный тип в public alert$ = new Subject()
Например public alert$ = new Subject<IAlert>()

Да, законно, но работать не будет.

Что есть справочник в ИС?

(В моём понимании. Моё понимание не совпадает с пониманием 1С)
Справочником, как правило, считают данные, которые не имеют бизнес-ценности сами по себе, редко добавляются новые записи, очень редко меняются уже занесённые - короче очень статичные.

Например справочником будет:
Список адресов по ФИАС.
Города и страны.
Единицы измерений.

И так далее.

Тоесть список клиентов, грузов, получателей и так далее - это не справочники. Это полноценные бизнес-данные.

Или предприятие чудит?

Я думаю, что так.

Смотрим на требование, которое вам дало руководство и попробуем его деконструировать:

В общем очень интересная тема. Как-то кто-то сказал (приказал), что справочники должны управляться отдельным доступом (АРМом). Всё бы ничего, но в ИС 50 АРМов и примерно 150 справочных модулей и некоторый диапазон АРМов должны иметь доступ к редактированию справочников (конкретно: клиенты, грузы, получатели, доверенности, доверенные лица, агенты ну и что-то и т.д.

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

Ваше первое и, очевидно, неподходящее решение - ограничить доступ к операциям со справочникам. Перевести их в readonly для каких-то групп пользователей и разрешить редактирование для других групп.

Вы уже правильно заметили, что в таком случае у вас поломаются бизнес-процессы и сотрудники не смогут выполнять свои обязанности.

Правильным решением будет:
1. Проанализировать бизнес-процесс и понять кто и какие действия вообще делает.
2. Изменить логику работы ИС так, чтобы она способствовала работе в рамках этого бизнес-процесса.

Дальше буду на примере условного магазина, в котором условные операторы оформляют заказы для клиентов, а условные менеджеры заносят товары в номенклатуру, а условные курьеры доставляют товар клиенту.
В отрыве от 1С.

Получается, у нас будут такие виды пользователей с их обязанностями и нуждами:

1. Оператор
- Заводит в систему заказ для клиента
- Читает номенклатуру товаров, чтобы можно было наполнить заказ товарами, которые нужны клиенту.
- Читает уже созданные заказы, чтобы сообщить клиенту статус его заказа
- Заводит новых клиентов при первом заказе

2. Менеджер
- Вводит в номенклатуру новые товары
- Выводит из номенклатуры товары, которые больше не продаются
- Читает номенклатуру, чтобы иметь возможность понять, что какой-то товар ещё не заведён, или что какой-то товар требуется вывести из оборота.

3. Курьер
- Читает адрес доставки и машино-места заказа, который ему назначен
- Сообщает, что этот заказ был доставлен
- Сообщает, что не удалось этот заказ доставить
- Сообщает, что клиент отказался от товара
- Сообщает, что клиент отказался от заказа целиком

И вот нужно ввести в ИС "процедуры" для всех эти операций и ограничивать доступ на уровне этих процедур.
Прямого доступа к данным не должно быть ни у кого.
(Иначе зачем вам 1С? Если вам допустим полный доступ к данным - вам достаточно будет табличек в условном google docs)

Раз в принципе сущетсует такое понятие как full stack разработчик - значит неправда, знания фронта после бэка не выветриваются.

А может быть и нет готового бесплатного решения?

Может быть.

Ибо:
1. Достаточно сложно формализовать подобные проверки на "хорошие манеры"
2. Они часто избыточны
3. А чтобы что? Какую проблему должен решать такой рейтинг?
4. И почему нельзя вручную модерировать? Зачем пытаться воспитывать людей, которые не понимают, если можно просто один раз дать бан