I am having a page with documents loaded in SharePoint 2010. I have three buttons below each documents in the page and they are 'Like','Unlike' and 'Comment'. So whenever people go there and see the documents they can click on any buttons of their wish.
My question is how to take the hit count of these buttons seperately and display it for each document. Is it possible to create a list with having these three columns and handle it using Client-Side scripting. Any suggestions or help is much appreciated.
Each item in SharePoint has a property bag that can contain ad-hoc data like this. You could certainly add additional columns to store this data and update those columns but that does mean that users could easily manipulate the values via the UI. Since the property bag is only accessible via the various API's, you wouldn't have this issue.
For an example of accessing the property bag via CSOM (which would be your best option since I'm assuming you want your users to be able to like, unlike and comment without refreshing the page each time), see this post reading and writing property bag values using CSOM
Another thing to consider for comments is the existing notes functionality that exists in SharePoint 2010 and SharePoint 2013. These comments are ties into the social functionality and may give you a bit more bang for your buck. To show the comments page for a particular list item see this post SharePoint Social Data using Javascript
I've got a custom list with a custom content type. I'm aware that when you create a new item you can see a drop down for the different content types on that list which I assume all have their own NewForm.aspx somewhere. I can specify in the content type definition which columns are shown on the New form and that I can replace the new form with a custom one of my own design.
What I'm trying to achieve is to have multiple New forms but for the same content type listed on the New drop down. I would like each new form to expose different fields of the content type. Additionally I'd like to make particular New forms only visable by users with particular permissions although this isn't critical.
Scenario:
I've got a content type with all the fields I need for a risk assessment. When a new item is created it only exposes fields to enter contact details. Once this is created a workflow with infopath forms then drives the gathering of the rest of the risk assessment information through booking, the inspection itself and approval of the data. I want the ability to have a second option to easily enter all this information on a different new form for an inspection that's already been done and needs logging in the system.
You could customize the NewForm.aspx (e.g. via SharePoint Designer) for the initial submission case. Obviously, all of the required fields will need to be populated in some fashion.
The EditForm.aspx is the out-of-box page for updating existing list items. You may be able to customize this to meet your update an existing risk assessment case. From the post above it's not entirely clear to me whether this distinction between these pages is fully understood.
In both of these cases, you can add code-behind to the .aspx pages. However, it's usually best to start as simply as possible, keep it as simple as possible and only add complexity as necessary.
Hope this makes sense and helps. Good luck!
Dan,
Per your scenario, I have done something similar by creating one content type per actor/stage. Consider using a simple SharePoint Designer workflow to change your content types onChanged (simply by setting the Content Type) column so that the perspective actors only see the columns you want them to see in the edit/newforms. As long as the proper content type is set, your users will only see the fields you want them to see. Furthermore, with creative use of views and audience targetting of pages you can somewhat prevent these users from seeing columns.
Also, you can prevent users from seeing the different content types (under the new button) in the advanced content type page.
How do I create a different users category? (more restrictive - with view only properties)?
How do I create a View - only for this category of users?
I need to group some users into a view only category and then assign only ONE view to this group, so they can not see everything that is in my list.
SharePoint, so far, does not give the option to restrict access at cell level so I need to go around this and create a view for this group, with the condition that all that they can see is this View (and they should not be able to add columns to this view).
Thanks.
Considering that you want to restrict the List View to only specific set of users. You have the following options
Doing it in the SharePoint UI but not suitable if you have lots of item and you want to do it for a SharePoint Group.
Open Source - CodePlex Good one I have tried it - It has got what exactly you want Column level restriction
Third Party in case if you feel to spend $ - Seriously I didn't try this tool.
Another Option to do it in SharePoint UI - Quick solution but - Wont prevent user from creating their Own Views.
Our company is split into divisions. These divisions work for client companies and are then further split into account teams that work on projects for a product of the clients.
So the structure goes Division > Clients > Accounts > Projects. And this is mirrored in the setup of our sharepoint installation. At each stage from Division to Account there is a subsite. Access to each subsite is controlled by AD groups and on each subsite there is a 'latest news' announcements list
What we want to do is have a 'wall' of announcements that feeds through so that each user can see on the top-level site all the posts in all of these anouncement lists, but this must be filtered using the AD groups that they are a member of so that confidential information isn't shown to someone who shouldn't see it.
Can anybody think of a way to do this?
Let's see - are those lists split accross site collection? With what tool you want to accomplish this?
You have several options (if you are within a site collection):
Use Content Query Web Part to
aggregate list items. You can
customize it to display fields
you like the way you like.
You can use SharePoint Designer.
Using Object Model/WebServices: Use
SPSiteDataQuery class to query
multiple lists at once and then
SPGridView to display data.
As you have a MOSS build, you could
even use CrossListQueryCache.
It's also a cross list query that
has builtin caching and audience
targeting. Be sure to read this to be sure caching is working.
If you want to aggregate between multiple site collections, then you will need to write code that get's all your SPSite objects and execute SPSiteDataQuery on them.
Maybe you can find out some additional information on Rollup of all Tasks of a Recurring Meeting in SharePoint
Here is how we are doing it.
Set up a content type for each level of announcement. We have national, state, district and the basic site level announcements. Therefore I have 1 national content type, 10 state content types (because we are in 10 states) and 1 content type for each district. All of these content types inherit from the base Announcement type with no modification.
I added a content query web part. I exported it. I edited the XML in the .webpart file to point to a new custom ItemStyle_Announcements.xsl file I had created. I import the modified .webpart and delete the default Content Query Webpart.
I modify the ItemStyle_Announcements.xsl to create the structure and divs I need for the styling. I add styles to the default style sheet I have already created for my site to get the look and feel I want. (I happend to have two styles for these, one featured/most recent item which is big and full, then a listing the next 10)
I find an announcement list that will possibly post to the national new. I add the content types as needed. Now the end user can choose what scope of announcement they want from the New menu.
This remaining issue is that right now, the States and Districts must have TWO announcement webparts on their home pages. One that lists everything local to that site (regardless of scope) and one that has unit announcements aggregated from the other sites in the same state / district.
I need to create some functionality in our SharePoint app that populates a list or lists with some simple hierarchical data. Each parent record will represent a "submission" and each child record will be a "submission item." There's a 1-to-n relationship between submissions and submission items. Is this practical to do in SharePoint? The only types of list relationships I've done so far are lookup columns, but this seems a bit different. Also, once such a list relationship is established, then what's the best way to create views on this kind of data. I'm almost convinced that it'd be easier just to write this stuff to an external database, but I'd like to give SharePoint a shot in order to take advantage of the automated search capabilities.
Proper Parent/Child in Sharepoint is near impossible without developing it yourself. There is one approach to that here: Simulate Parent / Child relationship in SharePoint 2007 with Folders & Content Types
(Note: This concerns SharePoint 2007. In 2010, Joins make this much easier)
Do it in a separate database, create a page(s) with controls that surfaces the data and run search over that. Loses quite a bit of the SharePoint features though.
Otherwise it may be okay to create a custom field control that will allow you to lookup the data in the other list.
The custom field control can be the one to "view" the related data.
I know we have done it for parent child relationships between pages on the same list. Not 1-to-N though.
Tough choice either way.
My vote is "to write this stuff to an external database"
You miss a lot of things in Sharepoint things like transaction support, referential integrity, easy way of updating (compare SQL), reporting (using Reporting Services and a SQL database)... see sharepoint as a way to store documents and simple lists.....
The argument for Sharepoint is if it is a small application, no requirements on support for transactions, no need to import external data etc...
When people say Sharepoint is a development plattform there is a need to define whjat they think a development plattform is.
The latest rumours about Sharepoint 2010 tells us that there will be support for SQL server based lists in next version ..... which I think will at least move Sharepoint in the right direction ....
Take a look at SLAM, SharePoint List Association Manager, an open source project my company created and actively supports. SLAM allows you to synchronize SharePoint data to SQL, including any relationships between lists. SLAM, in addition to being very useful on its own, is really a framework intended to allow developers to create their own complex data associations using what we call SLAM type profiles. We have one out-of-the-box type profile which is part of the open source project which actually allows you to make a SharePoint list hierarchical using the nested set model. For more information, see this page on our codeplex site.
I do this a lot just using sharepoint, using a framework called AAA (Activity,Assignment,Artifact), which allows you to use lookup columns to link an assignment or artifact to a parent Activity. You then build a web part page with connected web parts that allow you to filter all assignments and artifacts by activity. For example, click next to a submission in the submission web part, and all of the submission items attached to that submission will show up. Works great.
The other approach that you can look at using is persisting XML with a field in the item. This is the approach used by the Podcasting Kit (on CodePlex) to store things like ratings.
One possible method is to create a submission content type based on the folder content type and a submission-item based on item content type. Then you can store data hierarchically like in file system and also will work default views and search functionality.
Other way is to create lookup field that points to same list (list=”self”). This field will be used like reference to parent item and you will get list that contains recursively related data. To use this data programmatically will be ok but using views functionality will be little bit complex.
It's easy to do using a connected web part.
Create two lists:
Parent (Id, Title)
Child (Id, Title, ParentId)
Create a new sharepoint page, add DataFormWebPart (displaying Parent) and another one for Child, set both of them to filter based on a QueryString parameter (use that Parameter to filter Parent.Id, and Child.ParentId) voila, you can display parent-child relationships. Now, adding children is more difficult, and that's the part I haven't worked out yet.