@Mikkkch

Каким образом реализовать иерархию пользователей?

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

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

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

Интересует сама реализация(возможно миксин какой-то написать, в котором вся перечисленная логика будет наблюдаться). И интересует сам процесс фиксации того, что пользователь достиг какой-то планки.
  • Вопрос задан
  • 98 просмотров
Решения вопроса 1
@AstraVlad
Финансист, консультант, программист-любитель
Я бы танцевал от того, в какой момент меняется показатель, к которому привязан статус. Скажем, если это просмотры объявления, то в какой момент фиксируется +1 просмотр. В этом куске кода подняли просмотры на один, дернули из базы юзера-владельца и вызвали у него соответствующий метод, скажем check_and_update_status(), передав ссылку на объявление. И уже в этом методе отрабатываем проверку на повышение статуса.

Или для гибкости сделать функцию-диспетчер, подписать ее на кастомный сигнал view_count_increased, после увеличения числа просмотров посылать этот сигнал, а уже в диспетчере обращаться к юзеру. Это будет менее наглядно (и в документации так не советуют делать), зато более гибко, можно будет в любой момент отключить или изменить эту часть логики.

Это только то, что сходу пришло в голову, наверняка более опытные коллеги смогут подсказать лучше.
Ответ написан
Пригласить эксперта
Ответы на вопрос 1
@bacon
В момент проверки лимита, вызывать метод юзера (это если нет отдельного слоя под бизнес логику):
def get_limit_objects(self):
    if self.view_count >= 1000:
        return 4
    # условия для других лимитов
    return 3

ЗЫ я почти всегда, самое первое решение делаю самым простым, потому что обычно сразу не известны все условия и различные нюансы, усложнить всегда можно позже, по мере получения опыт работ с этим.
Ответ написан
Ваш ответ на вопрос

Войдите, чтобы написать ответ

Войти через центр авторизации
Похожие вопросы