Kullanım kılavuzu

Başlarken

Panel nedir?

F13 Hub, Odoo için eksiksiz bir geliştirme ve barındırma akışını Türkiye’deki sunucularda sağlayan yönetim panelidir. GitHub deponuzdaki her branch otomatik olarak bir Odoo ortamına dönüşür: kod push edildiğinde derlenir, test edilir ve kendi adresinde yayına girer.

• Seçtiğiniz sürümün Odoo Community kodu doğrudan Odoo’nun resmi GitHub deposundan alınır.
• Deponuz boşsa sadece Odoo kurulur; kodunuzu push ettiğinizde üzerine eklenir.
• Her ortamın kendi veritabanı, dosya deposu (filestore), adresi ve logu vardır.
• Tüm müşteri verisi F13 sunucularında ya da sizin seçtiğiniz sunucuda kalır.

Panelin üst menüsünde Projeler, Destek ve kendi adınız (hesap sayfası) bulunur. Platform yöneticileri ayrıca Platform ve Yönetim menülerini görür.

Roller ve yetkiler

Yetkiler müşteri (firma) düzeyinde verilir; bir kişinin rolü o müşterinin tüm projelerinde geçerlidir.

Kılavuzdaki her bölümün başında o işlemi kimlerin yapabileceği etiketle gösterilir.

Giriş ve hesabınız

Giriş ekranında kullanıcı adınızı, e-posta adresinizi ya da bağlı GitHub kullanıcı adınızı yazabilirsiniz. Üst üste hatalı denemelerde giriş 15 dakika kilitlenir.

Adınıza tıklayarak açılan hesap sayfasında şunlar bulunur:

• GitHub hesabı: kullanıcı adınızı bağlayın; SSH anahtarlarımı GitHub’dan al ile GitHub’daki anahtarlarınız tek tıkla eklenir.
• Şifre: size geçici şifreyle hesap açıldıysa ilk girişte buradan değiştirin.
• SSH anahtarları: ortamlara SSH ile bağlanmak için public key’inizi (ssh-ed25519 AAAA…) ekleyin.
• İki adımlı doğrulama (2FA): Google Authenticator, Microsoft Authenticator gibi bir uygulamayla QR kodu okutup etkinleştirin.

Projeler ve ortamlar

Proje oluşturma

+ Yeni proje düğmesiyle açılan formdaki alanlar:

Proje oluşturulunca GitHub webhook’u otomatik kurulur ve production’ın ilk build’i başlar. Webhook kurulamazsa proje ayarlarındaki bilgilerle elle eklenebilir.

Production, Staging, Development

Her branch bir aşamadadır. Veritabanı aşamaya göre farklı ele alınır:

Proje sayfasının solunda branch’ler bu üç başlık altında listelenir. Yeşil nokta çalışıyor, sarı derleniyor, kırmızı hatalı demektir.

Branch açma, taşıma, birleştirme

Yeni branch

Staging ya da Development başlığının yanındaki + düğmesine basın; kaynak branch’i, yeni adı ve aşamayı seçin. Branch GitHub’da da oluşturulur ve derlenir. Bir branch’in araç çubuğundaki ⑂ Fork aynı pencereyi o branch kaynak olarak seçili açar.

Sürükle-bırak

• Development → Staging: branch staging olur, production verisinin nötralize kopyasıyla yeniden derlenir.
• Staging → Development: veritabanı sıfırdan kurulur.
• Herhangi bir branch → Production: branch, production branch’i ile GitHub’da birleştirilir (merge) ve production yeniden derlenir. Sadece yöneticiler.

Telefonda sürüklemek için branch’e basılı tutun. Her taşımadan önce onay istenir.

Pull request’ler

GitHub’da açılan her pull request otomatik olarak pr/<numara> adlı bir development ortamı olarak derlenir. Fork’lardan gelen PR’lar güvenlik nedeniyle varsayılan olarak derlenmez; proje ayarlarından açılabilir.

Build’ler ve geçmiş

Bir branch’e push yapıldığında build başlar: Odoo ve kodunuz çekilir, imaj derlenir, veritabanı aşamaya göre hazırlanır ve ortam yayına girer. Build sonucu GitHub’da commit’in yanında da görünür.

Geçmiş sekmesi

Build’ler tarihe göre gruplanır. Her kartta build’in getirdiği commit’ler (GitHub bağlantılı), yazar, süre ve test sonucu yer alır.

• BAĞLAN — yayındaki build. Yanındaki okla giriş ekranı, admin giriş bilgisi, shell ve loglara gidilir.
• DROPPED — daha yeni bir build yayına girdiği için kaldırılmış eski build.
• HATALI — build başarısız. Build logu ile ayrıntıyı görün; logda 💬 Destek iste kısayolu vardır.

Build’ler sayfası

Proje menüsündeki Build’ler, tüm branch’leri aşamalarına göre satırlar halinde, her birinin son dört build’iyle gösterir. Yeniden derle düğmesi aynı commit’i tekrar derler; development’ta bu veritabanını sıfırlar.

Testler ve CI

Development ve pull request build’lerinde kurulan modüllerin testleri --test-enable ile çalışır. Test sonucu build kartında ve CI / Testler sayfasında görünür; sayfa projedeki başarı oranını da gösterir.

Hangi modüllerin kurulacağı ve testlerin nasıl çalışacağı proje ayarlarında seçilir: depodaki modüller, tüm standart Odoo modülleri ya da belirli bir liste; testler kapalı, kurulan modüller ya da özel --test-tags filtresi.

Branch sekmeleri

Araç çubuğu

Branch başlığının altındaki araç çubuğu:

Submodule ve OCA modülleri

Submodule’ler sekmesinden başka depolardaki modülleri ekleyebilirsiniz. Depo alanına şunlardan birini yazın:

• OCA deposunun adı: queue
• OCA/queue ya da https://github.com/OCA/queue
• GitHub’dan kopyalanan bir modül bağlantısı: https://github.com/OCA/queue/tree/19.0/queue_job

Modüller alanına ad yazarsanız (ör. queue_job) deponun tamamı değil sadece o modüller ve bağımlılıkları eklenir. Boş bırakılırsa depo bütün olarak eklenir. Değişiklik GitHub’a commit’lenir ve branch yeniden derlenir. Eklenen modüller Odoo’da Uygulamalar menüsünden kurulur.

Loglar ve shell

Loglar sekmesi Odoo logunu canlı akıtır; seviyeye göre (hata, uyarı, bilgi) süzülebilir ve indirilebilir.

Shell sekmesi tarayıcıda bir terminal açar. Üç kip vardır:

• Bash — konteynerin içinde komut satırı.
• Odoo shell — Python ile doğrudan env['res.partner'] gibi Odoo nesnelerine erişim.
• psql — ortamın veritabanında SQL.

SSH erişimi

Hesap sayfasına SSH anahtarınızı ekledikten sonra her ortama şu biçimde bağlanırsınız (tam komut branch’in araç çubuğunda ve Shell sekmesinde yazar):

ssh -t -p 2222 odoo@panel-sunucusu proje-branch

Komutun sonuna bir komut ekleyerek tek seferlik çalıştırabilirsiniz, ör. … proje-main odoo shell. Proje yöneticisi production ve staging’e SSH’ı belirli IP adresleriyle sınırlamış olabilir; bkz. SSH güvenlik duvarı.

Editör

Editör sekmesi branch’in kodunu tarayıcıda VS Code ile açar.

1. Editörü başlat‘a basın. İlk açılışta kod GitHub’dan kopyalanır; bu birkaç dakika sürebilir.
2. Gösterilen şifreyi kopyalayıp Editörü aç ↗ ile açılan sayfada girin.
3. Değişikliklerinizi yapın ve editörün Git panelinden ya da terminalinden commit’leyin.
4. Panelde GitHub’a gönder (push)‘a basın. Push yeni build’i başlatır.

GitHub’dan çek başkalarının push ettiği değişiklikleri editöre alır. Kopyayı sıfırla editördeki gönderilmemiş her şeyi siler. Sekmedeki Git durumu commit’lenmemiş dosyaları ve gönderilmemiş commit’leri listeler.

Mailler

Staging ve development ortamlarından gönderilen tüm mailler gerçek alıcılara gitmez; Mailler sekmesinde yakalanır ve okunabilir. Böylece müşterilere yanlışlıkla test faturası gitmez. Gönderen adresi olmayan mailler notifications@<ortam adresi> adıyla yakalanır.

Production mailleri gerçek alıcılara platformun e-posta sunucusu ya da Odoo’da tanımladığınız giden mail sunucusu üzerinden gider.

İzleme ve durum

Her ortam dakikada bir kontrol edilir. İzleme sekmesi 24 saat, 7 gün ve 30 günlük erişilebilirliği, ortalama yanıt süresini, CPU ve bellek kullanımını gösterir. Üç ardışık başarısız kontrol kesinti olarak kaydedilir.

Proje menüsündeki Durum sayfası tüm branch’lerin erişilebilirlik şeridini ve son kesintileri tek ekranda toplar.

Yedekler ve geri yükleme

• Otomatik: production her gece 03:00’te yedeklenir. Yedekler 14 gün saklanır; ayrıca şifreli olarak başka bir lokasyona da kopyalanabilir.
• Güvenlik yedeği: production güncellenmeden ve geri yüklenmeden önce otomatik alınır.
• Elle: Şimdi yedek al.

Yedekler Odoo’nun standart formatındadır (dump.sql + filestore, .zip). İndirebilir, başka bir Odoo’ya yükleyebilirsiniz. Başka bir barındırmadan aldığınız Odoo yedeğini Yedek yükle ile içeri alıp bir ortama geri yükleyebilirsiniz.

Production yedekleri staging ve development’a da geri yüklenebilir; bu durumda veri otomatik nötralize edilir.

Sürüm yükseltme

Yükseltme sekmesi projeyi bir sonraki Odoo sürümüne (ör. 18.0 → 19.0) taşır. Yükseltme OCA OpenUpgrade ile sunucuda yapılır; veritabanınız yurt dışına gönderilmez.

1. Yükseltme testi

Kendi modüllerinizi yeni sürüme uyarladığınız bir GitHub branch’i seçin (yoksa sadece standart modüller taşınır) ve Yükseltme testini başlat‘a basın. Production’ın nötralize kopyası yeni sürüme taşınır ve ayrı bir staging ortamında açılır. O branch’e her push’ta test baştan tekrarlanır.

2. Production’ı yükselt

Test başarılıysa Production’ı yükselt. Sırasıyla: güvenlik yedeği → test branch’i production’a birleştirilir → proje yeni sürüme geçer → production veritabanı taşınır → yeni sürüm yayına girer. Herhangi bir adımda hata olursa yedek geri yüklenir ve production eski sürümde açılır. İşlem boyunca production kapalıdır; mesai dışını tercih edin.

Ortam ayarları ve paylaşım

Branch’in Ayarlar sekmesinde:

• Ortamın adresleri, veritabanı adı, worker sayısı ve admin giriş bilgisi (yeni kurulan veritabanlarında rastgele şifre).
• Durdur / Başlat — production’ı sadece yönetici durdurabilir.
• Paylaş: bağlantıyı herkese açık bırakın ya da 🔒 Şifreli paylaş ile kullanıcı adı ve şifre isteyen bir bağlantı üretin. Müşterinize test ortamı göstermek için idealdir.
• Aşama değiştir: staging ↔ development.
• Sil: onay için branch adını yazın. Ortam, veritabanı ve yedekleri silinir; GitHub’daki branch silinmez.

Proje yönetimi

Proje ayarları

Proje menüsündeki Ayarlar sayfasının bölümleri:

Alan adı, zaman aşımı ve worker değişiklikleri ortam yeniden derlendiğinde uygulanır.

Ekip yönetimi

Ayarlar → Ekip bölümünde kişiyi GitHub kullanıcı adıyla (@kullanici) ya da e-postasıyla ekleyin ve rol seçin.

• GitHub adıyla eklenen kişinin avatarı görünür ve GitHub’daki SSH anahtarları otomatik eklenir.
• Panelde hesabı yoksa açılır ve geçici şifre bir kez gösterilir; kişiye iletin, ilk girişte değiştirmesini isteyin.
• Rolü satırdaki listeden değiştirin; ✕ ile çıkarın.

