За прошедший год мы разработали четыре плагина для связки Redmine + Telegram (раз, два, три, четыре).

Потихонечку вырабатываются свои Best Practices в отношении них. В этой заметке расскажем о тестировании и интеграции с Travis CI.

Почему решили о тестировании рассказать? Потому что тестирование плагина для Redmine — тот ещё квест.

С давних пор для второго шага аутентификации мы использовали одноразовые пароли отправляемые через СМС. Такой функционал появился в Redmine в 2013, когда мы разработали плагин redmine_sms_auth. Об этом мы писали в давней статье.

Но время не стоит на месте. Мы активно внедряем Telegram в бизнес-процессы компании (раз, два, три).

В связи с этим решили сделать аутентификацию через Telegram в Redmine. Заодно с этим переписать старый плагин про СМС и добавить поддержку Google Authenticator.

Далее мы расскажем о том как установить, настроить и использовать этот плагин.

Это первая статья серии о том, как мы внедрили непрерывную интеграцию в процесс разработки CRM и облегчили жизнь финансовому отделу.

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

Раньше для автоматизации технических процессов в финансовом отделе мы использовали такую структуру.

Некоторое время назад я рассказал от том «Как хранить сложную иерархию настроек в проектах Redmine». Рассказ этот базировался на опыте разработки плагина redmine_intouch. В этой публикации расскажу о самом плагине и том, чем он может быть полезен для вас.

Наша компания растёт, полагаться на человеческий фактор всё сложнее и сложнее, а многочисленные клиенты ожидают мгновенной реакции на свои заявки.

В связи с этим мы стараемся максимально автоматизировать все возможные процессы, напоминать администраторам о необходимости вовремя написать статус по открытым задачам клиентам…

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

В течении последних двух месяцев работал над плагином redmine_intouch для компании Centos-admin.ru.

После завершения работ решил поделиться некоторыми нюансами, с которыми пришлось столкнуться в процессе разработки.

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

Перво-наперво хочу оговориться. Эта статья о реализации логики хранения настроек проекта в плагине для Redmine.

Т.к. это плагин, то использовать сторонние гемы, в которых данный функционал реализован — крайне нежелательно, во избежание конфликтов с логикой самого Redmine.

Поэтому в этой публикации речь будет идти о реализации с нуля системы хранения настроек со сложной иерархией.



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

На сайте centos-admin.ru дизайнер придумал очень здоровский эффект для формы логина. Идея формы состоит в том, что пользователь вводит свои логин и пароль в Redmine и попадает авторизованным на свою страничку.

Все бы здорово, но в Ruby on Rails (на коих Redmine сделан) прямые POST запросы с внешних сайтов не принимаются — для успешного запроса нужен авторизационный токен.

Сей токен генерируется rails-приложениями в автоматическом режиме, хранится в cookies. В связи с этим сперва думал в iframe загружать сайт с Redmine-ом и из cookies брать нужный ключ. Но как-то это совсем не rails-way.

Самое простое решение — слегка пропатчить Redmine — добавить возможность обработки запросов с внешних ресурсов. Благо в Redmine все для этого есть — можно написать небольшой плагин, который и будет решать эту задачу.

На хабре уже есть несколько статей о rbenv (раз, два, три), но ни в одной не упомянут очень удобный инструмент rbenv-installer. Этой статьёй я и заполню этот пробел.

Прежде чем начну описывать установку, хочу сказать чем меня порадовал rbenv и почему я перешёл на него с RVM.

В одном из моих проектов мне понадобилось периодически запускать задачи (rake tasks) с помощью cron. Задачи для cron-а я формировал и записывал в crontab с помощью гема whenewer. Тогда я ещё пользовался RVM и cron в лог писал что-то вроде:
bundle: command not found

Искал решение с помощью гугла и нашёл в issues whenewer-а упоминание о такой же проблеме. Тикет был закрытым и упоминалось что в rbenv всё работает. Установил я rbenv и без каких-либо дополнительных настроек мои cron-задачи стали работать так как я и хотел. С того дня в новых проектах я только rbenv использую.