Saturday, August 6, 2016

SharePoint 2013 App domain for this site has already been assigned

When deploying a SharePoint 2013 add-in (or app) from Visual Studio, we may get the following error:


ErrorDetail: The content database on the server is temporarily unavailable
ErrorType: Transient
ErrorTypeName: Intermittent
ExceptionMessage: The App domain for this site has already been assigned

This error is usually a result of an add-in prefix update on the farm.  When we configure the on-premises development environment for SharePoint add-ins, we need to provide a prefix to our apps. This prefix is used as a subdomain name for the app.

Domain
Description
ozkary.com
Domain name
app.ozkary.com
App subdomain name. app is the add-in prefix that was configured on the farm.

Set up SharePoint on premise development environment


https://msdn.microsoft.com/en-us/library/fp179923(v=office.15).aspx



Solution
To solve this problem, we need to make sure that the service returning this error is re-started after making the prefix change. If we are sure that our prefix is correct (see the URL on the browser when loading a different app from SharePoint), we just need to restart the service. Otherwise, run the command (PowerShell) to update the prefix and re-start the service as shown in the next steps:
Update the add-in prefix
This is the command to update the add-in prefix (SharePoint Management Shell). Notice the word “app”. This is the prefix.

Set-SPAppSiteSubscriptionName -Name "app" -Confirm:$false

Re-Start the service
These are the commands to re-start the service (stop/start). Run this command from the windows command shell (use Run as Administrator).


net stop sptimerv4

net start sptimerv4

Provided that there are no errors, we should be able to go back to Visual Studio and deploy the app.
Originally published by ozkary.com


Sunday, July 24, 2016

AngularJS SPA Controller Claims Authorization

Overview
In a previous article, we discussed the use of directives to enable claims based authorization on the user interface elements. For some scenarios, we notice that a directive can have performance issues as it is called everytime is declared on the mark-up. For the cases where there is an ngRepeat, this can lead to many calls depending on the size of the collection.

With the auth directive implementation, we notice on the browser console the number of times the directive is called.  This lead us to explore other options with better performance, and that also can provide the same results. With that in mind, we now take a look a providing claims authorization with controller only implementation.
Security Service
This service has a simple implementation in which it checks if a particular claim already exists for the current user by managing the claims information as a property. This service is injected into the controller with the purpose to manage the validation of the claims for the user. The controller sets scope variables which can then be used on the view to enable some of the user interface behavior like hiding elements for which the user has no permissions.
spa-auth-controller.png

Controller Implementation
If we look at the mark-up for the delete and edit buttons, we notice that we could manage the visibility of those controls by using the ngShow native directive. In addition, we need to have some controller variables which can be watched by Angular to enable the behavior. We can now take a look at the implementation details with the following JSFiddle.

On the JavaScript tab, we can see our controller implementation.  We are creating a controller variable for each of the claims that we need to validate (claimMapping). To figure out the if the claim is available, we pass the claims tags to the $svcAuth service which verifies if the claims  exists by calling hasClaim.  
The state of each variable is set by calling claimResuts. If the claim exists for the user context, the associated element is displayed. Otherwise, the element is not shown. We also need to track any changes on the claims, so we need to add a $scope.watch to evaluate the existent of our claims as we remove or edit them. Note that this watch is only added here to demo the behavior of editing the claims. On a live system, this would usually happen only when the user logs out as this resets his security context.
On the HTML tab, we only need to add the ngShow directive with the corresponding controller variable. For the the delete button, we use the ctrl.deleteAccess variable. For the edit button, we set the directive to the ctrl.editAccess variable.
Does It Work?
To check that this is working properly we can run a simple test. Run JSFiddle and delete both app.edit and app.delete claims. These should essentially remove all the icons on our list as shown below:
Areas of Improvements
This implementation was a lot simpler than having to use a directive, but it also has a big flaw. We can imagine an app with several controllers, and we need to do implement the claim validation logic in many of them. For those cases, we definitely would like to use some reusable component instead of adding the same code on the controller.  When the view has multiple elements like menus  and each menu has an independent claim/permission, we probably want to use the auth directive. For cases, when multiple elements are controlled by the same claim, we may just want to use the auth isolate directive.

Originally published by ozkary.com

Sunday, July 17, 2016

AngularJS SPA Isolate Scope Directive Claims Authorization

Overview
In a previous article, we discussed the use of directives to enable claims based authorization on some the user interface elements. For some scenarios, a directive is the ideal approach, but because of the fact that a directive is called every time is declared on the mark-up, it is not ideal for cases where an item lists can have many items, and we just need to validate one or two claims.

