The code below solves the problem programmatically (and yes, it changes the database directly). Of course, it’s an unsupported solution – if you use it, you may get in trouble with Microsoft official support.

string sSiteUrl = "http://moss/sites/yoursite/";
//after the code gets executed, we have to dispose the 
//spweb object, since the Navigation object of the current SPWeb instance will contain wrong information
using (SPSite oSite = new SPSite(sSiteUrl))
{
    using (SPWeb oWeb = oSite.RootWeb)
    {
        //check if the top navigation bar is already there
        SPNavigationNode oTopnav = null;
        try
        {
            oTopnav = oWeb.Navigation.GetNodeById(1002);
        }
        catch (Exception)
        {
            oTopnav = null;
        }


    if (oTopnav == null)
    {
        //we've found out there is no top navigation bar. Let's create one;

        //we create a temporary navigation node pointing back to web site root
        Microsoft.SharePoint.Navigation.SPNavigationNode oTempNode = new Microsoft.SharePoint.Navigation.SPNavigationNode("Navigation", oWeb.ServerRelativeUrl);
        //we add this node to the "global" collection (where quick launch and top nav bar normally live)
        oWeb.Navigation.GlobalNodes.AddAsLast(oTempNode);

        //now the dirty work - go to the database and change the ID of the navigation node
        System.Data.SqlClient.SqlConnection oConn = new System.Data.SqlClient.SqlConnection(oSite.ContentDatabase.DatabaseConnectionString);
        System.Data.SqlClient.SqlCommand oCmd = new System.Data.SqlClient.SqlCommand();
        oCmd.Connection = oConn;
        oCmd.CommandType = System.Data.CommandType.Text;
        //we only update the node which has the same ID as the one we just created, but, to be completely sure that 
        //nothing else gets changed, we add a requirement to have the same siteid and webid
        oCmd.CommandText = @"UPDATE NavNodes SET Eid=1002 WHERE (Eid=" + oTempNode.Id.ToString() + 
             @") AND (SiteId='" + oSite.ID.ToString("D") + "') AND (WebId='" + oWeb.ID.ToString("D") + "')"; ;
        oConn.Open();
        oCmd.ExecuteNonQuery();
        //closing the connection
        oConn.Dispose();
    }
}


}    //the oSite object is disposed here

This is actually not the only place where you can see the magic _vti_something. I remember myself deleting such directories from “wwwroot” quite often back in the days “everyone” used MS FrontPage. FrontPage used to create the folders “_vti_bin”, “_vti_cnf” on your computer locally as you developed a website .. and also on the server, if you used “Frontpage Extensions” for publishing. The _bin folder would normally contain executables required for FP server components (as far as I understand, something like cgi_bin).

So, even though FP is announced dead, guys from the SharePoint team apparently like the idea of puting executables in the _vti_bin folder which was used by FrontPage Extensions.

Anyway, the question is, what does the acronym “VTI” mean. Apparently, Microsoft did not develop MS FrontPage from scratch, they acquired “Vermeer Technologies Inc”. Thus the name of “bin” folder in FrontPage. Thus the URL for lists.asmx in SharePoint.

We swiped out all of the built-in styles and layouts to achieve maximum flexibility and stylability of MOSS infrastructure. I believe this is the best choice when you have to adapt your portal to custom tailored design layout.

Well, the result was, the portal worked fine with our master page, BUT the content query web part failed. It failed every time we enabled the RSS feed feature. Instead of seeing the actual content, it showed only an error message (in Latvian, since we’re using the latvian language pack) “Šo Web daļu nevar parādīt. Lai novērstu problēmu, atveriet šo Web lapu ar Windows SharePoint Services saderīgā HTML redaktorā, piemēram, Microsoft Office SharePoint Designer. Ja problēma netiek novērsta, sazinieties ar Web servera administratoru.”

No traces could be found in the ULS log nor in the event log of the server. After setting the diagnostic logging of all categories to verbose, finally an exception was written to the logfile:

 Error while executing web part: System.Xml.Xsl.XslTransformException: An error occurred during a
 call to extension function 'RegisterFeedUrl'. See InnerException for a complete description of the error. ---> 
 System.Web.HttpException: The control collection cannot be modified during DataBind, 
 Init, Load, PreRender or Unload phases.     at System.Web.UI.ControlCollection.Add(Control 
 child)     at Microsoft.SharePoint.Publishing.WebControls.WebPartRuntime.RegisterFeedUrl(String url, String type)    
 --- End of inner exception stack trace ---     at ....

