People picker not working in classic mode web application in SharePoint 2013 - sharepoint-2010

I have a SharePoint 2010 web application migrated to SharePoint 2013. this is a classic mode web application, we are not using claims, my client doesn't wants it ( Don't ask why?).
I had other web application migrated as same process but i can add users in them.
but in this i am not able to.
I can add users and find users in the web application in central administration. But not in the web application itself.
I am not sure what changes i have to make so that it starts picking or finding users from the people picker. any ideas.

it was because of the asp.netvalidation=2.0 not present in the httprequest line in webconfig. there was no validation for the input provided in any input box.
once we added the asp.net validation it worked fine.

It is a browser compatible issue as well whereas in new browser like IE 10 and other latest browsers it doesn't play well.
we updated the
In short the fix is to edit the pickerdialog.master file in notepad and add a meta data tag, , to the header section.
well keep in mind always save a local copy of your original master page.
it is recommended not to update any original files, we can run the site in compatible mode too.

Related

OData REST API for integrating MS Office

I need to open office documents from my Sensenet client application. My client application is in ReactJs and I need to invoke the document to open in MS office. Is there any OData REST API available for doing the same. Kindly help.
You have two options:
1. open a file in a desktop MS Office application
There is an action in sensenet that gives you the url for that. First, get the actions for a document, using a request like this:
https://example.com/odata.svc/Root/Content/myworkspace/Document_Library('abcdef.docx')/Actions
You'll get the list of available actions, which is a JSON array containing action properties, for example a url. Look for the action named EditInMicrosoftOffice. If you display the URL of that action and the users clicks on that link, the browser should open the appropriate desktop office app (e.g. Word). You may notice that the format of the url is special (something like ms-word:ofe|u|https://example.com/Root/...). Please do not try to assemble this url manually, use the one that sensenet generated for you.
2. open and edit a file in the browser
This requires Office Online Server to be installed and configured in your environment, and you also need to display an html containing an iFrame that'll display the editor.
A simple host page:
https://wopi.readthedocs.io/en/latest/hostpage.html#host-page
Geting data to display the host page:
https://example.com/odata.svc/Root/Content/myworkspace/Document_Library('abcdef.docx')/GetWopiData

Adding a Sandboxed app to Login Items

I have read through many questions here about launching my app on login. I have followed this awesome tutorial suggested many times. That tutorial does work. BUT...
The one side affect that comes from using a helper app and registering it using SMLoginItemSetEnabled is that my app does not show up inside the user's Login Items in System Preferences.
There are several apps in the App Store (such as PopClip and Dash) that do what I am trying to do. I just can't figure out how...
UPDATE: I found out from the Dash developer that Dash is actually not sandboxed. He also believes that PopClip is not either. This could explain things... https://alpha.app.net/kapeli/post/3975968
UPDATE #2: I just got confirmation from the PopClip dev that it indeed is not sandboxed as well. https://twitter.com/pilotmoon/status/313746294361427968
With the last 2 updates, I guess the answer is clear. As of today, there is no way to accomplish this with Sandboxed apps.
Hope it's not too late.
In Apple's "Daemons and Services Programming Guide":
Adding Login Items
There are two ways to add a login item: using the Service Management framework, and using a shared file list.
Login items installed using the Service Management framework are not visible in System Preferences and can only be removed by the application that installed them.
Login items installed using a shared file list are visible in System Preferences; users have direct control over them. If you use this API, your login item can be disabled by the user, so any other application that communicates with it it should have reasonable fallback behavior in case the login item is disabled.
In sandboxed environment, only Helper applications can be installed in login items. You need to create one, stored in the Contents/Library/LoginItems folder of the main application.
Then you can used SMLoginItemSetEnabled to set the helper as login item and ask the login item to start the main application.

When export/import a site in sharepoint 2010 (WSS), error occur "A Web Part with this ID has already been added to this page"

I have a webpart, and I insert that webpart into a site of Sharepoint 2010 (WSS).
I save a site as template by that site. After, I create a new site with that site template. I export this site, and after I import it. I see a error in import site:
"A Web Part with this ID has already been added to this page".
Please help me to fix it.
(It work well on MOSS 2010)
Is new site is on the same farm as the originating site?, I would also asume that this is a Team site with Publishing features or a publishing site al togethere right?, if so, basically is having a conflict of GUIDS for a particular web part within a page or layout. If you see most of the site comming up, then is easier, because you could open the page or layout using SPDesigner and change the guids of the added webparts on the page; if not, you might need to crack open the template file and do it there.
Changing the GUIDS might help you to bring the page up, however any change done of the front-end could reverse the changes, so the best option is to edit the page and re-add the web parts, so it takes a new GUID for good.

Cannot see "Custom" web part folder SharePoint 2010

I am new on SP 2010 and VS 2010.
After installation of SP, I am able to surf to localhost, and see a page called "Home".
I made a test Visual Web Part, and it deployed fine.
I am able to edit the home page, and see and add the web part from the Custom folder.
I then made a new site, called Foo Site. When I edit its home page, I do not see the web part Custom folder, so I may choose my web part and add it.
Why does the Custom folder show up on one page, when adding a web part, and not on another?
Did you activate the feature on your new site? When you deploy from Visual Studio it will automatically do this based on where your project is configured to deploy it to (which is why you see it on your original site).

SharePoint 2010 FBA with custom form - 403 error

I have a SharePoint 2010 site that is configured for Forms Based Auth using custom role, membership and profile providers. This works perfectly using the OOTB SharePoint 2010 FBA form (ie. under /_forms in the web app virtual directory).
My problem is with a custom login form that is located in a separate folder, /Landing/Login/default.aspx. I've configured the web app to point to this form (contains an unmodified ASP.NET login control), which is rendered when the user hits the root URL. The problem comes when they submit their credentials and the form posts back for the redirection to /_layouts/Authenticate.aspx. It stops cold with a 403.
If I revert back to the OOTB FBA form (using the same providers) everything works fine. Any suggestions on what could be going wrong?
So, I discovered the solution after examining the OOTB FBA login form that inherits from Microsoft.SharePoint.IdentityModel.Pages.FormsSignInPage and taking a look at the code with Reflector.
I modified my custom form to inherit from the same object and replicated the content placeholders (some I put into a panel control with the visibility set to false) from the OOTB Form.
Presto. My custom form now authenticates flawlessly. On reflection, this seems an obvious thing to do, just isn't documented anywhere.
I just went through this process myself, and wrote up the steps I had to take to get FBA working with a custom login form. Hopefully it'll help the next poor soul that is trying to get this to work.
http://mikevallotton.wordpress.com/2010/10/18/sharepoint-2010-claims-authentication-custom-login-form-2/
If you want to use ready-made solutions for the management of FBA users, you should take a look here:
http://www.devit.eu/products/121-fba-manager-sp2010-forms-based-authentication.aspx