Ever wanted to know the difference between the “ReadOnly” and “Hidden” attributes for the FieldRef? If your answer was yes, then keep reading..
You may get confused when you try to set the properties for a field in case you want to reference it in a content type, basically you use FieldRef to reference fields in your content type, then you may wonder when to use the “ReadOnly” and “Hidden” attributes.
The reason that makes you consider these attributes is that if you want to hide the item from the NewForm.aspx page. Both will hide your column from this page.
The difference here is that “Hidden” will hide your field completely from SharePoint, you will be able to use this field in code though (so you may use it like a property for the content type to store specific values that won’t be shown in the browser), but you won’t see it in browser, you won’t even be able to see the field when you want to modify the view for the current list, it’s Hidden (as its name says!).
ReadOnly will hide the column from the NewForm.aspx page (so it’s a ReadOnly), but you can always modify the list’s view to show this field. So it’s not Hidden 100%.
So never use Hidden in case you want to be able to view the field later in the list!
That was a quick tip that would clear things out for some people out there!
Here’s a fact I have found during my work on a SharePoint add-in with AngularJS, you might have read that ng-show does a similar work as ng-if in case you need to hide or show some markup on your page depending on specific condition, so ng-show and ng-if will both do the work, but with slight difference .. or is it a big difference?
The common thing that’s known about the difference between ng-show and ng-if is that, ng-show and ng-hide both will add the styling to change the display of the element to be “none”, so by changing the css for the element and changing the display property, ng-show will hide or show the element. The difference with ng-if is that it will remove the element itself from the markup if the condition is not met, and will return a clone of this element when the condition is met… But that’s not the only difference as well, and not the important difference..
What caught my attention is a difference that’s related to performance. Imagine you have a table with many rows in your page, with checkbox that’s when checked will view an image related to the row. The thing is, if you’re using ng-show with an expression that evaluates to true/false, all images will always be downloaded in your browser, but you will not see them as they’re going to be hidden because the checkbox is not checked yet. However, when you use ng-if and it evaluates to false by default because the checkbox is not checked, the image will not be downloaded until you check the checkbox, which will be better for browser’s performance (Imagine if you have a repeating section with 100, if you use ng-show, all images will be downloaded to your browser right away, but if you use ng-if, only images that you check will be downloaded).
I hope this helps someone out there with their Angular work as it helped during the Add-in I was working on!
If you worked with Managed Metadata columns in SharePoint, and tried to change the term’s value in the term store you will notice that the value of the new term is not reflected in your lists, this is a common problem with Managed Metadata, but not a problem at the same time.
The reason for this is, the terms used by the site collection are stored in a hidden list inside the site collection, it’s similar to the list used by variation to synchronize between source sites and target sites when using variation in SharePoint.
All what we have to do in this case is to call the method SyncHiddenList,
public static void SyncHiddenList(SPSite site)
As you see from the definition, we need to pass a parameter of our current site collection, and once it’s called, it will update all of your terms inside lists and libraries.
Here is a quick post on how to get all documents from a document set programmatically:
//First getting reference to the list:
SPList myList= web.Lists.TryGetList(“ListName”);
string strquery = “<Where><Eq><FieldRef Name=’Title’/><Value Type=’Text’>” + “DocumentSetName” + “</Value></Eq></Where>”;
SPQuery strcamlquery = new SPQuery();
strcamlquery.Query = strquery;
//getting reference to the document set item inside the list
SPListItem docsetitem = myList.GetItems(camlquery);
//Now to loop through items in the document set
SPQuery itemDocSetQuery = new SPQuery();
itemDocSetQuery.Folder = docsetitem.Folder;
SPListItemCollection items = myList.GetItems(itemDocSetQuery);
That was a quick post, but I am sure this will be helpful to someone out there.
Have you ever written a timer job in SharePoint to read from or writing to a term store in Managed Metadata, you might have done so and faced the error:
“The current user has insufficient permissions to perform this operation”
Even if you try to run the code with SPSecurity.RunWithElevatedPrivileges(), or with your own account from Visual Studio, it will still give you the same problem.
The thing is, that the timer job runs with its own service, which is “SharePoint 2010 Timer”, see the below image.
The user running this service has to have access to the term store administrators in Central Administration, see the image below:
Once permission is given here, you will start having access from your timer job to the managed metadata term store and create your desired term sets and terms.
Here is a problem I had and it took me a while to know the reason behind it, it’s when you try to add a farm property using PowerShell, like this:
Now try to get the farm properties using the following command: $farm.properties, you will see the following result:
that’s great! You could get your property name and value without any problems, so now let’s try to get the farm property in code, shall we?
In visual studio type the following in your code:
String myProperty = SPFarm.Local.Properties[“MyFirstProperty”].ToString();
Baaaaaam, you will get: object reference not set to an instance of an object.
The reason is, although you can see the farm property in PowerShell when you type $farm.properties, you need to write the $farm.update() command after that in order to be able to use that property and to be visible in your code.
Hope this helps someone out there.
So one quick tip.. I had a requirement to add an extra field for a CQWP, and map it to display a column inside my target list, Here is a mistake that took me a while until I figured it out:
So to add a new field, we modify both ItemStyle.xsl and the .webpart file to include our new field, right?
I have my field inside my list called: SecondLocation, so in our Template inside the ItemStyle.xsl, we add this field inside a div or any other html control we may need, in order to style it, like this:
Now we will add this field to the webpart itself, because it’s not there by default, so we export the webpart, and add this field to the “CommonViewFields” section, what I did is like this:
<property name=”CommonViewFields” type=”string”>
When I tried to view the webpart, I didn’t see my field displayed, Although the internal name is right, the field is written in ItemStyle.xsl, the field is added to the .webpart file, the thing is with the formatting of the xml for the .webpart itself, instead of writing the properties for the webpart on multiple columns, you should write it all on the same column, like this:
<property name=”CommonViewFields” type=”string”>SecondLocation, Text</property>