Messaging, Notes & Push

Bu sayfa, Cınga backend içinde kullanıcıya dönük mesajlaşma, teknik notlar, inbox durumu ve push bildirim altyapısı için kullanılan veri modelini detaylı biçimde açıklar.

Bu katman telemetry veya inventory üretmez; onların ürettiği anlamı kullanıcıya okunabilir ve yönetilebilir biçimde taşır.

Katmanın Amacı

Bu katman şu ihtiyaçları karşılar:

• cihaz veya kullanıcı bağlamlı sistem mesajı üretmek
• kullanıcılar arası mesajlaşma tutmak
• teknik / operasyonel notları saklamak
• push bildirim şablonlarını merkezi yönetmek
• okundu, arşivlendi, snooze edildi gibi kullanıcı bazlı inbox durumlarını tutmak

Genel Akış

1. notes

notes, cihaz veya kullanıcı bağlamında serbest biçimli notları tutar.

Neden vardır?

Her önemli bilgi alarm veya measurement değildir. Saha gözlemi, bakım notu, kullanıcıyla konuşma özeti, hatırlatma veya teknik tespit gibi yapılar daha serbest bir veri modeli ister.

Kolonlar

Kolon	Tip	Null	Anlamı
id	int	hayır	Not anahtarı
device_id	varchar(21)	evet	Not belirli cihaza aitse
user_id	int	evet	Not belirli kullanıcı bağlamındaysa
title	varchar(250)	evet	Başlık
note	text	evet	Not içeriği
is_deleted	boolean	hayır	Soft delete
is_technical	boolean	hayır	Teknik not mu
reminder_sent	boolean	hayır	Hatırlatma gönderildi mi
reminder_time	timestamp	evet	Hatırlatma zamanı
created_by	int	evet	Oluşturan kullanıcı
updated_by	int	evet	Güncelleyen kullanıcı
create_time	timestamp	hayır	Oluşturma
update_time	timestamp	hayır	Güncelleme

Örnek kayıt

{
  "id": 1,
  "device_id": "46000000C47CA670",
  "user_id": 1,
  "title": "Pompa Kontrolü",
  "note": "Kuyu 1 cihazında pompa akım değerleri son kontrolde normal göründü.",
  "is_deleted": false,
  "is_technical": true,
  "reminder_sent": false,
  "reminder_time": null,
  "created_by": 1,
  "updated_by": 1
}

2. inbox

inbox, sistem ve kullanıcı kaynaklı mesajların ana gövde tablosudur.

Neden vardır?

Alarm, offline bildirimi, hoş geldin mesajı, kullanıcı mesajı veya cihaz bazlı operasyon mesajı gibi farklı türler tek bir ortak mesaj kanalı üzerinden yönetilebilir.

Tasarım kararı

Mesaj gövdesi tek yerde oluşur; kullanıcıya özel okuma, klasör ve arşiv durumu ayrı tabloda tutulur. Böylece aynı mesaj birden fazla kullanıcıya farklı okunma durumlarıyla sunulabilir.

Kolonlar

Kolon	Tip	Null	Anlamı
id	bigint	hayır	Mesaj anahtarı
type	varchar(30)	hayır	Mesaj tipi
sender_id	int	evet	Mesajı oluşturan kullanıcı
receiver_id	int	evet	Doğrudan kullanıcı hedefi
device_id	varchar(21)	evet	Cihaz bağlamlı mesaj hedefi
title	text	hayır	Başlık
message	text	hayır	Mesaj içeriği
tags	json	evet	Kategori, severity vb.
reply_to_id	bigint	evet	Yanıt ilişkisi
conversation_id	bigint	evet	Konuşma dizisi
payload	json	evet	Şablon / push parametreleri
push_state	boolean	hayır	Push gönderildi mi
push_sent_at	timestamp	evet	Push zamanı
create_time	timestamp	hayır	Oluşturma
update_time	timestamp	hayır	Güncelleme

Önemli not

Bu modelde receiver_id ile device_id aynı anda kullanılmaz. Mesaj ya kullanıcı bazlıdır ya cihaz bağlamlıdır.

Örnek kayıt

{
  "id": 2,
  "type": "alert",
  "sender_id": null,
  "receiver_id": null,
  "device_id": "46000000C47CA670",
  "title": "Pompa Alarmı",
  "message": "Cihazda kritik akım alarmı oluştu.",
  "tags": { "category": "alarm", "severity": "high" },
  "payload": {
    "push_template": { "code": "DEVICE_ALARM", "version": 1, "locale": "tr" },
    "push_params": { "device_name": "Kuyu 1 PowerStat", "alarm": "Kritik akım alarmı" }
  },
  "push_state": true,
  "push_sent_at": "2026-04-03T10:30:05Z"
}

