Na rynku oprogramowania do zarządzania projektami jest wiele różnych skryptów i aplikacji, których filozofia w lepszy lub gorszy sposób wpasowuje się w nasz sposób postrzegania tego, w jaki sposób powinien przebiegać poprawny „przepływ pracy” powodujący powstanie produktu końcowego. Jednym z takich skryptów jest Redmine, który w pewien sposób „pasuje mi” podczas tworzenia własnych projektów. Nie oznacza to jednak, że korzystanie z niego jest proste – dlatego w dzisiejszym wpisie chciałbym przedstawić „wymęczony” sposób na konfigurację powiadomień emailowych dla akcji, jakie użytkownicy podejmują w systemie.
Wstęp: O Redmine słów kilka.
Systemy wspomagające zarządzanie projektami to bardzo fajny sposób na ułatwienie sobie pracy podczas pracy nad nimi, szczególnie, jeśli pracuje się w grupie. Od pewnego czasu znowu wróciłem do ThunderBirda jako głównego klienta poczty [nie wiem, jak wcześniej mogłem męczyć się z otwartą od rana do wieczora zakładką GMaila w Firefoksie], przez co nie postrzegam już odbierania maili jako przykrej konieczności, lecz jako „jeszcze jedno zadanie systemowe”.
Redmine był najprawdopodobniej pierwszym zainstalowanym świadomie, w środowisku produkcyjnym, systemem do zarządzania projektami. Potem przeżyłem krótką przygodę z FengOffice [też polecam, aczkolwiek brak "issue trackera" jednak mocno przeszkadza w pracy] i nieco dłuższą z Bugzillą [tutaj odwrotna kwestia - nie oferuje ona praktycznie niczego poza issue trackerem ;]]. Niedawno wróciłem jednak do Redmine, jako najlepiej wyważonego rozwiązania, posiadającego wszystko, czego potrzebowałem [issue tracker, podgląd repozytorium, wewnętrzne wiki, składowanie plików, itp., itd.].
Jak już wspomniałem we wstępie, nie wszystko jest tutaj jednak „krainą mlekiem i miodem płynącą”. Po pierwsze – Ruby, z którym „delikatnie mówiąc” nie jest mi po drodze [składnię Pythona jeszcze jakoś zniosę, ale to, co się dzieje w Ruby to już lekka przesada ;]], jako główny język programowania powoduje, że muszę jednak zaufać twórcom, że wszystko będzie działało, jak trzeba. Na szczęście Jean Philippe-Lang i spółka bezsprzecznie dają radę, ponieważ nie udało mi ani razu się trafić na jakieś przekłamanie danych, ani błąd aplikacji. Inną kwestią jest zasobożerność – na moim shared hostingu w DreamHoście mam czasem problem z wykrzaczającym się mod_passengerem:
z informacji znalezionych w Internecie wynika, że rzeczony „broken pipe” odnosi się tylko i wyłącznie do limitów serwera. Jak widać, czas zacząć szukać porządnego VPSa. ;]
Tyle w kwestii samego Redmine – zobaczmy, co da się zrobić z naszym problemem. ;]
Redmine: Konfiguracja powiadomień email dla Google Apps we własnej domenie.
Aby skonfigurować rzeczone powiadomienia mamy dwa sposoby, a właściwie mechanizmy faktycznej wysyłki [plik config/configuration.yml]:
- sendmail,
- zewnętrzny serwer SMTP.
Mój problem polegał na tym, że założyłem sobie konta pocztowe w domenie kowalczyk.cc i w przypływie niezrozumiałej śmiałości zechciałem skorzystać z serwerów SMTP GMaila do wysyłki powiadomień w ramach mojej instalacji Redmine. Okazuje się jednak, że Redmine wymaga nieco pokory, bo raz nie spodobała mu się domena serwera SMTP, a drugi raz miał problem z loginem i hasłem.
W ramach pomocy dla potrzebujących i przyszłej referencji dla siebie samego, publikuję działającą [na dzień dzisiejszy] konfigurację, która pozwala na uruchomienie powiadomień dla kont GMaila stworzonych w ramach aplikacji Google Apps dla własnej domeny:
# default configuration options for all environments
default:
# Outgoing emails configuration (see examples above)
email_delivery:
delivery_method: :smtp
smtp_settings:
tls: true
address: "smtp.gmail.com"
port: 587
domain: "yourdomain"
authentication: :plain
user_name: "yourmail@yourdomain.com"
password: "yourpassword"
Oczywiście należy podmienić określone fragmenty na własne dane dostępowe:
- yourdomain - domena, na której są zainstalowane Google Apps, w moim przypadku jest to kowalczyk.cc – w każdym razie nie należy podawać tutaj domeny ustawionej jako wyjściowy serwer SMTP dla samej domeny!
- yourmail@yourdomain.com – login GMaila, czyli nazwa użytkownika [at] domena, którą wpisaliśmy,
- yourpassword - to już chyba jasne, trzeba podać hasło do tego konta.
Będąc w głównym katalogu Redmine należy zrestartować aplikację [tak, tak, "stronki" w Rubym działają w trybie "ciągłym", a nie jak w PHP "zapisz i [F5]„] wykorzystując polecenie:
touch tmp/restart.txt
Polecenia tego można używać wielokrotnie bez kasowania pliku restart.txt – serwer sam wykrywa czas modyfikacji pliku i na podstawie tego reaguje odpowiednio.
Możemy się już cieszyć działającymi powiadomieniami w Redmine. ;]
Warto przeczytać.
Trwa ładowanie…

