Модераторы и правка статей

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

Модераторы

Казалось бы, самым очевидным способом раздать пользователям права является джанговская встроенная система прав. Однако я не стал ее использовать, потому что она представляет собой типичную ACL-систему, и предназначена в первую очередь для работы в связке с админкой. Как любая ACL она отличается универсальностью и простотой в управлении, но при этом некоторой негибкостью. Чтобы не вдаваться в теоретические размышления вот пример: как, имея в наличии модель статьи и стандартные операции add/change/delete, представить понятие "модератор может увеличивать рейтинг статьи на 10 единиц, в то время как обычный юзер — только на 1"?

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

class Profile(models.Model):
  # ...
  moderator = models.BooleanField(default=False)

Заодно теперь в профилях пользователей показывается, какие у них есть специальные права. Хотя множественное число пока не актуально, потому что я там пока единственный модератор и админ :-).

Для управления же правами никакого отдельного интерфейса делать не понадобилось: с этим прекрасно справилась джанговская админка. Несколько опций:

class Profile(models.Model):
  # ...

  class Admin:
    list_display = ('user', 'openid', 'name', 'moderator')
    list_filter = ('moderator',)
    search_fields = ('openid', 'name', 'user__username')

... и готов красивый и функциональный интерфейс:

Редактирование статей

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

Реализация состояла из трех мелких этапов:

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

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

class Profile(models.Model):
  # ...
  def can_edit(self, article):
    return self.moderator or article.author_id == self.user_id

Этот дополнительный уровень абстракции кажется мне полезным, потому что иначе детальную логику "если модератор или автор" нужно было бы дублировать минимум в двух разных местах — при показе ссылки в шаблоне и при проверке доступа во вьюхе. А потом еще и синхронно менять, если понятие "может редактировать" как-то изменится.

Следующий шаг — выставить эту функциональность в шаблон, чтобы рядом со статьями, которые пользователь может редактировать, рисовать соответствующую ссылку. В Джанго, как известно, нельзя в шаблонах свободно вызывать функции с аргументами, поэтому прямо вот так сделать не получится:

{% if profile.can_edit:"article" %}

Поэтому в таких случаях обычно делается свой if-подобный тег, который в шаблоне будет выглядеть так:

{% ifcanedit profile article %}
<a href="...">Редактировать</a>
{% endifcanedit %}

Реализацию пожалуй приведу целиком, потому что это довольно часто встречающаяся задачка.

class IfCanEditNode(template.Node):
  def __init__(self, profile_expr, article_expr, node_list):
    self.profile_expr, self.article_expr, self.node_list = profile_expr, article_expr, node_list

  def render(self, context):
    profile = self.profile_expr.resolve(context)
    article = self.article_expr.resolve(context)
    if profile and profile.can_edit(article):
      return self.node_list.render(context)
    return ''

@register.tag
def ifcanedit(parser, token):
  '''
  Выводит содержимое блока только в том случае, если пользователь
  имеет право редактироват статью
  '''
  bits = token.contents.split()
  if len(bits) != 3:
    raise template.TemplateSyntaxError, '"%s" принимает 2 параметра: профиль и статью' % bits[0]
  node_list = parser.parse('end' + bits[0])
  parser.delete_first_token()
  return IfCanEditNode(parser.compile_filter(bits[1]), parser.compile_filter(bits[2]), node_list)

Выглядит это довольно лохмато, хотя смысл простой:

1. принять из шаблона параметры и внутренности тега
2. в "render" вызвать с параметрами готовую функцию
3. в зависимости от результата либо рисовать, либо не рисовать содержимое

Самая запутанная и тупая часть — это функция тега "ifcanedit", которая вынимает из парсера шаблона параметры, ищет конец тега, а также запоминает внутреннее содержимое. Я ее никогда не пытаюсь воспроизвести на память, просто копирую из других проектов и адаптирую немножко :-).

Джеймс Беннетт (релиз-менеджер Джанго) даже как-то озвучивал идею, что неплохо бы завернуть все это в регистрирующий декоратор наподобие simple_tag и inclusion_tag, но пока, видимо, руки не дошли. Поэтому если кто возьмется, то у него есть неплохой шанс вписать себя в историю Джанго :-)

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

Добавлю только, что во view, которая обрабатывает пост из формы, обязательно нужно еще раз сделать проверку на право редактирования, потому что одного скрытия ссылок на формы недостаточно: данные в приложение могут прийти откуда угодно и от кого угодно.