I want to use SharePoint lists and workflows to improve some internal processes that our company is currently handling with Excel and email. I have a working user knowledge of SharePoint, but I am not a SharePoint developer.
There are 2 specific questions I've been trying to find a solution for. Having not found an answer after a fair amount of searching, I wonder if I'm not asking the right questions or if perhaps what I'm wanting to do is just more advanced (or not possible?) than I'd hoped.
I'd like to have 2 SharePoint sites in our production environment, but one would be the "dev/test" site and the other would be our "production" site. As we make changes to the lists or workflows over time, I'd like to be able to make the changes in "dev/test" site, and then after we verify the changes somehow move those to the "production" site.
I've looked at the list template, but that seems to only be usable for creating a new list, not updating the columns, views, etc. of an existing list.
Is there a way to move list changes (but not data) from one site to another?
Can the data in specific lists be automatically backed up and restored independently of a full SharePoint server backup?
I am currently working in a SharePoint 2019 Server environment and appreciate any answers or guidance you all can provide.
Thanks!
Related
Good day beautiful people,
Overall description
I have been assigned to a project where recruiters are using excel file to gather information about new joiners, leavers and people changing positions. Later on it is uploaded to SharePoint where this data is connected to some other files, dashboards and so on. There is also a copy of it, in InfoPath, but the program is working terribly wrong so personally for me this is no-go zone.
My goal
I would like to make this more automated and user friendly, so that's why I wanted to move it to the SharePoint. I want users to have one page, subpage, app to fill up necessary data, edit it if needed and then publish to the SharePoint.
Problem
I have visited tens of pages how to create SharePoint form without InfoPath, how to create SP form with PowerApps but most of these articles provides nothing useful. Just brief overview and I am not that power user of SP to get this done in no time.
Question
Is there a way, that I can make this working within accepted mater of time (few days) so the end result will be exactly what I need?
Make some lists in SharePoint with the columns they need, use that as your data source. Link your PowerApps application to that source, et voila. Recruitment can now fill their data in with what you need, and via Power Automate you can process the data and send it to the correct locations afterwards.
I am having problems figuring out a calendar workflow and am beginning to think what I need cannot be done w/out using .NET. I want to copy calendar items up and down between sites.
The site collection structure is Office-->Division-->Branch. There are 5 divisions under the office and multiple branches under each division. Each is a separate site with its own own calendar.
I want to populate a calendar on one site and have the item pushed up or down the site chain to another site calendar. So I need to be able to promote calendar events up AND down between calendars on different sites within the same site collection. Also, I don’t need the whole item copied. I need all fields except one because each site has its own set of check box values for one of the fields.
All my research has indicated this can’t be done without programming and I do not have Visual Studio. I have heard BCS may be a solution but am not sure that we have it. We are using SharePoint 2010 Enterprise Server but many things are not available to me such as Data Sources. One recommendation I got was to have one site (office) and put everything below it as site pages. So divisions and branches would just be pages, not separate sites. However, this seems like it would get out of hand quickly. Any help would be greatly appreciated.
So it looks like my site structure is not optimal as SharePoint lists and libraries do not easily flow between sites. I will need to change the structure so all the divisions and branches are site pages, not sites. This way everything will live in the same site and it will be much easier to move data around via workflow.
In this case, I won't need to move any data between calendars because now I can use one calendar for the office, divisions and branches and create different views to show the required data.
We'd like to create a web page that will list all Document libraries across all sharePoint Sites for the user currently accessing the page. We'd also like to offer a all site search for the user. That is all sites they have access to.
We currently do not have Mysites enabled, nor do we want to.
Possilbe to code this?
All site search is easy. If you are using the non-free version of SharePoint 2007 or 2010, then that capability is baked into the product. Users can use the search scopes to search across all content in the SharePoint farm. It will automatically trim search results that users don't have access to.
As for you list of all document libraries, this would probably be too much effort to generate in real time for any non-trivial SharePoint environment. You are most likely going to have to gather this information ahead of time and then display the appropriate summary of the data in a WebPart of some other similar interface. Code to crawl every web application and every site and every sub-site and then every Document Library isn't hard. Actually it is very straightforward. What will be a little tricky is that you will need to collect ACL entries for each of these lists so that you can compare them to the current end user. The real trick is that the ACLs might contain SharePoint Group names and Active Directory group names instead of individual end user names. That will make your reporting task more difficult.
We have a production SharePoint site that uses a custom database quite a bit. We have a dev site on a separate box where we develop all of our things then move them over to a live site when they are ready for our customers.
We have many pages that use data views to show information from the database. Most of the actual programmability is done with stored procedures and UDF's in the database itself. One of the problems we are having is that when we try to move these custom pages over from one site to another (even if within the same SharePoint installation), the data views become broken. As far as I can tell, the data views are associated with data connections via a GUID. We can go in and set up all of these connections by hand on the new site, however there is no option in the data view webpart to change the data view's associated connection.
At present, this pretty much prevents us from developing on a separate site at all. Doing a command-line SharePoint export/import is an all-inclusive way of accomplishing this. However, ignoring the limited options for this operation, it is at best unreliable. Our first attempts left out some of the content (like custom aspx pages). As we began to create more complex customizations on the SharePoint site, the export function stopped working altogether only to return cryptic errors.
Has anyone else found a good way to do this?
You can do the following:
Create a new page on the destination sharepoint and include an empty data view
copy/paste the old code into the new page
Replace the webpart id of the old dataview with the new one
It worked for me, although I'm still struggling with some complex forms that use drop-down lists that lookup their values in the database depending on other fields. For that I use custom datasources and on the original site they work... but haven't had success in copying it to the new one.
I am working on a project that is replacing an old portal system (Plumtree) with sharepoint and we want to make the transition as smooth as possible.
One thing we are look at currently is taking all the gadgets (Plumtree term for WebParts) and making sure they appear in the same place on the users new MySite.
Plumtree holds this information in a simple table containing the user, page, gadget and position information. I want to find a way to automate reading this table and putting the new WebParts on the users MySite and not have to manually set it up for hundreds of users.
I'm told modifying Sharepoint tables in SQL Server directly is not a good option as it may affect our support arrangements, but if it saves doing this by hand then I would concider it.
Other options that spring to mind are creating a equivalent table and using API calls to load the WebParts the first time the user accesses their MySite.
Any better suggestions?
You are right, messing directly with databases are not supported nor recommended.
Unfortunately, there are not much ways to modify MySites, the best way I know come from the MOSS Team Blog: http://blogs.msdn.com/sharepoint/archive/2007/03/22/customizing-moss-2007-my-sites-within-the-enterprise.aspx
The way we did it was pretty much what is described in the link above (http://blogs.msdn.com/sharepoint/archive/2007/03/22/customizing-moss-2007-my-sites-within-the-enterprise.aspx).
Your best bet is probably to staple a Feature to MySite creation and have it poll the plumtree database, find the gadgets for that user, and add a 'Page Viewer' web part for each, pointing to the gadget's location. That said, you may want to reconsider blindly migrating all your plumtree gadgets into SharePoint. There may be much better 'SharePointy' ways to provide the functionality that your gadgets are currently providing.