Directive Implementation
When looking at our previous implementation, we can see on the console windows the number of times that the directive is called. We want to optimize the approach by just calling the directive one time and validate the claims for the user.  A way to do this on AngularJS is by using an Isolate Scope Directive.  This means that the directive does not share the same scope as the controller, but it also provides the advantages that we can pass object references and functions which can be used to indicate what claims need to be validated all at once thus eliminating the additional calls.
New Approach Isolate Scope
Now that we understand our optimization approach, we can refactor our code by first removing the authorize directive from the button markup which is what causes the multiple directive calls. We can now define our new directive with isolate scope and restrict it to “E” which means that it can be used as an element only. The idea here is that we want to declare it only one time on the mark-up outside the ngRepeat scope.  
We also want to add two attributes to our element. These attributes are assigned to functions within the controller. We should notice that in order to pass evaluating expressions to our directive, the attributes need to be declare with “&”.

scope: {
                  authorizeMapping: '&',
                  authorizeCallback: '&',                   
      },//isolate scope    

The function assign to the authorize-mapping attribute returns a JSON with all the claims that need to be validated on behalf of that controller. The function assign to the authorize-callback attribute is called by the directive to return the status of each claim (true when found). Let’s take a look at our new implementation:


Controller Kicks In
Once the controller has received the status of each claim, we can leverage the power of AngularJS by mapping claims to controller variables. At this point, we just need to add an ng-show directive and assign a controller variable to evaluate if the user is authorized to see that element. Yes, we are still using a directive for each element, but that is just evaluating a true or false expression, and it is not calling the authorization service to validate the claim.
We can now compare the console output with the isolate scope, and we should see that we no longer have multiple calls to our directive. The result should be just one entry.


Does It Work?
To check that this is working properly we can run a simple test. Run JSFiddle and set the app.edit claim value to an empty string or just click the delete icon. This should remove the permission on the rest of the list items as shown below.
Areas of Improvement
As usual, we should ask ourselves if there ways of improving this approach. Since we can now notice that this solution uses controller variables, do we really need a directive? If the concern is reusability, the directive approach is preferred over a controller only implementation as this can create code duplication. To show this, we can review the controller only solution on another article.

Originally published by ozkary.com

Sunday, July 10, 2016

AngularJS SPA Directive Claims Authorization

Overview
When we talk about authorization of the elements on a web application, we make reference to the ability to hide or show some areas of the application based on the permissions that are granted to the logged on user.  These permissions are usually delivered to the application via claims on a security token like a JSON Web Token (JWT).
Security Service
For now, we assume that the claims have been populated in our security service. This service has a simple implementation in which it checks if a particular claim already exists for the current user by managing the claims information as a property. The purpose for this service is to be used by all controllers, directives and other services that require authorization services.
Specifications
We want to be able to create a simple user interface that contains a list of items with two action item buttons.  The delete button allows us to remove the item from the list. The edit button is used to edit the item information.   In order to understand what claim controls the access to what element, we must have some information that indicates what needs to be done.  The table below provides the information that we need. If the user has the respective claim, we display the element. Otherwise, we remove it from the DOM.
Element
Claim
Action
Delete Button
app.delete
Display the element
Edit button
app.edit
Display the element


Implementation
Now that we understand what claim and elements we need to look for, we can take a look at our app.  The image below shows a simple list with items. Each item has a delete and edit button. This maps well with what has was been defined on our specifications.
When using AngularJS, the recommended approach to change element behavior is by using directives.  With that in mind, we can implement an Authorize directive which takes a tag value. This tag is the actual claim value that can be used by the directive and the authorization service to verify that the user has the required claim.  Let’s take a look at our implementation next:

On the HTML tab, we have added the authorize directive with the respective claim tag for each of the call to action buttons (delete, edit). On the JavaScript tab, we can see our directive implementation (dirAuth) .  We read the claim tag from the element attributes and pass it as an argument to the auth service ($svcAuth).  If the claim is found on the claims collection, the result is set to true, and we show the element. Otherwise, we hide it.
Does It Work?
To check that this is working properly we can run a simple test. Run the JSFiddle and click on the delete icon for either the delete or  edit claim. We should see how all the icons for the remaining rows are no longer available. In the image below, the app.delete claim was removed. We could also just empty the claim value as this would evaluate as false and would remove the permission on the control.
Areas of Improvements
That was fairly easy to secure, but there is something there that bothers me a bit.  If we take a closer look, we can see that this list has multiple items, and each item has a delete and edit call to action buttons. As we can image, the directive will be called each time it is declared in the mark-up. In this example, there are five items with two buttons. This means that our directive will be called 5X2 times (n x 2 for any list).  We can see this by adding a trace call on the code and looking at the console window:
As suspected, our directive is called too many times, but we just need to check for two claim values. Clearly for this scenario, we need a better approach. We can address this concern by using a directive with isolate scope, but we can leave that for another article.

