Arkivat mujore: Nëntor 2007

MOSS tregon mua My Name kolonë është Rezervuara ose në përdorim … Por kjo nuk është

Lini një përgjigje

UPDATE 12/04/07: Shoh this Microsoft KB (http://support.microsoft.com/kb/923589) për informacione të lidhura.

Në të vërtetë, ajo rezulton se është, por tricksy MOSS had to make it difficult.

My customer does some development work on his MOSS site over the weekend. It’s a bit of a jumble as to what he actually did, por rezultati përfundimtar është ky:

  • He tries to add a site column called "Quantity" and MOSS replies: "The column name that you entered is already in use or reserved. Choose another name."
  • He attempts to add it to another environment and that works. Prandaj, "Quantity" is not a reserved name.
  • He tries to find an existing site column named "Quantity" in that site collection. He cannot find it.

I did some research, and even some coding, waxed philosophical and finally found that a column named Quantity did, në të vërtetë, exist. It was in the "_Hidden" group. Hence, we could not find it via the SharePoint user interface.

How did it get there? I do not know, but I have a theory (or as my wife would call it, "blah blah blah"). Somewhere along the line, një fabulous forty template was added and probably activated at a site in the site collection. It was then deactivated (or the site removed). The site column, megjithatë, remained but in the "_Hidden" group. If someone knows better, please let me know via Email or post in the comments.

SharePoint was telling the truth. It’s hardly worth pointing out that that message is not as helpful as it could be. It would be nice to see that message fork into two different messages in the future: 1) Say that the column name is reserved or it is not. 2) If it’s not reserved, show the site, or at least the group, where the column name is already used.

</fund>

Dhënat aktuale nëpërmjet Lista Custom OM (ose, Yet Another Dhënave OM Displayor [si YACC, por të ndryshme])

Lini një përgjigje

Sot, I spent a handful of hours tracking down the root cause behind the message "The column name that you entered is already in use or reserved. Choose another name."

Kolona në fjalë mund të jetë krijuar, fshihet dhe ri-krijuar në një mjedis tjetër, so I knew it wasn’t a reserved name. Megjithatë, I simply couldn’t find the column anywhere via the standard SharePoint user interface at any site in the site collection.

I posted to MSDN forums here and the indomitable Andrew Woodward pointed me in the direction of the underlying object model data.

I went off to codeplex to find some tools that would help me peer into the underlying OM data and help me locate the trouble.

I tried several tools and they were very cool and interesting but in the end, the UI wasn’t good enough for my purpose. I’m not criticizing them by any means, but clearly the tool-makers didn’t have my problem in mind when they created their UI :). Most people seem to be investing a fair amount of time and effort in creating workstation / client applications that provide tree views, right-click context menus and so forth. These are nice and all, but it’s a lot of work to create a top-of-the-line user experience that is also very flexible.

I really needed an answer to this problem. It occurred to me that if I could get all of the site columns in the site collection into a custom list, I could filter, sort and create views that would help me find this supposedly existing column (which it did, Btw). I went ahead and did that and an hour or two later, had all my site columns loaded into a custom list with grouping, sorting and so forth. I found my answer five minutes later.

If and when I successfully take over the world, I think I will decree that all SharePoint tools providers must seriously consider surfacing their object model data in a custom list. That way, I have the power to search any way I want (constrained, sigurisht, by standard sharepoint features).

SharePoint Designer Workflow Veprimit Custom — Vëzhgimi Rreth <Tie fushë Designer Type =”StringBuilder” … />

1 Përgjigje

Vetëm një vëzhgimi të shpejtë se ka një dallim shumë i rëndësishëm në mes të këtyre dy përkufizimeve:

<FieldBind Field="InParam1" DesignerType="StringBuilder" Id="2" Text="Input parameter #1"/>

përballë:

<FieldBind Field="InParam1" Id="2" Text="Input parameter #1"/>