Özel alan adı

1. DNS sağlayıcınızda alan adınız için (ör. erp.sirketiniz.com.tr) sunucunun IP adresine bir A kaydı ya da panel adresine bir CNAME oluşturun.
2. Proje ayarlarında alan adını yazıp DNS’i kontrol et‘e basın.
3. Ayarları kaydedip production’ı yeniden derleyin. SSL sertifikası (Let’s Encrypt) otomatik alınır.

İsterseniz varsayılan adresi kapat ile production’ı yalnızca kendi alan adınızdan erişilebilir yapın.

Denetim kaydı

Proje menüsündeki Denetim kaydı; shell oturumlarını, yedek indirme ve geri yüklemeleri, branch işlemlerini, ayar ve ekip değişikliklerini kim, ne zaman yaptı bilgisiyle listeler. KVKK kapsamındaki hesap verebilirlik için saklanır.

Proje silme

Ayarlar sayfasının en altındaki Tehlikeli bölge‘de projenin kısa adını yazıp Projeyi sil‘e basın. Tüm ortamlar, veritabanları, filestore ve bütün yedekler kalıcı olarak silinir; GitHub deposuna dokunulmaz. Silme işlemi kim, ne zaman, neyi sildi bilgisiyle kalıcı olarak kayda geçer.

Destek

Destek talebi açma

1. Üst menüden Destek → + Yeni talep.
2. İlgili ortamı seçin. Seçerseniz son build, hata logu ve izleme durumu talebe otomatik eklenir; destek ekibi bunları sormak zorunda kalmaz.
3. Kategori ve öncelik seçin, sorunu adım adım anlatın, ekran görüntüsü ekleyin (en fazla 5 dosya, 10 MB).

Destek ekibi yanıt verdiğinde e-posta alırsınız ve menüdeki Destek yanında bir sayı belirir. Talebin içinden yanıt yazabilir, çözüldüğünde Sorunum çözüldü, kapat ile kapatabilirsiniz. Kapalı bir talebe yazmak onu yeniden açar.

Platform yöneticileri

Yönetim alanı

Üst menüdeki Yönetim:

• Genel bakış — müşteri, proje, ortam sayıları ve sunucu durumu.
• Müşteriler — firma ekleme, üyelik ve roller, pasifleştirme.
• Kullanıcılar — hesaplar, yönetici yetkisi.
• Projeler — tüm projeler, arama, silme.
• Sunucular — müşterinin kendi sunucuları (ajan).
• Enterprise — Odoo Enterprise kaynak deposu.
• Destek talepleri, Denetim kaydı, Silme kayıtları (CSV olarak indirilebilir).

Yönetici hesaplarında iki adımlı doğrulama zorunludur; etkinleştirilmeden panel kullanılamaz.

Müşterinin kendi sunucusu

Müşteri Odoo’sunu kendi sunucusunda (AWS, Google Cloud, Bulutistan, kendi veri merkezi) tutmak isterse o sunucuya OdooPanel ajanı kurulur. Panel tek yerde kalır; veritabanı, dosyalar ve yedekler müşterinin sunucusundan çıkmaz.

1. Yönetim → Sunucular → Yeni sunucu: ad, sağlayıcı, isteğe bağlı sahip müşteri.
2. Gösterilen kurulum komutunu sunucuda root olarak çalıştırın. Komut bir kez gösterilir.
3. Sunucu birkaç saniyede “Çevrimiçi” olur; yeni projede Sunucu alanından seçin.

curl -fsSL https://panel.…/agent/install.sh | sudo bash -s -- --token op_…

Ajan panele yalnızca dışarı doğru bağlanır; sunucuda 80 ve 443 dışında port açmak gerekmez. Panel güncellendiğinde ajan kendini otomatik günceller. Token sızarsa Token yenile ile eskisi anında geçersiz olur.

Odoo Enterprise kaynağı

Enterprise kodu F13’ün kendi GitHub deposundan çekilir. Yönetim → Enterprise sayfasında:

