Sikkerhetsmessige kreves For InfoPath-skjemaer

Jeg måtte møte i dag et sikkerhetskrav for et InfoPath-skjema. I denne virksomheten situasjonen, et relativt lite antall personer tillates å opprette et nytt InfoPath-skjema og et mye bredere publikum er tillatt å redigere. (Dette er nye-utleie on-boarding skjemaet brukes av menneskelige ressurser som starter en arbeidsflyt).

Å oppfylle dette målet, Jeg opprettet skapt to nye tillatelsesnivåer («opprette og oppdatere" og "oppdatere bare"), brøt arv for skjemabiblioteket og tillatelsene til en "lag, oppdatere" bruker og en egen "oppdatering bare" bruker. Mekanikerne alle arbeidet, men det viste seg for å være litt mer med enn jeg forventet. (Hvis du føler litt ustø på SharePoint-tillatelser, Sjekk ut denne bloggen). Nødvendig sikkerhetskonfigurasjonen for tillatelsesnivået var ikke opplagt settet med granular permission. Opprette en oppdatering bare tillatelsesnivået for et InfoPath-skjema, Jeg did det fulgte:

  1. Opprett en ny tillatelse.
  2. Fjerne alle alternativer.
  3. Valgt bare følgende fra "Listetillatelser":
    • Redigere elementer
    • Vis elementer
    • Vise programsider

Disse alternativene kan en bruker oppdaterer et skjema, men ikke opprettet.

Kunsten var å aktivere "Application sidene". Det er ikke noen verbage på tillatelsesnivået som angir som er nødvendig for oppdateringen bare InfoPath-skjemaer, men dreier ut det er.

Opprett og Oppdater var enda rarere. Jeg fulgte de samme trinnene, 1 gjennom 3 ovenfor. Jeg måtte legge spesielt "område tillatelse" alternativet: "Bruke funksjoner for klientintegrasjon". Igjen, beskrivelsen det gjør ikke det virke som det burde være nødvendig for et InfoPath-skjema, men det er.

</slutten>

Technorati Merkelapper: ,

At “I mellom” Følelse; Observasjoner på SharePoint rådgivning

Dessverre, fase én av mitt siste prosjekt har kommet til slutten og klienten har valgt for å gå videre selv på fase to. Vi gjorde vår jobb for godt, som vanlig 🙂 Jeg er nå mellom prosjektene, en spesiell tid for ansatte konsulenter som meg (i motsetning til uavhengige som normalt må leve i evig frykt for mellomtiden 🙂 ). Vi ansatte konsulenter fylle denne gangen på ulike måter: Arbeide med salg folk til å skrive forslag; vikariere for noen eller sikkerhetskopiere en person på denne eller odde jobben; studere; Blogging :). Det er vanskelig å planlegge mer enn noen få dager på forhånd. Til tider som dette, mens jeg har litt tid på hendene mine, Jeg liker å reflektere.

Jeg er nesten alltid trist å forlate klientens campus for siste gang. Vi konsulenter danne en særegen slags forhold med våre kunder, i motsetning til typisk medarbeider forholdet. Det er penger vinkelen — alle vet konsulenten er Dobbeltrom/tremannsrom eller enda mer enn de klient ansatte. Du er en kjent midlertidig person. Som konsulent, du er en permanent outsider med en mer eller mindre kjente avreisedato. Ennå, du spiser lunsj med klienten, ta dem ut til middag og/eller drinker, kjøpe informasjonskapsler for laget, gå på kaffe kjører, gi/motta julekort — alle typer kolleger gjøre. På den ene siden, du er voksen i rommet. Du er en ekspert i teknologien som setter deg i en bedre posisjon. på den andre siden, du er en baby. På dag null, konsulenter vet navnene, stedene eller kundens lingo. De fleste ganger, konsulenter lære aldri alt.

