Front end permissions branch (fep) -- updates? need help? any idea when ready to merge?

[Jeffrey Hearn]

Since there's no PR or issue which I could find by which to track development of this branch, I was just curious about its status and if there was anything I could do to help.

[Matthew Westcott]

On 24 Jun 2014, at 22:16, Jeffrey Hearn <cowbe...@gmail.com> wrote:

> Since there's no PR or issue which I could find by which to track development of this branch, I was just curious about its status and if there was anything I could do to help.

It's pretty much done - just needs unit tests for the admin views, documentation, and possibly a spot of git rebasing / breaking down into smaller pull requests (since we've changed tack on the separation between Page.route and Page.serve a couple of times, making the git history rather larger than it needs to be). If you're willing to do the honours again with the documentation, that would be much appreciated! I guess the three main areas to cover documentation-wise are:

* the new Page.route vs Page.serve model and the before_serve_page hook (probably one for me to write, but you're welcome to give it a go...)
* setting up a custom 'password required' template, globally and per-model
* editor documentation for setting up password-protected areas

- Matt

[Jeffrey Hearn]

I would be happy to cover those docs.

I'm going through the branch comparison now and had a few questions about  get_view_restrictions() and check_view_restrictions(). Are these intended to be overridden to extend a model for other types of view restrictions, such as content gated behind user registration (login required) or a paywall? I can see that check_view_restrictions() basically replaces serve() in the event of an unmet view restriction, so you can serve alternate contexts and templates depending on the view restriction that way. But if you'd like to keep the password protection view restriction and add additional ones there are a few problems that crop up like the PageViewRestriction model assuming a nonblank password so it's not ideal for being subclassed. 

Is the FEP feature meant to be extended for extra view restrictions or should those be implemented in overridden get_context() or serve() methods along with all the other custom page functionality?

[Matthew Westcott]

Hi Jeffrey,
The feature was indeed designed with the intention of extending it in future to support other kinds of restriction, such as user logins - however, I didn't consider the possibility of users extending it from outside wagtail core. As it stands, the recommended way of doing that within a user app would be to hook in to the new before_serve_page hook (which *is* intended as a public API) with the app's own implementation.

(The presence of the check_view_restrictions method in Page is a bit of a red herring - it should probably be ditched, and the code moved back into the body of wagtailcore.wagtail_hooks.check_view_restrictions. It was put there because at one point there was an obscure case where we might want to run the permissions logic outside of the before_serve_page hook - but in the end we solved that problem in a better way.)

Up to now I was imagining that we'd just let the PageViewRestriction model grow to accommodate every kind of restriction we wanted - but now that you mention it, subclassing PageViewRestriction (so that PageViewRestriction itself doesn't dictate any particular mechanism, and having PasswordPageViewRestriction as one of many subclasses) would be a really neat way of organising it... and through the magic of multi-table inheritance, has the bonus property that new subclasses can live entirely outside of wagtailcore with no changes to the core schema required.

Cheers,
- Matt

[Jeffrey Hearn]

So the 'before_serve_page' hook is the public API for overriding serve()? If check_view_restrictions() is using the same hook, what determines precedence? What about overriding get_context() or get_template()? Is before_serve_page going to be the only public API for serving a page?

[Matthew Westcott]

On 30 Jun 2014, at 15:41, Jeffrey Hearn <cowbe...@gmail.com> wrote:

> So the 'before_serve_page' hook is the public API for overriding serve()? If check_view_restrictions() is using the same hook, what determines precedence? What about overriding get_context() or get_template()? Is before_serve_page going to be the only public API for serving a page?

before_serve_page is one public API for overriding serve(), but not the only one - it's still valid for subclasses of Page to override any of get_context(), get_template(), route() or serve() with their own behaviour, and that's still the preferred approach if the custom behaviour is specific to a particular page type. The advantage of before_serve_page is that it takes effect regardless of page type.

Officially, the order of precedence for hooks isn't specified... in practice, they're run in the order that the wagtail_hooks.py files are imported, which in turn is determined by the ordering in INSTALLED_APPS. I'm tempted to make that the officially documented policy (especially as I've written application code myself that unwittingly relies on that assumption!) - what do you think?

- Matt

> --
> You received this message because you are subscribed to the Google Groups "Wagtail" group.
> To unsubscribe from this group and stop receiving emails from it, send an email to wagtail+u...@googlegroups.com.
> To post to this group, send email to wag...@googlegroups.com.
> Visit this group at http://groups.google.com/group/wagtail.
> To view this discussion on the web, visit https://groups.google.com/d/msgid/wagtail/0c63f8fb-23a4-4642-88b6-12664f77bb37%40googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.