Permission based redirect about angular-permission

[RafaelVidaurre]

This has been discussed a couple of times before. It's a good idea though it is not yet implemented.

Probably the syntax would be just like the one you posted, there was also an Idea about adding a default redirect at the role definition instead of the route data. Though I think that would cause app mantainability issues.

We have to priorize other problems first, though if you feel like creating a PR I'd gladly review it thoroughly.

Either way, it's very likely I'll implement this at some point in the near future.

[fsauter]

Alright, I'll give it a try. Please be patient, I'm not a JS profi ;-)

I also like the idea to add the default redirect to the role definition. For me, both ways would be okay. Where do you see the maintainability issues?

Here a snippet how I understood the other idea, is this correct?

Permission.defineRole('anonymous', 'page.login', function (stateParams) {
// or...
Permission.defineRole({ name: 'anonymous', otherwise: 'page.login'}, function (stateParams) {

• Edit:
  What about a custom callback?

Permission.defineRole('anonymous', function (stateParams) {
    // Check role
}).accepted(function() {
    console.log('User is not anonymous!');
}).denied(function($state) {
    $state.go('page.login');
});
// or something easier to implement...
Permission.defineRole('anonymous', function (stateParams) {
    // Check role
}).defineDenied('anonymous', function($state) {
    $state.go('page.login');
})

[RafaelVidaurre]

In the app itself creating a default redirection of the role denied is kind of weird when you take a closer look. For example say we have roles: roleA, roleB

If we use the except way of granting access

data: {
  permissions: {
    except: ['roleA', 'roleB']
  }
}

If we define a default redirect for roleA then weird stuff would happen. The idea of except is that it only grants state access if roleA and roleB are rejected therefore, since we defined a redirect at role-definition level, this state cannot be accessed.

This is one of the reasons why I think redirection should be defined at state/route config level.

[fenos]

Hi, thanks for the amazing package!! I wanted to suggest if is a good idea to have as parameter either a string or a function in the redirectTo property. If a function is given we have more control to choose which redirect state we should take the user. Ex:

.state('mnm.activate-profile',{
                url:'/account/activation',
                data: {
                    permissions: {
                        only: ['authenticated'],
                        redirectTo: function(rejectedPromise) {
                                if (!angular.isDefined(rejectedPromise)) {
                                     return 'auth.login';
                               } else if(rejectedPromise.active === false){
                                     return 'auth.activation';
                              } 
                              return 'home';
                        }
                    }
                },
                template: '<h1>Hiii</h1>'
            })

Permission:

Permission.defineRole('authenticated', function(stateParams) {

            var deferred = $q.defer();
            Account.identity()
                .then(function(user) {
                    if (!user) {
                        defer.reject();
                    } else if(user.active === false){
                        defer.reject(user);
                    } else {
                         defer.resolve();
                   }
                });

            return deferred.promise;
        })

[RafaelVidaurre]

@fenos that sounds like a good idea, would have to probably add support for promises so that you can do async operations on the redirectTo function.

If you feel like it, open a discussion with your idea of a good implementation of this feature so we can all evaluate it.

[RafaelVidaurre]

Working on this right now, @fenos I'm trying your approach as it is the most powerful solution for now

[RafaelVidaurre]

A new version of Permission is now available, supporting @fenos' idea