Når ting går bra, du blir godt integrert med klientens prosjektgruppen. De behandler deg som en medarbeider i én forstand, og fortrolige i en annen. Siden vi ikke har en manager-stil rapporteringsrelasjon med klienten, prosjektgruppen føles ofte litt gratis å lufte skittentøy. De la deres barrierer ned og kan sette konsulent i en vanskelig stilling, aldri innser de gjør det.

Konsulenter ofte ikke implementere fase to og som aldri blir lett for meg. Jeg tror dette er spesielt hardt med SharePoint. Fase én av typiske SharePoint prosjektet dekker installasjon/konfigurasjon, styring, taksonomi, grunnleggende innholdstyper, osv.. og i mange respekterer, utgjør en lengre, ekstremt detaljerte funn. Det er hvordan jeg vise mitt siste prosjekt. Vi gjorde alt grunnleggende samt utføre noen hyggelig mini-POC ved å utvide CQWP, implementere BDC-tilkoblinger til PeopleSoft, introdusert en ganske kompleks arbeidsflyt med SharePoint Designer, rørte på grunnleggende KPIS og mer. En skikkelig fase to ville utvide alle som med omfattende, nesten gjennomgripende BDC, veldig fin arbeidsflyt, fin innstilt og bedre søk, arkivsenteret, Excel-tjenester og trolig viktigste, nå ut til andre forretningsenheter. men, Det er ikke for å være for meg, og det er trist.

Basert på denne siste erfaringen, Jeg tror det er rimelig å si at en skikkelig enterprise SharePoint-implementering er en ett år prosess. Det kan trolig legitimt kjøre to år før han nådde et punkt for avtagende avkastning. Detaljer saken, selvfølgelig.

Det er konsulentens livet og alle disse små klager er enda verre i en SharePoint-engasjement. Som jeg har skrevet før, SharePoint er vannrett naturen gir deg i kontakt med en rekke personer og bedrifter enheter. Når du arbeider med så mange, Du kan se så mange måter at SharePoint kan hjelpe firmaet mer effektivt, spare tid, gjøre ting bedre… men du får ikke alltid å gjøre dem..

Jeg ser ofte tilbake til min første jobb ute av college, før du starter en konsulent karriere 1995. Vi fikk til å gjøre en fase to og selv en fase tre. Det var hyggelig gangene. På nedsiden, men, Det betyr at det ville bety mye rutinemessig ting for. Administrere områdesikkerhet. Tilpasse innholdstyper. Lage visninger og endre visninger. Håndtere IE-sikkerhetsinnstillingene. Gjenopprette tapte dokumenter. Blech! 🙂

Til tross for min melankolsk stemning, Jeg kan ikke forestille meg et sted jeg vil heller være (unntatt på en varm strand med en vakker tilførsel av brennevin).

Jeg kan ikke vente å komme i gang gjennomført neste SharePoint virksomhetsprosjektet.

(Apropos ingenting, Jeg skrev det meste av dette blogginnlegget på en NJ Transit buss. Jeg tror ikke jeg gjorde noen venner, men man KAN blogge på bussen 🙂 )

</slutten>

Technorati Merkelapper:

Søndag Funny: “De er ikke så ille”

Tilbake i nærheten 1999, Jeg tilbrakte mange uker ute i Santa Barbara, CA, arbeider for en klient, forlate min dårlige kone tilbake her i New Jersey alene. Jeg kjærlighet inderlig min kone. Jeg elsker henne like mye i dag som jeg gjorde da hun tåpelig gift meg 1,000 år eller så siden. Et sted langs linjen, Jeg laget et uttrykk, "spesielle frykt", som i "Samantha har spesielle fears." Hun som en spesiell frykt "bugs", for henne er ikke fluer eller marihøner, men heller mikrober. Hun er redd for denne eller at virus eller uvanlig bakterier afflicting vår sønn, eller meg, men aldri selv. (Hun er også spesielt redd av vampyrer, miniatyr onde dukker (spesielt klovner) og ubåten ulykker; Hun vokst ut hennes spesielle frykt kledd i Santa Claus antrekk).

