App-only policy in the SharePoint App Model is very restricted regarding Taxonomy operations. Even if an app is granted full control over the tenant, it lacks the permission to do anything but read operations on Taxonomy. Please provide the ability to create Groups, Term Sets and terms using app-only policy.126 votes
Possibly by allowing the user to enter an app name upon granting permissions.
This will allow users to grant read/write permissions against two or more lists on a site.
This means, when designing apps they would be able to function more like OOB lists or libraries; with either extended functionality or be deployed in conjunction with a Client App Part to provide client functionality.
An Example of this might be a "Rotating Image Gallery" app. Allowing multiple of these to be deployed to the same web is ideal, with independent permissions and content.44 votes
Currently if you implement site provisioning solution and you need to install some third party known app, you should activate side loading feature that is not recommended for production(by security reasons) and use method load and install.
this way has several disadvantages:
1) Customers will afraid such solution because of recommendations outlined above.
2) Upgrade process. it will "painfully" to upgrade each package on each site
3) You need an app package file to get file stream for LoadAndInstall method40 votes
This applies to SharePoint Online in Office 365. We'd like to move over to using OAuth in our app that integrates with Office 365, but there is one blocker we cannot get around. We need to fetch users' PersonalUrl, which works fine when using regular credentials/a fedAuth cookie. Calling the https://siteurl/_api/sp.userprofiles.peoplemanager/getpropertiesfor(@v)?@v='i:email@example.com'&$select=PersonalUrl,DisplayName endpoint when using a valid OAuth bearer token results in a 401 Unauthorized error. Since we're only testing OAuth at the moment I went ahead and enabled all permissions for my app in the Azure management portal, so that's not the issue.38 votes
As a Sharepoint Developer I have used a lot the chrome control in Sharepoint Apps, however with the new App Launcher and My Apps Page, I would suggest that Microsoft creates an "app launcher chrome control", a piece of code we can "copy/paste" in our webforms/mvc/js apps that will show automatically the Apps Launcher.
I believe this will be a great way to navigate between LOB Apps that we create in the Offce 365 Platform.
Thank you38 votes
Currently when you deploy an App, any instances of the App will not upgrade until manually done via User Interface. It would be great to be able to Upgrade the App in the App Catalog from the Store or via Side Loading and it upgrade all instances at once.33 votes
It is extremely difficult to install Apps to run on-premises right now. It is also very hard to troubleshoot the installation if it goes wrong. This is a weakness that the average IT Pro is having problems with from my experience. On-Premises is not going away anytime fast. The steps to deploy Provider Hosted Apps is very complicated and requires a unique App Package per Tenant due to how it has been architected. Auto-Hosted is not supported either which has caused design decisions up front in many cases to support both Online and On-Premises.29 votes
I've a simple Sharepoint Add-In on O365 Store and some users notice app update failure with following message: "The operation took too long". It's random issue on some O365 tenants that causes very serious issue: when update fails, app cannot be used anymore and both app provider and app user cannot do antything to solve it! After submitting ticket request for Microsoft support team to solve particular issue, they say that it's not Microsoft problem.... This issue makes Sharepoint Add-Ins "children's toy", instead of stable and reliable solution.1 vote
- Don't see your idea?