When looking at the RegisterFeedUrl in .Net Reflector, we found out that the code actually accesses the Header property of the Page object that is being rendered and adds HtmlLink control to the collection. It gave us a hint that probably there is something wrong with the page and header objects. And – yes, we had left out the runat="server" part of the HTML and HEAD tags. So, this is the absolute minimum you must have:

<HTML runat="server">
    <HEAD runat="server">
....

.. and, of course, the name space references and other stuff you usually put in the HTML element tag.

I’m just wondering how does one count LOC in Sharepoint? Or, to be more general, how do you measure the amount of work that has been invested in creating a solution in Sharepoint.

A solution can consist of

• content type definitions (XML files),
• list definitions (XML files again)
• feature definitions (XML),
• Solution manifests (XML),
• CAB file descriptors (“code”),
• ASPX pages (ASP.net code),
• ASPX code-behind files (finally, VB.net, countable!),
• Event handlers code (VB.net, cool),
• Workflow diagrams (generated VB.net code),
• Workflow code-behind files (VB.Net files),
• Workflow rules (XML),
• … and many more things which are not crurrently the case for me;-)

So how do you put it all together? In my opinion, a line in feature.xml file has much more value than a table-tr-td line in ASPX page (the former can break “everything” in your site while the latter cannot). Some lines in list definitions are valuable, some are not. Should one assign values to LOCs of each file type? Seems like LOC is no answer at all. For instance, workflow designer generated code has kind of “no value” as a VB.Net code and LOC measurement wouldn’t tell you much about the effort made to create the particular workflow.

Workflow modificēšanas formas jāveido kā InfoPath XSN formas, nevis kā ASPX formas. InfoPath ir dabūjams pilnajā MSOffice paketē, oficiāli tas piederas pie “Microsoft Office Suites and Applications 2007″ pakas

Pašas formas izveide

Jāveido jauna forma, to veidojot uzreiz vēlams uzstādīt ķeksi “hide features that do not work in InfoPath Forms Services” (saucas kaut kā citādi, bet ideja ir tā).

Svarīgi ir uzlikt sekojošus atribūtus iekš “Tools->Form options”:

Browser

• Izvācam ķeķšus pie “Show toolbar at top of form; show toolbar at bottom of form.
  Modifikācijas formā šie toolbari nav būtiski, jo formas submitošanai visticamāk izmantosim pogu. Savukārt “Save”, “Update” utt darbības vispār šeit ir liekas.

Security and trust

• Security level: Domain (neļaujam automātiski noteikt)
• Security and trust -> Sign this form template. Ja ir administratoru piešķirts sertifikāts, var parakstīt ar to, bet šīm vajadzībām pietiek arī ar “Create certificate” (pats priekš sevis izveidos sertifikātu)

Compatibility

• Design a form template that can be opened in a browser or InfoPath

Datu submitēšanai jāizveido datu konekcija, kas nodos atpakaļ informāciju uz “hosting environment” (mūsu gadījumā – sharepoint workflow-am). To dara zem Tools->Data Connections. Jāspiež “Add”, jāizvēlas “Create new connection to: Submit data”. Nākamajā logā – “To the hosting environment…” un jāiedod konekcijai vārds.

Tai pogai, kas būs kā “submit” attiecīgi jāiekonfigurē, ka vai nu:

• tā ir submit poga – tad prasīs, pa kuru datu konekciju sazināties ar formu. Tad jāuzstāda, ka pie submitēšanas lietotājam nerāda paziņojumu, ka submits ir veiksmīgs un pēc submitēšanas aizver formu
• tā ir parasta poga, kas darbojas uz likumu (rules) pamata. Tad jāizveido likums, kas uzstāda formas vērtības un beigās nosubmitē formu un to aizver

Formas datu shēmai būtu vēlams iedot sakarīgu nosaukumu, pēc noklusējuma tas ir “myFields” – ja negribam ar tādu turpmāk strādāt, jāpārsauc un jāizveido normāli.

