Aggregating news with Sharepoint MOSS 2007 - sharepoint

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.

Related

Sharepoint list content from parent site to subsite

I have a list with multiple records in it. I want to filter some records from the list and display it on subsite web page. I goggled it and I found out that there is no direct way to use the list from parent site into subsite. I am using Sharepoint 2013 and I have full control access to site.
As far as I'm aware, you're correct--there doesn't seem to be a way to pull list items from a parent site to a subsite, at least not in the sense that you most likely want. This is a shot in the dark, but if you're looking to pull in static list items, such as street suffixes or product names, you can create a content type in your parent site that will pass down values you define in a choice field. If you really need dynamic linkage, give this a look: http://www.boostsolutions.com/cascaded-lookup.html
You have two options to display a SharePoint list from Parent site in a subsite:
Using Data View Web Part.
Using Content Query Web Part.
Check the details steps at
How to display a sharepoint list from parent site in subsite?
SP 2016 - Display list from Parent site in sub-site

SharePoint 2010 List - Need direction

I'm a coldfusion developer, and I've been asked to rewrite a coldfusion application for SP 2010. I have no SP experience, but I'm now the SP admin.
My application is a waiting list for customers that enter a service center. The customer is entered into a List that tracks the following:
Name
Location (drop-down list of physical store locations. no multiple/custom values)
Check-In Time (timestamp for when customer was added to list)
Service Required (drop-down list, not allowing multiple or custom values)
Staff Member Requested (option, user select box)
Time Seen by Staff (timestamp when list item edit begins)
Seen By Name (name of user that edited record)
Time Finished with Staff (timestamp when list item edit is saved)
There are a few pieces of functionality that I don't know how to build into this list.
1
The records on the list view must be automatically filtered by the location column. The location to be viewed should be based upon the users group membership. (one group per location)
The Time Seen date/time field must be a timestamp that occurs when the list item is opened for editing.
The Seen By name must be automatically entered when when the user opens the list item for editing.
The Time Finished timestamp must be automatically entered when the user saves the list item after editing.
I don't expect anyone reading this to create this for me, but I would truly appreciate any tips, suggestions, or tutorials you can point me towards that will help me to accomplish these goals.
You will have to create such a list with the SharePoint Administration. You have several possibilities to do this. You can build them in you web browser using your SharePoint Site with the necessary rights, you can use the Microsoft SharePoint Designer (similar, less functionalities but in my opinion easier to use) or you could deploy the list after you built it in Visual Studio (best solution if you want to deploy it on more than one server or you want to change your list afterwards, but difficult).
There are some things you have to know: A list manages one or more content types. A content type is a collection of columns that contain the types (and more information) of your data. There are templates for content types and columns, but you will have to create your own content type and maybe some new columns as the templates might not be enough for your demands.
I'm not sure how to manage your first point. There is definitely a solution but I'm beginner, too.
The other 3 points could be managed by workflows: You can define workflows for a list, that do things after an item of your list is created or edited. I'm not sure if this will be useful for your 2nd point.
Another possibility would be to build a webpart, but that wont be a solution for a coldfusion project as I think. In a webpart you could handle all the interaction that are made by an user and change your list item individually.
A third way is to build an event receiver (using Visual Studio) for your list, but then you would have to build your list with the help of the VS as well.
I'm sure that won't answer all your questions but I hope you have some directions that you can inform about.

Can SharePoint be used to maintain employee forms?

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.

Combining different lists data and showing it in a webpart

let me explain my current situation
i have a SharePoint site lets say it is MAIN, and a subsite lets call it SUBMAIN
in MAIN i have a list called "a" and in subMAIN i have a list called "b"
both lists have the exact same columns,
i need to show the content of both lists (ordered by modified date for example) in one webpart in the main page i know it is possible some how but couldnt get to it.
currently i am showing only the content of list "a" in a content query webpart (i have changed the way it display and added to it horizontal merquee) so it will be nice if somehow i can add contents of list"b" also to the same content query webpart (but if it is not possible in content query webpart its ok, at least let me know what other options do i have)
your help is appreciated
If you are using SharePoint Designer to do this, take a look at this blog.
If you are building your own web part, I would perform two queries on the SPList objects. You can then aggregate, sort, etc. the results however you would like. If you aren't familiar with SPList, you can look here for the MSDN overview.
I've built web parts to display items from 2 different lists, and I did something similar to what Scott Price suggested. I used an SPQuery object for each list and used it to get DataTable objects that I could then use with things like Repeaters and DataLists. You could merge your two tables and do something similar.
The biggest trick for me was setting up the custom templates for DataBinding in a webpart. To do that, I created a custom class that implemented the ITemplate interface and then emitted the HTML for each item from the template class in an event handler. Then, you just create an instance of your template class and set that as the ItemTemplate property of your, say, DataList.
This post and this one do a better job of explaining that approach, but the nice thing is that you have complete control of the markup, and you can style it as you like.
If you're not looking to code your own solution, you might consider this webpart on codeplex:
http://rssaggregator.codeplex.com/
It's actually an RSS aggregator, but since all SharePoint lists have built-in RSS feeds, you can use it just as well to aggregate the SharePoint lists from the different sites.
Another approach is SLAM, SharePoint List Association Manager, an open source project my company created and actively supports. SLAM will allow you to configure those two lists to be automatically synchronized to SQL tables at which point you can create a query to join the two. If you have the two lists built off a content type (since they have the same fields) you can actually slam the content type and have both lists in the same SQL table.

Representing parent-child relationships in SharePoint lists

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.

Resources