3. message_read_state

Bu tablo aynı mesajın kullanıcı bazlı okuma, klasör ve görünürlük durumunu tutar.

Neden ayrı tablodur?

Çünkü aynı inbox mesajı bir kullanıcı için okunmuş, başka biri için okunmamış olabilir. Mesaj gövdesi ile kullanıcıya özgü okuma durumu aynı satırda tutulmamalıdır.

Kolonlar

Kolon	Tip	Null	Anlamı
id	bigint	hayır	Durum anahtarı
message_id	bigint	hayır	İlgili inbox mesajı
user_id	int	hayır	Kullanıcı
status	enum	hayır	unread / read / deleted
folder	enum	hayır	inbox / archived / trash
snooze_until	timestamp	evet	Görünürlüğü erteleme zamanı
auto_archive_at	timestamp	evet	Otomatik arşiv zamanı
pinned	boolean	hayır	Pinli mi
read_time	timestamp	evet	Okuma zamanı
create_time	timestamp	hayır	Oluşturma
update_time	timestamp	hayır	Güncelleme

Örnek kayıt

{
  "id": 2,
  "message_id": 2,
  "user_id": 1,
  "status": "unread",
  "folder": "inbox",
  "snooze_until": null,
  "auto_archive_at": "2026-04-10T10:30:00Z",
  "pinned": true,
  "read_time": null
}

4. push_templates

Push bildirimlerinde tekrar eden metin şablonlarının sözlüğüdür.

Neden vardır?

Push metnini kod içinde dağınık string’lerle üretmek yerine şablonlaştırmak:

• lokalizasyonu
• versiyonlamayı
• tekrar kullanımını kolaylaştırır.

Kolonlar

Kolon	Tip	Null	Anlamı
id	bigint	hayır	Şablon anahtarı
code	varchar(100)	hayır	Şablon kodu
version	int	evet	Versiyon
locale	varchar(10)	hayır	Dil/bölge
title_template	text	hayır	Başlık şablonu
message_template	text	hayır	Mesaj şablonu
create_time	timestamp	hayır	Oluşturma
update_time	timestamp	hayır	Güncelleme

Örnek kayıt

{
  "id": 2,
  "code": "DEVICE_ALARM",
  "version": 1,
  "locale": "tr",
  "title_template": "{{device_name}}",
  "message_template": "{{alarm}} oluştu."
}

5. user_inbox_settings

Bu tablo kullanıcı bazlı inbox davranış tercihlerini taşır.

Neden vardır?

Farklı kullanıcılar farklı arşiv, snooze ve pin davranışı isteyebilir. Bu tercihleri kullanıcı tablosunda tutmak yerine ayrı ayar tablosunda saklamak daha temizdir.

Kolonlar

Kolon	Tip	Null	Anlamı
user_id	int	hayır	Kullanıcı
auto_archive_days_unread	int	hayır	Okunmamış mesajların arşiv süresi
auto_archive_days_read	int	hayır	Okunmuş mesajların arşiv süresi
include_system_in_auto	boolean	hayır	Sistem mesajları da arşiv kuralına dahil mi
snooze_allowed	boolean	hayır	Kullanıcı snooze kullanabilir mi
pin_exempts_auto	boolean	hayır	Pinli mesajlar otomatik arşivden muaf mı
update_time	timestamp	hayır	Güncelleme

Örnek kayıt

{
  "user_id": 1,
  "auto_archive_days_unread": 7,
  "auto_archive_days_read": 30,
  "include_system_in_auto": true,
  "snooze_allowed": true,
  "pin_exempts_auto": true
}

Katmandaki Temel Tasarım Kararları

Mesaj gövdesi ile kullanıcı durumu ayrıdır

inbox mesajın kendisini taşır; message_read_state ise kullanıcı bazlı okunma ve klasör durumunu taşır.

Teknik not ile sistem mesajı aynı şey değildir

• notes serbest içerik ve insan odaklı saha bilgisidir
• inbox ise sistem içinde akışa giren mesaj nesnesidir

Push şablonları merkezi tutulur

Şablon kodu ve locale mantığı push üretimini tekrar kullanılabilir hale getirir.

Sonuç

Messaging, Notes & Push katmanı; telemetry, rule engine ve kullanıcı işlemlerinden doğan anlamı insanlara aktarır. Bu modelde serbest not, inbox mesajı, okuma durumu ve push şablonu aynı deneyim alanında görünse de veri modelinde rolleri ayrı tutulur. Bu ayrım hem esneklik hem de kullanıcı deneyimi açısından önemlidir.