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.
Related
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.
I am an experienced .NET Developer acting as interim SharePoint Developer, and am new to SharePoint. After determining that I need to go with an application page instead of a site page for a new project due to it's complexity and need of custom code behind. Before developing the entire solution, I wanted to tie up the loose ends of my understanding of application page deployments. I need to add this page as a URL on the left side of a Site Collection page (kind of like what happens when adding a subsite to a site page.) I have read about the modules, which seems extremely hacky to me. There must be a better way to develkop a custom page on top of SharePoint without the page being accessible to anyone on the entire site.
EDIT
The application I am wanting to develop on top of SharePoint exists purely for data entry and reporting purposes.
Have you considered using a Webpart?
With a visual webpart which is essencially a usercontrol wrapped in a webpart you can add as much complexity as you want and you also have code behind to hook to events etc.
The benefit of using a webpart is that you can then drop it on a page, and use all OOB sharepoint access controls.
You mention that you want to develop a data entry reporting app. So something you can do is to create a subsite. Look all access to modify pages except to owners. Create all your screens by adding pages to the subsite and dropping webparts on it with the logic you require for each screen.
Also make sure you deploy the werbparts via a web feature that only is activated in your subsite, this way the webparts are only available in that particular subsite.
this seems to be a bit of an odd requirement, but we have a separate form (not an infopath form) being filled out by people. Now, this form that we have has quite a lot of validations in it. We're currently trying to prevent people from accessing the list where this certain form is saving the data, this is so that they won't bypass the validations we created in the form that we created. Is there a way to be able to do this, one way or another?
Easy fix. Use SharePoint Designer to browse to the list, starting from "All Files". The list has several files in it. You're only interested in NewForm.aspx and EditForm.aspx.
Open these files. Either add JavaScript redirect code directly to the file (near placeholdermain) to point back to AllItems.aspx, or add a Content Query Web Part to add the redirect JavaScript code in that added web part.
Either way, when users go to add/edit items in that list, they will be bounced back to the page that list the items.
This will only work when JavaScript is enabled. Mind you, SP won't work very well with JavaScript off anyway, so people may not disable JS. But for a bullet proof solution, make a Visual Studio feature for the specific list.
I am developing a sharepoint 2010 project.
I want to restrict users view on lists based on their identity. (e.g. the branch of organization they work in, but in fact the ristrictions can be more complicated).
What solutions do you recommend?
With out of the box features this is not possible. You can go to great lengths to remove the list's view selectors and other navigational elements that let people cruise around a the schema and metadata for a list but it is not a security mechanism.
If a user has read permissions to an item, they'll have read access to all the fields of that item.
There is an outside chance that it you disabled all RPC mechanisms, SOAP, RESTful web services, Client Object Model and the office clients that you might be able to claim this as a security mechanism. If you don't there will always be a way around your "security" scheme.
This feature can't be implemented by SharePoint by now and I think neither for the next version
You can use a third part tool to achieve it, such as BoostSolutions' Column/View Permission or LightningTools' DeliverPoint
BTW, I work for BoostSolutions and I mentioned our own product because it works for your issue. Hope it helps :)
create sharepoint groups based upon your requirement or diffrent type of user base and accordingly give them rights may be item level or on complete list
and while doing these things just go through the following posts
http://blogs.gartner.com/neil_macdonald/2009/02/25/sharepoint-security-best-practices/
http://weblogs.asp.net/erobillard/archive/2008/09/11/sharepoint-security-hard-limits-and-recommended-practices.aspx
Not 100% sure on SharePoint 2010, but definitley for SharePoint 2007, there is not a way to do this, especially if the views are corresponding to security requirements on the columns users are able to see.
One way to work around this is have the list be not accessible by users, and then have code logic allow for access to the data creating the different "views" on the data in something like a Web Part. The downsides to this is search becomes an issue (since the data is hidden) and having multiple "views" of the data (if necessary) is also another item to work through.
I know its a very old question but posting it as it might help someone.
There is an work around to do it as described here
I find it easier, if possible, to create the view and lock it with the filters on the list settings page.
For example, I have a list of employees that includes their employee IDs. I use that list on other pages to gather data in other webparts. So I filter the employee list to [ME]. So the data is available to the page needing it to filter others and they cannot see anything else.
Now, what about the person who needs to manage that page? I create a view, call it HR. That view can see everything. Then I export that webpart with that list view on it through the designer. I then delete the HR view from the employee list.
This leaves no way for anyone to switch views and see everything again. I create a webpart page for the person who manages it, and I upload that webpart and set the view of the webpart to HR. In the end, I have a page that I lock down instead of trying to lock down views or list permissions separately.
Would you be able to have two lists that are joined. One that all users have access to and another that only certain people have access to, and then join them? Then maybe the people that don't have access to the other table it doesn't pull the information? Not sure, but I'll try that out later today.
I am new to SharePoint development. We have created a base site template and have used that template to start new sites in other locations on the same server. This works fine but the newly created site seems to "flatten" the custom content types created in the original site. I would think there would be a way to keep the original content type inheritance intact to help support any necessary modifications on the new site. They can still make the modifications but they take longer because you have to visit each list individually. Does anyone know how to fix this or know a better way to approach this?
The problem you are having is the move from your original site collection to another. The site template does not store the complete definition of a site - only the differences from the underlying site definition. Move from one site collection to another and you lose the underlying site definition and run into problems such as the loss of your content types.
Site templates and site definitions are two separate customizations you can undertake. You need to make a decision based on your requirements as to which is best.
Site templates
Pro's:
Easy to create and reuse through the SharePoint interface
Ideal for end users
A site template is a customization of the underlying default site definition
Con's:
Dependency on underlying site definition means SharePoint updates could break your site templates
Poor performance since the modifications are held in the database and are read from the DB and compiled on each request
Limited customization options
Site definitions
Pro's:
Harder to create: involves coding XML
Made by developers and site administrators
Independent of SharePoint default site definitions so not affected by SharePoint updates
Limitless customization options
Con's:
Difficult to modify when deployed
Can be cached on the file system so is fast to load
Check out Google for info on creating custom site definitions.
Hope this helps!
Jonny
The best way to do this is to create a site definition where the content types are within features whose scope is to the farm.
Tim