Hiding the Title column in a derived content type is not so easy.
I've not been able to do it declaratevily, for example the blog post [SharePoint 2010] Modifier les Fields hérités dans un content type personnalisé was very promising, by sadly didn't work (at least for me!).
So I've done it programmatively, and here is the code:
SPContentType myContentType = web.ContentTypes["MyContentTypeName"];
myContentType.FieldLinks["Title"].Hidden = true;
After my previous blog post about the different versions of SharePoint 2007, I add the new infos for SharePoint 2010.
As usual, you can get the update status of the nodes of your SharePoint farm from Central Administration | Operations | Servers in Farm.
After that, you can find the updated list of SharePoint versions from the blog post SP2010: SharePoint 2010 build level and version numbers.
This is my third article about using the preconfigured 2010 Information Worker Demonstration and Evaluation Virtual Machine (SP1).
I think I've found the final solution, or better, I've found a sequence of exceptional blog postings describing how to use it with Oracle VM VirtualBox in very deep detail:
SharePoint, in both 2007 and 2010 releases, doesn't implement field level security.
For sure hiding fields at the presentation level is not the correct solution: the want-to-be-hidden data is still available to the unwanted users through internal SharePoint pages, web-service call and all the cllient object model APIs, search, and so on.
Doing some researches on this topic I've found a very clever implementation in the following article: Column Level Security in SharePoint. This implementation is very clever, uses lookup fields to a protected tables and methods to retrieve data to authorized users only. The nice thing is that the final result is very nice, and it fit perfectly in the native SharePoint user interface (but of course above all it's really safe).
You can also download the sources from codeplex in the following address: SharePoint - Secure Field.
You can implement pagination in SPQuery using the two following properties:
- RowLimit: to define page size;
- ListItemCollectionPosition: to define the current position:
- for the first page, don't give this value;
- for other pages, use the value returned by the GetItems method (it will be null for the last page);
- othersise, for more advanced scenarios, give a value to the PagingInfo string property.
The SharePoint content database schema can be found the in page Database Tables.
Other tables can be found in the reference page 2.2.7 Tables and Views.
Common queries can be found in the blog post SQL Queries for SharePoint Content Database.
Finally, an explanation of direct query access can be found in the APress book SharePoint 2010 as a Development Platform at page 280.
In a SharePoint it's possible to have many site collections inside a single web applications. If it could be difficult to manage permissions per each site collection, keeping them property synchronized could be a nightmare. Permission policies help to solve this topic, allowing to manage permissions for a subset of users or groups.
In fact, permission policies provide a centralized way to configure and manage a set of permissions that applies to only a subset of users or groups in a Web application.
To specify a permission policy:
- you must be in the Farm Administrator security group on the computer running the Central Administration;
- select the desired web application, and in the ribbon press the User Policy button, and then press the Add User button;
- select the desired zone;
- select specific users or groups;
- select the desired permissions.
For anonymous users, once enabled them in the web application, it's possible to specify the following user policies:
- None: no user policy defined;
- Deny Write;
- Deny All: it's like revoking access to anonymous users.
It's possible to find more information in the article Manage permission policies for a Web application (SharePoint Server 2010).
SharePoint 2010 drops the old concept of SSP (SharePoint Service Providers) and introduces the concept of Service Applications.
They are a way of exposing WCF services leveraging all the benefits of the SharePoint platform, for example load-balancing and high-availability using multiple front ends.
Here are some links:
SharePoint has the concept of SPPersistedObject and hierarchical object store.
The key concepts are:
- inherit your configuration class from SPPersistedObject, give it a Guid and mark the needed fields (not properties) as Persisted;
- hierarchical object store means that every object has a parent, so when the parent is deleted, all its children are deleted too;
- every object has to have a unique name in the context of its parent;
- it can be rather tricky to save collections of SPPersistedObject children, in this case the class SPAutoSerializingObject could be considered instead.
It's possible to find a very complete and detailed explanation in the article The skinny on SPPersistedObject and the Hierarchical Object Store in SharePoint 2010.
Property bags are used in SharePoint to store configuration values in the form of hash tables (key-value) at different levels: SPFarm, SPWebApplication, SPWeb and SPList.
They are simply used in the form of <my object>.Properties.
There is no default user interface to manipulate them, but it's possible to use SharePoint Designer 2010 (via Site Options | Parameters), SharePoint Manager 2010 and the more specific SharePoint Property Bag Settings 2010, or modify them by PowerShell too.
For other articles about them: