Toplu İşlem ve Çoklu Seçim Tablosu

Çoklu Seçim ve Toplu İşlem Tablosu

Sunucu taraflı DataTables üzerinde çoklu seçim ve toplu işlem. Seçili kayıtlar · Filtreye uyan TÜMÜ · Gerçek sayıyla onay · Onaylanan sayı denetimi

cilginyazilim.com  ·  Türkçe | English

---

Bu sayfadaki 10 satır işaretlendi. Çubuk belirdi ve “Filtreye uyan tüm 60 kaydı seç” bağlantısı çıktı —
seçimin ikinci anlamına geçiş buradan yapılır.

---

Bu proje ne yapıyor?

Bir bülten abone listesi üzerinde satırları işaretleyip toplu durum değiştirme ve toplu silme yapabilirsiniz. Ama asıl anlattığı şey bir arayüz hilesi değil:

Sunucu taraflı bir tabloda “seçili” kelimesinin iki farklı anlamı vardır ve bu iki anlamı birbirine karıştıran kod, kullanıcının onayladığından fazlasını siler.

Proje bu ayrımı kurar, iki anlamı tek bir doğru yoldan geçirir ve aradaki her boşluğu ölçüp kapatır.

---

“Seçili”nin iki hâli

Neden ikinci moda ihtiyaç var? — Gmail benzetmesi

Sunucu taraflı bir DataTables’ta kullanıcı asla tüm satırları aynı anda görmez; yalnızca o anki sayfayı görür. 50.000 kayıtlık bir listede “tümünü seç” dendiğinde 50.000 id’yi tarayıcıya indirip sonra sunucuya geri göndermek hem yavaştır hem anlamsızdır.

Gmail’de bir arama yaptığınızda üstteki kutucuğu işaretlersiniz ve şu çıkar: “Bu sayfadaki 50 konuşmanın tümü seçildi — bu aramaya uyan 4.312 konuşmanın tümünü seç.” İkinci bağlantıya bastığınızda Gmail size 4.312 kimlik göndermez; sunucuya “aynı arama koşulunu tekrar uygula, eşleşen herkese bu işlemi yap” der.

Bu proje tam olarak aynı deseni kurar:

resolve_bulk_scope()                             (system/ajax.php)
   scope=selected  →  WHERE id IN (:id0, :id1, :id2, …)
   scope=filtered  →  WHERE (name LIKE :s_name OR email LIKE :s_email
                             OR segment LIKE :s_segment) AND status = :status

Kritik nokta: koşul TEK YERDE üretilir

scope=filtered koşulu, ekrandaki listeyi üreten koşulla birebir aynı fonksiyondan gelir: subscriber_filter().

Bu koşul eskiden üç ayrı yerde (listeleme, sayaç, toplu işlem) kopyalanmıştı. Biri güncellenip diğeri unutulduğunda ortaya çıkacak hata sessizdir ve yıkıcıdır: kullanıcı ekranda 12 kişi görür, “tümünü seç” der, toplu işlem 15 kişiyi siler. Bu yüzden kopyanın kaldırılması burada bir temizlik değil, doğrudan bir güvenlik önlemidir.

---

Yanlışlıkla silmeye karşı iki ayrı fren

“Emin misiniz?” değil, “60 kayıt kalıcı olarak SİLİNECEK.”

1. Fren — Gerçek sayıyla onay (bulk_preview)

Toplu işlem tetiklendiğinde önce bulk_preview uç noktasına gidilir. Sayı, işlemi yapacak olan resolve_bulk_scope()’un ta kendisinden gelir; önizlemenin ayrı bir hesap yolu olsaydı gösterdiği sayı bir süsten ibaret kalırdı.

Sayı her zaman veritabanından sayılır. Eskiden seçili kapsamda istemcinin gönderdiği id adedi döndürülüyordu; var olmayan 10 id gönderildiğinde pencere “10 kayıt SİLİNECEK” diyor, gerçekte 0 kayıt siliniyordu. Onay penceresinin tek varlık sebebi gerçeği göstermek olduğuna göre, o sayının kaynağı istemci olamaz.

2. Fren — Onaylanan sayı denetimi (expected_count)

Önizleme ile onay arasında geçen sürede liste değişebilir. Ölçülen senaryo: kullanıcı 8 kayıt için onay verdi, başka bir sekme araya bir kayıt ekledi, silme 9 kaydı götürdü.

Artık istemci, onay penceresinde gördüğü sayıyı işlem isteğiyle birlikte geri gönderir (expected_count). Sunucu kendi saydığı sayıyla karşılaştırır:

expected_count eksik              → 422, işlem yapılmaz
expected_count ≠ gerçek sayı      → 409, işlem yapılmaz, güncel sayı döner
yazma sırasında sayı kayarsa      → transaction geri alınır (rollback), 409

Arayüz 409’u bir hata olarak değil, bir fren olarak karşılar: listeyi tazeler ve onayı güncel sayıyla yeniden sorar.

