[UserKarma] Версия 1.0.0

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

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



Далее все очень просто — на обновление пользователя навешен плагин, который в зависимости от кармы пользователя меняет его группы.

Объем компонента весьма не большой, но пришлось изрядно повозиться. Во-первых, хотелось сделать его максимально простым и удобным. Во-вторых, не мало тут и секурных вопросов (а удобство и безопасность мало совместимы), из-за чего пришлось много всего изучить оттестировать. Но на выходе получился компонент, который лично меня очень радует и есть подозрение, что сфера его применения очень обширна и он должен стать популярным :)

Итак, подробности… Для начала хочется отметить, что новое поле userkarma было добавлено непосредственно в таблицу modx_users. Для этого была использована вот эта технология (попутные темы раз, два и три). Данное поле автоматически создается в таблице, так что для его создания ничего дополнительно делать не требуется.

Внимание! Технология еще экспериментальная, так что не забывайте про бекапы сайта перед установкой пакета. Я протестировал на нескольких сайтах и вроде все ОК, но все же.
Если вдруг после установки у вас слетела сессия и не пускает в админку, 99% должно помочь ручное создание колонки userkarma int(11) в таблице modx_users (через phpMyAdmin или типа того).


Далее в озвученном выше интерфейсе создаем нужные нам правила. Для примера рассмотрим довольно распространенную ситуацию: в интернет-магазине созданы несколько групп пользователей, которые влияют на скидки, видимость остатков и т.п. (например, Новый клиент, Постоянный покупатель, Диллер). Для нас проще всего тут оттолкнуться от общей суммы всех совершенных покупок, например, купил на 10 000 рублей — достиг уровня Постоянный покупатель, купил на 100 000 — Дилер. Система разработана таким образом, чтобы учитывать и переходящие группы, и постоянные. То есть, в нашем случае мы создадим правило от 0 до 10 000 (Новый клиент), от 10 000 до 50 000 (Постоянный покупатель) и от 100 000 и без лимита (Диллер). Таким образом каждый новый клиент автоматом попадает в одну группу, затем при достижении нужного результата он выкидывается из одной группы и попадает в другую. Понятное дело, что он может и сразу попасть в Диллеры, если сразу оформит заказ на 100 к+.

Уточняю, что меняются только прописанные в правилах группы пользователей. Если пользователь добавлен в группы, для которых не созданы правила, на них не влияет карма пользователя.

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

1. Непосредственно воздействуя на объект пользователя.
$user = $modx->getObject('modUser', $user_id);
$user->userkarma += 10;
$user->save();
Это простейший вариант изменения кармы пользователя, но это не повлияет на участие пользователя в группах. Так мы только запишем новое значение кармы в базу данных, но изменение групп выполняется только в плагине (хотя если потом отредактировать пользователя на странице редактирования пользователей, группы ему все-таки сменятся).

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

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


Я немного вклинился в родной интерфейс управления пользователями, и теперь карму пользователей можно редактировать прямо в нем (на самой странице редактирования пользователя я не стал пока поле выводить). Вот здесь уже изменение кармы повлечет за собой изменение групп пользователя.

3. Через процессор.
Если говорить об API, то вызов обновление через процессор — самый правильный вариант. Во-первых, будут вызваны все необходимые события (в том числе и вызов всех плагинов). Во-вторых, мы получаем стандартизированный ответ, из которого мы можем понять успешно ли обновлен пользователь, на сколько у него изменилась карма, в какие группы он был добавлен, а из каких удален. Это нам позволит в том числе вывести различные сообщения пользователю в зависимости от изменений его объекта (к примеру «Поздравляем! Вы достигли нового уровня!»).

Вот пример вызова процессора (тут я не стал вычищать отладочные конструкции, может кому пригодится):
<?php 
print '<pre>';
ini_set('display_errors', 1);
$modx->switchContext('web');
$modx->setLogLevel(3);
$modx->setLogTarget('HTML');
 
$namespace = 'userkarma';        // Неймспейс комопонента

$params = array(  
    "id"    => 1,
    "userkarmaPoints"   => 10,
);

if(!$response = $modx->runProcessor('userkarma/security/user/updatekarma',
$params
, array(
'processors_path' => $modx->getObject('modNamespace', $namespace)->getCorePath().'processors/',
))){
print "Не удалось выполнить процессор";
return;
}

