ERETEK
BİLGİ SİSTEMLERİ

SharePoint’te Doküman Revizyon Yönetimi: Sürüm, Onay ve Yayın

SharePoint doküman revizyon yönetimi: ana ve alt sürüm, check-out, içerik onayı, taslak görünürlüğü, revizyon numarası ve sürüm sınırlarının depolamaya etkisi.

Bu makalede7 bölüm
Teknik özet
Teknoloji
SharePoint Online, Versioning, Content Approval, PnP PowerShell, Power Automate
Konu
Kontrollü dokümanlarda sürüm, onay ve yayın kurgusu
Seviye
Orta
Ön koşullar
  • Doküman kütüphanesinde tam denetim yetkisi
  • Kurumun doküman kontrol prosedürü
  • PnP PowerShell (isteğe bağlı)

Prosedür, talimat, form ve teknik çizim gibi kontrollü dokümanlarda denetçinin sorusu “dosya nerede?” değildir. Soru “yürürlükteki sürüm hangisi ve kim onayladı?” sorusudur ve yanıt kütüphane ayarlarında saklıdır. SharePoint Online bunun için dört yapı taşı verir: ana ve alt sürüm, check-out zorunluluğu, içerik onayı ve taslak görünürlüğü. Bu dördü ayrı ayrı açılınca çalışmaz; birlikte kurgulanmaları gerekir. Aşağıda bu kurguyu, depolama etkisini ve revizyon numarasının dokümana nasıl yansıtılacağını kalite sorumluları ve SharePoint yöneticileri için anlatıyoruz.

Sürüm geçmişi ayarları: ana ve alt sürüm

Doküman kütüphanesinde iki sürüm modeli vardır. Yalnız ana sürüm modelinde her kayıt 1.0, 2.0, 3.0 diye artar ve her sürümü okuma yetkisi olan herkes görür. Ana ve alt sürüm modelinde çalışma kopyaları 1.1, 1.2 gibi alt sürümlerdir (taslak); “Ana sürümü yayımla” işlemiyle 2.0’a yükselir.

Model Uygun içerik Sınırlama
Yalnız ana sürüm Ekip çalışma dokümanları, toplantı notları Taslak ile yayın ayrımı yoktur
Ana ve alt sürüm Prosedür, talimat, politika Yayımlama adımını kullanıcının bilmesi gerekir
Ana/alt sürüm + içerik onayı Denetime tabi kontrollü dokümanlar Onaycı rolü ve süreç disiplini gerekir

Kurumsal intranet çözümlerinde kontrollü doküman kütüphanesi için doğal tercih ana ve alt sürüm modelidir: ana sürüm “yayınlanmış revizyon”a, alt sürümler o revizyonun hazırlık çalışmalarına karşılık gelir. Yalnız şunu bilin: SharePoint’in sürüm numarası teknik bir sayaçtır. Kurumun Rev. 03’üyle birebir eşleşeceği garanti değildir. Bir ana sürüm geri alınır veya geri yükleme yapılırsa SharePoint numarası ilerler, kurumsal revizyon ilerlemez. Bu ayrıma aşağıda revizyon numarası bölümünde dönüyoruz.

Ayarlar kütüphane ayarlarındaki “Sürüm oluşturma ayarları” sayfasından yapılır. Kurulumu tekrarlanabilir ve belgelenebilir kılmak için PnP PowerShell kullanıyoruz:

Connect-PnPOnline -Url https://contoso.sharepoint.com/sites/kalite -Interactive `
  -ClientId <uygulama-kaydi-client-id>