“8 kayıt silinecek” onayı, 9 kaydı silmeye yetki vermez. Bu cümle projenin tamamının özetidir.

---

Ölçülen ve kapatılan sorunlar

Aşağıdakilerin hepsi çalışan kurulumda HTTP üzerinden ölçüldü, düzeltildi ve yeniden ölçüldü.

Denenip sorun çıkmayan noktalar

Bunlar da ölçüldü; burada bir açık bulunamadı ve kod olduğu gibi bırakıldı:

• SQL enjeksiyonu — sıralama sütunu: İstemci sütun adı değil, bir dizi indisi gönderir; tanınmayan indis id’ye düşer. order[0][column] alanına SQL parçası gönderildi, sorgu normal çalıştı.
• XSS: ` ve "> yükleri kayıt olarak eklendi; listede <script> olarak kaçışlı döndü. table.js metinleri .text() ile yazar, .html() ile değil.
• LIKE joker karakterleri: Arama kutusuna % yazıldığında 0 sonuç döndü (escape_like() çalışıyor) — aksi hâlde tek karakterlik bir arama tüm tabloyu “filtreye uyan tümü” kapsamına sokardı.
• BULK_MAX_IDS = 500: 501 id gönderildi → HTTP 422. Sınır gerçekten uygulanıyor.
• CSRF anahtarı oturuma bağlı: Başka bir oturumun anahtarıyla istek 403` aldı.

Bilinçli olarak değiştirilmeyen davranış

Filtre boşken scope=filtered tüm tabloyu hedefler. Ölçüm: bulk_preview → count: 60 (60 kayıttan 60’ı). Bu, Gmail’in “tüm konuşmaları seç” davranışının aynısıdır ve kaldırılmadı — “filtreyi temizleyip hepsini seçmek” meşru bir istektir; yasaklamak kullanıcıyı 500’er kayıtlık turlara zorlardı.

Yeterli koruma olduğu kanaatine şu gerekçeyle varıldı: bu işlem artık üç ayrı kapıdan geçiyor. Önizleme gerçek sayıyı yazıyor (“60 kayıt kalıcı olarak SİLİNECEK”), onaylanan sayı sunucuda doğrulanıyor, ve arayüzde bu moda geçmek ayrı bir bilinçli tıklama gerektiriyor. Sayının kendisi zaten en güçlü uyarıdır: tablonun tamamı olduğunda kullanıcı bunu okuyarak görür.

Transaction: neden var, neden tek başına gerekmezdi

bulk_status ve bulk_delete tek bir SQL ifadesi çalıştırır — tek ifadeli DML zaten atomiktir, bu hâliyle transaction tek başına gereksiz olurdu. Buradaki gerçek gerekçe, yazma sonrası yapılan “onaylanandan fazlasına dokundum mu?” denetimidir: sayım, yazma ve geri alma kararı ancak transaction içinde tek bir bütün olur. Transaction olmasaydı farkı görsek bile silinen kayıtları geri getiremezdik. (system/ajax.php execute_bulk())

---

Güvenlik katmanları ve her birinin nedeni

---

Kurulum

cd C:/xampp/htdocs
git clone https://github.com/CilginYazilim/bulk-actions-table.git

mysql -u root -p < bulk-actions-table/cy_bulk.sql

Tarayıcıdan: http://localhost/bulk-actions-table/

Canlıya alırken system/config.php içindeki APP_DEBUG değerini false yapın — açık kaldığında veritabanı hata metinleri istemciye gider.

Gereksinimler: PHP 8.0+ (PDO MySQL), MySQL 5.7+ / MariaDB 10.3+, Apache (mod_headers önerilir). Harici bağımlılık yoktur; jQuery, Bootstrap ve DataTables depoda gelir.

---

Dosya yapısı

bulk-actions-table/
├── index.php                  ← Arayüz: tablo, toplu işlem çubuğu, üç modal
├── cy_bulk.sql                ← Veritabanı kurulumu (cy_bulk, 60 örnek abone)
├── .htaccess                  ← Dizin listeleme kapalı, .sql/.md engelli, güvenlik başlıkları
├── system/
│   ├── .htaccess              ← Beyaz liste: yalnızca ajax.php dışarı açık
│   ├── config.php             ← Ayarlar, durum tanımları, PDO bağlantısı
│   ├── function.php           ← Çıktı/CSRF/doğrulama + subscriber_filter() (TEK doğruluk kaynağı)
│   └── ajax.php               ← 8 uç nokta + resolve_bulk_scope() + execute_bulk()
└── assets/
    ├── css/cilginyazilim.css  ← Marka tasarım kalıbı (ortak)
    ├── css/style.css          ← Sayfaya özel stiller
    └── js/table.js            ← Seçim durumu: selectedIds / selectAllMatching

Hangi fonksiyon ne yapıyor?

Seçim durumu nerede tutulur?

