Ana içeriğe geç

users

users, sistemdeki gerçek kullanıcı kimliğinin ana tablosudur.

Bu tablo sistemin temel kimlik katmanıdır. Uygulamaya giriş yapan her kişi burada tanımlanır. Notlar, inbox mesajları, finansal işlemler ve cihaz yetkileri hepsi kullanıcı kimliği etrafında döner. Mobil uygulama oturumları da bu tablo ile ilişkilendirilir; mobile_devices tablosu bu kullanıcı grubunun hangi fiziksel telefon/cihazdan giriş yaptığını ve her cihazın push token'ını tutar. Kısaca: sistem içinde bir kişi kim, nasıl giriş yapar, genel rolü nedir sorusunun cevabı bu tabloda yer alır.

Yeni kayıtta role_id değeri tek bir sabit default ile verilmez; onboarding kaynağına göre atanır. Kural: Maraba uygulamasından gelen kullanıcı için 21 (farmer_employee), Qapu uygulamasından gelen kullanıcı için 31 (corporate_operator), bayi panelinden gelen kullanıcı için 10 (dealer_admin) başlangıç rolü atanır. Bu atama uygulama servis katmanında yapılır.

AI servis kullanıcıları bu onboarding kuralının dışındadır. Agent kullanıcıları role_id: 6 (ai_agent) ile açılır, insan kullanıcı gibi mobil login/push akışına girmez ve cihaz bazlı authority kaydı oluşturulmaz.

Bu tablo yalnız kimlik ve giriş bilgisini taşır. Belirli bir cihaz üzerindeki yetki burada tanımlanmaz (o authorities tablosundadır). Cihaz başlat/durdur, nota ekleme, rapor görüntüleme gibi aksiyon izinleri bu tabloda değildir (authority_permissions tablosundadır). Mobil cihazın hangi push token'a sahip olduğu, OS bilgisi, model gibi teknik detaylar da bu tabloda tutulmaz (mobile_devices tablosundadır). Kısaca: bir kullanıcı hangi cihazda ne yapabilir sorusunun cevabı burada değildir.

Yapilacaklar (Soft Delete ve Audit)​

  • is_deleted boolean not null default false ve delete_time timestamp null alanlari eklendi.
  • created_by ve updated_by alanlari eklendi.
  • create_time ve update_time zorunlu yasam dongusu alanlari olarak korundu.
  • updated_by FK sertlestirmesi ve audit trigger migrationi uygulama asamasinda.

FK Davranis Notlari​

FKON DELETEON UPDATENot
users.role_id -> user_roles.idRESTRICTRESTRICTRol sozlugunde sessiz bozulma engellenir.
users.status_id -> statuses.idRESTRICTRESTRICTDurum sozlugu tutarliligi korunur.
users.address_id -> addresses.idSET NULLCASCADEAdres silinse de kullanici kaydi korunur.

Kolonlar​

KolonTipNullKısıtlarAnlamı
idinthayırPK, AUTO INCREMENTKullanıcı anahtarı
emailvarchar(100)evetUNIQUEE-posta ile giriş/iletişim
phone_numbervarchar(20)hayırUNIQUETelefon numarası (kayıtta zorunlu)
password_hashvarchar(255)evet-Parola hash'i
pin_codechar(4)hayırDEFAULT: phone_number son 4 hane4 haneli işlem PIN'i
first_namevarchar(100)hayır-Ad
last_namevarchar(100)hayır-Soyad
role_idinthayırFK → user_roles.id, uygulama kaynağına göre default (Maraba: 21, Qapu: 31, Bayi: 10)Genel rol
status_idinthayırFK → statuses.id, DEFAULT: 201Kullanıcı statüsü
address_idintevetFK → address.addresses.idAdres ilişkisi
last_login_timetimestampevet-Son giriş zamanı
marketing_consentbooleanhayırDEFAULT: falsePazarlama izni
is_deletedbooleanhayırDEFAULT: falseSoft delete bayrağı
delete_timetimestampevet-Soft delete zamanı
created_byinthayırFK → users.idKaydı oluşturan actor
updated_byinthayırFK → users.idKaydı güncelleyen actor
create_timetimestamphayır-Oluşturma
update_timetimestamphayır-Güncelleme

Security Notes​

  • pin_code alanı kullanım amacı gereği 4 haneli işlem doğrulama kodu olarak tutulur.
  • Bu alan parola yerine geçmez; yalnız işlem onayında kullanılır.
  • pin_code asla log, telemetry veya analitik çıktılarında düz metin olarak taşınmamalıdır.
  • İletim ve saklama güvenliği için uygulama katmanında maskeleme ve erişim sınırlaması zorunludur.

Doğrulama ve Guard Kuralları (Öneri)​

users tablosunda uygulama/DB seviyesinde aşağıdaki doğrulamalar önerilir:

  • pin_code her zaman 4 haneli numerik formatta olmalı.
  • Kullanıcı kaydında en az bir giriş yöntemi bulunmalı (email veya parola veya PIN).
  • Sistem kullanıcısı (id: 0) yalnızca 200 (System) statüsünde tutulmalı.
  • is_deleted = true ise delete_time dolu olmalı; aktif kayıtta delete_time null olmalı.
  • created_by ve updated_by alanları her insert/update işleminde set edilmelidir.
  • Operasyonel performans için role_id + status_id ve last_login_time alanlarında indeksleme uygulanmalı.

Örnek Kayıtlar​

{
  "id": 0,
  "email": null,
  "phone_number": "900000000000",
  "password_hash": null,
  "pin_code": "0000",
  "first_name": "Sistem",
  "last_name": "Otomasyonu",
  "role_id": 1,
  "status_id": 200,
  "address_id": null,
  "last_login_time": null,
  "marketing_consent": false,
  "is_deleted": false,
  "delete_time": null,
  "created_by": 0,
  "updated_by": 0,
  "create_time": "2026-01-01T00:00:00Z",
  "update_time": "2026-01-01T00:00:00Z"
}

Özet: Sistem tarafından oluşturulan sabit kayıt (ID: 0). Mobil app kurulumları, otomatik authority oluşturma gibi sistem olaylarında granted_by: 0 olarak yazılır. İnsan değildir, login yapamaz.