Proposal for amendments to the behavior of the productDetail routes

[newsiberian]

Hello. Going back to yesterday's issue of the productDetail routes. I believe that the current behavior in case when the product is invisible and unauthorized user trying to get this route is wrong. I think so, because this is unexpected behavior.

I think that the user expect to see content of this page. For example, he is an admin and he forgot to login. The behavior that he expect to see is an redirect to unauthorized page to login and then automatically be redirected back to product page.

I remind that currently user which is without access to invisible product always sees productNotFound page.

What do you think?

[aaronjudd]

You're correct, that the current behavior is not correct, but I'd suggest that a product that is not published anymore should display related products, or redirect to some other template views that can be used to up-sell a potential customer. The admin user should have additional views beyond isVisible though, and probably some UI to help them navigate multiple views. We've been working towards this goal with layouts and workflows.

The process began by introducing the workflow schema into each of the collections, first Cart, then Orders.

We're still working through the details of how workflows are used, and right now it's a bit different for each collection, which isn't ideal, so I'm still trying to decide how rigid things need to be, and this is currently what we're working on for the order workflow.

The next collection I've been planning to implement the workflow schema into is the Products collection. The approach that I am considering is that we'd replace isInvisible with workflows based on permissions.

Each product would have it's own workflow object, just like Carts, Orders. This package registry workflow object could then being used to define further what the product layout is, for instance, to provide different product types.

Conceptually, roles will control what view you see (allowing for a publishing workflow), one of which could control visibility of the edit/detail view as well. I don't see this affecting the default behavior that we have right now very much, but it should allow for much easier customization to the product page, and more complex workflow implementations.

The goal is that the package registry is the central component that controls both layouts, routing, and workflow and permissions for Reaction (and thus allowing any of those elements to reactive, replaceable from the registry).

The changes that have already been made to Carts, Orders are part of a series of changes that are intended to either address, or lay the groundwork for the following features:

• publishing workflow Publishing workflow #415
• split reaction-core into modules [suggestion] split reaction-core into modules #451
• reaction-layout reaction-layout #148
• itemTypes itemTypes #152
• basic CMS Pages management Basic CMS Pages management #383

Much of the foundation is also now laid for replacing current routing and layouts, and before we work on the product workflow we need to have two additional pre-requisite features completed:

• create a new reaction-router package (See reaction-router package #502)
  • initially use flow router, but there could also be a iron-router package, or whatever else comes along
  • use the package registry, and create dynamic routing from registry.
  • potentially use a Routes collection, maybe registry is sufficient
  • removes iron-router, or any specific router dependency from packages
  • package can use the package registry to enable routing, and it will be updated from admin, allowing further custom urls
  • use the registry for permissions, layout control.
• introduce layouts (Issue reaction-layout #148
  • a re-implementation of the coreLayout, but using reactionApps, reactionTemplate helpers
  • add basic page, route CRUD CMS functionality
  • create publishing workflows for content, that will in turn be used for product workflow