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
Related
I am using Visual Studio 2010, SharePoint 2010 with custom document content types and forms. And plan to also use jquery to build the document add/edit/view forms.
I am developing a solution where I want to have a document library where each document uploaded also has a number of external data elements added as metadata.
The tricky part I'm trying to figure out is I want the user to be able to specify and add a multiple number of those same external data elements.
I'm trying to figure out how I represent the data internally in SharePoint. My initial thought is to programmaticly add hidden external fields as the users adds those external selections. But then I also think of simply storing those external elements as non-external text fields but have my own code which performs the external data lookup and validation.
I'm not adverse to significant custom coding, as I'm probably going to need to do a lot anyway since even the user interface is going to be a jquery tabbed form to enable all the external data the user will be able to associate with each SP document.
I've made an attempt to hopefully further explain what I'm trying to do and included that image. Essentially I'm wanting to add 1+ external data relationships to each document, as desired by the user.
It uses just example data. I'll actually have 4-7 different complex relationships much like the example. And the user is permitted to drilldown and select 1, 2 or all 3 of the dropdowns.
Think of it as similar to how here on Experts-Exchange we can add multiple zones to a question.
An example illustration is here: http://flic.kr/p/aFUSJn
Could you simply add a multi-line text column and have the user input the metadata with comma's, then use your code to seperate the data and do what you want with it?
You said you were not adverse to significant custom coding :)
One solution is to use SharePoint content types. The trick is that not all items in a list need to have the same content type.
Therefore, you can do the following:
As the user is selecting the fields he wants to use you generate or select a content type that matchs those fields.
You then add your document to the document list using the content template
You then have all your information strongly typed in SharePoint lists.
We have previously built a system where we generate content types based on xsd files, this worked very well.
We have a list with 1000+ phone numbers in it. This list is sorted in a specific order by due dates and other criteria. This order is very important and needs to be maintained in the solution.
We have a group of callers (roughly 4) that will be calling the numbers in this list in the order they are sorted by. These callers are to be presented with one list item at a time, via an InfoPath form, and once they make the call they will update the list item and be presented with the next list item dictated by the sort order.
Here's the problem: This would be very easy with 1 caller but with 4 callers we don't want them calling the same people more than once. So they need grab the next list item off the top of the pile that isn't already taken by another caller.
Is there a way to build a webpart (remember without Visual Studio unfortunately) that as soon as it loads would find the first list item that is unassigned and assign it to the current user?
We could accomplish this whole thing manually of course by having an admin assign all the calls each day with a large copy/paste in Datasheet View but automatic would be soooo much better.
I will mention that I DO NOT have Visual Studio so I don't have that as an option here. But I do have SharePoint 2010, SharePoint Designer 2010, and InfoPath 2010.
I hope this makes sense and any ideas, thoughts, approaches would be greatly appreciated since I've run out! Thanks!!!!!
You can develop SharePoint web parts using Visual Studio Express, but its a bit harder as you miss some of the tools that make your life easier like WSPBuilder etc.
SO - Building webparts with Visual Studio 2010 Express
Another alternative would be to use javascript client side to access SharePoints Web Services via SPService - then nothing more than notepad is required.
You're really using a wrench as a hammer with either of these approaches though, so I've got to say - how much do you value your time at? ;)
I can offer a very bodgy alternative; presuming all the items are added piecemeal (not in the same second). You could add a calculated column to assign each item at random on addition, using the following formula:
CHOOSE(MOD(SECOND([Created]),4)+1,"Operator1","Operator2","Operator3","Operator4")
I suggest a workflow that is assigned to listItem's edit; that when a caller edits its extra field like "Operating(bool)" after the calling workflow completes; the item is disabled somehow.
Only overhead of this is a caller needs to edit the item every time.
But the easy part is a listviewer webpart (oob) can be used just with a default view setting like "Operating" field is "false" only.
This is simple. On form load, instruct the form to update a status field to (let's say 'assigned') and automatically resubmit the form back. Your infopath list that pulls in the next number to call would need to exclude any that are in the assigned status. You'd also need to re-query your data connection to refresh the list each time before a call is made to grab the next available. Once the caller is finished, they can click a button that submits the form, clears the status field and closes the form.
Yo can also pull in the active items into an infopath form using a secondary data connection. There is a way to use the insert hyperlink into the form field, and make any of your fields a URL hyperlink directly to the individual item. Although you'd have to have the URL epsaved in a field in the form the item was created in. That's easy to do, you can just con at the URL with the form name.
We'd like to create something within SharePoint that would allow to ensure a set of forms is completed for each employee (i.e., Tax forms, non-compete, etc.). HR staff would have access to a page listing employees and upon selecting a specific employee, they would be shown a list of these completed forms which could be opened to view the document.
Is this scenario something that can be done fairly easy with out of the box features? Or would a custom workflow, web part, or something else be the best bet?
The easiest way to do it out of the box would be to use a single Document Library (or possibly Forms Library) that has multiple document/form templates in it. Then create a View that groups by Created By. HR could then expand on an Employee and see what has been filled out.
To limit an Employee from seeing the forms of another Employee, set the View and Edit options to Only Their Own. Make sure that HR has a higher level of permissions for the list and/or site in order to see all Employees.
If you don't have complex workflows - my advice will be to populate SharePoint List using InfoPath Forms (this article will be a good start).
In other case solution heavily depends on your business requirements and may vary from simple SP List to custom workflows with infopath forms and custom webparts.
I'm developing a customized document library in the SharePoint 2007 environment. What I'm doing is creating a content type with multiple columns of information related to the document. Users will use this content type to upload new documents rather than the standard new document functionality. One of my columns in this content type is proving to be more difficult than I can handle.
The column is essentially supposed to be a sort of 'related documents' column, where it offers the user the option to select another document that is related to this document. So I thought I'll create a lookup column that displays the titles of all other documents in the library and allows the user to choose one. Simple enough, but I need much more functionality than this...and here is where I need help.
I need the related document column to actually link to the related document, not just display the title...not in edit mode while a user is adding a document, just in the standard document library view after the document has been added.
I also need the link to include a url variable that is stored in another column named 'Document Number'.
I assume this will require custom coding which is fine. Please not that I can't use SharePoint Designer. I use Visual Studio and code must be C#. This will be packaged and released as a feature.
Can anyone help me acheive this? Example code, suggestions, etc...? Thanks!
I would suggest using a multi-column field as your base value type - this article on MSDN should get you started. For rendering the field in document library views, you will need to use a rendering pattern. Conveniently, MSDN has an example of a multi-column RenderPattern.
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.