1. Depoyu (ör. TechF13/enterprise) ve yalnızca okuma izinli (Contents: Read) token’ı girin.
2. Branch adları sürüm adlarından farklıysa kalıbı değiştirin (ör. saas-{version}).
3. Erişimi test et ile hangi sürüm branch’lerinin bulunduğunu görün. İsterseniz Şimdi çek.

Enterprise kullanan her build, sürüm branch’inin son commit’ini otomatik alır. Çalışan ortamlar güncellemeden etkilenmez; yeni commit bir sonraki derlemede devreye girer. Uzak sunuculardaki ajanlar da aynı depoyu kullanır.

Destek kuyruğu

Destek sayfası yöneticilere tüm müşterilerin taleplerini kuyruk olarak gösterir: yanıt bekleyen, atanmamış, bana atanan sayaçları; durum, öncelik ve müşteri filtreleri; konu, mesaj ya da #1001 gibi numarayla arama.

• Sağ panelden sorumlu atayın, durum ve önceliği değiştirin. Her değişiklik talebin geçmişine yazılır.
• Yanıt yazarken İç not‘u işaretlerseniz müşteri o mesajı ve eklerini görmez.
• Gönderirken talebin yeni durumunu seçin: müşteri yanıtı bekleniyor, inceleniyor ya da çözüldü.
• İlk yanıt hedefi aşılan talepler SLA aşıldı olarak işaretlenir.

Yeni talepler ve müşteri yanıtları destek adresine ve sorumluya e-postayla bildirilir (sunucuda e-posta ayarı yapılmış olmalı).

Ek

Sorun giderme

Build “could not read Username” ya da “depoya erişilemedi” hatası verdi.

Depo özel ve token eksik ya da yetkisiz. Proje ayarlarına Contents: Read izinli bir token girin; Erişimi ve webhook’u doğrula ile kontrol edin.

Push yaptım ama build başlamadı.

Webhook eksik ya da hatalı olabilir. Proje ayarlarında Webhook’u yeniden oluştur‘a basın. Beklerken Yeniden derle ile elle başlatabilirsiniz.

Staging’den gönderilen mail Mailler sekmesinde yok.

Odoo’da Ayarlar → Teknik → E-postalar altında mailin durumuna bakın; kuyruk dakikada bir çalışır. Hata varsa destek talebi açın.

Ortam yavaş.

İzleme sekmesinde yanıt süresine ve belleğe bakın. Dış servislere (ör. şirket adı otomatik tamamlama) bağlanamayan istekler bekleyebilir; kalıcıysa ortam seçili olarak destek talebi açın, izleme verisi talebe otomatik eklenir.

Özel alan adım açılmıyor.

DNS’i kontrol et ile kaydın doğru IP’yi gösterdiğini doğrulayın, ardından production’ı yeniden derleyin. DNS değişikliğinin yayılması birkaç saat sürebilir.

SSH “Bu IP adresinden SSH izni yok” diyor.

Proje SSH güvenlik duvarı açık. Proje yöneticisinden IP adresinizi listeye eklemesini isteyin.

Development ortamım durmuş.

Günlerce kullanılmayan development ortamları kaynak tasarrufu için durdurulur. Ayarlar sekmesinden Başlat‘a basın.

Güvenlik ve KVKK

• Müşteri verisi F13’ün Türkiye’deki sunucularında ya da müşterinin kendi sunucusunda kalır. Sürüm yükseltme de yerel yapılır.
• Her projenin kendi veritabanı kullanıcısı vardır; bir müşterinin bilgileri başka müşterinin veritabanına erişemez. Müşteri ortamları ayrı bir ağda, bellek ve işlem sınırlarıyla çalışır.
• GitHub token’ları ve veritabanı şifreleri şifreli saklanır; editöre ve arayüze hiç yansımaz.
• Shell, yedek, geri yükleme, ekip ve ayar değişiklikleri denetim kaydında; silinen proje ve müşteriler kalıcı silme kaydında tutulur.
• Staging ve development verisi nötralize edilir: mailler yakalanır, zamanlanmış eylemler ve ödemeler kapanır.
• İki adımlı doğrulama tüm kullanıcılar için kullanılabilir, yöneticiler için zorunludur.