Permission to Add Top-Level Pages

Description of problem

Currently, only admins (or superusers) can create new top-level pages. We have many sites in which we would like to delegate the ability to create top-level pages to users without giving them full admin permissions to the site.

Without the “overriding” admin permission, page creation permissions are based on whether the user has edit permissions to the parent page (assuming the default permission provider is in place; otherwise, there may be additional permissions in play, but they are still based on the parent page).

Description of solution

We propose adding a new Permission specifically for creating top-level pages.

There would be a permission grid added to the Persona Bar to manage this permission. This could be added to the Security page of the Persona Bar. Alternatively, we could introduce a top-level item to the tree view of the Pages page of the Persona Bar, and selecting that top-level item would allow managing these permissions.

Description of alternatives considered

• We could allow TabPermission rows with TabID set to NULL.
• Instead of a top-level page creation permission, we could introduce a “page admin” permission that gave full permissions to manage pages. However, there would be scenarios where we would not want these users to have this level of permission (perhaps they can create new pages but not edit pages we have setup).

Additional context

We have a developer available to tackle this implementation if approved.

[bdukes]

We’ve gone around on the implementation of this a few times. There was feedback that using the home page would open up more permissions for folks without giving users control and was difficult to discover. We then started down the path of using NULL in the TabPermission table to indicate top-level pages, but we realized that we then didn’t have a portal context to know which portal the permission applied to. We briefly considered adding actual “root” entries in the Tabs table but decided that introduced too many potential breakages.

We currently see two options. The first is to implement these permissions as Persona Bar permissions. This is a simpler approach, but limits their reach, since the core doesn’t know about the Persona Bar. For example, a 3rd party module could ask the question of whether a user can add a page and get a different answer than the Persona Bar would give.

The second option is to implement a new Portal Permission concept (table, view, Info class, Collection class, Controller class, etc.). This is a more involved approach, but doesn’t appear to have any major downsides, and the “involved” part is mostly following the well-worn path of existing permissions. This is the approach we (@EngageSoftware via @DanielBolef) are currently working on implementing.

[jeremy-farrance]

I definitely feel that a “page admin” or Page Management Role would be more useful and cover a lot of the more common use cases. There is also an opportunity to establish a pattern that would allow for a User Management Role. Over the years the common need has been adding pages (or users) and editing page (or user) settings without giving the user (Portal) Administrator permissions.

I admit I like the “top-level” permission idea because it matches well with the way we’ve done our site setups over the years; I admit its sounds useful and may be less coding work to implement. But it feels like a solution that is fixing a problem instead of a solution that is a genuine and needed feature.

That having been said, I would be VERY happy to see just the proposed solution get done in the near term. Cheers!!