En dag, min kollega og jeg bestemte meg for å kjøre opp i de nærliggende fjellene nær Ohai. På et tidspunkt, Vi fikk ut av bilen i scenen. Når vi kom tilbake til bilen, Jeg la merke til at en sjekke var på skulderen. Jeg knipset ut av vinduet og det var det..

Natt, Jeg fortalte henne om vår stasjonen og nevnt tick. Samtalen gikk noe slikt:

S: "Oooo! De er dårlig. De bærer sykdommer."

P: "Vel, Jeg knipset det ut av vinduet."

S: "De er virkelig dårlig skjønt. De kan komme under huden og suge blod og overføre feil. Du bedre håret og kontroller at det ikke er noen i hodet!"

P: I en høy røst: "Min Gud! DE KAN TA OVER DITT SINN???"

S: Bokstavelig talt betryggende meg: "Nei, de er ikke det dårlig."

</slutten>

Technorati Merkelapper:

Rask og enkel: Automatisk åpne InfoPath-skjema fra SharePoint Designer Email

OPPDATERINGEN: Madjur Ahuja påpeker denne linken fra en nyhetsgruppe diskusjon: http://msdn2.microsoft.com/en-us/library/ms772417.aspx. Det er ganske definitiv.

===

Ofte ønsker å legge inn hyperkoblinger til InfoPath-skjemaer i e-poster sendt fra SharePoint Designer arbeidsflyter. Når brukere mottar disse e-postene, de kan klikke på linken fra e-posten og gå direkte til InfoPath-skjemaet.

Denne monster URL konstruksjon arbeider for meg:

http://server/sites/departments/Technical Services/InformationTechnology/HelpDesk/_layouts/FormServer.aspx?XmlLocation=/sites/departments/Technical Services/InformationTechnology/HelpDesk/REC REM RED Forms/REC2007-12-18T11_33_48.XML&Kilde = http % 3A % 2F % 2Fserver % 2Ecorp % 2Edomain % 2Ecom % 2Fsites % 2Fdepartments % 2FTechnical % 2520Services % 2FInformationTechnology % 2FHelpDesk % 2FREC % 2520REM % 2520RED % 2520Forms % 2FForms % 2FAllItems % 2Easpx&DefaultItemOpen = 1

Erstatt uthevet rød teksten med navnet på skjemaet, som vist i følgende skjermbilde:

bilde

Note det det er en masse hardkodede banen i URL-adressen, i tillegg til en URL-kodede komponent. Hvis dette er for vanskelig å oversette til din spesielle situasjon., Prøv å slå på varsler for skjemabiblioteket. Legge et skjema og når du får e-post, Vis kilden for e-post og du vil se alt du trenger å inkludere.

Gløgg lesere kan merke at ovennevnte e-kroppen viser også en kobling som får direkte tilgang oppgaven via en filtrert visning. Jeg vil forklare nærmere i en fremtidig innlegg.

</slutten>

Technorati Merkelapper:

Tenke på kommersielle produkter

Jeg satt opp en SharePoint Designer-servertillegg prosjekt opp på CodePlex tidligere i år og selv om det er egentlig ganske begrenset i omfang, Jeg anslår at det er blitt lastet ned av 40 til 60 (muligens også 100) selskaper i omtrent to måneder. Som indikerer for meg at det er et marked for løsningen og hvis jeg skulle lykkes kommersialisere den, that could translate into a goodly amount of beer 🙂

