Представлен (http://vtiger.com/blogs/2010/09/28/vtiger-crm-520-released/) релиз vtiger CRM 5.2.0 (http://vtiger.com/), многоплатформенной системы для организации (http://vtiger.com/index.php?option=com_content&task=view&id=...) взаимодействия с клиентами на предприятии, обеспечения работы службы продаж, ведения партнерской сети, организации работы службы маркетинга, оценки эффективности маркетиговых акций, поддержания инвентаризационной базы и корпоративной базы знаний, а также для координирования и планирования работы сотрудников. Код vtiger CRM (http://sourceforge.net/projects/vtigercrm/) написан на языке PHP и распространяется в полном объеме в рамках лицензии MPL.
Система снабжена гибкими механизмами для подключения дополнений, расширения функциональности и адаптации системы под нужды конкретного предприятия. Vtiger CRM является самодостаточной системой, все необходимые для работы компоненты входят в состав единого установочного образа, который доступен для Windows, R...URL: http://vtiger.com/blogs/2010/09/28/vtiger-crm-520-released/
Новость: https://www.opennet.ru/opennews/art.shtml?num=28110
Нет.. Бесполезно использовать vtiger. Более страшного кода в своей жизни я никогда не видел.Это АД!!! Так даже не писали программисты IE 6!!!
Вообщем пусть что хотят они выпускают, но этот продукт словно мертворождённый ребёнок.
Клиенту не в код смотреть, а чтоб работало.
Если кто-то недоволен имеющимся - пускай пишет свой код.
> а чтоб работало.А НЕ работает.
Сломали. Начиная с PHP 5.3.2 vtiger сломался.
И потребовался им ГОД почти, чтобы 5.2.0 выпустить.
Это ваще капец. Там фиксов на неделю работы.Сейчас уже ЛЕНЬ проверять, заработал vtiger 5.2.0 с PHP 5.3.3 или нет.
Вернулся на SugarCRM.А vtiger очень хорош был. Пока РАБОТАЛ. Но на PHP 5.3.2 - бздык!
На фиг никому не нужны эти м... рыдания с переездами, переносами колоссальных баз.
90% юзверей vtiger отдал Шугару. И поделом. Еще пара таких выходок и могут ваще закрываться.
> Клиенту не в код смотреть, а чтоб работало.
> Если кто-то недоволен имеющимся - пускай пишет свой код.Клиенту важно, что бы система на которой он собирается держать свою базу периодически, хотя бы раз в пару лет обновлялась и развивалась...
Втигер же представляет собой жалкое десятиэтажное подобие распорок и костылей. Где нет чёткой архитектуры и ясного понимания того что они хотят в дальнейшем.
Если клиенты думают о будующем своей системы, то я бы на их месте задумался о правильной CRM
> Более страшного кода в своей жизни я никогда не видел.втигер, вообще-то, форк шугара.
разошлись в кодовой базе они не так давно.
а к каким конкретно модулям втигера претензии?
с php 5.3.2 втигеры мрачно обделались, но отношения к стилю, идеологии кода это не имеет.
Вы вообще в код vtiger заглядывали?Я имею претензии ко всем модулям что индусы переписали. И даже не удосужились изменить копирайты sugar :)
Я всё веду к тому, что сейчас это свалка различных модулей и компонент. Они постоянно туда что-то новое привязывают, но совсем скоро ЭТО невозможно станет поддерживать.
Очень хотел доработать, но я испугался этого кода и поспешно слинял на Sugar. В шуге код конечно тоже не идеа (такой уж я перфекционист), но он хотя бы достаточно логичен и придерживается своего стандарта.
Вообщем втингер скоро некому будет поддерживать, а переписывать всё с нуля и рефакторить для такой большой системы - дело не подъёмное.
>>И даже не удосужились изменить копирайты sugar :)Мсье... И часто вы правите чужие копирайты в чужом опен-сорс коде?
Ну так и оставили бы рас на старом PHP работала, или как...?
> на старом PHP работала, или как...?На серваке неописучей мощности - псят штук сервисов и поважнее vtiger'a.
Сервак - в Сети, не в локальной.
Западла при накате до 5.3.2 никто не ожидал. Только втигер закосячил, больше ни одно приложение не пострадало.
Даунгрейд в таких условиях - безумие, огромный риск.
Вам понравится глючной или недоступный сайт банка? Или глючащая SSL почт-морда Банка?
Банку - нет.
Проще поднять за пять сек Шугар, и в рабочем порядке перенести базы, пока РАБОТА всяких так "кей-эккаунт менеджеров" НЕ ПРЕРЫВАЕТСЯ НИ НА СЕКУНДУ.
А выделять на Vtiger отдельный бокс на колокейшене это не скоро и это недешево.
Это знаете-ли большой шкандаль, остановить продажников.
Все-таки зря, зря, другие ОС и дистрибутивы не идут по пути RHEL/CentOS: в пятой ветке все еще PHP 5.1.X с бэкпортами, никаких дырок, и все работает (в том числе почти все новое, и почти все старое)З.Ы. Насчет исключительности vtiger'а, Вы не правы: на тех же хостинговых серверах, когда ПО контролируется кастомером, а не хостером-администратором сервера, после таких апдейтов наступают настоящие черные дни: увы, быдло-код неистребим.
>А выделять на Vtiger отдельный бокс на колокейшене это не скоро и это недешево.
Контейнеры и (или) виртуализация рулят?
> Все-таки зря, зря, другие ОС и дистрибутивы не идут по пути RHEL/CentOS:
> в пятой ветке все еще PHP 5.1.X с бэкпортами, никаких дырок,
> и все работает (в том числе почти все новое, и почти
> все старое)Центос хорош только в определенных условиях, соответственно не везде применим. Это если не
собирать кучи пакетов самому или юзать всякие рпмфорге/епелы - если же это делать, то оно ничем уже от генты не отличается, ну и соотв гента сразу становится гораздо логичней :)> З.Ы. Насчет исключительности vtiger'а, Вы не правы: на тех же хостинговых серверах,
> когда ПО контролируется кастомером, а не хостером-администратором сервера, после таких
> апдейтов наступают настоящие черные дни: увы, быдло-код неистребим.Это если кастомерами. Переписывать что то на халяву ( за еду ) в свободное от основной работы время (Вам не кажется, что переписывание все таки не работа админ) - моветон.
Если кому то нефиг делать - пускай переписывает.
>> Все-таки зря, зря, другие ОС и дистрибутивы не идут по пути RHEL/CentOS:
>> в пятой ветке все еще PHP 5.1.X с бэкпортами, никаких дырок,
>> и все работает (в том числе почти все новое, и почти
>> все старое)
> Центос хорош только в определенных условиях, соответственно не везде применим. Это если
> не
> собирать кучи пакетов самомуКучи-не кучи, но немножко мы собираем, и не видим в этом проблемы
> или юзать всякие рпмфорге/епелы - если же это
Имхо, Вы очень зря валите в одну кучу rpmforge и epel: второй никогда не заменяет центосные и rhel-овские пакеты, и особой проблемы в его использовании, имхо, нет (правда, есть проблемы, типичные для других дистрибутивов: мы, например, до сих пор боимся миграции с puppet 0.24.X: был бы он в базовых репозиториях, или гарантировалась бы самими puppetlabs совместимость еще несколько лет, этого можно было бы избежать)
>> З.Ы. Насчет исключительности vtiger'а, Вы не правы: на тех же хостинговых серверах,
>> когда ПО контролируется кастомером, а не хостером-администратором сервера, после таких
>> апдейтов наступают настоящие черные дни: увы, быдло-код неистребим.
> Это если кастомерами. Переписывать что то на халяву ( за еду )
> в свободное от основной работы время (Вам не кажется, что переписывание
> все таки не работа админ) - моветон.
> Если кому то нефиг делать - пускай переписывает.Нет, клиент просто уйдет на другой хостинг, где его таким не заставляют заниматься.
> ну и соотв гента сразу становится гораздо логичней :)в генте в стэбле кстати php 5.2.14. потому что там люди думают о качестве и стабильности. в чем радость от использования 5.3.х сейчас?
> Контейнеры и (или) виртуализация рулят?Контейнеры и (или) виртуализация - гуляют лесом.
Стоит Фря 7.3, которая держит нагрузку мама не горюй.
Таких линуксов нет и какое-то время еще не будет.
Будет биг-биг апдейт - за воскресенье сервак когда-нибудь переедет на Фрю 8.1 (а может, уже 9.4 к тому времени появится :)
Опыты с линуксами будут, может быть, сделаны локально.
Таки, десктоп система, эти линукса :)
Ну их, этих линуксов, на серьезно нагруженнои интернет-сервере им не место.
>> Контейнеры и (или) виртуализация рулят?
> Контейнеры и (или) виртуализация - гуляют лесом.
> Стоит Фря 7.3, которая держит нагрузку мама не горюй.
> Таких линуксов нет и какое-то время еще не будет.
> Таки, десктоп система, эти линукса :)Что-то Вы сильно красноглазите :)
А держать кучу неизолированных сервисов в одном box-е, большой моветон, и не только с точки зрения security.
> А держать кучу неизолированных сервисов в одном box-е, большой моветон, и не
> только с точки зрения security.Моветон, не моветон, а расколачивать 7U корпус, закупая аренду 42U стойки и 42 сервака по 7000 баксов, это, как бы, дорого? Не дорого? Мне дорого.
С точки зрения security тьфу-тьфу.
Расплавившийся сервак был восстановлен за три часа вместе со срочной закупкой (чудом нашелся в воскресенье наличный девайс в продаже). Ноу проблем.
Все "глабакамысленные" соображения разнести сервисы по 10 сервакам (картинки, статика, почта, мускул в выделенных боксах, web - через лоад-балансер за которым пучок навороченных по не могу 1U) были опровергнуты такой простой штучкой, как ПРАКТИКА.
Один МОЩНЕЙШИЙ сервер молотит в 100 раз шустрее, чем 10 мид-рейнджей, подключенных через балансер.
"Балансировать" или разносить мускул, почту, статику нужно только копиями этого супервсервака. Все остальное - это падение производительности на порядки. Не хватает мощностей - кратно умножай топовую железную конфигурацию, а не мостырь "ферму" из серверов, которые отвечают на клик медленнее того, который надо дублировать.
Что, впрочем из "курса" арифметики за второй класс начальной и без опытов следовало.
Извиняюсь за оффтоп, но можно будет с этого места поподробней. Мы как раз думаем - купить ли кучу 1U серверов или же парочку накаченных по самое "!немогу!"!? Ваша ПРАКТИКА была бы очень полезной и сэкономила бы многим кучу денег и нервов!
> Извиняюсь за оффтоп, но можно будет с этого места поподробней. Мы как
> раз думаем - купить ли кучу 1U серверов или же парочку
> накаченных по самое "!немогу!"!? Ваша ПРАКТИКА была бы очень полезной и
> сэкономила бы многим кучу денег и нервов!А Вам посоветую внимательно посмотреть в сторону Blade-серверов. Обратите внимание, чтобы не было лишнего флуда, я написал "посмотреть", а не "купить". А нужно ли Вам такое решение или другое - решать Вам. Вы должны чётко понимать, что потребуется от сервера как минимум через 5 лет. И заложить эту возможность роста уже сейчас.
P.S. Blade-сервера от различных производителей (а их немного) отличаются. У каждого есть плюсы и минусы. Взвесьте их. Как и заявленные перспективы развития от этих производителей.
> Извиняюсь за оффтоп, но можно будет с этого места поподробней. Мы как
> раз думаем - купить ли кучу 1U серверов или же парочку
> накаченных по самое "!немогу!"!? Ваша ПРАКТИКА была бы очень полезной и
> сэкономила бы многим кучу денег и нервов!Присоединюсь к рекомендации blade'ов. А вообще, лучше расскажите, что за задача.
>> Извиняюсь за оффтоп, но можно будет с этого места поподробней. Мы как
>> раз думаем - купить ли кучу 1U серверов или же парочку
>> накаченных по самое "!немогу!"!? Ваша ПРАКТИКА была бы очень полезной и
>> сэкономила бы многим кучу денег и нервов!
> Присоединюсь к рекомендации blade'ов. А вообще, лучше расскажите, что за задача.Задача простая - большие дяди хотят создать новый ISP в нашем городе!
>>> Извиняюсь за оффтоп, но можно будет с этого места поподробней. Мы как
>>> раз думаем - купить ли кучу 1U серверов или же парочку
>>> накаченных по самое "!немогу!"!? Ваша ПРАКТИКА была бы очень полезной и
>>> сэкономила бы многим кучу денег и нервов!
>> Присоединюсь к рекомендации blade'ов. А вообще, лучше расскажите, что за задача.
> Задача простая - большие дяди хотят создать новый ISP в нашем городе!Никогда в ISP не работала, но, на сколько я понимаю, Вам нужно будет:
а) Держать оборудование в ДЦ каждого магистрала, с которым будете работать
б) Держать некоторое количество своего оборудования под типичные сетевые сервисы (DNS, почта, форум, ftp какой-нибудь, чат, торрент, странички юзеров)
в) Нечто стабильно работающее под биллинг
г) Держать некоторое количество своего оборудования для обеспечения доступа конечных юзеров,
д) (IP)Телефония так же вряд ли сочетается с обычными блейдами
е) Потребуется несколько вандалостойких ящиков для размещения умных свитчей для соединения сегментов сети (или конечных пользователей, если сеть Ethernet, и сразу строится не на неуправляемых DLink'ах)если (г) это DSL и dial-up, и, тем более, какой-нибудь WiFi, вряд ли получиться разместить все в одном блейде.
Да и если нужно присуствовать в ДЦ нескольких магистралов.
В общем, Вам, наверное, будет лучше именно куча 1U серверов.Или Вы хотите свой маленький "ЦОДик"? Если хотите размещаться у себя, не советую блейды: 1-2-3U платформы Intel/Supermicro + шкаф получаются ощутимо дешевле, чем блейды (хотя и больше в юнитах и электроэнергии), и являются более гибким решением, например, без проблем можно вставить карточку для того же Asterisk'а, или хитро прицепить к серверу циску, раздающую диал-ап.
Наверное, самым лучшим будет проконсультироваться на nag.ru, там есть люди, которые съели собаку именно на построении ISP :)
Мда... есть над чем подумать!
Пока собираем всю необходимую информацию и будем иметь ввиду все комментарии, спасибо большое! :-)
> Задача простая - большие дяди хотят создать новый ISP в нашем городе!Вам пить пиво с существующими ISP и запоминать.
Идите, спрашивайте и учитесь.
Я вам в создании ISP не помощник (вся моя бодяга - это "веб-сайты", только навороченные и нагруженные), но могу только догадываться, что ISP ОБЯЗАТЕЛЬНО нужно разносить ВСЕ сервисы на отдельные боксы. Мускул(ы), днс(ы), почта(ы), биллинг(и), телефония(и), хостинг(и), маршрутизация - вот вам для начала пять-десять-двадцать отдельных коробок.
> что ISP
> ОБЯЗАТЕЛЬНО нужно разносить ВСЕ сервисы на отдельные боксы. Мускул(ы), днс(ы), почта(ы),
> биллинг(и), телефония(и), хостинг(и), маршрутизация - вот вам для начала пять-десять-двадцать
> отдельных коробок.Зачем? У одного знакомого ISP почти все виртуализировано в Zones, у другого ISP в OpenVZ. Таки железо, особенно если задача не загружает его до конца, на дороге не валяется.
Но к отдельным сервисам, специфичным именно для ISP, возможно, придется цеплять железки, и там виртуализация точно будет лишней.
С тем же, что следует обратиться к махровым ISP-кам, соглашусь.
> Зачем? У одного знакомого ISP почти все виртуализировано в Zones, у другого
> ISP в OpenVZ. Таки железо, особенно если задача не загружает его
> до конца, на дороге не валяется.
> Но к отдельным сервисам, специфичным именно для ISP, возможно, придется цеплять железки,
> и там виртуализация точно будет лишней.
> С тем же, что следует обратиться к махровым ISP-кам, соглашусь.Такую вещь, как авария, природа не отменяла.
Начнут подсыхать кондюки на мат. плате, запылится кулер на проце, коробка начнет дурковать.
Тут модульное решение задачу упрощает. К тому же с почтой справится 1U за 30000р., например.
Зачем
ISP может начать терять клиентскую базу от простоев.
В случае с корпоративным сервисом вопрос решается так: "Эй, доцент! Десятка давай! Новая керосинка покупать буду!"
А в случае с новым небольшим ISP клиент просто отдаст свои 500р в месяц конкуренту и убедить его раскошелиться на апгрейд, как понимаете, невозможно.
К тому же минимум PPP/PPPoE и их обвязка до магистрального канала обязаны быть продублированы минимум двукратно каким-нибудь CARP решением.
Чтобы не отрубать полгородка на выходные от Сети.
Единый бокс тут страшный риск.
> Такую вещь, как авария, природа не отменяла.
> Начнут подсыхать кондюки на мат. плате, запылится кулер на проце, коробка начнет
> дурковать.> Единый бокс тут страшный риск.Именно(!) два или больше боксов, но меньше, чем если каждый сервис разносить по железке.
В том же OpenVZ, или ESX совсем-совсем не зря есть LiveMigration.
А огромные тазики в одном экземпляре(как у Вас), имхо, зло.
Есть практика провайдинга, задавайте вопросы.
В случае с фряхой достаточно держать ВСЁ в джэйлах. В базовой системе у меня только mc и ez-jail. После чего раз неделю/месяц/год делает слепки джэйлов. Бэкапите их. При необходимости разворачиваете на новом железе за время, равное времени залива туда бэкапов + 15 минут на базовую настройку. Всё.Не считая возможнсоти быстро клонировать джэйл и эксперементировать в нем.
На накачанной машине в итоге проц простаивает меньше, чем на кучке изолированных серверов.
> В случае с фряхой достаточно держать ВСЁ в джэйлах. В базовой
> системе у меня только mc и ez-jail. После чего раз неделю/месяц/год
> делает слепки джэйлов. Бэкапите их. При необходимости разворачиваете на новом железе
> за время, равное времени залива туда бэкапов + 15 минут на
> базовую настройку. Всё.
> Не считая возможнсоти быстро клонировать джэйл и эксперементировать в нем.
> На накачанной машине в итоге проц простаивает меньше, чем на кучке изолированных
> серверов.Так и будет сделано. После обкатки. Это уже на новом боксе, который будет в конторе на столе, а не в стойке ЦОДа отлаживаться. Вы ж понимаете, что "зверинец" подросший за 10 лет, за сутки не переведешь в jailы. Сначала план, потом эксперименты, потом коррекция, потом тесты, а уже потом переставим коробки в стойке. Я кладу на это три-шесть мес неспешной медитации.
> Мы как раз думаем - купить ли кучу 1U серверовУ меня в одном боксе мускул (2Тб локальноно трафа в сутки), перловый бэкенд и кеширующий на диски фронт.
Кеш динамический, какая-то часть данных обновляется непрерывно, с немедленным удалением из кеша устаревших станиц, какая-то часть может лежать неделями, до полной чистки кеша, которая производится
"Теплый" кэш занимает на диске где-то 100Гб.
Спасибо Гуглу, он сотней запросов в сек разогревает пустой кеш :)
Когда сервер начал "сдыхать" под нагрузкой, встал вопрос о разнесении картинок, статики, мускула в отдельные боксы. Но боевые эксперименты показали, что если десятерых клиентов, запросивших одну и ту же страницу, раздать через балансер на 10 отдельных "лезвий" (на каждом из которых, понятно, полная копия сервиса), то ждут клиенты страницу ДОЛЬШЕ, чем если бы вдесятером одновременно стукнулись в один большой сервак. Т.е. один большой сервак, даже если заставляет клиента ждать в ПОЛНОЙ очереди, т.е. принципиально ничего ему не отдает, поскольку перегружен, дает результат задержка в очереди+плюс время исполнения запроса меньше, чем "лезвие", которое обслуживает одного клиента.Но, вообще, КАЖДЫЙ РАЗ надо смотреть, ЧТО ИМЕННО вы хотите поставить под нагрузку.
Если не нужно, типа, опрашивать большую базу с первой до последней записи то суперсервак не нужен. Т.е. скажем если у вас контент напоминает народ.ру, типа, 100% статики и лом посещений - то балансировка нагрузки как раз даст вам КОЛОССАЛЬНЫЙ прирост производительности! Выше линейного.
Я вам советую все, же провести эксперименты.
Например под вмварью вы можете поднять и 10 и 50 серваков и сделать виртуальную "стойку".
Начать с классики; мускул, почта, картинки, статика на выделенных серверах, пучок веб-серверов через балансер и нагрузить это тестовым сценарием.Если есть свободные железяки соберите зверинец на "соплях" локально и тоже тестовым сценарием, вам все станет ясно.
То есть все - от задачи.
Статика и несерьезно нагружающие проц скрипты очень много выгоды могут принести как раз при разнесении нагрузки на "лезвия".
В моем случае: огромные базы с кучей JOINов в запросах и длинной обработкой выдачи перлом в HTML - оставляют возможность "умножать" за балансером только сервера, которые уже достигли физического предела - нету на рынке более навороченных :) А до того - только единый бокс.
>> Мы как раз думаем - купить ли кучу 1U серверов
> У меня в одном боксе мускул (2Тб локальноно трафа в сутки), перловый
> бэкенд и кеширующий на диски фронт.И во что вся эта конструкция упирается? в i/o, или в CPU?
> Но боевые эксперименты показали, что если десятерых
> клиентов, запросивших одну и ту же страницу, раздать через балансер на
> 10 отдельных "лезвий" (на каждом из которых, понятно, полная копия сервиса),
> то ждут клиенты страницу ДОЛЬШЕ, чем если бы вдесятером одновременно стукнулись
> в один большой сервак.А чем и как балансили? LVS, например, позволяет балансить соединения на наименее прогруженные(в т.ч. по load average) ноды
> Я вам советую все, же провести эксперименты.
> Например под вмварью вы можете поднять и 10 и 50 серваков и
> сделать виртуальную "стойку".
> Начать с классики; мускул, почта, картинки, статика на выделенных серверах, пучок веб-серверов
> через балансер и нагрузить это тестовым сценарием.Имхо, это будет плохой полигон для тестов производительности (но хорошая лаборатория для построения и виртуализированных, и не виртуализированных систем)
> Статика и несерьезно нагружающие проц скрипты очень много выгоды могут принести как
> раз при разнесении нагрузки на "лезвия".Если у Вас все уперлось в CPU, может быть, просто стоило ставить на лезвия топовые, по MHz, CPU? меньшее число ядер не имеет значения, так как на ноду все равно идет меньшее число запросов
> нету на рынке
> более навороченных :)Если Ваш супер-тазик x86, можно посмотреть на PowerPC :)
Все уперто в CPU.
Вообще наблюдается отсутствие в Ваших размышлениях системного подхода... Если вы проникнетесь Дао системного подхода, то с Вашим опытом и знаниями вам светит блестящая карьера CIO.
вы ораклу с его эксадатой скажите об этом, а то они не знают бедолаги.
http://en.wikipedia.org/wiki/Oracle_Exadata
и главное про нечто подобное не забывать - http://ru.wikipedia.org/wiki/InfiniBand
>на тех же хостинговых серверах, когда ПО контролируется кастомером, а не хостером-
>администратором сервера, после таких апдейтов наступают настоящие черные дни:Причём без обедов и выходных, а пока глюк отловишь...
Приходилось срочно откатывать до 5.2 :(
Я Вам сейчас тайну открою... есть такая штука... виртуализация называется... так вот каждый жизненно важный сервис должен жить в своём отдельном окружении. чтобы таких как у Вас накладок не случалось, чтобы его за пару минут можно было перенести на другой физический сервер и там ещё много этих "чтобы". Right Way одним словом.
Хватит болтать - учитесь делать backup.
Я для тигра уже год пишу модификации, модули и т.п. Ожидал гораздо большего в 5.2 Как тут правильно подметили, за 1 год выпустить изменений на которые можно было потратить неделю - это бред!Скачал SugarCRM, чище, приятней, удобней, структура БД лучше, документация лучше. Интерфейс лучше, более дружелюбный и простой. В тигре чтобы даже добавить какое-нибудь действия в календарь надо зайди в Sales Leads -> Lead # -> Add Event -> и тут только добавляешь ивэнт. В SugarCRM на джаве все удобнее построено.
Короче, сильно пожалел что год убил на тигра, лучше бы я год убил дописывая отсутствующие функции в SugarCRM.
Аминь ))
токо при чём тут жаба к сугару ? (разве что zucker reports, но это убожество ещё то имхо)
> zucker
> reports, но это убожество ещё то имхоУ них нет бесплатного аналога, так что, убожество-убожеством, а юзать, для отчетов, приходиться...
Джава при том что в шугар6 переделали интерфейс и теперь он похож на leads360. Новый интерфейс сделано удобнее засчет Ajax, большинство окон выводятся как маленький джава попап, больше не надо ходить в дебри аккаунта.
это не жаба. это жабаскрипт.
Я знаю, мне не принцепиально писать жабаскрипт, кто в теме и так понимает что я имею ввиду, а если я кого-то ввёл заблуждение, то примите мои извинения ;)
ахахаа :)
изящно ))
Итак, свершилось! СМС модуль Vtigercrm теперь работает!Представляю Вам дополнение (и исправления) к модулю смс, которое позволяет полноценно использовать в работе vtigercrm индивидуальную и массовую отправку смс.
Ссылка на архив – http://myholdfoolder.s3.amazonaws.com/SMSpm.zip
Очень рекомендую включить данный модуль в следующую версию системы. Для этого достаточно закачать все файлы из архива в каталог /modules/SMSNotifier (с заменой файлов) и выставить на эти файлы права 755.
История создания
Как известно, встроенный в систему модуль смс с единственным поставщиком clickatell почему-то не работает. Я связался с техподдержкой clickatell и попросил их помочь с настройкой модуля в системе vtigercrm. На что они очень вежливо отправили меня в эротическое путешествие.
Тогда я начал искать в сети их конкурентов, т.е. компании предлагающие услуги отправки смс через интернет. И нашел отличную от других европейскую фирму под названием SMSPoint - http://www.smspm.com .
Компания SMSPoint специализируется на предложении услуг массовой и индивидуальной отправки смс по всему миру. У них есть свой API, который позволяет внедрить их систему практически на любой сайт. Что немаловажно, доступна русская локализация их официального сайта, личного кабинета и мастера рассылок смс. Также есть русская техподдержка. Оплата возможна через PayPal, Visa, Webmoney и прочее. Цены меня тоже порадовали - 2 евро цента (примерно 80 копеек) за смс.
На мою просьбу о помощи в интеграции их услуг во vtigercrm они откликнулись мгновенно!
Несколько дней их программист работал над интеграцией (в том числе исправлял баги, появившиеся благодаря ошибкам русской локализации), затем мы тестировали модуль, улучшали его и вот теперь он готов. Предлагаю его всем желающим.
В нашей компании мы уже начали использовать модуль в работе. Впечатления и результаты самые позитивные: экономия на звонках, экономия времени менеджеров, автоматизация, скорость обработки заказов и многое другое. Главное, правильно организовать workflow.
Возможности модуля:
1. Возможность проставления названия фирмы в отправителе смс вместо номера телефона!
Думаю, не нужно объяснять, насколько данная возможность повышает имидж фирмы в глазах потенциальных клиентов. Название должно состоять только из букв английского языка и не превышать длину в 11 символов. Тире и прочие символы не поддерживаются - это ограничение наложено самой структурой смс сообщений.
2. Отправка смс обращениям, контактам, контрагентам.
Внимание - стандартные ограничения смс сообщений:Сообщения набранные кириллицей не должны превышать длину в 70 символов.
Сообщения набранные латиницей не должны превышать длину в 160 символов.
При наборе сообщения, отображается количество набранных символов, так что не ошибетесь. Если вы отправите сообщение, превышающее данные ограничения, оно не дойдет до адресата (деньги со счета в этом случае, также, не списываются). Можно заранее создать пользовательские поля, из которых будет браться информация для смс, ограниченной длинны для того, чтобы менеджеры в запарке не ошибались.3. Одновременная массовая отправка смс для этих же категорий! Вы можете организовать свою собственную смс рассылку (например для уведомления клиентов о новых услугах, товарах и прочее).
4. Отчет о получении смс получателем.
В модуле смс сообщений есть раздел Status Information. Для того чтобы узнать состояние сообщения нужно нажать кнопку "Проверить статус".
Только что отправленные и не дошедшие до адресата сообщения подсвечены оранжевым цветом.
Сообщение может не дойти по следующим причинам:
1. Вы превысили допустимую длину сообщения при отправке.
2. Телефон получателя недоступен. Тогда сообщение дойдет позже.
3. Получатель использует какого-то экзотического провайдера сотовой связи, который не входит в следующий список http://www.smspm.com/ru/SMS-ceny#LetterR (смотрите внизу список поддерживаемых по тегу Russia)
Дошедшее до получателя сообщение подсвечивается зеленым и иногда белым цветом (разницу в их значении я пока что не понял)
Варианты использования модуля:
1. Автоматическое (или ручное) уведомление клиента о выставлении счета.
2. Автоматическое (или ручное) уведомление клиента о получении денег.
3. Уведомление поставщиков об оплате, отгрузке, заказах и прочее.
4. Отправка предложений клиентам. Благодаря сервису http://goo.gl и расширению к Firefox goo.gl lite, можно в один клик преобразовывать длинные ссылки в короткие и отправлять их клиентам в смс. Клиент прямо из телефона, сможет посмотреть товары и услуги на Вашем сайте. Мы кстати, так уже делаем.
5. Массовая рассылка уведомлений обращениям, контактам, контрагентам или их категориям о чём угодно. Для фильтра можно использовать расширенный поиск и фильтровать их по каким угодно параметрам и группам.
6. Благодаря модулю «Обработчики», можно настроить автоматическую отправку смс при наступлении определенных событий. Это, пожалуй, самая приятная и универсальная функция модуля. Возможности её применения, практически, безграничны.
7. В общем, полезных вариантов использования очень много )).
Как начать работать с СМС.
1. Зарегистрируйтесь на сайте http://www.smspm.com/ru
2. Войдите в личный кабинет и нажмите «Добавить кредитов».
3. Выберите сумму оплаты (до 35 евро) и нажмите «Добавить кредитов»
4. Кликните на логотип PayPro. В выпадающем списке «Способ оплаты» выберите удобный Вам способ (я например оплачиваю виртуальной картой Visa, которую можно мгновенно получить в личном кабинете киви-кошелька и пополнять в ближайшем киви-терминале).
5. Зайдите в настройки модуля SMS-Уведомления, Конфигурация Сервера.
6. Нажмите Add New и выберите SMSPm
7. Поставьте галочку активно, введите Ваш логин и пароль в системе http://www.smspm.com
8. В графе auth_hash введите Ваш хэш (хэш можно узнать в личном кабинете http://www.smspm.com щелкнув на ссылку с названием API в левой нижней части страницы)
9. В графе Sender введите название отправителя или номер телефона, который вы хотите отображать в отправителе смс сообщения и нажмите кнопку «Сохранить».Всё, можно начинать работать.
Небольшая просьба ко всем, кому интересен этот модуль. В качестве благодарности за отзывчивость компании SMSPoint и труд её программистов выкладывайте, пожалуйста, этот текст на своих блогах, форумах, сайтах. В SMSPoint меня заверили в том, что если этот модуль хорошо приживется в России, они займутся его дальнейшим совершенствованием и развитием, а это всем нам будет только на пользу.
Успехов!