Kad viss gatavs, dodamies File->Publish. * Izvēlamies “To a network location”. Norādām vietu uz c:, kur vēlamies formu “publicēt”, norādām formas nosaukumu vai, ja apmierina piedāvātais, atstājam to pašu. * Pēc tam wizardā ir jautājums “If all form users can access the location that you entered in the previous step, Click next”. Šeit ir svarīgi atstāt to teksta lauku TUKŠU, citādi forma nestrādās worklfowā! * Izmetīs warningu, ka tas var būt slikti – spiežam OK.

Paņemam File->Properties un apskatāmies/nokopējam automātiski noģenerēto “ID” lauka vērtību, kas izskatās apmēram kā “urn:schemas-microsoft-com:office:infopath:ReviewModForm:-myXSD-2007-08-22T06-32-52″

Formas lietošana worklfowā

Lai formu piesaistītu workflovam, kas aprakstīts kā Sharepoint Feature.

Iekopējam publicēto XSN failu blakus feature.xml failam. Instalējot featuri, šim XSN jānokļūst zem c:\program files….\12\template\features\ManaFeature

Feature.XML:

• Feature tagā:
  svarīgas ir šādas rindas (<Feature> taga iekšpusē, To rezultātā, pie feature aktivizēšanas, izpildīsies kods, kas aktivizē arī workflow-am piesaistītās formas):
  ReceiverAssembly=”Microsoft.Office.Workflow.Feature, Version=12.0.0.0, Culture=neutral, PublicKeyToken=71e9bce111e9429c” ReceiverClass=”Microsoft.Office.Workflow.Feature.WorkflowFeatureReceiver”

• ElementManifests tagā:
  Visi XSN faili jāpiemin arī ElementManifests tagā. Manā gadījumā bija:
  <ElementFile Location=”ReviewModForm.xsn”/>

• Properties tagā:
  Lai tiktu aktivizētas šīs formas, papildus vēl arī <Properties> tagā jāieliek šāda rinda:
  <Property Key=”RegisterForms” Value=”*.xsn” />

