About
We are a growing international software company committed to drastically improving the SharePoint experience, utility and ROI for casual and power users, administrators, site designers, content managers, business intelligence and knowledge workers.
Discover outstanding SharePoint add-ons at SharePoint-WebParts.co and facebook.com/sharepoint.tools
Friends
-
Loading…thankgoditsme about 1 month ago -
Loading…fin 2 days ago -
Loading…updates about 1 month ago -
Loading…langalex about 1 month ago -
Loading…enki 10 days ago -
Loading…horax 2 months ago -
Loading…probek about 1 month ago -
Loading…c3o 2 days ago -
Loading…ylem235 about 5 hours ago -
Loading…lisp 2 months ago -
Loading…antifuchs about 4 hours ago -
Loading…kcu 10 days ago -
Loading…tec about 1 month ago -
Loading…grundprinzip 2 months ago -
Loading…sovielsand 2 days ago - +14
Click here to check if anything new just came in.
September 25 2011
September 17 2011
Manual installation / deployment of our SharePoint WSP Solution Packages
All our Web Parts and SharePoint solutions come with a deploy.exe Windows-based installation+deployment wizard to achieve streamlined installation and deployment. This wizard works smoothly and pleasantly for 99% of users.
Except when it doesn't. With a growing user base, a tiny minority of edge-case users or misconfigurations that prevent the wizard from completing are to be expected, and this article applies only to them.
Always try deploy.exe first. As a reminder, when you download one of our SharePoint tools, you get a roxority_<Product>Zen.zip file, ie. roxority_FilterZen.zip, roxority_PeopleZen.zip etc.
Copy it to your SharePoint server (or in a multi-server farm environment, to the primary web front-end server, ie. the one hosting your SharePoint Central Administration) and extract this ZIP setup package on there.
Now, don't just double-click deploy.exe to run it: instead, right-click it and depending on the Windows Server version, you'll see either a 'Run as administrator' or a 'Run as...' option.
- If it's the latter ('run as...'), pick that option and then specify a user account that (A) has administrative rights on the machine AND (B) is also a member of the SharePoint Farm Administrators group (review it in Central Administration if unsure). Both conditions should be met for best results. (Better yet, you're already logged in to your Windows Server as such as user account.)
- If the former ('run as administrator'), be sure you're logged in to the server as a user account that (A) has administrative rights on the machine AND (B) is also a member of the SharePoint Farm Administrators group (review it in Central Administration if unsure). Both conditions should be met for best results.
Things should be smooth sailing from here, but if you belong to the less-than-1% of users where the deploy.exe wizard does not complete successfully, read on.
Manual step 1 — install via STSADM:
If you are about to install one of our add-ons, we have to assume you're already at least remotely familiar with the STSADM tool that ships out-of-box with every SharePoint installation. No need to be a command-line ninja, you'll just need one command:
- STSADM -o addsolution -file c:\fantasypath\<WspFileName>.wsp
Replace c:\fantasypath with the full directory path of the extracted setup package, which will contain between 2 and 4 WSP files. For <WspFileName>.wsp, substitute the WSP file appropriate for your environment:
Product SPF 2010 SPS 2010 WSS 3.0 MOSS 2007 roxority_ExportZen_… …xiv.wsp …xiv.wsp …xii.wsp …xii.wsp roxority_FilterZen_… …xiv.wsp …xiv.wsp …xii_wss.wsp …xii.wsp roxority_PeopleZen_… …xiv_wss.wsp …xiv.wsp …xii_wss.wsp …xii.wsp roxority_PrintZen_… …xiv.wsp …xiv.wsp …xii.wsp …xii.wsp roxority_UploadZen_… …xiv_wss.wsp …xiv.wsp …xii.wsp …xii.wspManual step 2 — deploy via Central Administration:
In SharePoint 2007 (WSS 3.0 or MOSS 2007), go to Central Administration / Operations / Solution Management — in SharePoint 2010, go to Central Administration / System Settings / Farm Management > Manage Farm Solutions.
Next, select the WSP file you just installed in step 1 with STSADM. Click Deploy Solution and follow the on-screen instructions. Do this repeatedly UNTIL you have fully deployed the WSP to:
- all your content Web Applications applicable for this WSP
- the Central Administration Web Application (MANDATORY!)
- all Shared Service Provider (SSP) and Shared Resource Provider (SRP) Web Applications (MANDATORY!)
Manual step 3 — enabling, and then IISRESET:
Using farm-administrative credentials (best to follow the recommendations from the beginning of this article regarding deploy.exe), open any one page linked under the <Product>Zen Studio section on the Central Administration / Site Settings page. This should "enable" the software for full use in this SharePoint server farm, AND notify you about the success of this "enabling" operation too.
The software will not work unless and until this "enabling" procedure has been completed (just opening any <Product>Zen Studio page under Central Administration as per above should do this) and all web front-end servers in the SharePoint server farm have been IISRESET afterwards.
Manual step 4 — activate Site Collection Features:
In the root Web Site of your content Site Collection, go to the Site Settings page. In the Site Collection Administration section, click Site Collection Features (NOT Site Features!) and on the next page, activate the Site Collection Feature(s) you need.
Uninstalling our SharePoint WSP Solution Packages
Just like installation, your best choice for uninstallation is our deploy.exe wizard that is part of the downloaded roxority_<Product>Zen.zip setup package. But if you need to uninstall the solution package manually:
- first perform manual step 4 above, but instead of activating the Site Collection Features, deactivate them.
- then perform manual step 2 above, but instead of choosing Deploy Solution, repeatedly Retract Solution until it is no longer deploy to any Web Application.
- then perform manual step 2 above, but instead of choosing Deploy Solution, click Remove Solution.
- IISRESET all web front-end servers in the SharePoint server farm
April 06 2011
SharePoint "Unknown Error": How to Show All the Details
Every couple of months, we receive a support request that goes something like this: "when I attempt to do X, SharePoint says Unknown Error". Of course there is no way we can fix an "unknown error". Yet these errors are not unknown, by default SharePoint simply does not show their inner details — presumably the user experience designers at Microsoft presumed that a real error message is too scary for SharePoint end users, but an "unknown error" is somehow so much more reassuring... or maybe there really are too many 3rd-party developers who as a matter of habit always include sensitive passwords in their error messages.
Anyway, if you do encounter an Unknown Error (this has become spectacularly rare fortunately as our software has grown ever more stable over the last 2 years), then we need you to turn on Detailed Error Messages in your SharePoint environment. This is easy to do and absolutely non-dangerous, plus typically you will be reporting your issue from your QA, test or dev server rather than production. Here is what we need you to do.
March 19 2011
February 20 2011
PeopleZen Data Field Templates: one new feature, many new possibilities
Lately we received a number of feature requests that could all be addressed by a single feature we've been meaning to add for quite some time, so we finally implemented it for the 1.9 release of PeopleZen: Customizable Data Field Templates.
Simply put, this gives you an easy tool that lets you fully redefine how PeopleZen displays or transforms certain user information, which is typically returned in rather raw form by your Data Source and may not be ready for human consumption as is.
PeopleZen has since its inception for many a common User Profile Property adopted "the most meaningful or usable way to display it", based on hard-coded heuristics driven initially by educated guesses and then increasingly by user feedback:
- multi-valued properties are displayed comma-separated (but this is configurable)
- email addresses are typically displayed as hyperlinks
- date/time values are slightly re-formatted
- all other information is displayed as plain text
But even if PeopleZen gets 90% of your needs right, out of the box, sometimes your users require more sophistication unique enough to your organization that we cannot simply hard-code it into the tool for everyone. Instead, with the new Custom Data Field Templates feature you can easily define your custom property display logic yourself — without having to struggle with messy XSLT.
Because this feature is so flexible, we will walk you through three real-world scenario of our users (anonymized) and how this new feature lets them implement their requirements:
Scenario 1: a better Manager field
Real-world user request:
I'm showing Manager as a column in my newest iteration. I'd like to display that as a clickable link to the manager's profile page (just like the main link in the far left column). Can I do that and at the same time show the person name rather than account name?
So by default the Manager user profile property stores just the account name / domain login name (ie. in the yourdomain\user123 pattern). Instead, this PeopleZen user wants to:
- show the real name (in a Farm User Profiles Data Source, this would be the PreferredName user profile property)
- and link it to the manager's profile page
Here are the steps to achieve this:
- go to Site Settings / PeopleZen Studio / Data Field Templates and add a new Data Field Template. If you do not have any yet, simply use the form readily shown to add one:
- Name: ShowManager
- Content mode: HTML source code
- Template content: <a href="{UserProfiles_PropertyValue;#AccountName;#[Manager];#rox___pu}">{UserProfiles_PropertyValue;#AccountName;#[Manager];#PreferredName}</a>
- after saving this, replace your previous, unsatisfactory Manager field (in the User Profile Properties section of your PeopleZen Web Part's settings tool pane, and/or in the Default Data Fields setting on the Data Fields tab of your Data Source under Site Settings / PeopleZen Studio / Data Sources) with the following line:
- {ShowManager}:Manager
The part after the colon is simply the display name of your field as shown to end users. The part before the colon, where you would typically specify a Data Source field, now instead references your own Data Field Template which you called ShowManager.
Inside this template, we used a similar (but a tad more complex) {placeholder syntax} to:
- obtain both the PreferredName of the manager for the display text inside the <a> hyperlink
- obtain for the <a href> attribute the profile page URL for which the special built-in field name rox___pu is used (which points back to the Link URL data field/s setting on the Data Source's Data Fields tab)
Inside your template you could use the same {placeholder syntax} to "call" any of your other Data Field Templates, if you have more than one. In fact this is precisely what is happening here -- a call to "another template" -- only you have never defined a template named UserProfiles_PropertyValue before, instead it is already built into PeopleZen and is simply a "predefined template" performing some very specific logic. In the above examples, when invoking the UserProfiles_PropertyValue template, it requires and is given three values:
- the User Profile Property to match with the next (2nd) given value. That property is AccountName for Farm User Profiles Data Sources.
- the value to obtain the User Profile to use for the next (3rd) given value. We pass [Manager] so now the template knows: pick the user profile whose AccountName is the Manager field of the current user profile.
- the property value to obtain from the fetched user profile. In this case, we want to show the PreferredName inside the link and for its URL, the rox___pu user profile page link.
All values given to a template are separated from each other and from the template name with SharePoint's ubiquitous ;# separator. So this is how you end up with an initially scary-looking, but ultimately very simple definition such as {UserProfiles_PropertyValue;#AccountName;#[Manager];#PreferredName}...
Scenario 2: display a field value but linked to a custom-composed dynamic URL
The next scenario is pretty similar in kind:
We need a special formatting for a certain Data Field in the rendered PeopleZen Web Part: <a href="http://roxority.com/ats/pages.aspx?param2=CurrentlyLoggedOnUser">datafieldValue</a> — is it possible to render a Data Field as a hyperlink exactly like in that example? All values in the column should have that rendering format. The currently logged-on user is also needed!
The steps are almost identical to scenario #1 above but let's walk through them again:
- go to Site Settings / PeopleZen Studio / Data Field Templates and add a new Data Field Template. If you do not have any yet, simply use the form readily shown to add one:
- Name: CustomLink
- Content mode: HTML source code
- Template content: <a href="http://roxority.com/ats/pages.aspx?param2={UserProfiles_CurrentUser}">[Department]</a>
- after saving this, add your custom linked field to your user profile lists (via the User Profile Properties section of your PeopleZen Web Part's settings tool pane, and/or in the Default Data Fields setting on the Data Fields tab of your Data Source under Site Settings / PeopleZen Studio / Data Sources) with the following line:
- {CustomLink}:Field Title
- {CustomLink}:Field Title
The part after the colon is simply the display name of your field as shown to end users. The part before the colon, where you would typically specify a Data Source field, now instead references your own Data Field Template which you called CustomLink.
Inside this template, we used a similar {placeholder syntax} to obtain the acount name of the current calling SharePoint user via the special, built-in "template" {UserProfiles_CurrentUser}. Note that the use of [Department] is just an example, this user probably wanted to show another User Profile Property but didn't tell us which. So replace [Department] with another know User Profile Property as required.
Scenario 3: Date/Time conversions
Real-world user request:
Our date of birth and hire date are entered into AD as Long Integers (ie. 122918688000000000 for 7/6/1990). Is there a way in PeopleZen to convert these to "human readable" dates?
Here you do not even really need to define your own custom Data Field Template. Simply replace your
- SPS-Birthday:Birthday (or SPS-HireDate:Hire Date etc.)
or similar line (via the User Profile Properties section of your PeopleZen Web Part's settings tool pane, and/or in the Default Data Fields setting on the Data Fields tab of your Data Source under Site Settings / PeopleZen Studio / Data Sources) with any one of the following:
- {DateTime_FromBinary;#[SPS-Birthday]}:Birthday
- {DateTime_FromFileTime;#[SPS-Birthday]}:Birthday
- {DateTime_FromFileTimeUtc;#[SPS-Birthday]}:Birthday
- {DateTime_FromTicks;#[SPS-Birthday]}:Birthday
These are simply different conversion functions for long integer representations of date/time values. Try them all if you're not sure which long format your Data Source's date/time values are in fact using.
December 25 2010
SharePoint 2010 List View AJAX Options and Filter Web Parts
A FilterZen user reported the following issue:
I have tried to set up the Filter Web Part with an Issue List on SharePoint Server 2010 and everything seemed to work flawlessly except the List 'unfilters' every time it is auto-refreshed.
I have tried putting the filters in a Web Part on the List and applying it to a List in a Web Part where AJAX Options Asyncronous Refresh is enabled with the same result: the List unfilters every time it is auto-refreshed.
The strange thing is that it seems to work OK when AJAX Options Manual Refresh is applied to a List in a webpart?!
We could reproduce the issue, but now the much bigger question was how to fix this. First off, to summarize the issue:
- In SharePoint 2010, List Views give you a tool-pane section with so-called AJAX Options:
- the Show Manual Refresh Button option lets end users refresh the List data shown in the List View Web Part without reloading the entire page.
- This AJAX refresh mode works just fine even with filters applied from connected Filter Web Parts such as FilterZen or the out-of-box Filter Web Parts.
- the Enable Asynchronous Automatic Refresh option seemingly performs the above background data refresh periodically and automatically, without the end user having to click a button.
- This AJAX refresh mode simply does not respect filters applied from connected Filter Web Parts, neither FilterZen nor the out-of-box Filter Web Parts!
- the Show Manual Refresh Button option lets end users refresh the List data shown in the List View Web Part without reloading the entire page.
- Since the out-of-box Web Parts exhibit the same problem as FilterZen, this did not seem to be a bug in our product, but nevertheless wouldn't it be neat if this could be made to work, at least for FilterZen users?
We looked "long and hard" in SharePoint's unintelligible heap of client JavaScripts to figure out why the first AJAX background data refresh mode seemed to work but the second wouldn't, with respect to filters applied from connected Web Parts.
There may be an easy fix waiting to be discovered, but we couldn't figure it out. Rather than give up completely on the issue, we added the same "hack" to FilterZen that we figured we would also apply as SharePoint devs / consultants, would we face the issue in a real-world project:
- the AJAX refresh called from the button works while the periodical background refresh doesn't (with respect to connection-provided filters)
- hence:
- deactivate the Enable Asynchronous Automatic Refresh option,
- activate the Show Manual Refresh Button option and
- add JavaScript to the page that periodically invokes the Manual Refresh button to "emulate" the automatic refresh, but in the way that has been shown to work (via the refresh button).
- optionally also include script to hide the Manual Refresh button if this should not be made available to end users.
The above logic is now included directly in FilterZen so you won't need to script the above yourself, starting from build 3.8.0.34 and we tested this, it works! This affects all List Views on the page that have both Enable Asynchronous Automatic Refresh disabled and Show Manual Refresh Button enabled:
October 09 2010
September 25 2010
Print-Friendly SharePoint Calendar / List Views & User Profiles Web Parts
We recently launched PrintZen, which lets you offer printer-friendly Views of SharePoint List, Calendar and other Web Parts. This article shows you how to integrate PrintZen with PeopleZen to offer print views for your User Profile Web Parts. Once you have both solution packages installed in your SharePoint environment — it's really easy.
August 26 2010
August 24 2010
August 23 2010
August 19 2010
Lost Web Part Connections on SharePoint 2010 List View Pages (Windows 7)
This is just a short notice on what has to be one of the most curious little bugs we have come across in SharePoint 2010 so far:
whether we use our own premier SharePoint Filter Web Part or the out-of-box ones, or attempt to create any other kind of Web Part connection:
- on a List View Page (AllItems.aspx etc.)
- in the browser, via the Connections option in any Web Part's edit menu
- in the context of SharePoint Server development deployments installed on physical 64-bit Windows 7 Ultimate machines (the client OS doesn't matter in this discussion, Win 7 in this case is the server OS)
then the connection gets LOST — routinely, repeatedly, reproducably — as soon as the page gets freshly reloaded. Now, as long as you stay in the page state and perform other changes via post-backs, but keep the page view state alive (this is ASP.NET lingo but it'll have to do for now), the connection seems to stay alive, but re-initialize the page fully (not via an F5-postback but by fully re-navigating to it) and the connection is simply gone. All other modifications to your Web Parts and the page seems to have been persisted to the Content Database just fine, except for the connection itself!
Now of course the official recommendation is to use a Windows 2008 Server OS rather than Windows 7 for SharePoint Server deployments, and furthermore from the general design of SharePoint 2010 the customizing of List View pages with further Web Parts or even connections seems to be implicitly discouraged in the overall design — for example, you lose the List View selector drop-down menu in the Browse ribbon tab as soon as you add another Web Part to your List View page, and some indeed argue that such view aggregations and advanced behaviors should be realized in separate pages rather than the mere core View pages — but...
...as usual, theres a work-around to keep going:
quite simply, set up your Web Part connection in SharePoint Designer and it will be persisted for good. Of course now you have a customized, a.k.a. un-ghosted copy of the List View page in your content database (for no particular reason other than SPD always un-ghosting a page when you hit Save, even though the same customizations when done in the browser would not have resulting in such an un-ghosting since Web Parts and connections are neatly stored outside your page mark-up in the DB and are just merged with the page HTML by SPD when it opens it), but neither on your Windows 7 development server nor on most productive systems is this typically really an issue.
August 16 2010
August 15 2010
August 13 2010
August 11 2010
Maybe Soup is currently being updated? I'll try again automatically in a few seconds...