Min bakgrunn er faktisk mye mer i produktutvikling og jeg vet hva er nødvendig for å få en top-notch produkt, i motsetning til en CodePlex hobby-prosjekt, markedet. I min tidligere liv, Jeg var ansvarlig for produktet R&D for alle programvareprodukter. Forskjellen mellom da og nå er at jeg er en konsulent som nå jobber for en (utmerket) konsulentfirma (Conchango). Tidligere, Jeg hadde en hele selskapet bak meg og meg, selger og støtter produktene brakt vi til markedet. I dag, Jeg ville være alene.

Jeg har flere produktideer i tankene, men jeg tror den enkleste er å opprette en kommersiell versjon av ovennevnte CodePlex prosjektet som bruker det som utgangspunkt og utvider den ytterligere. Min fuzzy off-the-cuff tenkning er å belaste noe sånt $100 for en ubegrenset utviklerlisens og $500 per produksjon webfront. Jeg tror jeg vil også gi bort kildekoden.

Hvis du har tanker og erfaringer du er villig til å dele, Legg igjen en kommentar eller email meg direkte. Jeg vil gjerne høre meninger som:

  • Er det hele verdt?
  • Anbefalinger for markedsføring, samler inn penger, distribusjon.
  • Priser.
  • Støtte.
  • Noen andre kommentar du ønsker å forlate.

Det er "lett" å komme opp med produktideer og implementere dem, Selv om mange titalls timer arbeid kreves. Andre ting er ikke så lett for meg.

</slutten>

Technorati Merkelapper:

Søndag morgen-morsom: “Jesus må dø”

Vi kjøpte vår første (og bare) "luksus" bilen tilbake når orkanen Floyd spikret østkysten av USA. Vi fikk mye regn her i New Jersey og gått flere dager før livet tilbake til normal. Like før Floyd slo, vi laget et tilbud for en brukte Volvo 850 GL og etter Floyd slo, kjørte den hjem.

Det var vår første bil med en CD-spiller. Som de fleste nye bileiere, Vi gikk litt CD-gal, gjenopplivet vår sovende CD-samling og gikk på lange stasjoner bare for å lytte til CD-er i bilen. Som alle moter, Dette gikk for oss og vi endte lytter til samme CD igjen og igjen. I vårt tilfelle, Det var Jesus Christ Superstar.

En av de (mange) strålende brikker i at rock opera er sunget av etablering religiøse typer, ledet av Kaifas, «High Priest». De synger vei til å velge hvordan du skal håndtere "Jesus problemet" og Kaifas leder dem til konklusjonen at "Jesus må dø". Refrenget på sangen er "bare må dø, må dø, må dø, Jesus må dø". Du hører det avstå mye i dette stykket.

Samtidig, min sønn var omtrent tre år gammel. Du kan sannsynligvis se hvor dette kommer.

Jeg kom hjem fra jobb en dag og min sønn er i stuen leke med leker og summende seg selv. Jeg tar av meg jakken, ser gjennom posten og alle mine vanlige gå-de-dørs ting og jeg plutselig innser at han bare sier, egentlig ikke synge: "Jesus må dø, må dø, måtte dø." Jeg var mortified. Jeg kunne bare se ham gjøre det på en av hans baby spille datoer på en venns hus — sannsynligvis sist spille dato med at baby venn.

We pulled that CD out of the Volvo after that 🙂

</slutten>

Technorati Merkelapper: ,

Google godtok min Live Spaces-blogg i AdSense-programmet

OPPDATERINGEN: Som av 03/09, Jeg har funnet noen måte å integrere min live spaces-konto med Google Adsense. Microsofts system her synes å forhindre alle tekniske mekanismer som Google gir potensielle adsense kroen. Jeg pleier å tro dette er hovedsakelig en bivirkning av de har bygget i levende områder, ikke en direkte innsats for å deaktivere Adsense.

Dette er ikke en SharePoint-innlegg, men kan være av interesse for bloggere generelt.

Noen kommenterte på deres Windows Live Spaces-blogg at Google bekreftende nektet sin søknad til å delta i AdSense. Hun teori om at Google nektet henne fordi Windows Live Spaces vert bloggen hennes. Men, Jeg var nylig tatt opp i programmet for min live spaces-blogg, så politikken har enten endret eller Google nektet henne for en annen grunn.

