This will be a very short post following one of my previous posts about the Office Graph and the GQL. I have taken most of the code there and put it inside a SharePoint Hosted App.
The App queries the Office Graph for the colleagues with whom you closely work with and displays them. Basically, it does the same thing which you see on the left hand side when you log in to Delve. This app can be a good starting point if you want to further develop apps which consume the Office Graph API. You can pick and choose the Delve elements which you want in your app. Also, you can create customized scenarios which leverage the Office Graph and deliver them as Apps for SharePoint.
Since the App requires Search permissions to be granted in the AppManifest, you will need to have the Tenant Admin credentials to install the App. I think this might be a blocker for some people in installing the App. Now fortunately, if you just want to test the functionality out, you can take all the code in the App.js and run it from inside a SharePoint Online page. You do not need tenant admin permissions to execute the code in the page.
This App will only work in SharePoint Online (Office 365) as there is no Office Graph for SharePoint On-Premises at the moment.
The code for the App is part of Office Developer Patterns and Practices repository and is available here:
https://github.com/OfficeDev/PnP/tree/dev/Samples/OfficeGraph.Demo.App
Showing posts with label Apps. Show all posts
Showing posts with label Apps. Show all posts
Saturday, 3 January 2015
Saturday, 13 September 2014
Deploy Workflows to Host Web with Integrated Workflow Apps
Update (19/08/2015): Integrated Workflow Apps are now part of Visual Studio 2015. You do not need to manually edit any XML files now. You will just need to:
1) Use Visual Studio 2015 (I was using the Enterprise version)
2) Create a SharePoint App (Add-In as it's now called)
3) Add a Workflow to your Add-In Project. (Your Add-In cannot be an Integrated Workflow Add-In unless there is a Workflow in it)
4) Go to the Project Properties and set the "Integrated App" property to True. That's it!
Original Article:
In the recent Office 365 Developer YamJam on the Office 365 Technical Network, there were lots of great questions asked to and answered by the Office 365 Engineering Team. You can view all the questions over here: https://www.yammer.com/itpronetwork/#/threads/inGroup?type=in_group&feedId=4419638
One thing which I was interested in was the Integrated Workflow Apps. I have seen a lot of people ask about this as they want to deploy Workflows to their Host Web (or Content Site) from their Apps. I had known that something was in the pipeline as I had seen a glimpse of it in this video from SPC 2014 http://channel9.msdn.com/Events/SharePoint-Conference/2014/SPC3994
Luckily, Tim McConnell who is the speaker in the video was part of the YamJam and he answered that Integrated Workflow Apps are already available on SharePoint Online but they are waiting for tooling support so no official announcement has been made till now.
I have tested them on my development Office 365 Tenant and it works! In this post, I will be detailing the process by which you can get it working too.
You will need to have installed Visual Studio 2013 and Microsoft Office Developer Tools for Visual Studio 2013 for this. My test project is available on GitHub here: https://github.com/vman/Integrated-Workflow-Apps
1) Start Visual Studio 2013 > New Project > App for SharePoint
2) Enter the SharePoint Online Site Url and select the hosting model for your app. I have selected SharePoint Hosted.
3) Right Click App Project > Add > New Item
4) Select Workflow and type in a name for your Workflow
(Click on the Image to Zoom)
5) Select the type of Workflow as Site Workflow
(List Workflow Deployment is shown at the end of the post)
6) Select "Create New" for History List and Task List.
7) Add some sample activities to your Workflow.
I have added a LookupWorkflowContextProperty to get the current Site Url and a WriteToHistory activity which will write the Current Site Url to the History List
(Click on the Image to Zoom)
(Click on the Image to Zoom)
8) Give your App Manage Permissions on the Web:
9) Right click App Project > Publish > Package the app. A window will pop up showing you the packaged .app file.
(Click on the Image to Zoom)
10) Now the interesting part. Open the .app file as an archive with a tool of your choice.
I have used 7-Zip which is a really awesome tool. You can download it from here: http://www.7-zip.org/
(Click on the Image to Zoom)
11) Once opened, look for the WorkflowManifest.xml file and open it. It will be empty to start with. Copy the following in the file and save it.
(Click on the Image to Zoom)
12) After Clicking save, you will get the following prompt. Click Ok.
13) Now your .app package is ready to be deployed to your App Catalog. Go to your App Catalog and upload the .app file in the "Apps for SharePoint" document library.
14) Once uploaded, go to your Team Site > Site Contents > Add an App > Select your app and add it to your Team Site.
15) You will be prompted to trust your App. Click on "Trust It".
16) Once the App is installed on your site, go to Site Contents > Site Workflows
17) Click on your App to see your Site Workflow deployed on the site. Click on the Workflow to start it.
(Click on the Image to Zoom)
18) Let the workflow complete. After it has completed, click on the Internal Status to see what the workflow logged to the History List
(Click on the Image to Zoom)
19) You can see that the Workflow logged the url of the Team Site on which it was running.
(Click on the Image to Zoom)
This proves that the Workflow was deployed to and ran on the Host Web (Content Site).
Deploy List Workflow:
The process to deploy the list workflow is quite the same except in step 5, select List Workflow.
Do not associate your workflow to any List. We will do the association after the deployment of the Workflow.
Select when you want your workflow to start.
Add a Sample Workflow Activity in the Workflow to Log the Current List Name and the Current Item Url:
Steps 8 to 15 are the same as for a Site Workflow. After the Workflow is deployed, Go to a list > List Settings > Workflow Settings > Add a Workflow
Click on your App, Associate your Custom Workflow by giving it a name and configuring other settings. Click on OK.
After you associate the Workflow, Start it either manually, or create an item, or update an item depending on the method you selected in the Workflow Designer in the App.
After the Workflow Completes, Click on the Internal Status to see what the Workflow Logged to the History List:
Thursday, 14 February 2013
SharePoint 2013: Provision AppPart/ClientWebPart to Page
Along with Apps, SharePoint 2013 has introduced App Parts (ClientWebParts) which give you the functionality of placing the app inside and iframe on a page. This way, you can view your app as a part of the page just like you would a normal webpart.
(The terms App Part and Client Web Part are interchangeable. I will be using both the terms in this post to emphasize the similarity)
Adding an App Part to the page from the SharePoint User Interface is pretty easy. You just put the page in edit mode and add the AppPart from the Insert Menu. Pretty similar to how you would add a regular WebPart.
Now what if you have to provision your AppPart in a Page or a PageLayout so that when a new page is created with a feature, your AppPart is automatically placed on that page?.
If you want to know how to add an app part to a page declaratively through the Elements.xml file, please have a look at my post here:
http://vrdmn.blogspot.in/2013/03/sharepoint-2013-declaratively-add-app.html
Lets look at how it can be done:
First and foremost, you will need to create an AppPart (Client WebPart) for your app. Here is a great tutorial on it:
http://msdn.microsoft.com/en-us/library/fp179921.aspx
Your Client WebPart xml file should be similar to this:
Here, I have created a Client Web Part with 2 Properties of type int and enum respectively.
Second, you have to make sure that your app is already installed on the Web on which you will be provisioning your page. The AppPart will only work if the app is installed on the same web.
Next, you will need the ProductId of your app. Here is how to find it:
1) Open your app in Visual Studio -> Right Click on the AppManifest.xml -> View Code
3) Save your ProductId in a convenient location.
4) Now open your Page or Page Layout and add the following code to it:
In FeatureId, enter the ProductId which we got from the app earlier.
In ProductWebId, create a new random GUID and add it.
You can even set default values for the App Part Properties.
5) That's It, Now deploy your page and see that the App Part is Provisioned on the Page.
(The terms App Part and Client Web Part are interchangeable. I will be using both the terms in this post to emphasize the similarity)
Adding an App Part to the page from the SharePoint User Interface is pretty easy. You just put the page in edit mode and add the AppPart from the Insert Menu. Pretty similar to how you would add a regular WebPart.
Now what if you have to provision your AppPart in a Page or a PageLayout so that when a new page is created with a feature, your AppPart is automatically placed on that page?.
If you want to know how to add an app part to a page declaratively through the Elements.xml file, please have a look at my post here:
http://vrdmn.blogspot.in/2013/03/sharepoint-2013-declaratively-add-app.html
Lets look at how it can be done:
First and foremost, you will need to create an AppPart (Client WebPart) for your app. Here is a great tutorial on it:
http://msdn.microsoft.com/en-us/library/fp179921.aspx
Your Client WebPart xml file should be similar to this:
Here, I have created a Client Web Part with 2 Properties of type int and enum respectively.
Second, you have to make sure that your app is already installed on the Web on which you will be provisioning your page. The AppPart will only work if the app is installed on the same web.
Next, you will need the ProductId of your app. Here is how to find it:
1) Open your app in Visual Studio -> Right Click on the AppManifest.xml -> View Code
2) Here you will find the ProductId of your app in the following location:
4) Now open your Page or Page Layout and add the following code to it:
In FeatureId, enter the ProductId which we got from the app earlier.
In ProductWebId, create a new random GUID and add it.
You can even set default values for the App Part Properties.
5) That's It, Now deploy your page and see that the App Part is Provisioned on the Page.
Tuesday, 29 January 2013
SharePoint 2013: Elevate User Access with App Only Policy
In SharePoint 2013 Apps, the authorization is handled by a 2 part mechanism. Along with the current user's permissions, the app permissions are also taken into account. User permissions and app permissions are two separate entities which dictate whether an app is allowed to perform a certain action.
When you build an app, you can specify that what all permissions are going to be required for the app to run successfully. You have to specify this in the App Manifest under the Permissions tab.
(Click Image to Zoom)
When a user installs an app, he can only grant permissions to the app up to the level which he has. So if a user has "Read" permissions on a list, he cannot grant the app "Full Control" on the same list.
There are basically 3 types of app authorizations or authorization policies in SharePoint 2013.
1) User Only Policy: In this policy, only the user permissions are taken into account. App permissions are ignored. It is checked whether the user has the permissions to perform the action and if yes, then he/she is allowed to perform the action.
2) App + User Policy: The user as well as the app permissions are taken into account. This is an AND operation. If both the user and the app have the permission to perform the action,only then the action is allowed.
3) App Only Policy: Only the permissions granted to the app are taken into account. User permissions are ignored. So even if the current user accessing the app does not have appropriate permission, the action is allowed provided the app has the permission to do so.
The App Only policy works by using a separate OAuth token which runs under the user "SHAREPOINT/App" much like SPSecurity.RunWithElevatedPriviledges() runs under the "SHAREPOINT\System" user (app pool account) in the Server Object Model.
To enable the App Only policy in your app, you have to add the "AllowAppOnlyPolicy" attribute to your "AppPermissions" element in the App Manifest:
Enough chit chat, lets see how we can actually utilize the App Only policy to elevate user permissions. I have written the following code in the code behind of the Default.aspx of an Auto-Hosted App:
As you can see, the ClientContext which is opened with the appOnlyAccessToken will run with the identity of the SHAREPOINT\App account. This is a very good practice to remember even when using RunWithElevatedPreviledges in the Server Object Model. You can switch on/switch off database calls with app only token. This means that if you need to make only one operation with the elevated token, then you can do that and get back to using the current user's token in one action.
When you build an app, you can specify that what all permissions are going to be required for the app to run successfully. You have to specify this in the App Manifest under the Permissions tab.
(Click Image to Zoom)
When a user installs an app, he can only grant permissions to the app up to the level which he has. So if a user has "Read" permissions on a list, he cannot grant the app "Full Control" on the same list.
There are basically 3 types of app authorizations or authorization policies in SharePoint 2013.
1) User Only Policy: In this policy, only the user permissions are taken into account. App permissions are ignored. It is checked whether the user has the permissions to perform the action and if yes, then he/she is allowed to perform the action.
2) App + User Policy: The user as well as the app permissions are taken into account. This is an AND operation. If both the user and the app have the permission to perform the action,only then the action is allowed.
3) App Only Policy: Only the permissions granted to the app are taken into account. User permissions are ignored. So even if the current user accessing the app does not have appropriate permission, the action is allowed provided the app has the permission to do so.
The App Only policy works by using a separate OAuth token which runs under the user "SHAREPOINT/App" much like SPSecurity.RunWithElevatedPriviledges() runs under the "SHAREPOINT\System" user (app pool account) in the Server Object Model.
Since OAuth is required to generate the app token, the App-Only policy can only be used in the Auto-hosted and Provider-Hosted apps. SharePoint-Hosted apps cannot use the app only policy.
To enable the App Only policy in your app, you have to add the "AllowAppOnlyPolicy" attribute to your "AppPermissions" element in the App Manifest:
Note: Although you can add this attribute to the App Manifest of the SharePoint-Hosted apps, it will be ignored as the App Only policy is not supported in SharePoint hosted apps.
Enough chit chat, lets see how we can actually utilize the App Only policy to elevate user permissions. I have written the following code in the code behind of the Default.aspx of an Auto-Hosted App:
As you can see, the ClientContext which is opened with the appOnlyAccessToken will run with the identity of the SHAREPOINT\App account. This is a very good practice to remember even when using RunWithElevatedPreviledges in the Server Object Model. You can switch on/switch off database calls with app only token. This means that if you need to make only one operation with the elevated token, then you can do that and get back to using the current user's token in one action.
Subscribe to:
Posts (Atom)