Хората често питат за използването на колона с тип данни "лице или група" в друга колона от данни тип "Изчислена".

Долната линия, Това не работи в WSS 3.0 (или мъх).

При добавяне на изчисляема колона, WSS показва списък на полета ви позволява да използвате за изчисляване. Ако напишете името на колона, която не е в списъка си, Той ви казва:

Една или повече препратки към колони не са позволени, защото колоните са дефинирани като тип данни, който не се поддържа във формули.

Workaround: Използвайте манипулатор на събитие. Манипулаторът на събитие пожари, когато потребителят записва елемента. Тя изпълнява актуализация, който би искал изчисляемата колона да направи за вас.

Полезни връзки за изчислени полета като цяло:

• Използване на [Мен] в изчисляема колона
• Примери на формули изрази (с любезното съдействие на http://jopx.blogspot.com/2007/10/calculated-fields-in-windows-sharepoint.html)

Бърз отказ от отговорност: Вярвам, че по-горе да бъде вярна и точна, но аз съм виждал достатъчно умни трикове тук и там в Мос/ВиК, че няма да бъде изключително изненадан (възбуден, ако щете) Ако някой е измисли начин да направите това без да се прибягва до код. Ако сте се разбра, умни работа-наоколо или познавате някой, че е, Моля да ме уведомите!

Ние направихме някои тежкотоварни повторно организиране на нашия сайт таксономия чрез "Управление на съдържание и структура". По незнайни за мен причини, този процес (Въпреки че работи в главната) счупи някои връзки за навигация в бързо стартиране. Прекъснати връзки се характеризират с:

• Грешен URL. За пример, Тя трябва да бъде "/ сайтове/департаменти/сайт с човешки ресурси /…". Въпреки това, новата връзка е "/ сайтове/корпоративни/сайт с човешки ресурси /…".
• Повторни бита на низа на заявката на заглавието, както и в:

/sites/departments/HumanResources/_layouts/viewlsts.aspx?Базов тип = 0?Базов тип = 0?Базов тип = 0?Базов тип = 0

Това е достатъчно лесно да се определи чрез сайта настройки/навигация. С изключение на, Мос представя ме с това, когато се опитвам и да го направя:

Факт е, никой не прави промени там (настрана от мен, Разбира се).

Едно бързо търсене се появи този MSDN форуми дискусия: http://forums.microsoft.com/MSDN/ShowPost.aspx?PostID=1691577&SiteID=1

Уилям Heurdier го излага добре в предпоследна (като от 10/02/07) пост:

Факт е:

За да възстановите повредената заглавия, Вие трябва да :

– премахнете всички списъци под повреден заглавие

– премахване на повреден заглавието

– От настройките на списъка, Добавяне на отстранения списък за бързо стартиране (Това регенерира за повредени заглавие)

След това сте добре да тръгвам….

---

SharePoint експерт – Sogeti капачка Джемини Швейцария

Аз бях малко объркан, защото продължих да искат да отидете на страницата на навигация, Направете промяната и след това се удари със "страницата е модифициран" съобщение. В крайна сметка, Разбрах, че аз трябваше да отидете в настройките на списъка и премествам/прибавям то към бърз хвърлям. Това е трик. Щастливите времена са отново тук!

</край>

Абонирайте се за моя блог!

АКТУАЛИЗИРАНЕ 12/10/07: Актуалната корекция, описана в MSDN KB929816 решила проблема за нас споменати по-долу. Получаване на спешната корекция и след това инсталиране на всеки сървър в групата. След това, помощната програма за конфигуриране на SharePoint на всеки сървър. Тук е MS поддръжка връзката за тази KB: http://support.microsoft.com/kb/932816.

Фон:

Ние имаме бизнес изискване, където околната среда инженеринг мениджър трябва да гарантира, че 30 Some-ODD производство места, разположени в целия Съединените щати трябва да гарантира, че тези растения файл за техните различни държавни с мандат на разрешителни в своевременно. Един подход, ние сме разследвани лостове "пауза преди дата" дейност достъпни за нас чрез SharePoint Designer worfklow. Инженеринг мениджър (или си асистент) въвежда всички необходими разрешителни и напомняне дати в началото на годината. Системата след това не всички вдигане на тежки предмети.

Околна среда:

МОС, 64 малко, действителен машина среда (развитие кутия), 2 сървъри (SQL сървъра #1, всичко останало на сървъра #2).

Проблеми:

Пауза преди дата действие изглежда като идеалното решение и добре може да се окаже себе си да бъде. Въпреки това, Тя не работи добре от кутията (за нас).

1. Задачата на работния поток не е планирана за изпълнение, някога. Аз открих това от четене чрез Кристофър Уайт (http://chrissyblanco.blogspot.com/2007/06/issues-with-delay-activity-in-moss.html) отличен хвалебствена използвайки stsadm thusly:
   

   C:\>stsadm -o getproperty - именасвойство "работа-поток" -URL адрес HTTP://Localhost

   <Свойство съществува = "не" />

   C:\>

   Това беше изненадващ резултат но лесно решени:

   C:\>stsadm -o setproperty - именасвойство "работа-worfklow" -propertyvalue "всеки 1 протокол между 0 и 59" -URL адрес HTTP://Localhost

   Операцията завърши успешно.

   C:\>

   При това, че, първата "в ход" поток бързо уволнен нагоре и го е направил работа.

2. За съжаление, следващия не работи както се очаква. За щастие, Кристофър се отнася ни Тук (http://support.microsoft.com/kb/932816). Както на писане на този пост, Ние чакаме за ИТ отдела да получи тази спешна корекция, но тя изглежда обещаващ. Нашите копия на засегнатите .dll не споделят един и същи размер в байтове, така че се надяваме това ще реши проблема.

Workaround:

Отново тичане командата stsadm -o setproperty сякаш prod буден таймера за работен поток. Това би, приблизително 7 минути по-късно, всъщност се събуди и продължи с работния поток.

Въпроси / Въпросите, разгледани:

Пауза преди дата не работи.

Пауза преди дата не възобнови.

Състояние на работния поток не се променя от "в ход"

Състояние на работния поток остава "в ход"

Общ преглед

Този запис описва един казус, който описва действителната MRO (Поддръжка, Ремонт и операции) работния поток одобрение процес в MOSS.

Това не е откровено техническа дискусия, но вместо това служи да осигури действителен свят пример, който показва как платформата на Мос срещна реални трябва.

(Този запис е кръстосано публикувани между http://paulgalvin.spaces.live.com и http://blogs.conchango.com)

Фон

На клиента MRO процес са се характеризират със следното

• Ръчно одобрение процес.
• Някои поддръжка using Превъзхождам spreadsheets.
• Нередовни одобрение процес. Процесът на одобрение на същото MRO закупуване ще варират ден за ден, лице от лице.
• Много хартия и саморъчните подписи — закупуване на заявки изисква до 3 писмени подписи преди окончателното одобрение.

Целите на проекта бяха осъществени:

• Напълно автоматизира процеса на.
• Прилагат корпоративни стандарти за одобрение.
• Предоставя обобщен изглед на MRO закупуване на различни мениджъри.
• Подробна одитна пътека.

Като страничен ефект на разтвора, писмени подписи вече не са необходими.

Процес на одобрение

Процесът на одобрение се състои от четири "плува платна": Предприятията за оригинални, Пряк ръководител, Функционални мениджър и разделението мениджър.

Предприятията за оригинални:

Климушка определителен член нужда за покупка и започва процеса. Обърнете внимание, че наредителят може или не може действително да влезе заявка за покупка, но вместо това пряко друг служител да го направят. Някои пъти, Авторът не разполага с техническа експертиза за попълване на PO заявки. За пример, Потребителят може да искате да заявка нов преносим компютър, но не знае най-добър доставчик, IT стандарти, н. В този случай, Авторът работи с нея и тя действително се попълва заявка.

Пряк ръководител:

Това е пряк ръководител на автора (които могат да бъдат различни от лицето, което действително са били пуснати на PO заявки в Мос). Преките ръководители трябва да одобри на PO заявки, преди системата да потърси одобрение допълнително установяване на ред.

Функционални мениджър:

Диспечерът на функционални е лицето, отговорно за гарантиране, че предложената покупка отговаря предприятието стандарти в обхвата на определена корпоративна функция. За пример, ИТ покупки са одобрени от ИТ функционални мениджър.

Разделението мениджър:

Мениждърите одобри покупка искания строго с долар сума. Дивизия мениджър одобри покупка искания повече конфигурируеми долар сума.

Решението

Ние използвахме следните инструменти и компоненти за изпълнение на решението:

МОС: Служи като платформа, от която всичко останало "увисва". Мос предоставя здрава основа услуги за сигурност, главни данни, одит и други функции.

Услуги за формулярите на InfoPath: Мос компонент, Това дава възможност на потребителите да попълват покупка искания чрез уеб браузър.

SharePoint Designer (SPD): Ние използвахме SPD да приложат процеса на автоматизиран работен процес.

Уеб услуга: C# уеб услуга подобрява работата на потребителите като даде възможност на каскадни селекции списъци в InfoPath форма и осигурява по-добра производителност спрямо филтриране на данни. Вижте Тук за технически дълбоко гмуркане по този въпрос и причини за използването му.

Потребителски списъци: Мос потребителски профили предоставя пряк ръководител на даден потребител, но не предостави повечето от данните, които контролират работния поток решения (e.g. дали дивизионен мениджър се изисква да одобри на PO заявки). Използвахме потребителски списъци в "корпоративни данни" сайт за поддържане на данните като "Дивизионен мениджър одобрение сума за долар", "Функционална област мениджър" и така нататък. Списъци интегрирани много добре с InfoPath и също така предоставя създаване/актуализиране/изтриване (CRUD) функционалност за одит и сигурност на кутията.

Случай употреба

Този употреба случай илюстрира как решението се вписва заедно:

1. Paul иска нов лаптоп. Той описва нуждите му да Vivek, човек запознат с корпоративен лаптоп стандарти, Предпочитани доставчици, н.
2. Вивек трупи в Мос, достъп до формуляра PO заявки и навлиза заявки от името на Paul. Формата подканва Вивек за покупка категория, които след това използва уеб услуги да се пренесат капка-голо възвишение списък на фирмата одобрени доставчици. Вивек също задава корпоративни функционалните областта на тази покупка (e.g. "IT" или "Финанси").
3. ЕДП базирани поток започва, определя на Paul в пряк ръководител и изпраща заявка към неговия мениджър, Стейси.
4. Стейси одобрява заявка за покупка.
5. ЕДП поток инспектира заявки и определя това е ИТ покупка. Той разпраща работния поток до функционални диспечера на ИТ, Wonson.
6. Wonson одобрява заявки.
7. ЕДП поток отново инспектира заявки и определя че сумата на покупката, надвишава maxium долар и го насочва към разделението мениджър за одобрение.
8. Разделението мениджър одобри заявка за покупка.

Бележки

• Използването случай показва "чиста" тичам без откази или скокове.
• Всеки одобряващ има възможност да одобри или отхвърли заявки, както и да представят писмени коментари. Те са влезли в одит.
• Ако един отговорен мениджър отхвърли искане за покупка във всеки един момент, PO заявки е "мъртъв" и процесът трябва да се стартира от началото.
• Работният поток ще уведоми наредителя на всяка стъпка от процеса на.
• Няма писмени подписи — Клиентът определя (след някои силно въздействащи препоръки) че Одитът пътека както чрез хронологията на работния поток, служи на нуждите им одит.
• Усилие — Отне около три мъж седмици, за да приложи това решение.

Заключение

Този разтвор лостове Мос като развитие и Пусни време платформа. Клиентът е в състояние да се наберат основните Мос функции за автоматизиране на рутинни бизнес процес, който засяга почти всеки служител в компанията. С изключение на прости уеб услуга (която от своя страна лостове Мос), почти никакви действителни "програмиране" е необходима.

Решението също така служи като "витрина" за клиента, демонстрира как различните Мос функции могат да бъдат комбинирани за създаване на напълно функционален бизнес приложение и да генерират нови възможности за консултации в бъдеще.

Речник

МАРС РИКОНИСЪНС ОРБИТЪР: Поддръжка, ремонт и операции. Тези покупки обикновено включват елементи като бележник, столове, персонални компютри, принтери, клетъчни телефони и други подобни.

Това може да е очевидно за мнозина, но докато учи за моята Мос програмиране изпит, Аз научих, че това е доста лесно да получите действителната XML от заявката за търсене чрез потребителски интерфейс.

Един бърз метод е както следва:

• Достъп до Разширено търсене.
• Извършване на търсене, който връща някои данни.
• Редактиране на страницата (чрез настройките на сайта).
• Промяна на XSL на следните:

<?XML версия="1.0" кодиране="UTF-8"?>
<XSL:стилове версия="1.0" xmlns:XSL="HTTP://www.w3.org/ 1999/XSL/трансформация">
<XSL:изход метод="XML" версия="1.0" кодиране="UTF-8" тире="Да"/>
<XSL:шаблон мач="/">
<предварително>
<XSL:копие на Изберете="*"/>
</предварително>
</XSL:шаблон>
</XSL:стилове>

• Удар прилагам.
• Преглед на изходния код в браузъра.

Забележете, че <предварително> Етикет не помага много, освен служи като удобен маркер когато разглеждате резултатите.

Тозихитрост могат да бъдат много полезни при работа с контролирани свойства и персонализиране Търсене. Тя ще предостави окончателен списък на XML можете да използвате във вашата xslt, който би бил много полезен последните 25 пъти съм създал някои персонализирано търсене резултати.

Това би трябвало да работят за dataviews както и, Въпреки, че аз не са изследвани това все още.

Виждам, че Ерик Краус е изправена пред изискване обикновено се срещна с уеб компонент на заявка за съдържание. Проблемът? Той е бил в чиста среда WSS без достъп до CQWP. Вместо да кърлинг нагоре в позицията на плода (желание трябва да се бори всеки ден, изглежда), Той излезе с решение, че най-малко дава WSS Магазини борба шанс за успех. Той е описан Тук.

Стефан Goßner е събрал страхотен 4-част серия на SharePoint съдържание и разполагане на API Тук. Той предлага голям обзор и много добри примери в код (C#).

Първи път вдигна тази връзка от Йорис poelmans блог на http://jopx.blogspot.com/.

Дори и ако сте като мен, в които не сте имали да се направи много практическа работа за управление на съдържанието, Това е добре си струва 20 минути от времето си да прочетете.

Използване на API, може да се:

• Експортиране и импортиране на съдържание много лесно.
• Повторна родителска съдържание. Ако искате да експортирате някои съдържание от сайта "А" и да го изпратите на сайта "Б" но в една напълно нова място в йерархията на, Това е възможно.
• Експортиране на съдържание от сайта А и импортирате избрани бита в сайт А.
• Повторно свързване на съдържание (което означава, се справят с всички хипервръзки).

Някой на Internets питаше как да създадете изчисляема колона в списък, който показва една стойност, форматиран като"[Потребител] – [Статус] – [Местоположение]" както и в "Пол Галвин – Пиене [безплатно] Бира – Плаж".

Paul ще ида и да актуализирате си записа в списъка и изчисляемата колона ще актуализира по подходящ начин. На [Потребител] трябва да бъде по подразбиране потребителя въвеждане/актуализиране на списъка.

Изчисляема колона не може да използва "летливи" функции, като например [Мен] или [Днес]. Аз го решават в средата на тестване с тези стъпки:

1. Създаване на текст колона, наречена "Текущ потребител".
2. Задайте стойността й по подразбиране [Мен]
3. Създаване на изчисляема колона, наречена "Calc тест".
4. Задайте си стойност = [Текущ потребител]

Отидох, Добавяне на елемент към списъка и тя работи.

Аз съм поразен от това за 9 месеца и аз виждам, че хората по форумите на MSDN и Usenet са го too.l

Понякога, при достъп до документ на word (или други видове док) от документ библиотека причинява Internet Explorer да просто катастрофа и отивам далеч (като всички раздели с него, ако всички са отворени).

Този MS корекция може да го реши: http://support.microsoft.com/kb/938888

Също, има някои описание за проблема тук:

http://jopx.blogspot.com/2007/07/solving-internet-explorer-crash-when.html

Общ преглед:

Създава потребителски списък, който управлява тип съдържание с дузина колони.

Го добавите към страница а след това чрез SPD, превръща в изглед на данни.

Проблем:

Моят израз на Xpath се връщаше празен за една колона, наречена "Позиция". Аз го посочена thusly:

    <граница на таблица = "1">
      <XSL:за всеки избор = "/ dsQueryResponse/редове/ред" >
        <TR>
          <TD>
            Текущо състояние:
            <XSL:select="@Current_x0020_Status стойност на"></XSL:стойността на>
          </TD>
        </TR>
      </XSL>
    </таблица>

Колоната в КТ е наречена "Текущо състояние". Тя се показва в справката като "Текущо състояние". Навсякъде търсите, виждате "Текущо състояние".

Докато побой лудо около, Търсене на решение, Вместо това посочени "@Recruiter" и Ето! — Това всъщност се върна обратно на текущото състояние. Очаквах го да се върне обратно в работодател, когато направих това.

Разтвор:

Аз мушкам в ЕПД. Отидете на тази страница в ЕПД и показва изгледа на данните. Можете да проверите действителните данни за изгледа и свързаните с тях Xpath. Тук разбрах, че наистина, Xpath посочи "Работодател". Достатъчно странно, "действителна" работодател поле посочи от "Recruiter1".

Изнасям:

ЕПД предвижда авторитетен Xpath изрази за редове & колоните в изглед на данни.

Секунда, Тя показва действителните данни. Така например, е колона от типа показва това:

<NOBR><еталониране><HREF="/sites/Corporate/HumanResources/TalentAcquisition/_layouts/userdisp.aspx?ID = 17">Галвин, Пол</А><IMG границата ="0" височина = 1" ширина = "3" SRC="/_layouts/images/blank.gif"/><a href = "javascript:’ onclick ='IMNImageOnClick();връщане фалшиви;’ клас = "ms-imnlink"><име на IMG ='imnmark’ Заглавие =” границата =’0′ височина ='12’ ширина ='12’ SRC='/_layouts/images/blank.GIF’ ALT = "няма информация за присъствие’ глътка ='PGalvin@xxx.com’ ID = "imn_77 тип = smtp" /></а></еталониране></NOBR>