Workflow.xml (vai kā nu saucas XMLs, kas apraksta workflowu:

• Workflow tagā:
  Uztādām noklusēto WorkflowModifications:
  ModificationUrl=”_layouts/ModWrkflIP.aspx”

• MetaData tagā:
  Jāveido jauns modifikācijas apraksts, kas atsaucas uz formu. Manā gadījumā bija:
  <Modification_d03867f5-99f7-469e-94af-7fcefe476a22_FormURN>
  urn:schemas-microsoft-com:office:infopath:ReviewModForm:-myXSD-2007-08-22T06-32-52
  </Modification_d03867f5-99f7-469e-94af-7fcefe476a22_FormURN>
  <Modification_d03867f5-99f7-469e-94af-7fcefe476a22_Name>
  Atsaukt saskaņošanu
  </Modification_d03867f5-99f7-469e-94af-7fcefe476a22_Name>

Ar slīprakstu atzīmēju tās vietas, kas katram gadījumam ir citādi. Kā redzams, šeit FormURN tagā iekšpusē esošais sakrīt ar to formas ID, kas tika nokopēts InfoPath-ā. Jaunu GUID ģenerējam ar GuidGen, UZMANĪGI – tam guidgen uzģenerēs ar lielajiem burtiem. VisualStudio izmantojot, tas automātiski pārtaisa uz mazajiem burtiem. Tāpēc ērtāk būs arī šeit izmantot ar mazajiem, jo citādi tas netiks atpazīts.

Pašā workflowā, vietā, kur šāda modifikācija ir pieļaujama, jāievieto EnableModification aktivitāte, kurai ModificationID uzstāda uz iepriekšējā solī ģenerēto GUIDu (ar mazajiem burtiem). Pēc tam vēlams ieveitot “EventHandlingScope”, kur normālajā zarā veic normālo darbu, bet eventu ķērājā ieliek EventDriven aktivitāti, kas gaida OnWorkflowModified notikumu (šeit atkal sasaiste notiek pēc ModificationID).

Šajā brīdī vēl nekas nestrādās, jo nav izveidota datu apmaiņa starp InfoPath formu un Workflow. No WF puses tā tiek nodrošināta, izmantojot ContextData atribūtu – tur tiek sagaidīts XMLs kas atbilst InfoPath formas aprakstītajai shēmai. Tieši tādu pašu ContextData piedāvā arī OnWorkflowModified aktivitāte, tikai šeit saņemam no formas atpakaļ pienākušos datus.

XMLu, protams, var sacerēt pats, bet var arī iegūt automātiski.

XSD shēmas ģenerēšana

InfoPath formu atveram dizainēšanas režīmā, izvēlamies tai “Save as Source files” un izvēlas, kur saglabās. Izvēlētajā folderī uzradīsies vairāki faili, no kuriem svarīgākais: myschema.xsd – tas satur mūsu InfoPath formas shēmu.

Pēc tam no šīs shēmas var uzģenerēt VB vai C# klasi, kas “apkalpo” šādu shēmu. To darām ar komandrindas rīku “xsd.exe”:

  cd c:\manataka
  xsd.exe myschema.xsd /C /o:.\ /L:VB

Uzģenerējas fails myschema.vb, kurā iekšā klase ar nosaukumu tādu, kā iedevām savam datasetam 1. solī. Manā gadījumā – ReviewModDataSet

Šo klases failu iekļaujam savā projektā. Lai sagatavotu aktivitātei nepieciešamo XML stringu, var lietot šādu koda fragmentu:

        Dim oFormData As New ReviewModDataSet
        Using stream As New IO.MemoryStream
            Dim serializer As New Xml.Serialization.XmlSerializer(GetType(ReviewModDataSet))
            serializer.Serialize(stream, oFormData)
            Me.enableRecall_ContextData = Encoding.UTF8.GetString(stream.GetBuffer())
        End Using

Ar slīprakstu iezīmēju atribūtu, kurā nepieciešams uzstādīt iegūto XML vērtību.

SPPS ļauj glīti nomainīt gan “Sort order”, gan “Locale” katram atsevišķam Web vai Site objektam. To dara apmēram šādi. Varam uzstādīt latviešu lokāli un latviešu kārtošanas secību. Rezultātā iegūstam, ka konkrētā vietne tiešām izmanto 1062 lokāli (&H426 vai lv-LV, var saukt dažādi).

Pēc vērtības nomainīšanas, varam, skatot kādu ierakstu, pamanīt: “Izveidots: 2007.07.31 , 11:30. Autors: TādsUnTāds”.
Rodas jautājums, kas gan tas par interesantu datuma formātu, kurā sākumā raksta gadu, tad mēnesi un tad datumu (yyyy.MM.dd.) Skolā taču mums ir mācīts izmantot formātu dd.MM.yyyy, tātad šodien es gribētu rakstīt 31.07.2007.

Pēc nelādzīgi plašas izpētes esmu noskaidrojis, ka tā tas ir paredzēts! Microsoft darinātais (bet acīmredzot taču kādas latviešu komisijas ieteiktais) formāts ir tieši tāds.

Neliels VB.Net koda fragments parāda, ka tā ir:

    Dim oLoc As New Globalization.CultureInfo( _ 
                    culture:=1062, _ 
                    useUserOverride:=False)
    Debug.WriteLine(oLoc.Name & ": " & _
                    oLoc.DisplayName & ":" & _
                    oLoc.DateTimeFormat.ShortDatePattern)

Izejā tiek izdrukāts

   lv-LV: Latvian (Latvia):yyyy.MM.dd.

Sharepoint to ņem vērā un tieši tā arī parāda datumus. Kāpēc mēs to ikdienā neredzam? Visticamāk, tāpēc, ka vai nu paši vai sistēmu administratori pēc operētājsistēmas instalēšanas esam atvēruši Control Panel un nomainījuši datuma formātu sadaļā “Regional Settings”. Koda piemērā bija redzams, ka parametrs “useUserOverride” tiek nodots kā “False”, tātad – ignorējot lietotāja veiktos pielāgojumus. Protams, savā datorā veicot pārbaudi un šo parametru norādot kā “True”, ieraudzīju jau sagaidāmo datuma formātu.

Sharepoint, kas ir servera produkts, nedrīkstētu izmantot atsevišķa lietotāja veiktus pielāgojumus, lai rādītu saturu citiem lietotājiem – un tā tas arī dara.

Pašlaik diemžēl neredzu labu apkārtceļu. Vienkāršākais ir uzstādīt, ka izmantosim vācu lokāli (1032), bet tad vietās, kur uz ekrāna parādās garais datums, parādīsies “Diensdag, 31. Juli”.

Ja nepieciešama valodu paka “plikajam” Windows Sharepoint Services, tā pieejama jau ilgāku laiku.Te gan uzreiz gribu brīdināt, ka šis latviskojums ir nepilnīgs. Publiskajā daļā redzamie teksti ir nolatviskoti, administrācijas daļā vietām redzami arī angliski teksti, vietām vispār parādās resursu identifikatori (izskatās apmēram kā $Resources:UberAdminLink$).
Lejupielāde: WSS 3.0 valodu paka

Kopš šī gada sākuma tīmeklī it bieži tiek pieminēts “jaunais Sharepoint” – visvairāk kā apjūsmojoši ieraksti dažādos blogos, cik ērts gan tas būs. Runa ir par Sharepoint 2007, precīzāk, diviem Sharepoint saimes produktiem – Windows Sharepoint Services (WSS) 3.0 un Microsoft Office Sharepoint Server (MOSS) 2007. Ar ko tie atšķiras? Apmēram ar to pašu, ar ko Notepad atšķiras no Wordpad – ar iespēju bagātību. Ja WSS iedomājamies kā skudrupūzni, tad MOSS ir skudrupūznis ar centrālapkuri, četriem skursteņiem un peldbaseinu pagrabā. Vārdu sakot, MOSS ir daudz papildus lietu – unificēta meklēšanas sistēma, lietotāju individuālie saiti, papildus saitu templeiti, papildus darba plūsmu realizācijas, biznesam svarīgo indikatoru (KPI, key performance indicators) monitorēšana, Excel web servisi utt utt. Vēl viena atšķirība – WSS ir “par velti”, tas ir, kopā ar Windows Server 2003, bet MOSS ir maksas produkts… un dārgs maksas produkts.

Atpakaļ pie pamatstāsta. Solīja jau kādu laiku, šī gada sākumā iznāca pirmā beta versija, kas bija patiešām ar īstu “betas” garšu, šī gada maijā – otrā Beta, augustā – Beta2TR versija. Pagājušajā nedēļā Microsoft paziņoja par galaversijas iznākšanu, pašlaik jebkuram ir pieejama 180 dienu trial versija MOSS un, protams, jebkuram Windows Server 2003 īpašniekam – WSS 3.0 RTW Instalēšanai būs noderīgs .NET Framework 3.0, kas arī tika izziņots pagājušajā nedēļā.

Par jaunumiem šajā versijā. Vēl joprojām Sharepoint kā datu glabātuvi izmanto Microsoft SQL Server, tagad varam lietot gan 2000., gan 2005. versiju. Joprojām tas darbojas kā IIS webservera process (bet, atšķirībā no iepriekšējās versijas, tagad kā normāla ASP.Net aplikācija, nevis ISAPI filtrs). Ir krietni uzlabota Active Directory integrācija, tagad varam precīzāk definēt attiecību “domēna lietotājs:portāla lietotājs”, piemēram, nosakot, kurus portāla lietotāja atribūtus nolasīt no kuriem domēna lietotāja konta atribūtiem (šī atkal laikam tikai mani interesējoša nianse).

Piekļuves tiesību granularitātes līmenis (ak, svešvārdi…). 2003. versijā nebija daudz iespēju – piekļuvi varēja definēt vai nu visam saitam kopā, vai katrai dokumentu bibliotēkai vai sarakstam atsevišķi. Un viss. Jaunajā variantā piekļuves tiesības varam definēt līdz pat ieraksta līmenim, kas ir daudz loģiskāk, ja nepieciešams izveidot koplietošanas dokumentu glabātvi. Šī iemesla dēļ gan sanācis tā, ka tiesību administrēšana ir kļuvusi ķēpīgāka. Ja līdz šim šķita, ka normālā prakse būtu – 1) Sharepoint saita līmenī sadefinēt loģiskas lietotāju grupas 2) Šīm grupām piešķirt tiesības skatīt to vai citu dokumentu bibliotēku, sarakstu, darīt to vai citu darbību 3) Šajās grupās ievietot cilvēkus vai grupas no domēna … tad tagad rodas sajūta, ka “ai, vai tad nu es šī viena dokumenta dēļ taisīšu speciālu grupu?”, tātad tiesības tiek izmētātas pa visu saitu.