selvfølgelig, Jeg ser ikke noen opplagt måte å integrere Google AdSense i mitt live space, but it’s a start 🙂

</slutten>

Technorati Merkelapper: ,

Implementering av Master / Detalj relasjoner ved hjelp av egendefinerte lister

Forum brukere ofte som spørsmål som dette:

> hallo,
>
> Behage fortelle meg hvis det er noen muligheter til å bygge en egendefinert liste med
> overordnet og detaljert type (som fakturaer) uten å bruke InfoPath.
>

SharePoint gir litt ut av boksen-funksjoner som støtte typer forretningskrav sånn.

Generelt, en kobler to listene sammen med en oppslagskolonne. Liste A inneholder fakturaen meldingshodeinformasjonen og liste B inneholder Fakturaopplysninger.

Bruk flere lister til å vedlikeholde kundenumre, produktnumre, osv..

Bruke en webdel for innholdsspørring (i MOSS bare) og/eller en vise webdelen for å opprette flettede visninger av lister. SQLServer Reporting Services (SRS) er også tilgjengelig for rapportering siden av det.

Men, Det er noen viktige begrensninger som kan gjøre det vanskelig å bruke ren ut-av-esken funksjonene for noe som er selv moderat kompleks. Disse inkluderer:

  • Størrelsen på relaterte søk viser vs. "smartness" av kolonnetypen oppslag. Kolonnetypen oppslag presenterer seg på Grensesnittet forskjellig avhengig av om du har aktivert merker eller ikke. I begge tilfeller, out-of-the-box kontrollen viser alle tilgjengelige elementer fra listen. Hvis kildelisten inneholder 1,000 elementer, det skal være et problem. Kontrollen oppslag ikke bla gjennom elementene. I stedet, det trekker dem alle i kontrollen. Det gjør for en svært vanskelig brukergrensesnitt både dataregistrering og ytelse.
  • Oppslag "Trekk tilbake" én kolonne med informasjon. Du kan aldri trekke tilbake mer enn én kolonne med informasjon fra listen. For eksempel, Du kan ikke velge en kunde "12345" og vise nummeret som kundens navn og adresse samtidig. Oppslag bare viser antall og ingenting annet. Dette gjør for et vanskelig og vanskelig brukergrensesnitt.
  • Ingen intra-skjemaet kommunikasjon. Jeg har skrevet om dette her. Du kan ikke implementere gjennomgripende rullegardinlister, betinget aktivere/deaktivere felt, osv..
  • Ingen gjennomgripende sletting eller innebygd referanseintegritet. SharePoint behandler egendefinerte lister som uavhengige enheter og kan du koble dem til hverandre i en tradisjonell ERD forstand ikke. For eksempel, SharePoint kan du lage to egendefinerte lister, "kunde" og "fakturahodet". Du kan opprette et fakturahode som kobler til en kunde i kundelisten. Deretter, Du kan slette kunden fra listen. Esken, Det er ikke mulig å hindre dette. Å løse denne type problem, du bruker vanligvis hendelsesbehandling.

