Column permissions (or field security or whatever you like to call it) is a very common need, especially as more and more companies chose to computerize their paper forms using SharePoint. A simple vacation request form that needs to be approved by the manager has two kinds of columns - thse filled out by the employee (start date and end dates come to mind :)) and those filled out by the manager (approve/deny). How can that be accomplished?
Well, the short answer is - it cannot be done in SharePoint out of the box. The product does not have any support for column security, all columns always have the same permissions as the item which values they represent. So we need to look at the alternatives.
- InfoPath forms- SharePoint and InfoPath have been best friends for a long time, there was a forms library in SharePoint 2003 and the situation has been improving ever since. In InfoPath you can implements rules and condition and create just the user interface you want using a simple designer. Using Forms Services you can fill out the resulting form using nothing but your browser. But there is also a dark side:
- InfoPath forms are not lists, although you can promote certain value to become columns in the form library, but this is not 100% list-based solution, for once, you cannot use custom fields
- Creating InfoPath forms requires some learning curve, nothing major, but enough to deter users
- It looks different, it behaves differently, it just does not fit in the familiar look and feel of your system
- "Secure" custom field type- some sort of custom field that encrypts its value and only shows it to users with sufficient permissions. This type of solution is offerred by a few companies out there and does seem to provide an interesting approach. But there are some drawbacks as well:
- This is a custom field, although it is possible to make it behave similarly to the built-in fields, such as text, number or date, it can never replace all field types out there, certainly not the custom one you might need in your solution.
- The value is stored can only be used by the field itself, if you want to get rid of the field type, you need to re-enter all the data. All you wanted was a SharePoint list, not a catholic wedding :)
- Custom iterator - is the component that controls which columns will appear on the new/edit/view form of any SharePoint list or document library. The SharePoint infrastructure allows the built-in component to be replaced by custom one, that can show or hide columns based on custom logic, such as column permissions. Due to the fact that only the background component is replaced, your user interface remains unchanged and you can use any field type, built-in or custom. This approach is not without sin:
- These are display restrictions, the underlying data does not have any security layer applyed to it. So the columns can still be shown using standard views and datasheet view. This is actually not a big deal, as you can control which columns appear in views and you can block the datasheet view. But in most cases even these measures are unnecessary as all you want to do is basically prevent a regular user from accidently editing the fields they are not supposed to edit, the changes can always be tracked by turning on the auditing feature when needed.
In my personal opinion, the third option is by far the most convenient and useful, despite the drawbacks. It allows you to create advanced, multistage electronic forms with minimal effort and easy-to-use, consistent interface. This is why we based out Smart List Pro (https://www.infowisesolutions.com/product.aspx?id=SmartListPro) product around this appoach, adding such cool features as tabs and tab permissions, view permissions, custom validation and more. We even have a feature-limited free version, Smart List Lite, for you to enjoy. Get it free or install the 30-day trial version, this is really cool and helpful.
That's all for now :)
Don't want to mess around with HTML? Want a more robust solution? Try our List Marquee web part!
I think that anyone, who has ever worked with SharePoint products, has heard the request:
".. and on the main page.. i want you to add the news list .. and .. yeah make it scroll through the topics.."
so you go and search the web.. maybe they have one on codeplex (maybe they really do.. ),
maybe some products company has a sale or even better, they're giving it free ???
what i am gonna show you now is how to do it yourself.
All you need is a SharePoint web site, a list and a SharePoint designer!
the process is really quick and simple - believe me, it will take much less time to do it, then it took me to prep it :)
Step One: take a list, any list (in fact any web part or other content)
Step Two: prepare a site page on which you'll have the list displayed
press "Edit Page" > "Insert" > "Existing List" and select your list
Step Three: Adjust list web part appearence
select wanted view, disable list toolbar, remove web part frame..
prepare the list visual appearence
Step Four: Open SharePoint Designer
open the site, which contains your page and edit it
Step Five: Find list's web part in code view
Step Six: Add marquee object
in a brief: html marquee object let's you scroll it's content on a web page.
now you need to "wrap" the list's web part with the marquee element, so:
save the page and you're all done, let it scroll !!!
it's hard to show scrolling content with an image - so you'll just have to take my word on it
In this post I am going to demonstrate how you can create wiki index pages without any code.
SharePoint Wiki site template (both 2007 and 2010) is great for creating large information depositories with multiple interconnected articles. The very nature of the wiki in general emphasises the ability to easily browse the related article using the hyperlinks embedded into the body of the current article. But what if you needed just to browse the list of articles present in the system? Wiki is not hierarchic in nature and does not possess a table of content nor an index of terms.
But we can create one easily. We will use a regular view, which, depending on the parameter passed using the query string (the characters in the page's address, after the question mark :)). We will pass the first letter and see all the articles beginning with that letter.
First we need the index itself, looking something like this:
This is basically a Content Editor web part, created in a browser. Each letter/digit is a link to our view page, in the format https://[server]/Wiki Pages/forms/index.aspx?fl=A
where index.aspx is our view page and the "fl" (first letter) parameter takes the value of the clicked letter or digit.
Where do we put this web part? On the default page of course. In my case I completely customized this article and created a welcome page of sorts, including the index, a search box, Featured Article web part and even article categories. Under SharePoint 2007 you need to edit the page in SharePoint Designer to add web part zone, in 2010 it is not needed as the wiki text editor now allows web parts as well as text (which is really cool BTW).
Now it is time to create our view. Go to View All Site Content and locate the wiki library. Open it and create a new view, name it Index (the name does not matter obviously, just as long as the URL is the same as the one that we used in the Index web part).
The view should only include the Name (linked to document) field. Sort the items by Name.
Now we need to make the view aware of the query string parameter we pass.
- Open the view page in SharePoint Designer
- Convert the view web part into XSLT
- Delete all unnecessary elements, such as column title
- Add new Query String parameter names "fl"
- Add new filter: Name column start with the value of the "fl" parameter.
- This is it, now you will see all the articles starting with the letter you clicked on