Audiences (šķiet, šī ir MOSS, nevis WSS iespēja). Katram ierakstam varam norādīt mērķauditoriju (target audiences), t.i., grupas, kam tas varētu būt interesants. Tāpat – lapā ievietotam webpart-am var norādīt auditoriju. Ja pareizi saprotu, piekļuve šādā veidā netiek aizliegta, bet attiecīgais ieraksts vai webparts tiek aizvākts no to lietotāju acīm, kam tas nebūs vajadzīgs. Un tas ir ērti.

Navigācijas sistēma. Jau noklusētajā shēmā tā ir stipri sakarīga. 1) katram saitam var veidot savu augšējo navigācijas paneli, sastāvošu no atsevišķām cilnēm (tabs). Ir izvēle, vai mantot “parent” saita tabus, vai izmantot savējos. 2) stipri labāks ‘quick launch’ menu saita kreisajā malā. Ir izvēle, vai nu automātiski ģenerēt no visām dokumentu bibliotēkām un sarakstiem, vai veidot pašam savējo 3) breadcrumbs pasākums, kas parāda vertikālo navigāciju saitu struktūrās. Visumā ir sajūta, ka apmaldīties nevarēs.

Darba plūsmu programmēšana. Kopā ar Windows Workflow Foundation ir atnākusi iespēja strādāt ar darba plūsmām arī no Sharepoint. Ir sajūta, ka te ir savāktas vienkāršākās un nepieciešamākās lietas no Biztalk Server un palaistas plašākās tautās. Līdz ar to tādi procesi kā dažādu veidu vīzēšana, atsauksmju savākšana, atbilžu sagatavošana un citi darbiņi, ko cilvēki veic nelielās komandās, ir aprakstāmi un programmējami arī šajā vidē.