Bardzo ciekawym projektem jest jeszcze pythonowy Trac: http://trac.edgewall.org/
Polecam!
Nie wiem dlaczego, ale na shared hostingu są straszne problemy z uruchomieniem Traca. Może po prostu DreamHost ma jakieś złe wersje oprogramowania, ale z tego co pamiętam nie udało mi się postawić w pełni funkjonalnego Traca.
Inna sprawa, że jego filozofia przewiduje tylko jeden projekt na instalację, co mi za bardzo nie pasuje.
Redmine- Konfiguracja powiadomień email dla Google Apps we własnej domenie
A na czym polegał sam problem?
Dodam też od Ciebie: jestem bardzo zadowolony z redmine. Wcześniej pracowałem na mantisie, tracku, jirze. Integracja z SVN
em (i innymi systemami wersjonowania) obsługa ticketów przez maile (w obie strony) itp. jedyny minus to ruby, ale passangerem da się je pokonać :)
Passenger już się chyba ustabilizował, ale dalej potrafi walnąć 500tką w najmniej oczekiwanym momencie. Możemy uznać jednak, że działa. ;]
Co do problemu – to zależy, o który pytasz:
* ten z wpisu,
* ten z odpowiedzi na komentarz @aquamarine’a.
W pierwszym przypadku chodziło o to, że konfiguracja powiadomień w Redmine to dosyć ciężki orzech do zgryzienia jak się do tego siada po raz pierwszy albo przypomina sobie całą procedurę po długim czasie. Stąd pomysł na zamieszczenie działającej konfiguracji dla Google Apps. Mam nadzieję, że jeśli ktoś też skonfigurował to u siebie w nieco inny sposób, to podzieli się swoim YAMLem w komentarzach albo potwierdzi, że działa. ;]
W drugim miałem na myśli to, że wtedy, kiedy chciałem zainstalować Traca na DreamHoście, to strasznie krzaczyły się wszystkie pythonowe narzędzia – wymagały praw admina [sudo] albo system killował mi dane polecenie w połowie wykonania. W każdym razie to, że Trac jest „jednoprojektowy” dla mnie jest czynnikiem dyskwalifikującym go z praktycznego użycia. Pomimo tego, że zespół bardzo ładnie argumentuje fakt, że jest to niezgodne z ich filozofią prowadzenia projektów, ale czy nie można wbudować „kilku Traców w jeden” np. z wyborem bazy danych w zależności od projektu? Wtedy filozofia zostaje ta sama, a wrażenie użytkownika jest o wiele lepsze.