Toplu işlemler UI kalıpları: önizleme, izinler ve geri al

Toplu işlemler neden ters gidiyor (ve “güvenli” ne demek)\n\nToplu işlemler, hızlı hareket ederken insanların başvurduğu “birçok kayda bunu uygulama” kontrolleridir. Gerçek ürünlerde bu genellikle toplu düzenleme (bir alanı değiştirme), toplu silme, başka bir klasöre veya aşamaya taşıma, bir kişiye veya ekibe atama, etiket ekleme veya bir iş akışını tetikleme anlamına gelir.\n\nBunların başarısız olmasının basit bir nedeni var: ayrıntılı, kayıt kayıt düşünmeyi hız için feda ederler. Bu fedakârlık kapsamın açık olduğu durumlarda sorun yaratmaz. Çok sık kapsam belirsizdir, sonuçlar net değildir ve izin kuralları tutarsızdır. İşlem iyi görünür ta ki birisi yanlış 200 kaydın güncellendiğini fark edene kadar.\n\nAynı problemler tekrar tekrar ortaya çıkar:\n\n- Seçim belirsizdir (filtreler vs işaretlenmiş öğeler, sayfalar arası, “tümünü seç” sürprizleri).\n- Etki önizlenmesi zordur (gerçekte ne değişecek göremezsiniz).\n- İzinler çok geç veya sadece UI'da kontrol edilir.\n- “Geri al” eksik, güvenilmez veya yanıltıcıdır.\n- Bir denetim izi yoktur, bu yüzden kimse ne olduğunu açıklayamaz.\n\nZarar nadiren önemsizdir. Müşterilere yanlış e-postalar gider, faturalar yanlış duruma geçer veya bir satış hattı yanlış sahibine atanır. Veriyi geri getirebilseniz bile kurtarma saatler sürer ve kuşku yaratır: “Sisteme güvenebilir miyiz?”\n\n“Güvenli” yavaş veya uyarılarla dolu demek değildir. Kullanıcının işlem yapmadan önce üç soruyu yanıtlayabilmesi demektir:\n\n1. Tam olarak hangi kayıtlar etkilenecek?\n2. Tam olarak ne değişecek ve ne değişmeyecek?\n3. Bu bir hataysa, en hızlı ve dürüst şekilde geri dönüş yolu nedir?\n\nBir destek liderinin bir kesinti sonrası biletleri topluca kapattığını hayal edin. Eğer UI gizlice arşivlenmiş biletleri de dahil ediyorsa, son sayıyı göstermeden kapatıyorsa ve geri al sunmuyorsa, 30 saniyelik bir temizlik gerçek bir olaya dönüşebilir.\n\n## Güvenli toplu işlemler için temel ilkeler\n\nİyi toplu işlemler iki riski aynı anda azaltır: kullanıcının yanlış şey yapması veya sistemin yanlış şey yapması. İnsanları yavaşlatmaya çalışmıyorsunuz; işlemi net, kasıtlı ve doğrulanması kolay hâle getirmeye çalışıyorsunuz.\n\nSeçimi işlemden ayırın. İnsanların önce öğeleri seçmesine (veya filtrelenmiş bir küme onaylamasına), sonra eylemi seçmesine izin verin. Seçim ve eylem iç içe geçtiğinde kullanıcılar hangi öğelerin dahil edilmesi gerektiğine karar verirken değişiklik tetikleyebilir.\n\nKullanıcı taahhüt etmeden önce kapsamı gösterin. Bu, tam sayıyı, uygulanan filtreleri ve herhangi bir hariç tutmayı (düzenlenemeyen öğeler, zaten hedef durumda olan öğeler vb.) içermelidir. “128 seçildi (filtre: Durum = Açık, Atanan = Ben; 6 hariç: izin yok)” gibi tek bir satır çoğu sürprizi önler.\n\nYıkıcı eylemler farklı hissettirmeli. Net etiketler (“128 kaydı sil”), güçlü görsel işaretler kullanın ve bunları güvenli eylemlerden uzak tutun. Ayrıca kasıtlı bir tetikleyici (özel bir düğme) gerektirerek yanlışlıkla tıklanmayı zorlaştırın; menü öğesi gibi gözüken şeylerden kaçının.\n\nAkışı kısa ve öngörülebilir tutun: seç, kapsamı incele, onayla, sonucu gör. İş gerçekten ekstra seçim gerektirmiyorsa çok adımlı sihirbazlardan kaçının.\n\nHızlı bir kontrol istiyorsanız, gerekliler şunlardır: seçim açık, kapsam eylemin yanında görünür, yıkıcı eylemler kazara tetiklenmesi zor, onay metni ne olacağını söylüyor ve sonuç açıkça gösteriliyor (başarılı, kısmi başarı, hatalar).\n\n## Önizleme-öncelikli UI: uygulamadan önce etkiyi gösterin\n\nİyi bir toplu işlem inanç sıçraması gibi hissettirmemeli. Kullanıcı Apply'a tıklamadan önce “Tam olarak ne değişecek?” sorusunu yanıtlayan bir önizleme gösterin.\n\nGüvenilir ve anlaşılır bir özetle başlayın. Seçim büyükse sayılar uzun tablolardan daha güvenilirdir. Durum değiştiriyorsanız, her mevcut durumdan kaç öğenin yeni duruma geçeceğini gösterin. Sahip değiştiriyorsanız, mevcut sahip bazında ve yeni sahibi bazında sayıları gösterin. Özeti birincil eylem düğmesine yakın tutun ki gözden kaçması zor olsun.\n\nSonra kullanıcıların sürprizleri yakalaması için yeterli detayı verin. Basit değişiklikler için birkaç örnek satır yeterli olabilir (örneğin “Önceliği Yüksek yap”). Kullanıcıların istisna beklediği veya seçimin bir filtreden geldiği durumlarda tam liste (veya etkilenen kümenin dışa aktarılabilir hâli) daha iyidir.\n\nNe olmayacağını da açıkça gösterin. “Atlanacak” küçük bir alan, hariç tutmaları açık dilde açıkladığında güven oluşturur; örneğin: izin yok, zaten hedef durumda, onay iş akışı tarafından kilitlenmiş veya gereken veriler eksik.\n\nAnahtar nokta: önizleme gerçek kuralları yansıtmalı. Eğer backend bir güncellemeyi reddedecekse, önizleme kullanıcının onaylamasından önce bunu göstermeli, sonra değil.\n\n## Kullanıcıların gerçekten anlayacağı onay diyalogları\n\nOnay diyaloğu bir engel olmamalı. Tek bir soruyu yanıtlamalı: “Buna tıklarsam ne olacağını tamamen anladım mı?” Eğer iki hızlı okumada bunu yapamıyorsa insanlar görmezden gelir.\n\nEylem adını ve son durumu öne çıkarın. “Durumu güncelle” gibi genel etiketler kullanıcıyı tahmine bırakır. “Durumu Kapalı yap” veya “24 müşteriyi sil” gibi tercih edin.\n\nRiskli seçeneği varsayılan yapmayın. İki düğme varsa, en güvenli olan varsayılan odak olsun. Eğer seçenekler varsa (örneğin “Biletleri kapat ve müşterileri bilgilendir”), en yıkıcı olanı önceden işaretlemek yerine kullanıcıdan açık bir seçim yapmasını isteyin.\n\nDiyalog metnini gerçek risk için kullanın. Ne değişeceğini, ne olmayacağını, neyin kalıcı olduğunu ve neyin dahil olduğunu söyleyin. Belirsiz “Emin misiniz?” ifadelerinden kaçının.\n\nHer toplu işlem aynı sürtünmeyi gerektirmez. Düşük riskli, geri döndürülebilir değişiklikler (etiket ekleme gibi) için basit bir onay yeterlidir. Silme, izin değişiklikleri, büyük ödemeler veya doğrudan müşteriyi etkileyen durumlar gibi yüksek etki alanı olan işlemler için yazılı onay (typed confirmation) mantıklıdır.\n\nKullanışlı bir desen: kullanıcıdan DELETE veya CLOSE 24 gibi bir metin yazmasını isteyin; böylece kullanıcı onaylarken kapsam da gözünün önünde olur.\n\n## Toplu işlemler için izin ve erişim kontrolleri\n\nToplu işlemler, izin kurallarının en çok sınandığı yerdir. Bir kullanıcı bazı kayıtları düzenleyebilir, hiçbirini silemeyebilir ve yalnızca belirli alanları değiştirebilir. İzinleri sürpriz değil iş akışının bir parçası olarak ele alın.\n\n“İzinli” ne demek açık olmalı. Nadiren sadece “öğeyi açabilir mi?” demektir. Genellikle görüntüleme erişimi, düzenleme hakları, silme hakları, alan düzeyinde kurallar (durumu değiştirebilir ama sahibi, fiyatı veya izinleri değiştiremez) ve kapsam kuralları (sadece kendi ekibindeki, bölgesindeki veya projesindeki öğeler) karışımıdır.\n\nBir seçimde karışık izinler normaldir. Güvenli bir sistem dürüst bir yaklaşım seçip bunu açıkça iletiyor:\n\n- Sadece izin verilen öğelere uygulayın ve atlananları özetleyin.\n- Seçim sadece izin verilen öğeleri içerene kadar işlemi engelleyin.\n\nİlk seçenek yüksek hacimli işler için daha akıcıdır. İkinci seçenek ise silme veya izin değişiklikleri gibi yüksek riskli işlemler için genellikle daha iyidir.\n\nErişimi olmayan bazı öğeler olduğunda veri sızıntılarından kaçının. Engellenen kayıtların isimlerini, başlıklarını veya hassas alanlarını açığa çıkarmayın. “12 öğe erişim kuralları nedeniyle güncellenemedi” demek, hangi öğeler olduğunu listelemekten daha güvenlidir.\n\nİyi UI geri bildirimi kullanıcıların ne olduğunu anlamasına yardımcı olurken cezalandırılmış hissettirmez. Örneğin: bir ön-kontrol banner'ı (“Seçilen 50 öğeden 38'ini güncelleyebilirsiniz”), kısa sebep kodları (“Engellendi: ekibinizde değil”), ve kullanıcı düzenleyemeyeceği öğeleri gizleyen bir filtre gibi.\n\nBackend tarafında, her kayıt için aynı kuralları tekrar uygulayın. UI ön kontrol yapsa bile sunucu her kayıt ve her alan için doğrulama yapmalıdır.\n\n## Güvenli ve dürüst geri alma desenleri\n\nEn güvenli geri alma, gerçekten yerine getirebileceğiniz olandır. Bu genellikle son dakikada bir düğme eklemektense kurtarmayı baştan tasarlamak anlamına gelir.\n\nGüçlü bir varsayılan soft delete ve zaman sınırlı geri yükleme penceresidir. Kayıtları anında silmek yerine silinmiş olarak işaretleyin (ve normal görünümden gizleyin), sonra daha sonra kalıcı silme yapın. Bu yanlış tıklamaları, yanlış filtreleri ve “o öğelerin dahil olduğunu fark etmedim” hatalarını yakalar.\n\nHızlı işlemler için bir undo toast iyi çalışır çünkü anında ve düşük eforludur. Ne değiştiğini spesifik gösterin ki kullanıcı güvensin: ne değişti, bir Geri Al düğmesi, zaman sınırı ve bazı öğelerin atlandığı notu.\n\nRiskle uyumlu bir geri alma penceresi seçin. Küçük hatalar için 10–30 saniye yaygındır. Saatler veya günler gerektiren durumlar soft delete + restore ekranı ile daha iyi idare edilir.\n\nUzun süren toplu işler için “geri al” genellikle iptal etmek anlamına gelir, tam bir rollback değil. Zaten e-posta, ödeme veya dış güncellemeler tetiklenmiş bir işi geri almak yanıltıcı olabilir. Kullanıcılara kalan işi iptal etme seçeneği verin ve nelerin zaten gerçekleştiğini gösterin.\n\nGeri alma mümkün değilse açık olun ve bir kurtarma yolu sunun: etkilenen ID'leri dışa aktar, denetim kaydı yaz ve mümkünse bir geri yükleme iş akışı teklif et.\n\n## Backend korumaları: doğrulama, idempotency, denetlenebilirlik\n\nGüvenli bir toplu işlem sadece UI meselesi değildir. Güçlü bir önizleme olsa bile kullanıcılar çift tıklar, tarayıcılar yeniden dener ve arka plan işleri iki kere çalışabilir. Backend, her toplu isteğin riskli olduğunu varsaymalı ve uygulamanın güvenli olduğunu kanıtlamalıdır.\n\nSıkı doğrulama ile başlayın. Sadece ilk öğeyi değil, her öğeyi doğrulayın. 200 kayıttan 3'ü başarısız olacaksa (gerekli alan eksik, yanlış durum, izin yok) baştan tüm grubu reddedecek misiniz yoksa kısmi başarıya izin verip öğe bazlı hataları açıkça raporlayacak mısınız buna karar verin.\n\nIdempotency kazara çift uygulamayı önler. Her toplu isteğe benzersiz bir idempotency anahtarı (ya da istek ID'si) verin ve sonucu saklayın. Aynı anahtar tekrar gelirse, güncellemeyi iki kere çalıştırmadan aynı sonucu döndürün.\n\nEşzamanlı düzenlemeler için optimistic locking kullanın. Kayıt başına bir versiyon veya updated_at değeri saklayın ve sadece uyuşuyorsa güncelleyin. Değiştiyse, başkasının çalışmasının üzerine yazmak yerine bir çakışma dönün.\n\nİki API deseni çok işe yarar:\n\n- Dry-run: doğrulama ve izin kontrollerini çalıştırın, sayıları ve örnek değişiklikleri döndürün ama yazma yapmayın.\n- Apply: onay token'ı veya aynı hesaplanmış seçimi zorunlu kılarak yazma yapın.\n\nSistemi korumak için pratik limitler ekleyin: bir istekte maksimum öğe sayısı sınırı koyun, oran limitleri uygulayın (silmeler için daha sıkı olabilir) ve bir bağımlılık takılırsa tüm işi dondurmamak için batch zaman aşımı uygulayın.\n\nSon olarak, her toplu değişikliği denetlenebilir kılın. Kimin yaptığını, neyin değiştiğini ve kapsamı loglayın. Kullanışlı bir denetim girdisi aktörü, zaman damgasını, eylem parametrelerini (filtreler, sayılar), öncesi/sonrası veriyi (veya diff) ve bir batch/iş ID'sini içermelidir.\n\n## Toplu işlemleri ölçeklendirirken güvenilirliği bozmamak\n\nToplu işlemler 50'den 50.000'e çıktığında risk sadece kullanıcı hatası değildir. İşin ortasında sistemin yüklenmesi, yarım kalmış değişiklikler bırakma ve bunların açıklanmasının zor olması gibi sorunlar ortaya çıkar.\n\nİşi parçalara ayırın. Tüm kayıtları tek bir uzun işlemde güncellemek yerine partiler halinde işleyin (örneğin 500–2.000 arası) ve her partiden sonra ilerlemeyi kaydedin. Bir şey başarısız olursa temiz bir şekilde durabilirsiniz, nerede durduğunu gösterebilirsiniz ve uzun süre tabloları kilitlemekten kaçınırsınız.\n\nBüyük işler için arka planda çalıştırın ve açık durum gösterin: sırada, çalışıyor ("X of Y"), tamamlandı sorunlarla, başarısız veya iptal edildi (destekliyorsa).\n\nKısmi başarı dürüst bir UI gerektirir. %20 başarısızsa “Bitti” demeyin. Nelerin başarılı olduğunu, nelerin başarısız olduğunu gösterin ve başarısızlıklara karşı işlem yapmayı kolaylaştırın: sadece başarısız öğeleri yeniden dene, başarısız ID'leri dışa aktar veya filtrelenmiş bir görünüm aç.\n\nBasit ama işe yarayan bir kural: işin şu anki durumunu bir cümlede açıklayamıyorsanız, kullanıcılar da güvenmeyecektir.\n\n## Kaçınılması gereken yaygın hatalar ve tuzaklar\n\nÇoğu toplu işlem hatası “kullanıcı hatası” değildir. Seçimin ne anlama geldiğini UI'nın sessizce değiştirmesi veya sistemin kullanıcının en geniş değişikliği kastettiğini varsayması gibi durumlarda ortaya çıkar.\n\nKlasik bir tuzak “görünen tüm satırlar” ile “tüm sonuçlar”ı karıştırmaktır. Kullanıcı ekranda 20 öğe seçer, sonra 20.000 öğeyi hedefleyen bir “tümünü seç” kutusuna tıklar. “Tüm sonuçları seç” destekleniyorsa bunun ayrı, açık bir adım olmasını sağlayın ve nihai sayıyı eylemin yanında gösterin.\n\nBir başka sıkıntı, seçim ile uygulama arasında filtrelerin sessizce değişmesidir. Kullanıcı bir sipariş kümesi seçer, sonra paylaşılan görünüm değişir veya liste yenilenir ve filtre kayar. İş, inceledikleri kümeden farklı bir küme üzerinde uygulanır. Eylemleri bir snapshot'a (seçilen ID'ler) bağlayın ve seçim değiştiyse uyarı verin.\n\nKalabalık menüler de zarar verir. “Sil” yanında “Dışa aktar” ve “Etiket” duruyorsa hatalar olacaktır. Yıkıcı eylemleri ayırın ve daha net onaylar verin.\n\nVe asla "UI düğmeyi gizledi"yi izin kontrolü zannetmeyin. Backend yine de her öğeyi doğrulamalıdır.\n\n## Toplu işlemler için hızlı güvenlik kontrol listesi\n\nBir toplu işlemi yayına almadan önce, “Bunu yapmak istemedim” anlarını önleyen ve destek soruşturmasını çok daha kolay hale getiren temel maddeleri kontrol edin.\n\nKapsam açıklığıyla başlayın. Kullanıcılar sadece eylem etiketini değil, tam olarak neyin etkileneceğini görmelidir. Öğesi sayısını ve bu sayıyı üreten filtreyi veya seçimi gösterin (örneğin, “132 bileti eşleşiyor: Durum = Açık, Bana atanmış”).\n\nSonra üç yüksek riskli alanın gizlenmediğinden emin olun: etki, izinler ve sonuçlar.\n\n- Kapsam açık: kayıt sayısı artı seti oluşturan filtre/seçim.\n- Riskli eylemler önizleme içerir: değişiklik örnekleri veya kısa diff tarzı özet.\n- İzinler sunucuda her öğe için uygulanır, sadece UI'da değil.\n- Gerçek bir geri dönüş yolu vardır: mümkünse geri al/geri yükleme veya çalıştırmadan önce net “geri alınamaz” uyarısı.\n- Sonuçlar belgelenir: denetim günlüğü ve açık sonuç özeti (başarılı, atlandı, başarısız ve neden).\n\n## Gerçekçi bir örnek: destek biletlerini güvenli şekilde topluca kapatma\n\nBir destek lideri kampanya sonrası bir temizlik yapıyor. Yüzlerce bilet “promo-2026” etiketi taşırken, çoğu zaten self-servisle çözülmüş. Geriye kalanları VIP vakalarını veya başka bir ekibin sahip olduğu biletleri yanlışlıkla kapatmadan topluca kapatmak istiyorlar.\n\nFiltrelenmiş bir listeden biletleri seçip “Seçilenleri kapat”a tıklıyorlar. Hiçbir şey değişmeden önce etkileri somutlaştıran bir önizleme görüyorlar:\n\n- Sayım özeti: 183 kapatılacak, 12 atlanacak, 4 dikkat gerektiriyor.\n- Atlanan öğeler için açık nedenler (örneğin “Zaten kapalı” veya “VIP hesap, topluca kapatılamaz”).\n- Küçük bir örnek liste (10 öğe) ve etkilenen kümenin dışa aktarılma seçeneği.\n- Tam değişiklik: durum “Closed” olacak, sebep “Campaign cleanup” olarak kaydedilecek.\n\n- Açık bir birincil buton: “183 bileti kapat”, belirsiz bir “Onayla” yerine.\n\nOnayladıktan sonra sistem bir arka plan işi çalıştırır ve ilerlemeyi gösterir. İş bittiğinde sonuç ekranı kaçının başarılı olduğunu, hangilerinin başarısız olduğunu ve nedenini gösterir (örneğin, bir bilet işlem sırasında bir ajan tarafından güncellendi).\n\nBackend tarafında akış savunmacı kalır: yürütme zamanında her bilet için izinleri tekrar kontrol et, izin verilen durumları doğrula, batch ID ile bir denetim kaydı yaz, güncellemeleri küçük parçalar halinde uygula ve bir sonuç raporu döndür.\n\nGeri alma gerçek bir operasyon olarak ele alınır, bir söz olarak değil. UI 30 dakika boyunca “Bu batch'i geri al” sunar. Buna tıklamak, yalnızca o batch tarafından değiştirilen ve o zamandan beri düzenlenmemiş biletlere önceki durumu ve sebebi geri yükleyen yeni bir işi başlatır.\n\n## Sonraki adımlar: bu hafta bir güvenlik geliştirmesi uygulayın\n\nToplu işlemleri daha güvenli hale getirmek için tam bir yeniden tasarıma ihtiyacınız yok. Kaza ve destek taleplerini azaltacak tek küçük bir değişiklik seçin, yayınlayın ve üzerine inşa edin.\n\nAçıklıkla başlayın: düğmenin yanına tam olarak neyin değişeceğini söyleyen bir kapsam etiketi ekleyin (“37 seçili fatura”) ve işlem çalıştıktan sonra kısa bir sonuç özeti gösterin (kaç başarılı, başarısız ve neden). Bu tek değişiklik bile “Sadece bir öğe sanıyordum” hatalarının çoğunu önler.\n\nSonra daha yüksek riskli eylemlere geçin. Toplu silmeler, durum değişiklikleri ve izin hassasiyeti olan güncellemeler için, kullanıcı herhangi bir şey kaydetmeden önce etkiyi gösteren bir önizleme/dry-run ekleyin. İlk 10 öğe için basit bir “önce -> sonra” tablosu bile yanlış filtreleri yakalar.\n\nÇoğu ekip için işe yarayan pratik sıra:\n\n- Düğmenin yanına seçim sayısı + açık kapsam metni ekleyin.\n- Hatalar ve nedenleri ile birlikte bir sonuç ekranı ekleyin.\n- En riskli eylemler için bir önizleme veya dry-run doğrulaması ekleyin.\n- Silmeler için geri yüklemeyi ekleyin (soft delete + restore görünümü) ve kurtarma seçeneğini hemen gösterin.\n- Büyük batch'ler için işi arka planda çalıştırın ve tamamlandığında bildirim gönderin.\n\nEğer bir iç araç veya AppMaster üzerinde bir yönetici paneli inşa ediyorsanız, bunu ayrı sistemler birleştirmeden yapabilirsiniz: Data Designer ile PostgreSQL'de denetim ve iş tabloları modelleyin, Business Process Editor'da kayıt bazlı kuralları uygulayın ve web veya mobil UI oluşturucularında önizleme, onay ve sonuç ekranlarını kurun. Değerlendirme yapan takımlar için, appmaster.io prototipleme ve güvenlik kontrollerini günlük kullanıcıların doğal hissettiği biçimde test etmek için pratik bir yerdir.