|
|
|
|
Sharing is Caring > Categories
|
20/12/2008
Day 46... hang in there, only a few craptastic posts left until Christmas!
The Problem
It's not so much a problem, but a common scenario that is just crying out for some out-of-the-box support. Often in our taxonomies and data models we have the need for a drop-down or choice list where the lookup values should, are, and will always be consistent across the organisation. For example, selection of a region, or specific office for a global organisation.
Now, this sort of field cries "Site Column", but in a server farm with more than a single site collection, this won't necessarily be satisfactory. Unless you use one of the "workarounds" below, you're forced to duplicate your lookup lists (or if you're naughty, choice field lists) in multiple places.
Possible Solution
Introducing Candidate One for your consideration... the Server Site Column. This puppy is defined in Central Administration and then available to every single site collection in the farm. This would definitely allow you to have a global Choice field... though lookups (which is what we really want, so we can get version control and other features around the lookup values) would be a little trickier. If Server Site Columns could lookup lists defined in Central Administration and this data would remain available (and perhaps even cached for performance) in each site collection, that would be super.
Candidate Two would be some sort of "Global Lookup" concept, whereby the columns would still be defined at each Site Collection, but would retrieve data from either "central choice lists" in Central Administration, or perhaps even via extending lookups to be capable of peeking across Site Collection boundaries. Either way, it would need to be simple for users to generate and then link in one of these globally managed lists.
Workarounds (For Now)
Here's just a few ways to achieve this:
- Build or buy a cross-site Lookup column capable of retrieving its data from a list in Central Administration.
- Build or buy a replication tool/scheduled job/workflow that would allow Lookup values to be specified in a central location, and then push those changes out to a local copy in the site collections that require it.
- Re-archiect your farm to use a single Site Collection. (Yes, I'm joking!)
:) Matt 19/12/2008
Back to your regularly scheduled vNext Wishlist programming, Dear Reader: here is blog 45 of one-blog-per-day-until-Christmas.
The Problem
Connecting SharePoint lists and libraries to Outlook is cool. It's usually easy to wow-the-socks-off-a-colleague by simply showing them a connected Calendar with two-way data sync. What? I can make changes in Outlook as well!?
Despite this coolness, a common misconception I've seen from Exchange users is that they expect this connection to be maintained on multiple machines. Sorry dudes, the data is synced as an old-fashioned PST file on the local disk, so you'll need to "Connect to Outlook" on every single instance of Outlook. This also makes it difficult for your IT chaps to push down a sync to force - err - make available - a connection to all users.
Possible Solution
Add a "Connect via Exchange" option or similar that allows the sync to be maintained and hosted in the user's exchange store, so that the synced data is available everywhere. The Outlook data would then sync with Exchange, which itself would perform the sync with SharePoint (possibly even once for all users with a few smarts). This would also provide more reliability if SharePoint was down or unavailable - the Outlook syncs would still work as they would be against Exchange, not SharePoint itself.
Another cool benefit of this approach would be in "cloud" scenarios where users may not even use the Outlook client, only the web client. The synced data could be easily delivered via Outlook Web Access, something that isn't possible with the current sync.
And while I'm at it, why not have a completely generic and simple-to-extend connection architecture? Dare I say it... "Connect to Google Apps"... "Connect to Facebook"... "Connect to Cloud Service X"... you get the idea. This could even be "Connect via Middleware Application" (substitute your favourite middleware tool here) where the logic of the mapping and sync could be easily defined in an external application with knowledge of SharePoint. A generic sync mechanism would open up even more opportunities for SharePoint to be a data aggregator/presentation tier in the enterprise and beyond.
Workarounds (For Now)
This one isn't really a showstopper.... just train your users. (I never said it would be easy!)
:) Matt 17/12/2008
Day 43 of the pre-Christmas blogathon, and we're back to another vNext Wishlist cheatpost. Not long to go now!
The Problem
When creating or modifying a view on a List or Library, if you remove the Title or Name column, you'll no longer get the typical context menu on the List Item, which can make it pretty hard to work with the view. There's no obvious way of adding this drop-down to the other columns.
Technically, this is because the rendering patterns and alternate fields are associated directly with the Title column, and don't simply get dynamically attached to, say, the first field in the view. Dang!
Possible Solution
Allow a column in a view or list to be identified as a key column, or as a column that has the edit menu shown against it. Dynamically attach the drop-down rather than making it part of the column definition itself.
Workarounds (For Now)
Well, you could extract the list definition/fields and modify the rendering patterns yourself... or, you could write some funky JavaScript/JQuery to dynamically add the menu where you want it. Without this, however, your only real option is to add the title field back, or perhaps use the "Edit (link to edit item)" button to go to the edit page from where many (but not all) of the context-menu options can be clicked.
:) Matt 15/12/2008
Day 42 – and if only this post was the answer to the ultimate question of life, the universe and everything. Sorry – it's just another vNext Wishlist rant.
The Problem
Lookups can become orphaned – lose their connection to the target list that is – for many reasons. Waaaay back on day 29 (you were reading then, weren't you?) I moaned about a couple of these. Another common scenario is caused by the lack of referential integrity – you can easily delete the target list without the source list knowing about it or even getting the opportunity to say goodbye.
Now you might think I'm suggesting the actual problem here is this brutal break-up in the first place, but no, I'm accepting that this might be unavoidable in certain scenarios. The real subject of this particular rant is the inability to remap lookups from the browser. You just get an empty "Get information from:" in the edit page for the column without any additional options or advice.
Possible Solution
Add a "remap lookup" facility to the browser interface to allow lookups to be re-united with their parents, or at least given a new home. I'm imagining you would click a button, then select the new target list. For bonus points, this feature could even detect discrepancies in existing data that no longer matches an item in the target list, and allow those to be wiped, or set to a default, or perhaps even mapped to new values. At the very least, this feature should not automatically wipe the lookup values since the remapping might correct this.
Workarounds (For Now)
Delete then recreate your lookups (if you don't care about or have any existing data – lucky!) Otherwise, see day 29.
:) Matt 13/12/2008One-blog-per-day-until-Christmas reaches the forties - #40 infact. Yup, you guessed it, another vNext Wishlist!
The Problem
Out of the box, standard list view web parts can only be added on the same site. So you've got a nice list at a top-level site that you want to render in sub-sites... bad luck. At least, not with a list view web part anyway - and let's face it, a large number of SharePoint users won't have access to SharePoint Designer, or just want to add web parts in that friendly browser-only drag-and-drop fashion, and without thinking about any of the workarounds listed below.
Now I can understand why certain technical limitations may prevent web parts from showing across site collections given their inherent boundary points. But, within a site collection, and definitely within a site in the same branch of a hierarchy, it's just a data source, man! What's the big deal?
Possible Solution
In the "Add Web Parts" dialog or advanced tool pane, add the ability to browse to other sites within the same site collection and add list view web parts from those sites. Or, perhaps, show each site in the branch as having its own gallery (and maybe even give each site its own gallery, rather than one per-site collection). Or, perhaps show a "List View Lookup" web part or similar in the gallery that allows users to then select a list from the site collection after adding it to the page, rather than having this effectively done for us by the enumeration of all local lists and libraries at the top.
Workarounds (For Now)
Here's just some of the ways this can be achieved, in my order of preference (though it depends on the requirement):
- Use a Data View Web Part in SharePoint Designer
- Use a Content Query Web Part in the browser
- Buy a third party product that effectively gives you browser-editable Data Views, such as Bamboo's or Lightning's
- Use an RSS Viewer Web Part
- Write a custom web part with its own data source.
Not all of these will give you the same rendering options or look as out-of-the-box list views, or at least not without getting into some funky XSLT (not a bad thing necessarily, but not as easy to use as dragging a list view onto the page, which I think is my point :)
:) Matt 12/12/2008On the 12th day of Christmas, my true love (SharePoint) gave to me, one-blog-per-day-until-Christmas #39. (Songs don't have to rhyme, you know...)
The Problem
Once you break inheritance on a securable object in SharePoint, that inheritance is forever isolated from the parent, making it very difficult to manage security additions that are intended to flow downwards. Yet often breaking inheritance is unavoidable, as individual security rules cannot be set or changed at a lower level - it's all or nothing, man.
For example - List "Christmas Gifts" is secured to and can be read by Bob and Jo (though of course, you've used groups in real life haven't you!?) Item "Bob's Christmas Gift" has inheritance broken so that only Jo can read it. But if Thomas comes along and is granted access to read the list "Christmas Gifts" also, he won't by default by able to see "Bob's Christmas Gift".
Compare and contrast to the file system. Bob and Jo can access folder "Christmas Gifts". Bob is denied access on document "Bob's Christmas Gift", so only Jo can access it. Thomas is then given access to folder "Christmas Gifts". Because he isn't denied at the lower "Bob's Christmas Gift" document level, he'll be able to see that as well.
Not sure about you, but I find the latter much more flexible and intuitive.
Possible Solution
Make SharePoint security inheritance like file-system security inheritance, or at least add the option of "break inheritance and stay broken" vs "merge inherited rules" or similar.
All of this would require the abilty to explicitly Deny privileges, which can only be done through security policy in Central Adminstration (AFAIK). I think it would be flippin' useful.
Workaround (For Now)
Plan your security structure very very carefully to minimise inheritance breakages, including extensive use of groups. Perhaps try something like this free access checker web part to improve visibility - or something more comprehensive.
:) Matt 11/12/2008
1BPDUC38.
The Problem
OOTB, SP pages are not strictly W3C standards compliant. They operate in " quirks mode" making it incredibly difficult to work with things like the AjaxControlToolkit that rely on strict mode (as well as making for some generally bloated and difficult-to-CSS pages).
Possible Solution
Output strict standards-compliant pages. Or else.
Workaround (For Now)
Try Arf arf... you do the doggie bounce. Or this post from Zac is quite enlightening. But really, these only apply to public-facing sites. Attempting to get this 100% correct for a large corporate intranet would be suicide, so IMO we're better to beg and plead for this to be baked in.
:) Matt 10/12/2008By now I'm sure you've worked out that this week is all about the short and sweet. Cue blog 37 of one-blog-per-day-until-Christmas.
The Problem
Possible Solution
AJAXify wherever possible to improve user experience and interactivity.
Workaround (For Now)
Keep your master pages lightweight and accessible to reduce size and therefore load time. And get a really really fast server so you don't notice the refresh.
:) Matt 9/12/2008
The stubborn commitment to one-blog-per-day-until-Christmas rolls on. Here's the 36th.
The Problem
When working with web part pages where a large number of web parts need to be connected, e.g. in this scenario, its necessary to add the connections one web part at a time, waiting for the page to refresh after each save. I'm lazy, and this is slow.
Possible Solution
Add a "Web Part Connection Manager" or similar that allows you to setup multiple connections in a single leap.
Workaround (For Now)
Like all glorious workarounds, you could write some code to automate this. But mostly, all we need is a little patience. Yeeeaaaaahhh yeeeahh. Thanks Axl.
:) Matt 8/12/2008Day 35... must... continue... despite all project work to the contrary.
Today's vNext Wishlist is pretty specific, but equally as spastic.
The Problem
After changing the URL of a reporting services report in a reporting services web part, all filter connections to that web part are lost, even if the report contents or available filters haven't actually changed (e.g. you've moved the location of the report and are simply updating referencing web parts).
Possible Solution
Improve the intelligence in the web part save so that after changing the report URL, only those filters that no longer have a matching name specification are removed.
Workaround (For Now)
Without access to write code, your only option is to reconnect the filters manually. One. By. One. This was my situation on a recent project with over 50 web parts. Ouch.
If you do have code access though - write a method to loop over and update the URLs in the web parts. Lucky you.
:) Matt |
|
|
|
|
|
|
|