I've got a custom webpart in Sharepoint 2007 that works when used on the same machine sharepoint is installed on. When I browse to the page from a remote machine, the webpart renders but when you click the submit button, I get redirected to /_layouts/login.aspx?ReturnUrl=
Does anyone have any idea what is happening, or what I should do?
You can view the setting to enable annymous access here:
http://office.microsoft.com/en-us/windows-sharepoint-services-help/enable-anonymous-access-HA010113018.aspx
Related
Hy,
I use SharePoint Foundation 2010 and I learned that the "target audiences" are disabled on the Foundation version.
I need to customize a WebPart on a wiki page when A user of a certain group is connected.
Have you an idea ?
Thanks
Sam
Alternatively you can add a new web part page in your SharePoint site
and then add this Documents web part on the page. Once it is done,
Give access to only intended users for this page. Which means control
access at page level.
source
I have found a solution.
I insert JavaScript code in a WebPart in my wiki page from my SharePoint.
Ive been having a problem with a webpart in a sharepoint (moss 2007) site.
Basically I cannot remove the webpart, every which way results in an error and we cant get rid of the darn thing.
Unfortunately SharePoint designer errors out as wel when I try to remove the webpart manually from Default.aspx (its only on the homepage).
Is there anyway without SharePoint designer I can gain access to the Default.aspx file so I can manually remove the webpart?
Someone mentioned default.aspx doesnt actually exist and is generated at runtime? Is this true and if so does anyone know where in the moss database I could gain acces to the table(s) that build up the default.aspx or where the webpart refs are stored for manual removal?
Thanks all!
you can try adding ?contents=1 at the end of your URL page. for example:
http://myserver/Pages/default.aspx?contents=1
this will bring you to a "Web Part Page Maintenance" page where you can checkout the page itself and remove/disable web parts.
I have VS 2010 installed on the same VM machine as my sharepoint 2010 server that I remote into. When I create a simple webpart and click "run", it appears to compile and deploy the webpart with no problems, and opens up http://[sharepointserver]/SitePages/Home.aspx.
In the demos I have seen, I expected to see my webpart page. So, I click on "edit" > "Insert" > "web part" > "custom" > choose my webpart.
Then my http://[sharepointserver]/SitePages/Home.aspx shows the webpart.
HOWEVER,
When I access that same url from my local machine (not remoted into the VM), I don't see the weppart on that page at all. I click refresh, and the webpart debugger indicates webpart pass-through activity, but the page is the standard "welcome to your site!" page.
Do I need to explicitly "deploy" this? It's confusing since they are the same url, being accessed from two different contexts (browsers).
When you edited the page and added your web part, did you save it and check it in?
So i just started trying to develop a simple webpart today for a sharepoint foundation i put on a virtual machine. I have no previous experience with sharepoint whatsoever.
As i cant run a sharepoint 2010 on my local machine for dev purposes i followed advices in this thread http://social.technet.microsoft.com/Forums/en/sharepoint2010programming/thread/cda807f6-4edf-4efc-8e9b-4d446356c8ae to able to actually develop something (just the registry bit).
I created the simple test web part (writes out "hi"), uploaded it to virtual machine, added it with add-spsolution and install-spsolution in powershell with success. When i do get-solution through powershell on my webpart it says deployed = true.
What am i missing from here to get it to actually show up somewhere in the web interface so i can add it to a page?
Cheers
You need to go into site settings and activate the feature. If its already activated edit the page > Insert WebPart > Look under Custom to find your webpart.
HTH
I’m trying to publish an InfoPath form to a SharePoint document library, and have the form be viewable in a web browser.
The problem is that in the InfoPath publishing wizard tells me that although the form is browser compatible, that it cannot be browser enabled because of one of the following:
The Server is not running InfoPath forms services
The necessary features are not available on the site collection
The policy setting on the server does not allow a user to browser enable forms.
Well, I’ve verified that the SiteCollection has an active feature called “Office SharePoint Server Enterprise Site Collection features”, which includes Form Services, so I assume that the first two issues are not the cause
Also, I’ve verified in Central Admin that the Forms Services are configured to allow browser-compatible forms to be viewable in the web browser. So the 3rd reason doesn’t seem to make sense either.
I've tried applying different Security levels to the form: Restricted/Domain/Full Trust, but that doesn't seem to have an effect. I have been able to publish this form to a different SharePoint site, so I'm assuming that the issue is with the configuration of the SharePoint site, not the InfoPath form
Does anyone have any other ideas as to why this might not be working?
Thanks for any help you can provide!!
Make sure in the Form Lib Advanced Setting section you have the Option "Display as a Web page" is set "Opening browser-enabled documents"
Try testing the XSN file against the MOSS server by copying the file to the server itself (c:\temp for example) and running the following command:
c:\temp> stsadm -o verifyformtemplate -filename myform.xsn
The tool STSADM.EXE sits in %programfiles%\common files\microsoft shared\web server extensions\12\bin so add this to your %PATH%.
Post the answer back here if it still baffles you.
Besides the recommendation from #x0n to check if directory has been allocated as usable, check the event viewer and see if anything is showing.
As a stupid but check item go to:
Central Administration > Operations > Convert License Type
and ensure that you have the enterprise Client access listed.