Det kan virke dystre, men jeg ville fortsatt bruke SharePoint som utgangspunkt for å bygge denne typen funksjonalitet. Selv om det er mellomrom mellom det du trenger i en løsning, SharePoint gjør det mulig for oss å fylle disse hullene med verktøy som:

  • Hendelsesbehandling. Bruk dem til å fremtvinge referanseintegritet.
  • Egendefinerte kolonner: Opprette egendefinerte kolonnen og bruke dem i stedet for standard oppslagskolonnen. Legge til personsøker, bufring og AJAX funksjoner for å gjøre dem mottakelig.
  • BDC. Denne MOSS-bare funksjonen kan vi spørre andre SharePoint-lister med overlegen brukergrensesnitt for vanlige oppslagskolonnen. BDC kan også nå ut til et serverprogram for bakenden. Bruk BDC for å unngå replikering. I stedet for å replikere kundeinformasjon fra bakdatabase forretningssystem, Bruk BDC i stedet. BDC funksjoner gir en hyggelig bruker grenseflate å rykk informasjonen direkte fra ERP-systemet der det hører og unngår å måtte opprettholde en replikering løsning.

    BDC er en MOSS-funksjon (ikke tilgjengelig i WSS) og er utfordrende for å konfigurere.

  • ASP.NET-webskjema: Opprette en fullfunksjons AJAX-aktivert skjema som bruker SharePoint-objekt modell og/eller tjenestene for å utnytte SharePoint-lister samtidig som det gir en svært forståelsesfull brukergrensesnitt.

Det siste alternativet kan føle som om du starter fra scratch, men vurdere det faktum at SharePoint-plattformen starter du med følgende nøkkelfunksjoner:

  • Sikkerhetsmodellen med vedlikehold.
  • Menysystem med vedlikehold.
  • "Master tabell" (dvs.. egendefinerte lister) med sikkerhet, innebygd vedlikehold og overvåking.
  • Søk.
  • Bakenden integrasjonsverktøy (BDC).

Hvis du starter med et nytt tomt prosjekt i visual studio, du har mye infrastructure og avløp å bygge før du nærmer hva SharePoint tilbyr.

Jeg tror at Microsoft har til hensikt å utvide SharePoint i denne retningen programutvikling. Det virker som en naturlig utvidelse til eksisterende SharePoint base. Microsoft CRM-programmet gir en stor utvidelse av måtte topptekst/detaljert programutvikling. Selv om disse funksjonene i CRM, teknologien er åpenbart tilgjengelig for SharePoint-utviklingsteam og jeg forventer at det vil gjøre sin vei til SharePoint-produktet slutten av 2008. Hvis noen har en kunnskap eller innsikt i dette, Legg igjen en kommentar.

</slutten>

Technorati Merkelapper:

Quick Tips: Webdelen for innholdsspørring, Kolonnen oppslagsverdien og XSL

Jeg har et kolonnenavn i en innholdstype som kalles "Real Estate plassering".

Denne kolonnen er av typen "oppslag".

Jeg har endret <CommonViewFields> og ItemStyle.xsl å vise kolonnen.

En enkel <XSL:verdien av merker =…> Returnerer tilbake en intern verdi som inkluderer ordenstallsplassering data, eksempel:

1;#Miami

Å få den menneskelige-vennlig-verdien, bruke xsl delstreng-etter, som vist:

<XSL:valuXSLf Velg = "delstreng-etter(@Real_x005F_x0020_Estate_x005F_x0020_Location,’#’)"></XSL:verdien av>

Du kan bruke denne teknikken når du arbeider med oppslagsverdier i XSL-transformeringer og trenger for å få verdien menneske-vennlig.

<slutten />

Technorati Merkelapper: , ,

SharePoint-Beagle Desemberutgaven opp & Live

Mange av dere vet dette allerede, men den desember utgaven av SharePoint Beagle er live.

Hver artikkel er verdt å lese i min mening.

Jeg ønsker å gi en litt ekstra bump til kollegaen min artikkel (Natalya Voskrensenskya). Hun gir en skjerm-shot extravaganza mens beskriver hvordan hun brukte egendefinerte lister, arbeidsflyt, SharePoint Designer, datavisninger og andre elementer til å implementere en selvbetjent trening funksjon i MOSS. Hun beskriver teknikker som kan brukes i mange ulike forretningsscenarier. sjekk ut hennes blogg mens du er i gang.

Ikke glem å sjekke min artikkel as well 🙂 I wrote about using MOSS to help an HR department manage open positions.

</slutten>