Originally published by ozkary.com

Wednesday, June 29, 2016

SharePoint 2013 Adding Multiple Timelines Graph to a Project

When creating a SharePoint site using the project template a default timeline view is created. A timeline view provides the graph which shows tasks with dependencies on a timeline format.  The limitation with this template is that there is only one timeline view created, and we often find the need to create more than one. In this article, we take a look at how we can add additional timeline properties on a project site by using the SharePoint JavaScript Client Object Model (COM).


Timeline










Find the List Folder URL

In order to add a new timeline view, we first need to find out the URL for the list folder properties.  This URL is needed to query for the list properties using JavaScript. The URL can be found by visiting Site Content->List Name->List Settings. This link should have this format:


The highlighted text is the information that we need to query the properties.

Script to load the list properties

Now that we have the folder name, we can move on to write the script that can help us query the properties information. We start by creating a JavaScript function which can let us define the request and then make a call to display the properties.  The goal here is to become familiar with the SharePoint Client Object Model (COM).

//usage:  findProperties('sitename/Lists/Tasks')
function findProperties(path) {
try {   
    var context = new SP.ClientContext.get_current();
    var web = context.get_web();
    //build the request for folder and props
    var url = path;
    var folder = web.getFolderByServerRelativeUrl(url);
       context.load(folder);
    var props = folder.get_properties();
       context.load(props);
    //server call to load the folder and properties
       context.executeQueryAsync(function () {
        var fields = props.get_fieldValues();
        for(var key in fields){
               console.log(fields[key]);
        }        
    }, onError);
} catch (ex) {
    console.log(ex);
}
}

The function just makes the call and displays the results on the browser console. This can help us inspect the results and discover what property we need to clone. After looking at the results, we should find a property with the name of “Timeline_Timeline”.  This is the property that contains the metadata for the timeline graphs.

Script to clone a timeline view

Now that we know how to query the properties, we can focus on how to clone one. The goal is that we need to create additional timeline properties. This is what allows us to create additional graphs on the project.  In order to clone a property, we can leverage our first script to query the properties collection. The change now is that instead of just displaying the properties, we can fetch the property value and create a new one by calling set_item(newPropName, value) on the collection object and update the folder information. This is what adds a new property.

//usage:  cloneProperty('Timeline_Timeline', 'Timeline_Timeline2','sitename/Lists/Tasks', function(){},function(){})
function cloneProperty(propName, newPropName,path, onOk, onError) {
var context = new SP.ClientContext.get_current();
var web = context.get_web();
//build the request for folder and props
var url = path;
var folder = web.getFolderByServerRelativeUrl(url);
context.load(folder);
var props = folder.get_properties();
context.load(props);
//server call to load the folder and properties
   context.executeQueryAsync(function () {
    var fields = props.get_fieldValues();
    var value = fields[propName];
    if (value) {
           props.set_item(newPropName, value);
           folder.update();
        //server call to apply update
           context.executeQueryAsync(function () {
            var updatedFields = props.get_fieldValues();
               onOk(updatedFields);
        }, onError);
    }
}, onError);
}
Simple way to use this script

This script can be loaded from a SharePoint page that includes the SP JavaScript files. The approach to do this is to edit the page and add the script editor web part to the page. This allows us to add embedded script and quickly test our JavaScript changes by reloading the page with the script and calling the functions using the browser console. For example, open the browser console and type:

findProperties(‘'sitename/Lists/Tasks'’)

We could also just add an HTML button and wire the onclick event to call our function.

Validate that we have new timelines

After we run the script, we can now edit the default project plan page and edit the timeline webpart properties. On the timeline views, we should see a dropdown with the list of views that are available. Depending on the number of times that you clone a timeline, you should see that many entries.

Keep in mind that the selected view becomes the default timeline. This is important to know because when you add items to the timeline from the task lists, the items are added to the default timeline view.

Enjoy your multi-timeline SharePoint Project site.

Originally published by ozkary.com