Multiple lookups. Iepriekšējā Sharepoint versijā sarakstam bija iespējams izveidot lauku, kurš norāda uz cita tajā pašā saitā esoša saraksta konkrētu ierakstu. Piemēram, cilvēku tabulā varētu būt lauks, kas ir norāde uz struktūrvienību sarakstu. Līdz šim nebija iespējams apskatīt situāciju, kad cilvēks strādātu vairākās struktūrvienībās vienlaicīgi. Tagad ir.

Custom field types. Šis ir interesants. Pēc noklusējuma Sharepoint sarakstiem var pievienot laukus ar tipiem kā “text”, “multiline text”, “number”, “date”, “choice”, “lookup”… tagad varam veidot savus tipus. Nu, kaut vai tas pats iecienītais piemērs ar personas kodu – zināms teksta formāts, zināms garums. Atliek tikai izstrādāt savu klasi, kas mantota no SPField tipa, izveidot rediģēšanas kontroli savam lauka tipam (Jo Sharepoint taču automātiski ģenerē datu ievades un parādīšanas formas katram sarakstam), varbūt vēl neliela čupiņa koda… un tam ir jādarbojas. Pagaidām neesmu izmēģinājis, bet jau ticu, ka būs labi.

Wiki un Blog saitu templeiti. Nezinu, pagaidām nešķiet, ka jaunā spēļmantiņa būs tik vērta, cik viņi paši sola. Wiki sintakse ne tuvu nelīdzinās wikipedia iespējām, blogi it kā ok, pat komentēt var… bet kaut kā nav ērti, vismaz ne priekš tiem, kas paši tajos raksta.

Overall – labais! Uzrakstīšu citreiz vēl, šoreiz jau tā par garu sanāca.

The result is: NEVER use this code construction to find an element by its ID:

oList = oWeb.Lists("LongList")         'gets the list object
oItem = oList.Items.GetItemById(123)   'finds the element within the list in the list

You should rather use this one:

oList = oWeb.Lists("LongList")         'gets the list object
oItem = oList.GetItemById(123)         'finds the element within the list in the list

The big mistake is that accessing the “Items” property of the SPList object oList creates an SPQuery object in background to read all the items in particular list and then GetItemById() method of the SPListItemCollection (oList.Items is a SPListItemCollection object) runs a loop, looking for an item with ID attribute set to the value 123.

However, if you use the second code example the SPList ojbect oList creates an SPQuery object in background to read only one object having ID attribute set to 123, i.e.:

<Where><Eq><FieldRef Name="ID"></FieldRef><Value Type="Integer">123<Value></Eq></Where>

and then returns the element it found.

The same applies to the DeleteItemById() method. I had to work around in a bit different manner:

'oList.Items.DeleteItemById(123) 'this was the original code
oList.GetitemById(123).ListItems.DeleteItemById(123) 'this is the improved code

As you can see, the improved code first finds the list item by its ID, then accesses the ListItems property (which is again SPListItemCollection) and executes a DeleteItemById() command on the particular collection where the size of the collection is 1.

A really difficult workaround was needed to fix the AddNewItem function where I had code like this:

Dim oNewItem as SPListItem
oNewItem = oList.Items.Add()

Again, accessing the Items attribute leads to reading all the items in the list. To avoid that, I created a SPQuery object that never returned any elements, then called Add() method on the collection returned by the query.

'reads all items having id=0. Should return no rows
oEmptyQuery.Query = "<Where><Eq><FieldRef Name='ID' />" & _
        "<Value Type='Counter'>0</Value&gt;</Eq></Where>"
oItemColl = oList.GetItems(oEmptyQuery)
oNewSPItem = oItemColl.Add()    'adds an item to the empty list
'saves the new item and re-reads it from SharePoint
oNewSPItem.Update()
oNewSPItem = oList.GetItemById(oNewSPItem.ID)

The two last lines were needed because it seems that the field collection is not geting populated when a query returns no rows. However, my code didn’t seem to run nice without the last two rows.

So we all know that in SharePoint you can allow people and assign them SharePoint roles in two ways:

• creating a “Sharepoint User” within the portal and assigning roles to the user,
• adding a domain group to users and assigning roles to a particular group.

The first case is the easy one. The second is not. Say, we add a group “MyDomainGroup” to SharePoint users and assign them a specific SharePoint role “MySharepointRole”. What happens when a user belonging to the domain group visits your SharePoint site:

• the user is allowed to open the page, because he belongs to the specific group
• the IIS thread runs under the security account of the user because this is the way IIS impersonation works
• code in webparts is executed under the security account of the user

The interesting thing is that SPControl.GetContextWeb(context).CurrentUser returns a valid SPUser object (even though we know there is no SharePoint Web user profile for him). You can get the LoginName property of the CurrentUser and you get the actual login name (let’s say, MyDomain\MyUser).
So let’s try the opposite way – we know the user name, let’s find the user:

SPControl.GetContextWeb(context).Users("MyDomain\MyUser")

This ends up in an SPException, because there is no such a user MyUser in this SharePoint web – he was only allowed to open this page because he is in the domain group.

OK, I think I should explain the situation a bit more. Of course, if you run all the code in the webpart itself, there is no problem – just keep using the CurrentUser property and everything should run smoothly. However, due to some particular security considerations I need to run some code under a privileged account. This is why I’m using a COM+ component that runs under another security account.

For instance, I have a function in the COM+ component that returns an array of role names user belongs to. Within the function, you have to find the SPSite, SPWeb and SPUser to read the roles. You can do it like this:

Dim oSite as New SPSite("http://server/sites/somesite")
Dim oWeb as SPWeb = oSite.AllWebs(New System.Guid("6CCED9AD-7C38-4FF3-9E69-1B2F43D2BD65"))

For a regular user, you could read his role list like this:

oUser = oWeb.Users("MyDomain\MyUser")
For Each oRole As SPRole In oUser.Roles
    '... add to the return array
Next

This does not work for a user belonging to a domain group and not being registered as a local user in the SPWeb. As mentioned above, there is no such user. However, there is a special user “MyDomain\MyDomainGroup” registered in the web. So you can do it this way:

For Each oGroup As SPUser In oWeb.Users
    If oGroup.IsDomainGroup() Then 'this is "True" for domain groups, "False" for regular users
        If IsUserMember("MyDomain\MyUser", oGroup.LoginName) Then
            For Each oRole As SPRole In oGroup.Roles
             '... add to the return array
            Next
        End If
    End If
Next

This should work fine now. Of course, you will do it in the “Catch” block after you have tried to find the user in the regular manner.
The only thing we need is a function IsUserMember that tells if a user ir member of a domain group. This is quite another story, covered in another article – here: Does this user belong to a domain group?