Set-PnPList -Identity "Prosedürler" `
  -EnableVersioning $true -EnableMinorVersions $true `
  -MajorVersions 100 -MinorVersions 5 `
  -EnableModeration $true `
  -DraftVersionVisibility Approver `
  -ForceCheckout $true

Get-PnPList -Identity "Prosedürler" |
  Select-Object EnableVersioning, EnableMinorVersions, MajorVersionLimit,
    MajorWithMinorVersionsLimit, EnableModeration, DraftVersionVisibility, ForceCheckout

Sahada en sık karıştırılan parametre -MinorVersions’tır: kaç ana sürüm için taslakların saklanacağını belirtir, alt sürüm sayısını değil. Değerleri kurum politikasına göre seçin; SharePoint Online kütüphane düzeyinde ana sürüm sınırı için bir alt değer uygular (uzun süredir 100) ve daha düşüğünü reddeder. Bağlantıdaki -ClientId, kiracınızda PnP PowerShell için açtığınız Entra ID uygulama kaydıdır. Betiğin sonundaki Get-PnPList satırını atlamayın. Ayar yazıldı sanmak, yazıldığını görmek değildir.

Check-out ve birlikte düzenleme dengesi

Check-out zorunluluğu, dokümanı düzenleyecek kullanıcının dosyayı önce kendine ayırmasını sağlar. İki kişinin aynı anda farklı değişiklik yapmasını önler; her check-in’de değişiklik açıklaması istenebilir. Bedeli birlikte düzenlemedir (co-authoring): check-out zorunlu kütüphanede Word, Excel ve PowerPoint dosyalarını birden çok kişi aynı anda düzenleyemez. İkisini birden alamazsınız.

Karar ölçütü dokümanın yaşam döngüsüdür:

  • Hazırlık birden çok yazarla yürüyorsa taslak ayrı bir çalışma kütüphanesinde, birlikte düzenlemeyle hazırlanır; nihai metin kontrollü kütüphaneye check-out zorunluluğuyla aktarılır.
  • Tek sorumlu yazar varsa check-out zorunluluğu kontrollü kütüphanede doğrudan kullanılır.
  • Teknik çizimlerde (CAD gibi birlikte düzenleme desteği olmayan formatlar) check-out, çakışmayı önlemenin tek yerleşik yoludur.

Check-out zorunluluğunun bilinen yan etkisi “unutulmuş check-out”tır: kullanıcı dosyayı ayırır, izne çıkar, doküman haftalarca kilitli kalır. Kütüphanede tam denetimi olanlar dosya menüsündeki “Check-out’u iptal et” komutuyla kilidi kaldırır. Bunun için “Check-out Yapan” sütunu boş olmayan dosyaları listeleyen bir kontrol görünümü hazırlayın ve haftalık bakın. Bir tuzak daha var: yeni yüklenen ve hiç check-in yapılmamış dosyaları yalnız yükleyen kişi görür. Bu dosyalar kütüphane ayarlarındaki “İade edilmiş sürümü olmayan dosyaları yönet” sayfasından sahiplenilir. Kullanıcı “yükledim ama kimse göremiyor” diyorsa ilk bakılacak yer burasıdır.

İçerik onayı ve taslak görünürlüğü

İçerik onayı (content approval) açıldığında her ana sürüm Beklemede durumuna geçer ve onaycı Onaylandı veya Reddedildi diyene kadar okuyuculara görünmez; okuyucular son onaylı sürümü görmeye devam eder. Onay yetkisi “Öğeleri Onayla” iznini içeren izin düzeylerindedir; varsayılanlardan Tam Denetim ve Tasarım bu izni taşır. Tasarım düzeyi yeni sitelerde gizli olabildiği için onaycılara yalnız bu izni ekleyen özel bir izin düzeyi tanımlamak daha temizdir. Onaycıları ayrı bir SharePoint grubunda toplayın; onay yetkisi site sahipliğinden ayrılmış olur.

Taslak görünürlüğü (draft item security) üç seçenek sunar:

Seçenek Taslağı kim görür Kullanım
Okuyabilen herkes Tüm okuyucular Kontrollü dokümanlar için uygun değil
Düzenleyebilenler Düzenleme yetkisi olanlar Ekip içi gözden geçirme
Onaylayabilenler ve yazar Onaycılar ve dokümanın yazarı Kontrollü doküman kütüphanesi (içerik onayı gerektirir)

Yerleşik içerik onayı tek adımlıdır ve kimin onayladığını sürüm geçmişine yazar. Hazırlayan–kontrol eden–onaylayan zinciri, paralel onay veya süre aşımında hatırlatma gerekiyorsa Power Automate akışı devreye girer. Akış tasarımı için Power Automate ile onay süreçleri rehberine bakın. Bu kurguda akış, onay bitince yerleşik onay durumunu güncelleyen adımla sonlanmalı. Aksi hâlde iki ayrı onay kaydı oluşur ve denetimde hangisinin geçerli olduğunu açıklamak zorunda kalırsınız. Uygulama tarafında Power Automate onay ve otomasyon hizmet sayfamız referans alınabilir.

Revizyon numarası ve doküman üst bilgisi

Denetimde basılı veya PDF kopyada revizyon numarası, yürürlük tarihi ve onaylayan görünmelidir. SharePoint sürüm numarası kütüphanede “Sürüm” sütununda durur; dokümanın içine kendiliğinden yazılmaz. Seçenekler:

Yöntem Nasıl çalışır Dikkat
Kurumsal revizyon sütunu “Revizyon” ve “Yürürlük Tarihi” sütunları onay anında doldurulur Elle doldurmada hata riski; akışla doldurmak daha güvenli
Word belge özelliği alanı Word’de Ekle → Hızlı Parçalar → Belge Özelliği ile sütun üst bilgiye bağlanır Yalnız Office dosyalarında; şablonda hazırlanmalı
Onayda PDF üretimi Akış onaylanan sürümden PDF üretip yayın kütüphanesine kopyalar İki kopya oluşur; kaynak ve yayın ayrımı net olmalı
Yalnız SharePoint sürümü Sürüm sütunu referans alınır Basılı kopyada görünmez; kurumsal numarayla eşleşmeyebilir

Sahada en az sorun çıkaran kurgu şudur: içerik türünün Word şablonunda üst bilgiye bağlı “Revizyon”, “Yürürlük Tarihi” ve “Onaylayan” alanları; bu sütunları onay akışının son adımında dolduran bir eylem. Elle girilen revizyon numarası er geç yanlış girilir. İçerik türü ve site sütunu tasarımı için meta veri ve içerik türü rehberine bakabilirsiniz.

Sürüm sınırları ve depolama etkisi

Her sürüm kiracı depolama kotasından yer yer. Otomatik kaydetme açık Office dosyalarında kısa aralıklarla yeni sürüm oluşabildiği için büyük dosyalarda geçmiş hızla şişer. Örnek hesap: 20 MB’lık bir teknik çizimin 100 sürümü yaklaşık 2 GB tutar; aynı kütüphanede bu boyutta 200 dosya varsa sürümler tek başına yaklaşık 400 GB’a ulaşabilir. Bu hesap üst sınırı gösterir; gerçek tüketim dosya boyutunun sürümler arasında nasıl değiştiğine bağlıdır. Kota uyarısı geldiğinde ilk bakılacak yer çoğu zaman burasıdır.

Depolamayı yönetmek için:

  • Kütüphane bazlı sınır: Kontrollü dokümanlarda saklanacak ana sürüm sayısını politika belirlesin; çalışma kütüphanelerinde daha düşük sınır kullanılabilir.
  • Kuruluş ve site düzeyi sürüm geçmişi limitleri: SharePoint Online sürüm sayısına veya yaşa göre otomatik ya da manuel sürüm temizleme seçenekleri sunar. Seçenekler ve varsayılanlar zaman içinde değiştiği için Microsoft’un sürüm geçmişi limitleri dokümantasyonundan güncel durumu doğrulayın.
  • Saklama ilkeleriyle etkileşim: Saklama ilkesi veya etiketi kapsamındaki sitede silinen ya da değiştirilen içerik Koruma Tutma Kütüphanesi’nde (Preservation Hold Library) tutulur ve kotadan yer kaplar. Sürüm sınırını düşürmek saklama yükümlülüğünü kaldırmaz.

Sürüm sınırını düşürmek mevcut fazla sürümleri her zaman anında silmez; temizlik ayrı bir işlem gerektirebilir. Kontrollü dokümanlarda eski revizyon denetim kanıtıdır. Temizlikten önce kalite yönetim sisteminin saklama gerekliliğini yazılı olarak teyit edin.

Kontrollü doküman kütüphanesi kontrol listesi

  • Ana ve alt sürüm açık; saklanacak ana sürüm sayısı yazılı politikaya dayanıyor.
  • İçerik onayı açık; taslak görünürlüğü “onaylayabilenler ve yazar”.
  • Onaycılar ayrı bir SharePoint grubunda; site sahipleriyle aynı kişiler olmak zorunda değil.
  • Check-out zorunluluğu kararı birlikte düzenleme ihtiyacıyla birlikte verildi.
  • Revizyon, yürürlük tarihi ve onaylayan sütunları içerik türünde tanımlı ve şablon üst bilgisine bağlı.
  • Onay akışı kullanılıyorsa yerleşik onay durumunu da güncelliyor.
  • Bekleyen onaylar ve unutulmuş check-out’lar için izleme görünümleri hazır.
  • Saklama ilkesi ile sürüm sınırı arasındaki ilişkiyi kalite ve BT birlikte onayladı.
  • Okuyucuların yalnız onaylı sürümü gördüğü test kullanıcısıyla doğrulandı.

Son madde neredeyse her projede atlanır. Yetkiler kurgulandıktan sonra yalnız okuma yetkili bir test hesabıyla kütüphaneyi açıp taslakların görünmediğini görmek, ayarların birbiriyle doğru etkileştiğinin tek pratik kanıtıdır. Yönetici hesabıyla yapılan test hiçbir şey kanıtlamaz. Okuyucu ve onaycı gruplarının kurgusu için SharePoint izin modeli rehberi tamamlayıcıdır. Kontrollü doküman kütüphanesinin kurulumundan devreye almaya kadar tüm adımlar SharePoint doküman ve revizyon yönetimi hizmetimizin kapsamındadır.

Sık sorulan sorular

SharePoint sürüm numarası kurumsal revizyon numarası olarak kullanılabilir mi?

Doğrudan kullanmayın. SharePoint sürüm numarası geri yükleme gibi işlemlerde de ilerleyen teknik bir sayaçtır. Kurumsal revizyon numarasını ayrı bir sütunda tutup onay anında doldurmak daha güvenilirdir.

Check-out zorunluluğu birlikte düzenlemeyi engeller mi?

Evet. Check-out zorunlu kütüphanede Office dosyaları aynı anda birden çok kişi tarafından düzenlenemez. Çok yazarlı hazırlık için ayrı bir çalışma kütüphanesi bu dengeyi kurar.

Okuyucular taslak sürümleri görür mü?

İçerik onayı açıksa ve taslak görünürlüğü “onaylayabilenler ve yazar” olarak ayarlıysa, okuma yetkili kullanıcılar yalnız son onaylı ana sürümü görür. Bu davranışı mutlaka bir test hesabıyla doğrulayın.

Sürüm sınırını düşürmek depolamayı hemen azaltır mı?

Her zaman değil. Mevcut fazla sürümlerin temizlenmesi ayrı bir işlem gerektirebilir; saklama ilkesi kapsamındaki içerik de Koruma Tutma Kütüphanesi’nde kalmaya devam eder.

Teknik özet
Teknoloji
SharePoint Online, Versioning, Content Approval, PnP PowerShell, Power Automate
Konu
Kontrollü dokümanlarda sürüm, onay ve yayın kurgusu
Seviye
Orta
Ön koşullar
  • Doküman kütüphanesinde tam denetim yetkisi
  • Kurumun doküman kontrol prosedürü
  • PnP PowerShell (isteğe bağlı)
Eretek uzman desteği

Bu konu sizin ortamınızda nasıl çalışır, birlikte bakalım.

Mevcut yapınızı inceliyor, darboğazı tespit ediyor ve uygulanabilir bir iş planı öneriyoruz.