[UserKarma] Версия 1.0.0

Почему бы не сделать плагин на OnUserSave?

Тогда обработка кармы будет запускаться при любом сохранении modUser, хоть через интерфейс, хоть через API.

У компонента действительно большая область применения, от смены групп покупателей до реализации игрового интерфейса!

Если не возражаете, выскажусь по поводу видения данного дополнения и метода его работы в целом:

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

Соответственно, потенциальный список разделения (в большинстве проектов) выглядит так:
— Админинстратор (управление всем)
— Модератор (управление другими пользователями)
— Публицист/Контенщик/Менеджер (управляет определенными страницами сайта)
— Премированная группа пользователей (доступ к определенным «закрытым» ресурсам)
— Пользователь (минимальный уровень персонализации)

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

Динамичное же изменение «статуса» пользователя в зависимости от его рейтинга/потраченной суммы денег, относится скорее к понятию «подгруппа» и, за исключением применения в конкретных сниппетах, не имеет «глобальной» уникальности, присущей группам пользователей в понятии modx'a.

Пример подгрупп:
Статусы «форумного рейтинга»: Новичок, Ветеран, Бывалый, Старожил, Наумкин
Статусы «покупателя»: Покупатель, Активный покупатель, Суперактивный покупатель, 50% прибыли компании

К чему все это:

Если отталкиваться от возможности переключения именно групп пользователей, то правильнее было бы напорядок расширить понятие «кармы», внеся возможности вписывать произвольные условия, не ограничиваясь числовым показателем.
Например: заполнив все требуемые поля профиля, пользователь переходит в более «провинутую группу». Или просуществовав на сайте Х лет, к примеру.

В противном случае, создавать под каждую «рейтинговую» группу полноценную группу modx'a воспринимается излишне громоздко и, на мой взгляд, для такой задачи вполне достаточно ограничиться одним доп. полем для пользователя, где будет записываться «подгруппа».

Это круто! Я серьезно)) Я видел соответствующие плагины на xenforo и vanilla. У нас их часто называют дополнениями «геймификации», заграничные друзья — «бейджами». Суть в том, что при выполнении определенных условий, пользователя будут награждать некой «медалькой» (изменением оформления, приветствием с пением гимна и т.п.) и/или расширением прав на ресурсе (постить новые темы форума, проводить опросу, и сюда же я отношу и скидки). Как написал чуть выше Максим, если говорить о широте применения, то это часто конкретные вещи, которые весьма распространены и(!) пользуются большим спросом. Проблема, как всегда, в уровне знаний))

То есть, для «не программистов» этот компонент будет не очень полезен, так? Как человек далекий от join, get, OnSave и API в целом, могу сказать: первое, что бросается в глаза — привязка userkarma к конкретному показателю. Для меня это темный лес, ей богу)) Но об этом чуть позже. Николай, фактически я — твоя целевая аудитория и поэтому как человек, который ХОЧЕТ такой функционал, но не может допиливать его сам хочу указать на моменты, которые могут превратить этот компонент из потенциальной конфетки в очень популярный плагин.

Чтобы избежать ненужной демагогии и препирательств хочу указать сразу — Да, можно нанять программиста, который на основе компонента реализует что-то конкретно под мои условия. К тому же, насколько я понял идею Wassi Wassinen, он рассчитывал, что различные расширения к компоненту будут появляться как сейчас дополнения к miniShop2 — все как бы и не нужны, потому каждый добавляет на свой ресурс конкретные модули (плагины). Но! Если компонент не применим для меня как для рядового пользователя именно из коробки, то я трижды подумаю стоит ли его покупать.

Какой-то функционал из коробки для рядовых пользователей обязан быть! Иначе все полетит в трубу, а это в свою очередь означает прекращение развития компонента, чего очень бы не хотелось. В конкретно нашем случае привязка к рейтингу Тикетс — то, что доктор прописал)) Во-первых, рейтинг там уже сам рассчитывается, во-вторых, теперь, когда мы уже разобрались, что на Тикетс можно замутить нативный, шустрый и красивый форум для modx, вопрос перевода пользователей по группам в зависимости от рейтинга становится весьма остро. Чем шире аудитория клиентов, тем больше популярность (доход от продаж), поэтому я очень рекомендую это сделать.

Дальше… Сейчас я начну говорить вещи, которые отчасти можно отнести к программированию, но при этом сам я не программер, что значительно увеличивает шанс написания некой глупости по незнанию «очевидных» вещей. Поэтому, если что пусть кто-нибудь поправит, ок?

Я вижу главную проблему компонента, из-за которой вероятно придется создавать UserKarma2. «Многопоточность», если можно так выразиться)) Проще говоря, одна линейка «кармы» изначально ущербна. Возможно, в компоненте реализована возможность создавать параллельную, но я этого в статье не увидел. Как уже сказал Максим, разумно говорить о подгруппах. Мы прекрасно понимаем, что для modx это такая же группа, но функционально «кармические» группы используются для совершенно иных целей. И если мне понадобиться учитывать раздавать скидки для покупателей магазина (а мне понадобится) и одновременно переводить пользователей из группы в группу на форуме (не смотря на то, что это кажется какой-то ерундой, вовлеченность увеличивается, что сугубо положительно влияет на ресурс), то как быть?

Ограничение по «группам». Не просто так были упомянуты «бейджи». Суть в том, что при достижении некого количества «кармы», пользователю присваивается некая «медалька», общий список которых выводится сниппетом. Тут все до омерзения просто это даже мне понятно: создается таблица со списком медалек, как только условие выполнилось, ставим 1, и конкретный бейджик выводится сниппетом. В сущности, это будет разумно сделать отдельным компонентом и выложить в репозиторий как расширение UserKarma(2?). Почему я об этом заговорил, хотя к делу это вроде как не совсем относится? С радостью поясню))