Tamamen istemcide: table.js içinde bir Set (selectedIds) ve bir bayrak (selectAllMatching). Sunucu her zaman işaretsiz checkbox döndürür; hangi satırın işaretli görüneceğine istemci karar verir (restoreCheckboxState()).

Arama veya durum filtresi değiştiğinde seçim otomatik sıfırlanır: “filtreye uyan tümü” seçimi belirli bir filtreye bağlıdır, filtre değişince o seçimin ne anlama geldiği belirsizleşir.

İki sekme açıksa: her sekmenin kendi selectedIds’i vardır; birbirlerini görmezler ve görmeleri de gerekmez, çünkü seçim bir kullanıcı niyetidir, paylaşılan bir durum değil. Sekmeler arası asıl risk seçimin değil, sayının kaymasıdır — onu da expected_count denetimi kapatır (ölçüldü: HTTP 409, veri değişmedi).

---

API uç noktaları

Hepsi system/ajax.php adresine POST ile gider ve JSON döner. action=list dahil tümü csrf_token ister.

Kapsam alanları: scope=selected → ids[] · scope=filtered → search, status_filter

HTTP durum kodları

419 bilerek kullanılmaz: resmî bir kod değildir ve bu Apache kurulumunda sessizce 500’e dönüşerek istemciyi yanıltır.

---

Veritabanı şeması

cy_bulk · tek tablo: subscribers (60 örnek kayıt — aktif 47, pasif 9, engelli 4)

İndeksler neden bu sütunlarda? (123.000 kayıtla ölçüldü)

Arama neden hâlâ ~300 ms? Arama LIKE '%metin%' kullanır; baştan joker içeren kalıp hiçbir indeksten yararlanamaz. Bunun çözümü indeks eklemek değil FULLTEXT indekse ya da ayrı bir arama motoruna geçmektir — örneğin sade tutmak için bilinçli olarak yapılmadı.

---

Özelleştirme

Yeni bir durum eklemek — tek yer yeterli, config.php:

define('SUBSCRIBER_STATUSES', [
    'aktif'   => ['label' => 'Aktif',   'css' => 'success'],
    'pasif'   => ['label' => 'Pasif',   'css' => 'secondary'],
    'engelli' => ['label' => 'Engelli', 'css' => 'danger'],
    'beklemede' => ['label' => 'Beklemede', 'css' => 'warning'],   // ← yeni
]);

Form açılır listesi, filtre kutusu, rozetler, toplu işlem menüsü ve doğrulama hepsi buradan beslenir. Ayrıca cy_bulk.sql içindeki ENUM değerini genişletmeyi unutmayın.

Arama kapsamını değiştirmek — yalnızca subscriber_filter() içindeki koşul. Listeleme ve toplu işlem otomatik olarak aynı anda güncellenir; ikisinin ayrışması yapısal olarak mümkün değildir.

Seçim sınırını değiştirmek — config.php içindeki BULK_MAX_IDS.

Yeni bir toplu işlem eklemek (örn. “toplu segment değiştir”) — execute_bulk()’a bir SQL şablonu vermek yeterlidir; sayı denetimi, transaction ve parametre bağlama hazır gelir:

[$affected] = execute_bulk(
    $db,
    'UPDATE subscribers SET segment = :segment WHERE {where}',
    [':segment' => $segment]
);

Kendi tablonuza uyarlamak — subscribers yerine kendi tablonuzu, SUBSCRIBER_STATUSES yerine kendi alan tanımlarınızı koyun. Toplu işlem altyapısı tabloya değil, koşula bağlıdır.

---

Örnek kullanım alanları

• Bülten / e-posta pazarlama panelleri — “Bu segmentteki herkesi pasife al”, “sert dönen adresleri toplu engelle”.
• E-ticaret yönetimi — “Stoğu biten tüm ürünleri yayından kaldır”, “bu kategorideki 400 ürüne toplu indirim”.
• Yorum / içerik denetimi — “Bu kullanıcının tüm yorumlarını gizle”, “onay bekleyen 250 yorumu toplu onayla”.
• Üyelik ve CRM sistemleri — “Bir yıldır giriş yapmamış üyeleri toplu arşivle”.
• Sipariş / talep yönetimi — “Bugünün kargolanan siparişlerini toplu ‘tamamlandı’ yap”.
• Veri temizliği — “Doğrulanmamış kayıtları filtreleyip toplu sil” — burada expected_count freni en çok işe yarayan yerdir.

Ortak nokta: hepsinde kullanıcı gördüğünden fazlasını seçebilir ve işlemlerin çoğunun geri dönüşü yoktur.

---

Lisans

MIT — dilediğiniz gibi indirip kullanabilir, değiştirebilir ve ticari projelerde kullanabilirsiniz. Ayrıntılar için LICENSE.

Çılgın Yazılım · cilginyazilim.com
github.com/CilginYazilim/bulk-actions-table