Tregon parë si kjo në SPD:

imazh

ndërsa kjo e fundit tregon si kjo:

imazh

I’m not sure how helpful these screen shots are but I put in the effort to make them so you have to view them 🙂

Vëzhgimi është kjo: StringBuilder ju lejon për të ndërtuar një varg (qartë) nga përzierja së bashku literals varg dhe të dhënat workflow (via the "Add Lookup" button në këndin e poshtëm të majtë). When you use the Add Lookup button, it inserts a token in the form "[%% token]". When SharePoint invokes your custom action, (C # Kodi në rastin tim), SharePoint kalon shenjë vetë, not the value of the token. If you use the default designer type (Lloji i dytë), SharePoint zgjeron shenjë dhe kalon vlerën aktuale të shenjë për veprimin tuaj.

StringBuilder = KEQ, projektuesi default lloji = mirë.

Sigurisht, that’s not what I really mean. Just don’t try and pass a parameter to your custom action when the designer type = StringBuilder. Use the default designer type and chain a StringBuilder to it up front if you need to build complex strings in your workflow (e cila rastësisht është pikërisht ajo që ai bën për të krijuar një subjekt dinamik për veprim email, por kjo është një temë për një tjetër hyrje blog, ka).

<Fundi />

Aktivizimin e parakohshme Workflow — Një jo-mjekësore Zgjidhja

8 Përgjigje

UPDATE: Shiko këtë diskutim MSDN, sidomos hyrja e fundit: http://forums.microsoft.com/MSDN/showpost.aspx?postid=2631057&siteid=1. It describes a condition that may short circuit this whole thing. In short, kjo mund të jetë aq e thjeshtë sa duke bërë të paktën një nga fushat detyrueshme.

Unë kam një bibliotekë dokument që mbështet tetë llojet e përmbajtjes.

I have a SharePoint Designer workflow that wants to calculate and assign a "reminder date" thjesht duke zbritur 30 ditë nga një kolonë, "due date". This should only happen for one of the content types, "Insurance". The business objective is to produce a KPI that shows two categories of insurance documents: "about to expire" and "expired." (Ju mund të lexoni më shumë në lidhje me këtë lloj të IPK-së dhe më substancial stërvitje-down këtu).

I have configured the workflow to fire when a new item is created and when an item is modified. The idea is that when an insurance document is uploaded, we calculate a "warning date" based on the expiration date. A pair of views work in connection with a KPI List to highlight these conditions when users hit their home page.

Kjo strategji nuk funksionon kur unë të ngarkoj një dokument.

I upload the document and I am presented with the meta data entry screen. Në këtë pikë, I’m already in trouble. SharePoint has already, para kohe nga perspektiva ime, fired the workflow. I haven’t had a chance to pick the correct content type nor assign a due date. Në të njëjtën kohë, the workflow does not fire when I hit the submit button at this time. There’s some built-in logic that "believes" that first submit is part of the "create" event. Kështu … workflow ime ka gjuajtur dhe kur ekzekutohet, it was passed default meta data values.

The best work-around I know of is to insert a "pause until" activity in the workflow. I have the workflow pause for 1 minute. While it’s pausing, Unë zgjidhni llojin e saktë përmbajtje, enter the meta data and submit. The pause completes and the workflow proceeds as needed. (Vini re se në mjedisin tim, timer workflow activities from SPD do not work out of the box. You may have the same trouble. Shoh këtu për më shumë detaje).

I don’t like "magic delay" work-around. What happens if the user uploads a document and the phone rings and the ensuing conversation outlasts the pause? I can make the pause longer, por unë ende nuk e pëlqen atë.

Kam shkruar në lidhje me këtë në forume MSDN këtu: http://forums.microsoft.com/MSDN/ShowPost.aspx?PostID=2430725&SiteID=1

SharePoint të Sigurimit Bazat e parë / Shmangni kurthet e përbashkët

8 Përgjigje

UPDATE 12/18/07: Shih artikullin Paul Liebrand për disa pasoja teknike të hequr apo modifikuar emrat e grupit parazgjedhura (shih komentin e tij poshtë si).

Përmbledhje:

SharePoint security is easy to configure and manage. Megjithatë, it has proven to be difficult for some first-time administrators to really wrap their hands around it. Not only that, I have seen some administrators come to a perfect understanding on Monday only to have lost it by Friday because they didn’t have to do any configuration in the intervening time. (Unë e pranoj për të pasur këtë problem veten). This blog entry hopefully provides a useful SharePoint security primer and points towards some security configuration best practices.

Shënim i rëndësishëm:

This description is based on out of the box SharePoint security. My personal experience is oriented around MOSS so there may be some MOSS specific stuff here, but I believe it’s accurate for WSS. I hope that anyone seeing any errors or omissions will point that out in comments or email mua. I’ll make corrections post haste.

Bazat:

Për qëllimet e këtij shqyrtimi, ekzistojnë katër aspekte themelore të sigurisë: përdoruesit / grupe, objekte securable, Nivelet leje dhe trashëgimia.

Përdoruesit dhe Grupet prishen për:

  • Përdoruesit individualë: Nxorrën nga directory aktive apo krijuar drejtpërdrejtë në SharePoint.
  • Grupet: Mapped directly from active directory or created in SharePoint. Groups are a collection of users. Groups are global in a site collection. They are never "tied" në një objekt specifik securable.

Objekte Securable prishen në të paktën:

  • Sites
  • Document bibliotekat
  • Zërat individualë në listat dhe bibliotekat dokument
  • Dosjet
  • Settings ndryshme QZHB.

Ka objekte të tjera securable, por ju merrni foto.

Nivelet leje: Një pako e grimcuar / low level access rights that include such things as create/read/delete entries in lists.

Trashëgim: By default entities inherit security settings from their containing object. Sub-sites inherit permission from their parent. Document libraries inherit from their site. So on and so forth.

Përdoruesit dhe grupet lidhen me objekte securable nëpërmjet niveleve leje dhe trashëgimia.

Rregullat më të rëndësishme për të kuptuar Siguri, Ever 🙂 :

  1. Grupet janë thjesht koleksionet e përdoruesve.
  2. Grupet janë globale brenda një site collection (i.e. nuk ka asnjë gjë të tillë si një grup i caktuar në një nivel të faqes).
  3. Emri i grupit nuk qëndrojnë, grupe nuk, në vetvete, have any particular level of security.
  4. Groups have security in the context of a specific securable object.
  5. Ju mund të caktojë nivele të ndryshme leje për grupin e njëjtë për çdo objekt securable.
  6. Aplikimi Web politikat atu e gjithë kjo (shih më poshtë).

Administratorët Siguri humbura në një det të grupit dhe lista e përdoruesve gjithmonë mund të mbështeten në këto aksiomat për të menaxhuar dhe për të kuptuar konfigurimin e tyre të sigurisë.

Grackë e përbashkëta:

  • Emrat e grupeve rrejshëm nënkupton leje: Nga kutia, SharePoint defines a set of groups whose names imply an inherent level of security. Consider the group "Contributor". One unfamiliar with SharePoint security may well look at that name and assume that any member of that group can "contribute" to any site/list/library in the portal. That may be true but not because the group’s name happens to be "contributor". This is only true out of the box because the group has been provided a permission level that enables them to add/edit/delete content at the root site. Through inheritance, the "contributors" group may also add/edit/delete content at every sub-site. One can "break" the inheritance chain and change the permission level of a sub-site such that members of the so-called "Contributor" grup nuk mund të kontribuojë në të gjitha, por vetëm lexuar (për shembull). This would not be a good idea, qartë, pasi ajo do të jetë shumë konfuze.
  • Grupet nuk janë të definuara në një nivel të faqes. It’s easy to be confused by the user interface. Microsoft provides a convenient link to user/group management via every site’s "People and Groups" lidhje. It’s easy to believe that when I’m at site "xyzzy" and I create a group through xyzzy’s People and Groups link that I’ve just created a group that only exists at xyzzy. That is not the case. I’ve actually created a group for the whole site collection.
  • Grupet anëtarësimi nuk do të ndryshojnë nga faqja (i.e. ajo është e njëjtë kudo Grupi është përdorur): Consider the group "Owner" dhe dy vende, "HR" and "Logistics". It would be normal to think that two separate individuals would own those sites — an HR owner and a Logistics owner. The user interface makes it easy for a security administrator to mishandle this scenario. If I didn’t know better, Unë mund të hyni në njerëzit dhe grupet lidhjet nëpërmjet faqes së Burimeve Njerëzore, select the "Owners" group and add my HR owner to that group. A month later, Logistics comes on line. I access People and Groups from the Logistics site, add pull up the "Owners" group. I see the HR owner there and remove her, thinking that I’m removing her from Owners at the Logistics site. Në të vërtetë, I’m removing her from the global Owners group. Hilarity ensues.
  • Dështimin për të përmendur grupe të bazuara mbi rolin specifik: The "Approvers" group is a perfect example. What can members of this group approve? Where can they approve it? Do I really want people Logistics department to be able to approve HR documents? Of course not. Always name groups based on their role within the organization. This will reduce the risk that the group is assigned an inappropriate permission level for a particular securable object. Name groups based on their intended role. In the previous HR/Logistics scenario, Unë duhet të ketë krijuar dy grupe të reja: "HR Owners" and "Logistics Owners" dhe të caktojë nivele të ndjeshme leje për secilin dhe shuma minimale e nevojshme për ata përdorues që të bëjnë punën e tyre.

Referencat e tjera të dobishme:

Nëse ju keni bërë deri tani:

Please let me know your thoughts via the comments or email me. If you know other good references, ju lutemi të bëjë të njëjtën!

Technorati Tags:

Quick dhe Easy: Krijo një Dhënave Web Part Shiko (DVWP)

2 Përgjigje

Nuk është një pasuri e madhe e informacionit mbi WSS 3.0 Të dhënat Pjesa Shiko Web-faqen (DVWP) on the web from several sources. Megjithatë, I found it to be surprisingly difficult to find information on this first very basic step. Here is another article in the "quick and easy" seri për të trajtuar atë.

Ndiqni këto hapa për të krijuar një pjesë të të dhënave web view (DVWP). They are based on an "Announcements" Pjesa web, por zbatohen për shumicën e listave të.

  1. Krijoni një pjesë web Shpallje dhe shtoni atë në një vend.
  2. Hapni faqen në SharePoint Designer.
  3. Hapni Default.aspx e faqes.
  4. Select the Announcements web part and right-click.
  5. Nga context menu, select "Convert to XSLT Data View".

SharePoint Designer ju njofton se kjo faqe është përshtatur tashmë nga përkufizimi i saj faqes. Kjo nuk është domosdoshmërisht e keqe, por ka implikime të rëndësishme (Performanca, përmirësuar, të tjerët) which are beyond the scope of this little "Quick and Easy" hyrje. To get more information on this subject, Unë rekomandoj dy libra këtu si dhe kërkimit tuaj të preferuar në internet.

Konfirmoj që ju e bëri atë të saktë:

  1. Mbylle dhe ri-hapur shfletuesin e Internetit (to avoid accidentally re-posting the original "add a new web part").
  2. Select the web part’s arrow drop-down and choose "Modify Shared Web Part" nga menyja.
  3. Paneli mjet hap të drejtë.
  4. Paneli ka ndryshuar nga mundësitë e saj të zakonshme të vendosur për këtë:
imazh

“Nuk mund të merrni skemen listë pronën kolonë nga lista SharePoint” — Përshkrimi i / punë-arounds

4 Përgjigje

Këtë javë, ne fund riprodhohet një problem që kishte qenë raportuar nga një përdorues të largët: Kur ajo u përpoq për të eksportuar përmbajtjen e një liste të shkëlqejnë, gjërat duket se do të fillojnë të punojnë, por pastaj Excel do pop up një gabim: "Cannot get the list schema column property from the SharePoint list". She was running office 2003, windows XP and connecting to MOSS.

I searched the Internets and saw some speculation but nothing 100% definitive. Hence, këtë post.

The problem: Exporting a view to excel that contains a date (date = the data type of the column).

What worked for us: Convert the date to a "single line of text". Pastaj, convert it back to a date.

That solved it. It was nice to see that the conversion worked, në të vërtetë. It was quite nervous that converting things this way would fail, but it did not.

This bug has thrown a huge shadow over the date data type in the client’s mind, so we’re going to be seeking out a definitive answer from Microsoft and hopefully I’ll post and update here in the next short period of time with their official answer and hotfix information.

Other references:

http://www.kevincornwell.com/blog/index.php/cannot-get-the-list-schema-column-property-from-the-sharepoint-list/

http://forums.microsoft.com/MSDN/ShowPost.aspx?PostID=2383611&SiteID=1

<fund>

Abonohen në blogun tim.

Technorati Tags: ,

Shpejtë dhe i thjeshtë: Dërgo një email me hyperlink ngulitur nga workflow SharePoint Designer

Lini një përgjigje

Një herë ose dy herë në muaj, Postimet e dikush një pyetje forum: "How do I include hyperlinks to URL’s that are clickable from a SharePoint Designer email?"

Paraqitur pa koment të mëtejshëm: (mirë, në fakt atje është komentuar më tej pas imazhit):

imazh

Becky Isserman vijon me një shpjegim të dobishme se si të embed një lidhje me një artikull në e-mail: http://www.sharepointblogs.com/mosslover/archive/2007/11/20/addition-to-paul-galvin-s-post-about-sending-an-e-mail-with-hyperlinks-in-spd.aspx

Lirimi i ri: SharePoint Designer Workflow Extensions (Funksionet e manipulimit string)

5 Përgjigje

UPDATE: Shiko këtu për mendimet e mia në komercializimin e këtij projekti: http://paulgalvin.spaces.live.com/blog/cns!1CC1EDB3DAA9B8AA!569.entry

Unë kam qenë i zënë duke punuar në CodePlex projektin tim i cili është fokusuar aktualisht në sigurimin e zgjerimeve manipulimesh string për të krijuar menu me anë të SharePoint Designer.

Shiko këtu për detaje:

Shtëpi projekt: http://www.codeplex.com/spdwfextensions

Publikimit: https://www.codeplex.com/Release/ProjectReleases.aspx?ProjectName=spdwfextensions&ReleaseId=8280

Version 1.0 përfshin këto karakteristika të reja:

Funksion Përshkrim (në qoftë se nuk e njëjtë si. funksion Net)
Num-entries() Kthehet "numri hyra" in a string as per a specified delimiter.

Për shembull: Num-entries in a string "a,b,c" with delimiter "," = 3.

Entry() Returns the nth token in a string as per a specified delimiter.
Length String.Length
Replace() String.Replace()
Përmban() String.Contains()
Returns the word "true" or the word "false".
Substring(start) String.Substring(start)
Substring(start,length) String.Substring(start,length)
ToUpper() String.ToUpper()
ToLower() String.ToLower()
StartsWith() String.StartsWith()
Returns the word "true" or the word "false".
EndsWith() String.EndsWith()
Returns the word "true" or the word "false".

Një gabim QZHB Runtime shpjegoi

2 Përgjigje

Unë shkaktuar një gabim QZHB këtë javë se manifestuar veten në ndërfaqen e përdoruesit dhe në 12 hive log at runtime.

I parë, kjo u shfaq në ndërfaqen e përdoruesit:

Nuk mund të gjejnë fusha për të futur të gjitha vlerat identifikues për të ekzekutuar saktë një MethodInstance SpecificFinder me Emri … Ensure input Parameters have TypeDescriptors associated with every Identifier defined for this Entity.

Ja një e shtënë ekran:

clip_image001

I could also cause this message to appear in the 12 hive log at will (using my patented high-tech-don’t-try-this-at-home "mysterious errors" metodë):

11/14/2007 09:24:41.27 w3wp.exe (0x080C) 0x0B8C SharePoint Portal Server Business Data 6q4x High Exception in BusinessDataWebPart.OnPreRender: System.InvalidOperationException: The Identifier value ”, of Type ”, is invalid. Expected Identifier value of Type ‘System.String’. at Microsoft.Office.Server.ApplicationRegistry.MetadataModel.Entity.FindSpecific(Object[] subIdentifierValues, LobSystemInstance lobSystemInstance) at Microsoft.SharePoint.Portal.WebControls.BdcClientUtil.FindEntity(Entity entity, Object[] userValues, LobSystemInstance lobSystemInstance) at Microsoft.SharePoint.Portal.WebControls.BusinessDataItemBuilder.GetEntityInstance(View desiredView) at Microsoft.SharePoint.Portal.WebControls.BusinessDataDetailsWebPart.GetEntityInstance() at Microsoft.SharePoint.Portal.WebControls.BusinessDataDetailsWebPart.SetDataSourceProperties()

I searched around and found some leads in the MSDN forum, but they weren’t enough for me to understand what I was doing wrong. I watched a webcast by Ted Pattison that my company has squirreled away on a server and came to realize my problem.

In my ADF, I’m connecting to a SQL database as shown:

            <Pronë Emër="RdbCommandText" Lloj="System.String">
              <![CDATA[
                SELECT
                      SETID, CARRIER_ID, EFFDT, DESCR, EFF_STATUS, TAXPAYER_ID, NETWORK_ID, FRT_FORWARD_FLG, ALT_NAME1, ALT_NAME2, LANGUAGE_CD,
                      COUNTRY, ADDRESS1, ADDRESS2, ADDRESS3, ADDRESS4, CITY, NUM1, NUM2, HOUSE_TYPE, ADDR_FIELD1, ADDR_FIELD2, ADDR_FIELD3,
                      COUNTY, STATE, POSTAL, GEO_CODE, IN_CITY_LIMIT, COUNTRY_CODE, PHONE, EXTENSION, FAX, LAST_EXP_CHK_DTTM, FREIGHT_VENDOR,
                      INTERLINK_DLL, TMS_EXCLUDE_FLG
                FROM
                      dbo.PS_CARRIER_ID_VW WITH (nolock)
                WHERE
                  (SETID <> 'SHARE') dhe
                  (lower(CARRIER_ID) >= lower(@MinId)) dhe
                  (lower(CARRIER_ID) <= lower(@ MaxId)) dhe
                  (lower(DESCR) LIKE lower(@InputDescr))
                ]]>
            </Pronë>

I was provided that SQL from a DBA person and I’m given to understand that it’s a i veçantë view they created just for me. The unique key there is CARRIER_ID.

Here is the bug I introduced:

      <Identifiers>
        <Identifier Emër="CARRIER_ID" TypeName="System.String" />
        <Identifier Emër="DESCR" TypeName="System.String" /> 
      </Identifiers>

Somewhere along the line, Kisha arritur të ngatërruar veten mbi kuptimin e <Identifiers> and added DESCR even though it’s not actually an identifier. I took DESCR out of the identifiers set and presto! Ajo ka punuar të gjithë.

I hope this saves someone some grief 🙂

Technorati Tags: , , ,