SharePoint dokumentum jóváhagyása adatbázis szinten

Akkor kezdjük rögtön valami kellően technikai bejegyzéssel a blogot, ugorjunk a közepébe:)
 
Adva volt egy SharePoint Portal Server 2003, és rajta egy jóváhagyásos tár, oda tölthetett fel mindenki dolgokat. A célunk az volt, hogy egyenlőre még ne láthassák a többiek anyagát, ezért is volt jóváhagyásos. Már kezdetben jelentkeztek furcsaságok: egy user jelezte, hogy ha tallózó nézetben nézi a doktárat, akkor látja mindenkiét, sőt le is tudja tölteni, és vissza is menteni;)
Na ettől kicsit frászt kaptunk, jogsultságok tízszer ellenőrizve, elvileg nem szabadna ezt megtennie. Írtam a microsoft.sharepoint newsgroupba is, de semmi válasz. Még egy napig kellett ez a doktár privát módón, úgyhogy végül hagytuk az egészet ennyiben. (tudom, nem szép megoldás:)
 
Azonban nyilvánossá kellett volna tenni az összes feltöltött anyagot, el kellett mindegyiket fogadni. Nosza, adatlap nézet, ott pillanatok alatt végig lehet lépkedni a feltöltött 150 file-on. Eléggé belelendültem, már vagy 100-at elfogadtam, amikor szóltak, hogy azért mégse kéne mindet elfogadni;)
Abbahagytam, párat letöltöttem, párat visszaraktam folyamatban állapotra, és biztos csináltam még valamit:D, mert legközelebb a SIKERTELEN LEKÉPEZÉS kiírás fogadott a Jóváhagyás/elutasítás nézetben.
Vow! Na  ehhez hozzá nem tudtam szólni, foglamam sincs ezt hogyan sikerült elérni:) [ezért jó a magyar szoftver, mert esélytelen, hogy rákeressek google-ban a hibaüzenetre:)]
 
Viszont a maradék doksit is el kellett volna fogadni, nosza elő a visual studio. A Microsoft.SharePoint.dll-t le kell szedni a szerverről (a SharePoint táján oly fontos C:\Program Files\Common Files\Microsoft Shared\web server extensions\60 és azon belül az ISAPI könyvtárból), ezt kell hozzáadni a projekthez referenciakánt, és lehet SharePoint objektumodellét használó programot fejleszteni anélkül, hogy SharePoint fenn lenne a gépen [ami mellesleg csak Windows Server 2003-ra települ]. Hogy legyen részletes intellisense, érdemes letölteni ezt.  (bár nekem miután felraktam, nem történt változás, de elvileg, ha jól beállítjuk, teljes intellisense támogatást ad, ezt még ha lesz időm, megnézem:).
Szóval nekiálltam gyorsan összedobni egy alkalmazást, ami egy doktár elemeit megjeleníti. A megjelenítés megy, az elemeit kell lekérni, és utána DataTable-ben meg lehet kapni, majd azt bind-olni egy DataGridhez, csak még a módosítást meg kellett volna csinálni, meg az elfogadás állapotát a lista osztály tárolja, amiből a doktár származik, úgyhogy végül meguntam és engedtem a "sötét" oldal csábításának:), és nekiálltam adatbázis szinten buherálni.
EZ AZONBAN NEM SUPPORTÁLT ÉS NEM JAVASOLT MÓDSZER:) Azonban hasznos, és érdekes kihívás, ráadásul az admin guide is javasolja egyszer, amikor arról van szó, hogy hogyan lehet a kvótát később megnövelni (majd leestem a székről, amikor megláttam, hogy az admin guideban egy UPDATE utasítás szerepel, holott mindenhol az van, hogy ne módosítsunk adatbázis szinten, mert nem publikált a séma/változhat/csomó ellenőrzést nem végez el).
Tehát ennyi figyelemfelhívás után, lássuk, miből is élünk:
a _site postfixű adatbázisban van a portál tartalma. Itt van egy Docs tábla, ami az egyes feltöltött dokumentumokat tartalmazza. Ebből kéne nekünk egy konkért doktár elemei, ehhez kell a doktár ID-ja:
 
select * from lists where tp_Title = ‘Pályamunkák’
 
Innen a tp_ID oszlop kell. Meg a tp_Web-et is érdemes megjegyezni, ez az a site, amin a doktár van.
Ezután:
 
select id, doclibrowid, leafname, docflags, metainfo, extension from docs where listID = ‘2435897C-6073-4D38-AE5A-72051C79D3B2’
 
Ahol az aposztróf között az előbb megkapott tp_ID áll.
Ha ezt jobban megnézzük, sajnos ebben sincs benne az approve státusza, azt lista szinten tárolja. A listákba felvett elemeket a UserData tábla tárolja, itt viszont nincs benne a filenév, ezért a két táblát össze kell joinolni:
 
select tp_moderationstatus AS mod,   leafname
from userdata inner join docs on CAST( doclibrowID AS varchar(50) ) = CAST(tp_id AS varchar(50) ) AND listID = tp_ListID AND siteID = tp_SiteID
where tp_listID = ‘2435897C-6073-4D38-AE5A-72051C79D5DA’
 
Na, ez egy kicsit csúnya, mert a két helyen tárolt ID nem azonos típus (az egyik int, a másik pedig egy user defined type: uniqueidentifier), de végre megvan, amiket kerestünk: egy eredményhalmazban a filenév és a moderálás státusza.
Ehhez már csak annak az értékeit kell visszafejteni:
tp_ModerationStatus: Folyamatban – 2 , Elutasitva – 1, jovagyva – 0
 
Most már csak pl. az Enterprise Managerbe kell beírni, mert ott lehet is szerkeszteni az eredményt, és ezzel kész is az elfogadó felületünk:)
 
Végül így visszaolvasva szép kisregényt sikerült összehoznom. De azért látszik belőle, hogy, bár nem javasolt módszer, de azért adatbázis szinten is meg lehet mindent találni (ráadásul sokkal nagyobb kihívás, mint a dokumentált objektummodell alapján). Azért mondjuk éles környezetben adatbázis matatással nem próbálkoznék:) (egyszer már megjártam WSS esetén;)
Reklámok
Kategória: Tech | Közvetlen link a könyvjelzőhöz.

Vélemény, hozzászólás?

Adatok megadása vagy bejelentkezés valamelyik ikonnal:

WordPress.com Logo

Hozzászólhat a WordPress.com felhasználói fiók használatával. Kilépés / Módosítás )

Twitter kép

Hozzászólhat a Twitter felhasználói fiók használatával. Kilépés / Módosítás )

Facebook kép

Hozzászólhat a Facebook felhasználói fiók használatával. Kilépés / Módosítás )

Google+ kép

Hozzászólhat a Google+ felhasználói fiók használatával. Kilépés / Módosítás )

Kapcsolódás: %s