Developer forum

Hi Hans,

There is no substitute. The whole point of the rewrite was to make it not needed to manually check for if the page was active and visible.

Maybe if you describe the scenario you're trying to solve, I can help you use the new dw9 approach? Fx. you can use .HasPermission(PermissionLevel.Read) on any page object to see if the current user (or current anonymous user) has access to read the page. That might be what you need? Or it can be combined with .Active to sort of match the old behavior.

BR

Martin

About the scenario:

We have functionality that creates navigation in code.
We upgraded this project from 8.9.2.16 to 9.7.5.

We have replaced the old permissions with the new permission model.

The custom navigation shows links based on your front-end permissions.

In the 8.9.2.16 situation we used the Dynamicweb.Frontend.Page.IsActive to filter a list of page based on the old permission model

var pages = GetPages().Where(p => Dynamicweb.Frontend.Page.IsActive(p.ID));

In the 9.7.5 situation we tried to use the  GetPermissionForUser

var pages = GetPages()?.Where(p => p.Active && pagePermissionService.GetPermissionForUser(dwUser ?? null, p, PagePermissionLevels.Frontend).Equals(PagePermissionAccess.Allow));

But the outcome is just wrong!
We can't get the navigation to behave the way it did in the 8.9.2.16 situation in combination with the old permission model.

When wel log what the frontend permissions are in the navigation loop and also loop through all user groups of the current user, we see that when using pagePermissionService.GetPermissionForGroup  the outcome is DENY in places where it should be ALLOW.
The DENY pages targeted are accessible for that same user and don't result into a login or whatsoever, so the system does know this page is accessible for the current user, but still results in a deny when using GetPermissionFoUser or GetPermissionForGroup.

And by the way there doesn't seem to be a HasPermissions method on a list of Page:  pages.where(p => p.HasPermissions(PermissionLevel.Read)) 

Dynamicweb.Security.Permissions > page.HasPermissions(PermissionLevel.Read) seems to be the golden tip! Thanks Martin!

Thanks Martin,

Just for the future, where would we find these extension methods in the documentation? Searching for HasPermissions on the API page gives zero results. I am curious if there are more of these methods that could be usefull for us.

Greets Hans

Hi Hans,

Good question. Generally we try to not use extension methods, because they can be very difficult to find. But sometimes we have constraints that make it impractical to change everything in our API - like adding permission controllability to all objects in our application. When we DO add extension methods, we always try to add them to the same namespace that you use when you use the object that is the target of the extension.

Regarding your search, I think it's because we don't use stemming for our searches. Try with HasPermission (without the s) or GetPermission (again, without the s) and you should find them.

Here is a quick guide to ensure that most extensions you might want to use are available when you write a template:

When you use fx. Common.Context.Request you can do it like this:

      int value = !string.IsNullOrEmpty(Common.Context.Request.QueryString["MyRequestInt"]) ? 0: Converter.ToInt32(Common.Context.Request.QueryString["MyRequestInt"]);

This can be split up a bit, resulting in you having more readable code, and as a bonus, discover all possible extension methods for IRequest (because you now have to be "using Dynamicweb.Environment" to compile the template).

      IRequest request = Common.Context.Request;

      int value = request.GetInt32("MyRequestInt")

The code is now cleaner and easier to maintain, and unless you've done it alot of times before, it's probably less error prone. So always split up the code into smaller pieces - it will even present extension methods relevant to your immidiate needs.

BR

Martin