Yep - Checking is more of an informational event to let you know the process is about to start. You wouldn't be able to define the answer there, but you could do some substitutions. Doesn't apply to your case but in Checking you could the user, permission,
or content values before the access test begins.
Complete does work if you want to alter the pass/fail Granted value. You can also use the Adjust event to change the Granted boolean to false - be sure to leave the Adjusted boolean to false, though, because if you set Adjusted to true you'll be asking the
roles module to recalculate based on your changes.
(2) frontend authorization
That is correct at the moment. There is not a frontend access check in place at the points you would need to control - those would be:
Orchard.Core.Contents.Controllers.ItemController Display(int id)
Orchard.Core.Routable.Controllers.ItemController Display(string path)
Assuming some view access checks were in place there you'd still be redirected to an access denied or logon page rather than a custom view.
Interestingly those both call IContentManager.BuildDisplayModel... Maybe a handler on those events would be a better place to replace the shape after all?
(3) module/event priority/order
yeah, it is one of those nature-of-the-beast situations. something we should double check is what order the services come back in when resolved from the IoC container. e.g. is it deterministic? determined by what? it would be nice if the modules or features
could have a priority, and also take into account dependency order, so you can make assumptions about order-of-execution between modules handling events...