We used to have a legacy PHP Site as an internal blog site but have since recreated the site in SharePoint. The native SharePoint reporting gives us almost everything we need but our admins need a single place/page to view all the comments from every modern page/news post.
Is there a way I can pull all the comments and show them in a list? I know there's an API I can use but I was hoping there would be an easier way instead of developing an spfx webpart. Ideally a list with the page/news post title, the comment, who posted it, when it was posted and a link to the article would be ideal.
I have created a webpart annual results.This should be available only to managers and not for developers in the home page.How to achieve it?
If you're using MOSS then you can use audience targeting, but be aware that this should only be used as a way to help people notice what's important to them not as a mean of authorizing what they can see.
If you're using WSS then you'll have to write code in the webpart to achive the same functionallity
Per Jakobsen is right, however that is still "security by obscurity". If the data is being pulled from a SharePoint list then consider security that list or the list items within that list, your users who don't have rights will still see the web part but they won't see any data.
I am new to Sharepoint (WSS 3.0) and have the task of creating a company intranet. This site will have a number of sub-sites - each owned by a different department. Each of the sub-sites will have an 'Announcements' webpart on their top-level page.
What I want to do is to take the most recent announcement from each of those sub-sites and display them on the main top-level site - the idea being that anyone in the company can see at the top level what is coming up in each of the departments.
My question is, what is the best way to do this? and does any one have any links that can point me in the right direction.
Many thanks.
In case you have MOSS, you should use Content Query Web Part here is the way to do it.
You can achieve the same by using Data View Web Part.
The third option is to create a custom code to do that, but since you mentioned that you are new to SharePoint I would advise against since that might be a bit complicated and it cannot be compared to the strength of built-in web parts.
The thing you should consider here is security. If a UserA from DeptA does not have permission to read Announcements from SiteB then the thing you are building does not make much sense because information from SiteB will not be visible to this user.
Along with the Toni answer you can try the SPDataSource & SPGridView if custom code is okay.
We are researching the various options that exist in our environment to create an Employee Directory. We have a SharePoint portal, AD and recently moved from Lotus Notes to Exchange. Our current employee search is a custom Notes DB that has since been retired.
Since moving to SharePoint an year ago, we've used a custom list using SharePoint Profiles that are updated from AD. But the simple list interface isn't very user friendly and is very slow. Sone of the requirements include type-ahead, pictures, and details of skills/certifications and other demographic information etc. We are considering building an ASP.NET or SilverLight application that can consume the information in the SharePoint list. With the introduction of Outlook and the Global Address List, we are now wondering if it might be easier to build something within Outlook.
Has anybody traveled a similar path and what would you advice us to do?
Microsoft has a huge set of offerings for Collaboration and Social Computing in Sharepoint.
See this document, pages 8 and 9 for information about features related to an employee directory, including details of skills/certifications and other demographic information.
A la carte availability of individual features (such as People Profiles and People Search) and pricing may be an issue, but you may want to look into buying something rather than building it (if you can get the pieces you want for a price you can afford).
Sharepoint can connect with Outlook to keep the lists synchronized if you want to use outlook. And there are definitely a lot of different ways to change the way the lists are presented in the Sharepoint portal to make them more user-friendly. Having those details on the portal will certainly be a boon when combined with the powerful search and indexing features in SharePoint so you can identify employees based on their profile details easily.
We use the people search for this pretty effectively. We populate data in AD, then connect profile properties to AD attributes. That's only if you have MOSS, though. If you're working with WSS, you'll have to build something more custom.
One gotcha, though, is that the People Search out of the box doesn't easily do partial searches (i.e. searching for "john" doesn't match "johnson"). That's a big downer in my mind. You can use Ramon Scott's approach of a Content Editor Webpart with a form and some Javascript to work around it, and you can also get there via the advanced search box (albeit indirectly), but it sure would be nice if it were easy to make the default search box do partial name searches.
I recently just discoverd a somewhat easy visual basic script that draws information from the active directory where you can specify which OU to draw from where it displays all user information in a simple .HTM page. it includes a search bar, recognizes patterns (address) (company telephone number) etc... If you would like i can post it for you. you only need to fill in a few sections (display name for directory, OU, OU display, and tags) and you can always change the way things look too.
This should be taken care of by using the My Site feature that's available within SharePoint. You will then be able to search SharePoint users by skills, certifications, projects, and educational qualification.
Please refer to the SharePoint Planning and Deployment material on TechNet for more info.
SH.
We have had SharePoint where I work for a little while now, but we've not done a lot with it. We have an intranet with hundreds of ASP/ASP.Net applications and I'm wondering what kind of things can be done to integrate with SharePoint to make a more seamless environment? We put documentation and production move requests and so on in SharePoint now, but it pretty much feels like it's own separate system rather than an integrated tool on our intranet.
I've searched around to see what other people are doing with SharePoint but I've been finding a lot of useless information.
A great idea for you would be move your most used asp.net apps to run within the SharePoint site. Each app can be added either as a control directly on a pagelayout or integrated into a webpart (use the webpart to load child controls).
This would allow you to use the flexible moss interface to move the asp.net app into a unified information architecture so people can find the app easily.
SharePoint is really easy to roll out something that works, but creating a seamless intranet does require a bit of thinking outside of SharePoint itself (i.e. what should go where, which users need to see what, navigation structure...)
That is really a lot of work and requires lots of input from people outside the IT area.
A typical intranet portal segments functionality by department. Each department will probably have some custom web-based apps that you might have historically implemented in ASP.Net, and linked to from the intranet portal. With sharepoint you can start bringing the useful bits of those custom web-apps in as modular parts, so that the business owner of the portal can have more control as to how information is structured and displayed to his/her users.
Think dashboards, populated with custom metrics that only make sense to individual departments. That's one of the most obvious places to start. HR, accounting, IT, they all have metrics they want to track and display. They all have legacy systems that they might want to correlate information from. All this can be done in reusable web-parts. Since Sharepoint gives the end-user the control over layout, display, audience control, etc, you don't end up reinventing wheels all day.
SharePoint was designed to be a collaboration portal and document repository. If you have other business processes wrapped up in other internal web sites, you may not get much benefit from converting these sites into SharePoint sub-sites.
However, if there is signifcant overlap in your applications (contact lists, inventory, specs, etc.) you may want to make the investment to combine.
If you have InfoPath, you can create online forms. You can share your docs and edit them online. You can start an approvement workflow on these docs. You can create polls. You can create work groups.
Basically SharePoint is a giant and robust document store, but you can do anything what you can do in any ASP.NET web application. You can create e.g. custom workflows to automate business processes. We've worked for several customers to create corporate intranets and sometimes internet sites, so it really works. :)
But sometimes it's very hard to implement the requested features (a lot of workarounds).
Really its an intranet in a box. We pretty much run all of our day to day development tasks off of it. We keep documentation, track defects, manage people's time off etc. You can migrate your asp.net and asp applications to run under the sharepoint site. In the adminstration section you can set up web applications to run under the same site, but outside of sharepoint's control. That would probably help with the "feel" of it being completely seperate.
Sharepoint is really a shift in the way people have to think about web development and that's the key. You're no longer developing a standalone application, you're adding on to an existing framework. I would put it akin to having "silos of data" vs. a centralized database system which houses all the company's data. Once people realize that everything is connected, it will feel more like a seemless integration. My advice is to actively try and create applications in sharepoint and think about how to migrate existing apps on to it.
How about BI and reporting from an ERP?
When we know IE is uncapable to handle a page with 10000 table rows (without pagination)
Many don't realize but the success of a reporting tool depends on the performance of the grid object used - Excel and the SpreadSheet obj from the defunct Office Web Components are still the #1 in user's (accountants, managers, ceo) choice.
I think it depends on your environment. In our environment, we setup each department with their own pages and we use it for basic information, surveys, and the employee's homepage. We've built Google/Live Search and Weather.com widgets and roll RSS feeds using Tim Huer's RSS control.
One thing you can do is to create web parts to provide access to data from existing applications. Initially they could simply be read-only views, but depending on your experience they could be fleshed out to allow writes.
Another idea is to add links between SharePoint and your applications (assuming they're web based); that will at least allow a flow between them.
I haven't done it, but you could also theoretically skin SharePoint to look like the rest of your intranet.
Create libraries
Form libraries, documents libraries, slide libraries
Create standard or custom lists
Standard lists - announcements, tasks, contacts
Custom lists - suppliers, contractors, inventories, orders
Setup secure team discussion areas
Build shared team calendars
Create simple workflow processes on documents and lists