print_r($response->getResponse());
Примерно вот такой ответ можно получить:
Array
(
    [success] => 1
    [message] => 
    [total] => 0
    [errors] => Array
        (
        )

    [object] => Array
        (
            [id] => 1
            [username] => admin
            [password] => xxxxxxxxxxxxxxxx
            [cachepwd] => 
            [class_key] => modUser
            [active] => 1
            [remote_key] => 
            [remote_data] => 
            [hash_class] => hashing.modPBKDF2
            [salt] => xxxxxxxxxxx
            [primary_group] => 1
            [session_stale] => Array
                (
                    [0] => mgr
                    [1] => spravochniki
                    [2] => web
                )

            [sudo] => 1
            [userkarma] => 30
            [userkarmaPoints] => 10
            [email] => info@local.host
            [userkarma_excluded] => Array
                (
                    [8] => Array
                        (
                            [id] => 8
                            [name] => Менеджеры магазина
                            [description] => Для менеджеров, обрабатывающих заказы.
Имеет минимальные права. Видит только новые и свои заказы. Контактные данные заказчика видит только по своим заказам.
                            [parent] => 3
                            [rank] => 0
                            [dashboard] => 1
                        )

                )

        )

)
Здесь userkarma — это текущая карма пользователя (уже с новым значением).
userkarmaPoints — переданное значение изменения кармы. Это может быть как положительное, так и отрицательное число. Важно понимать, что это число, на которое изменится общее значение кармы. К примеру, карма была 1000, мы передали userkarmaPoints = -100, карма стала 900.
userkarma_excluded — массив данных групп пользователей, из которых пользователь был исключен. Он содержит значения только тогда, когда пользователь исключается из групп, а не всегда.
Такой же смысл и у массива userkarma_included, только это уже в какие группы пользователь был добавлен.

Обратите внимание, что вызывается не родной MODX-процессор security/user/update, а кастомный. На самом деле этот процессор расширяет родной и на логику никак не влияет (так как изменения все на уровне плагина выполняются), Но нужен был он по двум причинам. Во-первых, политики безопасности. Часто процессор будет выполняться от имени не привилегированных пользователей (а порой и от анонимов даже), и у них просто не будет прав на сохранение пользователей (что прописано в процессоре), поэтому в кастомном процессоре эта политика снята. Но по безопасности тут проблем нет, так как принимаются на вход только два параметра: id (пользователя) и userkarmaPoints (программист сам уже должен следить чтобы правильный id пользователя передавался). Все остальные входящие параметры удаляются. Во-вторых, родной процессор требует обязательной передачи параметров username и email (вот этого вообще никогда не понимал. Почему не проверять свойства объекта, а не передаваемые данные?). В общем, в этом процессоре я прописал подстановку текущих значений юзернейма и емейла, и потому необходимость их передавать отпала. Согласитесь, что передать id гораздо проще, чем id, username и email.

4. Через сниппет.
Знаю, что далеко не все любят работать через процессоры, потому добавил простой сниппет userkarma. В него передаются два параметра: user_id и points. В ответ, если все ОК, он возвращает JSON-строку ответа (просто потому что сниппеты умеют только строковые ответы возвращать). Но этот ответ можно JSON-декодировать и нормально обработать.

Все, это основные способы обновления кармы. Теперь кратко о том, как в этот процесс вклиниваться. Тут на самом деле тоже все просто. Плагин вызывается на два события:
1. OnBeforeUserFormSave. В этот момент значения кармы изменены уже, но пользователь еще не сохранен. Изменилось ли значение кармы, можно легко проверить методом $user->isDirty('userkarma'); Так же в оценке изменения кармы будут полезны свойства $user->userkarma_old (текущее значение кармы в базе) и $user->userkarmaPoints (переданное значение на изменение).
Здесь вы можете дополнительно повлиять на значения кармы, навесив свой плагин.

2. OnUserFormSave. Это уже после сохранения пользователя в БД. Как и говорилось выше, вам тут в помощь свойства $user->userkarma_excluded и $user->userkarma_included.

P.S. компонент выложен в modstore.pro.
Цена пока что 990 рублей, но когда обкатается и будет стабильным, подорожает.
Пожелания купивших пакет рассматриваются с наивысшим приоритетом.
Fi1osof
13 декабря 2015, 05:06
modx.pro
8
4 317
+15

Комментарии: 29

Василий Наумкин
13 декабря 2015, 08:10
+7
Почему бы не сделать плагин на OnUserSave?