Вот эти медальки-бейджики — классический пример расширения под «идеальный» UserKarma. Скидки покупателям в магазине? Дзинь! Еще один компонент. Нужно, это просто к примеру, чтобы карма изменялась в зависимости от того, сколько пользователь предложил новостей на СМИ-портал (по аналогии с предложением постов в группу ВК)? Дзинь! Еще один компонент=) Работа с календарем и датами появления пользователей на ресурсе, частота, длительность перерыва и т.д. — еще один компонент-надстройка. Думаю, все предельно понятно. Ах да, Дзинь! =) Эти дзинь это капающие денежки, если что ;)

А теперь перейдем к адовой (на первый взгляд) части. Как это все увязать? Правильно, нужно общее ядро, которое сделает так, что надстройки не будут конфликтовать и при этом все будет предельно понятно рядовому пользователю, иначе компонент пролетит как фанера над Парижем. Никто не станет брать дополнение, в котором на каждый чих нужно звать программиста (я знаю, что повторяюсь, но, Николай, у тебя есть такой пунктик. Нужно ближе к народу быть). Итак, как это сделать? Очень просто на самом деле ;)

Мне, как конечному пользователю, нужен интерфейс в котором я смогу создать «линейку кармы» и затем настроить ее. Последнее подразумевает, что будет возможность выбрать условия для «конкретного действия» при наступлении конкретных условий. Я акцентирую внимание еще раз — именно «условий», во множественном числе.

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

Берем конкретный пример (сейчас будет та самая адовость). Я хочу перевести пользователя в группу «Скидка 10%», если он а) вошел в группу «доверенные» на форуме (часть карма-форума), б) вошел в группу «купил товаров на 100 000» (надстройка для карма-магазина), в) сегодня вторник и пользователь онлайн/оффлайн (надстройка карма-календарь).

Либо! Удалить пользователя из группы «Скидка 10%», если он: а) заработал получил медаль «Тролль» (на форуме получены 100 минусов, знаю, что тикетс это не считает, но кто-то однажды может сделать плагин для допподсчетов, тут был бы спрос. К примеру, мне этот функционал реализует нанятый программист) б) отсутствует на ресурсе более 6 месяцев (карма-календарь).

При этом у каждого условия и действия могут быть свои типы значений, что подразумевает появление своих особенных полей для каждого из них при выборе. Предусмотреть все действия нельзя, так? Но вот тут и появляются надстройки! Родительский компонент должен свободно работать с полями дополнений и обеспечивать работу со значениями параллельных линеек (было бы очень хорошо, если бы он изначально понимал все группы modx. Конечно, нужна защита от дурака, чтобы пользователь не ставил взаимоисключающих условий приписывать к условиям одной линейки одинаковую цифру (не обязательно пользователь должен выводится из одной группы и помещаться в другую — если! конечному юзеру компонента это нужно, то он указывает условие «форум-карма» значение=«40» действие: 1) добавить в группу «проверенный» 2) удалить из группы «новобранец».

Именно так, чтобы линейка формировалась самостоятельно! Чтобы была расширяемость сторонняя и стандартизированная хоть немного! Только тогда это будет по-настоящему популярное дополнение. В этом случае очередь за компонентом выстроится огромная)) И что на мой взгляд немаловажно, в таком варианте мы получаем приложение в духе modx — свобода творчества! Николай, не нужно делать расширения только для программистов, так и денег будет сложно заработать)) Кстати, на счет последних, я понимаю, что работы тут нормальная кучка, но при этом было бы круто сделать «материнскую основу» свободно распространяемой. Возможно имеет смысл замутить краудфандинговый сбор (сам похвастаться большим количеством свободных средств не могу, но толпой, думаю, осилим). Это ускорит распространение компонента и соответственно простимулирует создание небольших платных надстроек)) Вроде бы опыт MiniShop2 достаточно положителен как пример?

Короче, я свое видение универсализации показал, нужны будут уточнения с точки зрения «конечного пользователя», всегда готов))

Николай с командой решили захватить мир:)))
Хоть мне выложенные на данный момент компоненты пока, вроде бы, и не нужны, всё равно большое спасибо за вклад в развитие!

полезно, дайте 2 )

Здравствуйте, Николай, не подскажете как вы «вклинили» в стандартную таблицу юзера свои поля(мне нужно стандартное вывести zip, но очень интересно как кастомное)?
p.s. я понимаю, что там должен быть плагин на событие загрузки страницы. Но интересует код, не могу найти конкретно для моего случая… (Видел раньше где-то тут был вопрос похожий, но его не нашел).
p.s.s ну и чтобы поиск работал :) Да я не сильний в extJs, но пытаюсь изучать

Может быть все же внедрить функционал перевода из группы в группу плагинами на определенные количественно-качественные показатели, как я предлагал раньше? Объясню, почему я это предлагаю. Вы бы могли сделать основу условно-бесплатной (Интерфейс групп и плагинов, которые к ним привязаны с одним плагином для ознакомления), а дополняющие плагины продавать по 100-200 рублей и закрывать максимально обширную аудиторию. Одним нужно переводить из группы в группу исходя из кол-ва комментариев и постов, а другим — в зависимости от рейтинга в определенном разделе и т.д. А так вы создали узконаправленный компонент, но он практически никому не нужен.

Заранее благодарен за ответ!