Restore Reviews into a new Extension moved from contrib to solidusio

[fthobe]

The current review extension does not function on the new front-end and comes with very outdated code. Considering the discussions made in the following two issues it was decided to make a hard fork into a new extension as the burden of maintenance seems to have reached the limit of what's possible.
#50
#63
#120
#125

The current WiP can be monitored here.

Planed Features

The new extension will contain following features:

• Endpoints and starter frontend integration to allow users / customers to leave a review on a 5 star scale (1-5) and a comment with the review and an approval process;
• Integration on the PDP of the starter frontend
• Integration on the taxon pages inside the product cards
• Endpoints to allow users / customers to upvote or downvote a review (thumbs up / thumbs down) reflected also in the frontend with the possibility to toggle the entire feature or negative votes on and off;
• An Endpoint to report a review;
• A Management Interface to approve or disapprove reviews;
• New Columns in the admin interface to show upvotes / downvotes
• A verification if the user is a "Verified Review" and has purchased the product before;
• The model of reviews will also be extended to include the store id allowing at a later point to return reviews only on the matching store considering also multi store environments in addition to multi-language environments through the local;
• A method of configuration to allow toggling the feature on store fronts in a multistore environment

Future Features

• Integration with the new frontend

Dropped Features

1. The legacy Front-End will not be supported
2. All endpoints allowing users to review reviews (no, they are there, it's not a pun), will be fully removed

What will be responsibility of the operator of the store

While the feature will allow moderation in either offensive (approve reviews before publication) or defensive (disapprove published reviews) manor, bot and spam protection will be left to the operator of the store. Suggestions will be given in the readme.md.

Features that are nice to have

• Add positive/negative review endpoint #63 allowing to sort for better reviews by using the thumbs up / down functionality

[fthobe]

@tvdeyen @jarednorman

Questions:

1. is cache counting and a table an acceptable way to count the thumbs up thumbs down actions? It is outlined in a guide in the edge documetation as a reference implementation to count likes
2. Do you have other preferences or no gos?

[fthobe]

Hey,
this is the first draft for a new review extension.
The extension currently works with the starter frontend and provides a simple review functionality.
gms-electronics#2

• jquery free
• jscript only
• works with starter frontend
• works with admin backend
• thumbs up / down for reviews not implemented on frontend yet
• report review not implemented on fronte-end yet
• Style aligned with starter frontend
• filter for store not yet implemented
• circleci not fully implemented yet, (shahmayur001 could need your help there

@tvdeyen @jarednorman @kennyadsl

[kennyadsl]

👍 Code wise it looks ok to me overall. Still have to go into details but the direction seems fine. Do you need anything from us now to continue with this work?

[fthobe]

@kennyadsl we are struggling with these issues:

1. In the Solidus Review gem, settings are stored in preferences, which reset if we restart the application. How do we generally handle this when we want any setting to be available in SolidusAdmin, persist after restarting the server, and save data properly? Do we hard code a configuration file or store settings in additional tables.
2. In the Solidus Review gem, test cases are built with the old, deprecated frontend. What is the correct way to build test cases or create a demo app for test cases using the new Starter Frontend? Please be as specific as any possible as @shahmayur001 did struggle to understand you.
3. What is the best way to deface the view part and view components? We want to add a few modifications to the Review gem that will affect the product or taxon pages. How should we handle these modifications?
4. What is the best way to implement JavaScript? Should we use Hotwire, Backbone.js, or plain JavaScript? There are different structures used in various parts of the application.
5. Sometimes, we encounter issues with receiving params in different formats, such as those from the Solidus API, backend, or core. In such situations, what is the best way to handle and normalize these parameters?

[kennyadsl]

1. Which settings are you talking about? Can you link a specific file/LOC? Is the application a real application or a sandbox environment? More details on the context where you are facing the issue might be useful.
2. the starter fronted is copying frontend specs over the host application. We can do the same here in the extension installer.
3. Ideally, there is no need for deface and we should change the views of the starter frontend with the installer (like injecting a render "reviews" in an existing starter frontend view)
4. Do you mean for the admin or storefront? By the way, the Hotwire stack is the preferred way.
5. Can you make a more specific example, not sure I follow here.

[fthobe]

All points are related to this gem:

1. Which settings are you talking about? Can you link a specific file/LOC? Is the application a real application or a sandbox environment? More details on the context where you are facing the issue might be useful.

None of the admin settings of reviews seem to be stored anywhere but in memory, in fact don't seem to persist after a restart of the service. Is this by design (which means the interface is wrong) or incomplete implementation (which probably means we miss tables) or is there a 3rd way (like writing a conf as in eg Wordpress from a PHP script with appropriate elevated rights).

solidus_reviews/app/controllers/spree/admin/review_settings_controller.rb

Line 4 in 215ad02

before_action :process_unset_checkboxes, only: [:update]

2. the starter fronted is copying frontend specs over the host application. We can do the same here in the extension installer.

@shahmayur001 , can you work with these instructions?

3. Ideally, there is no need for deface and we should change the views of the starter frontend with the installer (like injecting a render "reviews" in an existing starter frontend view)

Ok, can you give an example of any extension doing doing that on the starter-frontend

4. Do you mean for the admin or storefront? By the way, the Hotwire stack is the preferred way.

Both, does Hotwire apply to admin as well as frontend?

5. Can you make a more specific example, not sure I follow here.
   There you go:

[shahmayur001]

@kennyadsl Thank you so much for your prompt response.

1. Adding more context: In the SolidusReview gem, we provide a few settings to the admin, but these are just preferences and reset when the application restarts, such as in the ReviewsConfiguration file. Is it possible to make these settings permanent instead of temporary?
2. Thank you! I will try this out and let you know.
3. Got it, thank you.
4. Got it, thank you.
5. A specific example is the SolidusGiftCard gem. As you can see in above screenshot, to work with the GiftCard parameters, I used different conditions as a workaround. However, I would like to understand how to properly tackle this kind of situation.

[fthobe]

@kennyadsl we seem to still struggle with point 2.