Тогда обработка кармы будет запускаться при любом сохранении modUser, хоть через интерфейс, хоть через API.
    Fi1osof
    13 декабря 2015, 15:29
    +2
    Блин, постоянно ищу ивенты в ресурсах, и их там по прежнему нет. Отложилось в голове, что нет событий в основных объектах. Спасибо за подсказку! Так вообще огонь будет! :)
    Сейчас новую версию соберу.
      Fi1osof
      13 декабря 2015, 15:58
      0
      Вот теперь реально круто! :)
      joxi.ru/nAyz3VMFXXJQYr
      Спасибо!
    Василий Столейков
    13 декабря 2015, 09:29
    +1
    У компонента действительно большая область применения, от смены групп покупателей до реализации игрового интерфейса!
      Fi1osof
      13 декабря 2015, 15:30
      +1
      Именно так! Честно сказать, мозг взрывается от того, где и как это хочется применить :) А Василий на счет событий подсказал, так вообще из любого положения можно будет играться)
      Максим Кузнецов
      13 декабря 2015, 09:57
      +6
      Если не возражаете, выскажусь по поводу видения данного дополнения и метода его работы в целом:

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

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

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

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

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

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

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

      В противном случае, создавать под каждую «рейтинговую» группу полноценную группу modx'a воспринимается излишне громоздко и, на мой взгляд, для такой задачи вполне достаточно ограничиться одним доп. полем для пользователя, где будет записываться «подгруппа».
        Fi1osof
        13 декабря 2015, 15:46
        +1
        Максим, то, что вы говорите, это применимо только к ситуациям, которые зависят напрямую от времени. То есть если человек просидел на сайте год, то на ему значок, просидел 11 мес, 25 дней — еще не заслужил. Речь же идет о тех ситуациях, когда можно заранее примерно просчитать к чему вообще пользователям можно стремиться. К примеру, если у меня магазин, и я знаю, что у меня сейчас только 5 групп (к примеру, как здесь joxi.ru/MAj0VK9hvvMdRm ), до я могу для себя решить каких они результатов должны достичь и выразить это в числовом значении. Далее мне остается только создать правила в интерфейсе и все. И за год они накопят карму, или за день — уже будет зависеть от набранных баллов (к примеру, 1 балл за 1000 рублей).
        И это напрямую относится к группам пользователей (и к сфере их применения), так как просто пользователь не только скидки не имеет, но и остатков не видит, а оптовики видят.
        А ваша задача решается уже индивидуально. Хотя и видится мне возможность указывать тип правила (количественное, или временное и т.п.), и эту штуку тоже автоматизировать (навесить плагин на автопаблишь, сброс кеша или типа того).
          Wassi Wassinen
          13 декабря 2015, 16:43
          0
          Я согласен с высказыванием Максима. Изначально писал о том, что действия пользователя для перевода из группы в группу добавляются плагинами к компоненту. Это позволило бы перемещать пользователей из группы в группу не только в зависимости от числового значения кармы — это уже позволяют делать Тикетс. В моем понимании это компонент, которому можно задать любые условия, для перемещения пользователя из группы в группу. Условия эти добавляются плагинами.
            Fi1osof
            13 декабря 2015, 16:50
            0
            Вешайте плагин на OnUserSave и modUser::leaveGroup()|modUser::joinGroup() в помощь. Мне видится этот модуль в таком виде более удобным. Как программисту, мне проще многое выразить в числовом эквиваленте.
            Но да, это еще надо будет додумывать, так как пока годится для более однозначных сценариев (как с группами оптовиков в магазине). Множественные надо будет еще домысливать.
          Алексей Федоров
          14 декабря 2015, 01:19
          +4
          Это круто! Я серьезно)) Я видел соответствующие плагины на 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 достаточно положителен как пример?

          Короче, я свое видение универсализации показал, нужны будут уточнения с точки зрения «конечного пользователя», всегда готов))
            Fi1osof
            14 декабря 2015, 12:50
            0
            Алексей, спасибо за развернутый фидбэк. Приму во внимание.
            Fi1osof
            14 декабря 2015, 13:15
            +1
            Пакет одобрили в магазине. Советую уже сейчас приобретать. Во-первых, поддержите развитие компонента. Во-вторых, сегодня скорее всего обновленная версия появится, значительно доработанная и соответственно дороже. Но этот компонент уже обещает быть вообще юзерфрендли и более универсальным.
              Антон Фомичёв
              14 декабря 2015, 14:29
              +1
              Николай с командой решили захватить мир:)))
              Хоть мне выложенные на данный момент компоненты пока, вроде бы, и не нужны, всё равно большое спасибо за вклад в развитие!
                Fi1osof
                14 декабря 2015, 14:36
                0
                Как всегда :)
                Не за что!
                Сергей Скат
                14 декабря 2015, 15:17
                +1
                полезно, дайте 2 )
                  Fi1osof
                  14 декабря 2015, 16:11
                  0
                    Это сообщение было удалено
                      Это сообщение было удалено
                        Это сообщение было удалено
                        Это сообщение было удалено
                          Это сообщение было удалено
                            Это сообщение было удалено
                    Захарий
                    29 декабря 2016, 12:48
                    0
                    Здравствуйте, Николай, не подскажете как вы «вклинили» в стандартную таблицу юзера свои поля(мне нужно стандартное вывести zip, но очень интересно как кастомное)?
                    p.s. я понимаю, что там должен быть плагин на событие загрузки страницы. Но интересует код, не могу найти конкретно для моего случая… (Видел раньше где-то тут был вопрос похожий, но его не нашел).
                    p.s.s ну и чтобы поиск работал :) Да я не сильний в extJs, но пытаюсь изучать
                      Fi1osof
                      30 декабря 2016, 06:36
                      0
                      Там дофига делов. Коротко: в момент инициализации страницы управления пользователями добавляется еще один JS с гридом, расширяющим MODX-овый грид пользователей, и регистрируется новый компонент поверх старого
                      Ext.reg('modx-grid-user',UserKarmaGrid);
                          Fi1osof
                          30 декабря 2016, 08:19
                          0
                          Я так понимаю, что речь все-таки не о странице редактирования пользователя, а о таблице пользователей.
                            Захарий
                            30 декабря 2016, 11:55
                            0
                            да спасибо, я как раз знаю процедуру, но не знаю что «вклинивать», после праздников куплю компонент, мб разберусь. Ну или сам как-то) С наступающим Николай!
                              Fi1osof
                              30 декабря 2016, 12:06
                              0
                              Взаимно!
                        Wassi Wassinen
                        08 января 2017, 13:00
                        0
                        Может быть все же внедрить функционал перевода из группы в группу плагинами на определенные количественно-качественные показатели, как я предлагал раньше? Объясню, почему я это предлагаю. Вы бы могли сделать основу условно-бесплатной (Интерфейс групп и плагинов, которые к ним привязаны с одним плагином для ознакомления), а дополняющие плагины продавать по 100-200 рублей и закрывать максимально обширную аудиторию. Одним нужно переводить из группы в группу исходя из кол-ва комментариев и постов, а другим — в зависимости от рейтинга в определенном разделе и т.д. А так вы создали узконаправленный компонент, но он практически никому не нужен.

                        Заранее благодарен за ответ!
                          Fi1osof
                          08 января 2017, 21:50
                          0
                          Как я и писал, переводить из групп в группы можно по любым показателям (опять-таки, это решается плагинами). Кому нужны специфические плагины, за отдельную плату они обсуждаются. Просто, видимо, далеко не всем это понятно.
                          Второе: как я и говорил, на основе этих технологий был разработан прототип другого, более гибкого компонента, который позволяет настраивать более гибкие автоматические модификации. Надеюсь, когда-нибудь доберусь до него и допишу. Пока же есть более важные задачи.
                            Wassi Wassinen
                            08 января 2017, 22:23
                            0
                            Благодарю за ответ! Надеюсь, получится что-то интересное. В этом компоненте, действительно, нет понимания его масштабируемости и базового функционала.
                              Fi1osof
                              09 января 2017, 22:53
                              +1
                              Не за что!

                              К слову: мы используем, и кейс не один. К примеру, не так давно на минишопе использовали. Обратился клиент, который у себя на сайте сам настроил различные скидки для различных групп пользователей с помощью msDiscount, и оставалось только при оформлении заказа (а точнее при переводе его в конечный статус) подсчитывать сумму всех заказов клиента и в зависимости от пороговых показателей закинуть его в ту или иную группу. Вот это совсем не сложно было реализовать с помощью userKarma. Вообще в msDiscount есть свой механизм добавления пользователей в группы в зависимости от суммы заказов, но у него есть минус — он не выкидывает из групп. То есть если есть несколько групп прогресса, то пользователь проходя все эти группы, во всех этих группах и останется. А userKarma умеет в том числе и выкидывать из указанных групп, при чем как при превышении максимальных пороговых показателей, так и недостижении минимальных.
                                Wassi Wassinen
                                10 января 2017, 01:53
                                +1
                                Это классно! Если рейтинг или сумма заказов уменьшилась (расторжения, отказы), то пользователь переходит на предыдущий уровень возможностей\скидок. Удобно.
                                  Fi1osof
                                  10 января 2017, 02:20
                                  0
                                  Так и есть.
                          Авторизуйтесь или зарегистрируйтесь, чтобы оставлять комментарии.
                          35