@nenti commented on Sat Oct 15 2016

Expected behavior

In some e-commerce scenarios shipping address is not required and thus you can remove the workflow step in the checkout process.

Actual Behavior

When converting the cart to order on completing the checkout process an error occures and order never completes.

Steps to Reproduce the Behavior

Remove workflow step 2 from the checkout process. Checkout a shopping cart.

This issue is related to a wrong handling in method "cart/submitPayment" where a missing billing address is handled with a wrong mongo query.

@aaronjudd commented on Tue Oct 18 2016

Thanks @nenti makes sense, we need to allow for payments that don't require a billing address.

Feature:

For true internationalisation sellers should be able to specify which regions / countries they will ship to.

Considerations

• When searching for products from a location only products available to the buyer should be published
• Seller location should also be easily filterable for the buyer.

It would be great if the "codes" functionality could be extended to marketplace sellers.

It would be great to have ReCaptcha required for signup if someone registers using an email address, rather than a google or facebook account. This would add some protection from bots spamming the site.

Hi,

Is it possible to always force a vertical menu (like on mobile view)?

When adding multiple tags and sub tags, the horizontal menu is showing some UX limitations for my use case (for example space is missing to diplay all menu items).

I don't have this problem when using the vertical menu in mobile or tablet mode.

Thanks

Is there way to set up dynamic shipping rates based on location and weigh? If not any plunging for this

@Stat1c14 commented on Thu Apr 27 2017

When building a plugin with custom routes, the database must be reset in order for changes to route and template names to take effect.

Expected behavior

Editing custom routes in register.js should trigger a server restart and changes should take effect.

Actual Behavior

Changes only seem to take effect if the database is reset.

Steps to Reproduce the Behavior

Edit the name of a template in register.js and in that template file. Notice that the application still looks for the old template name even after server restart, meaning that the template name for that route must be stored in the database somewhere.

Running reaction reset -n updates to reflect your changes.

Versions

Max OSX Sierra 10.12.1
Node: 6.2.2
NPM: 4.0.5
Docker: 17.03.1-ce
Reaction CLI: 0.8.0
Reaction: 1.1.1
Reaction Branch: master

@aaronjudd commented on Thu Apr 27 2017

I think this is/was a known issue. Two things come to mind there.. you can just delete the Packages collection instead of resetting the db, then reload will reimport. (so before you edit,save delete the running instance Packages collection). And also ReactionCore.Router._routesMap and ReactionCore.Router.Reload() should allow you to view and reload the router.

@aaronjudd commented on Wed Mar 04 2015

Support for subscription products and payment models.
We don't want to store payment information, so support will need to be for existing payment providers that offer a subscription / stored payment service (such as Recurly).

Subscription profile

• Billing Interval
  • day
  • week
  • semi-month
  • month
  • year
• Billing Cycles
  • terminate subscriptions after a xx of billing cycles.
• Timespan
  • Begin
  • End Date
  • Infinity
• Free Trial
  • Time the subscriber is allotted on the plan for free. The paid subscription will begin at the end of the trial period.
• Setup Fees
  • A one-time charge processed at the time of sign-up.
• Select payment service per profile
• Assign "subscription profile" to products on product edit/management.
• Assign ROLE to USER on subscription purchase.

@pomaking commented on Thu Mar 05 2015

Glad to see you're looking subscription/membership scenarios. We've also been looking at implementing a separate Membership Collection. The same model can generally be used for both online and offline subscriptions/memberships. The term "Billing Cycle" can be confusing, as some organizations use it in reference to rolling memberships versus a static membership calendar. Where you have a static calendar, there can also be an issue related to pro-rated payments.

Additional terms: Semi-annual and quarterly, although not frequently used.

Use of roles to assign subscriptions. This works well if the purchaser is the one using the membership. We have use cases, though, where users are purchasing for other family members or entire families, or for businesses, etc. So we're thinking of it as a fielded relationship, an edge more like a graph database that links the membership to the user(s), although this would probably work in conjunction with an assigned role...still trying to figure some of this out.

@RobertLowe commented on Sun Aug 30 2015

Instead of Recurly, and since Stripe is mentioned on #99 it would probably be best to target Stripe Subscriptions first.

@rymorgan commented on Mon May 08 2017

Need more requirements. Cart? Orders? PDP? Would love a basic user story to make the this an issue that ready for design.

@zenweasel commented on Tue Feb 13 2018

Closing to Review roadmap

The EU General Data Protection Regulation https://www.eugdpr.org/ compliance will be required for companies doing business in the EU starting May 25th, is Reaction compliant?

Does Reaction support multiple sellers? I'm looking to build a marketplace where I can connect buyer and sellers. Thanks.

Feature:

For Peer to Peer marketplaces, or B2B marketplaces, for shop owners/admins payment should be possible using their existing stripe connect account.

Benefits:

1. This means charges are at a rate of 1.5% instead of 2.9% for non-european cards.
2. Buyers wouldn't have to input card details on checkout. It would just require a single click.

Suggestion:

• Create new permission level on shops "Allow Checkout" or similar
• For people at checkout with this permission show a toggle on stage (5) Payment, "checkout with stripe connect".

In modern marketplaces escrow like functionality is becoming the norm. It massively increases buyer trust, and allows new sellers to get started. It's extremely important for B2B marketplaces and high value goods.

Stripe Connect allow such functionality. Here you can see the docs of how they have implemented this functionality at sharetribe https://help.sharetribe.com/payments-and-transactions/online-payments-with-stripe/how-to-delay-payments-and-hold-funds-with-stripe.

A good default implementation could be: payouts 14 days after valid tracking info is entered. Buyers would then have time to raise an issue if their parcel has not arrived (or service not provided for other sales types). The marketplace admin could then refund the buyer with certainty, and without any fees being taken.

@spencern commented on Wed May 31 2017

Navigation level tags should have the option of showing products from multiple tags.

e.g. clicking navigation tag "Sweaters" should have the option of showing tags "knitwear", "sweaters", and "sweatshirts"

@aaronjudd commented on Thu Jun 01 2017

Perhaps, like elasticsearch we could build a synonyms library? Or is this really just a routing task?

@mikemurray commented on Wed Aug 30 2017

This PR reactioncommerce/reaction#2747, which adds additional fields to tags schema, may help with this.

@spencern commented on Thu Aug 31 2017

I think having metafields on tags will help a lot with this.

"Smart Tags" would probably be a good candidate for a plugin at this point and I think could be accomplished with metafields

@aaronjudd commented on Wed Feb 14 2018

Feature request that requires more definition to meet our current issue guidelines.

@zenweasel commented on Thu Feb 16 2017

Currently we two panels labeled "Analytics" that both appear to be settings panels. (I think one is supposed to be the analytics dashboard and the other one settings)

@rymorgan commented on Tue May 09 2017

Yes, we're using this for an analytics dashboard. Worked with @spencern to come up with some of the basic analytic we'd like to include:
Sales stat.
Aging - Unfulfilled orders w/ in last week (for example), Aging returns for returned items received,
Coupon Codes - Best selling, time left, User limits, How many left
Best Selling products
Abandoned carts - last day, week month, date picker
Attribution channels - Social, affilates, product review, search, direct, app, paid ads

@rymorgan commented on Tue May 16 2017

First pass at an analytics dashboard. I am planning on iterating on these to make the analytics more contextual and actionable.

Zepplin link:
https://zpl.io/1NYpcJ

Screenshots:

@carlos-olivera commented on Tue May 16 2017

WOOOW! :)

The current Shippo documentation is not sufficient for understanding the existing implementation.

@cooloney commented on Mon Sep 28 2015

Currently users can't save the products during shopping but only saving them into cart.

Wishlist is a good feature to support this.

@cooloney commented on Tue Sep 29 2015

@mikemurray my friend @lhz516 Hanz will work on this feature. If he has some questions, please help to answer.

I think the right place is to add a similar solution to Cart into core package and we don't need to create a separated package for this wishlist feature, right? @mikemurray

@aaronjudd commented on Thu Feb 01 2018

Closing - insufficient details.

Currently, from, to, subject and html are allowed as options by the sendEmail job (server/jobs/email.js), which runs behind Reaction.Email.send.

When building contact forms, specifying a "reply to" address is often required. It would thus be very helpful to allow replyTo as an option.

@spencern commented on Tue Mar 07 2017

Currently there is no UI to enable the taxShipping flag that is present in the Taxes schema. It does appear that there is a relevant config option in the package config but that it's not enabled.

Expected behavior

While there is no UI to enable taxes for shipping, I'd expect that if I enable those flags in the database for our taxes that the tax calculation would include the shipping amount.

Actual Behavior

Tax calculation is based on item subtotal and does not include taxes.

Steps to Reproduce the Behavior

Enable a non-free shipping method.
Enable basic taxes.
Turn on taxShipping flag with db call.
Checkout with an item in a taxed zip code.
Taxes are charged for items, but not for shipping amount.

@lindoelio commented on Fri Jan 12 2018

Add ability to provide rating for sellers and buyers, like already exists for products.

Both use cases are relevant: sellers rate buyers and buyers rate sellers.

🇧🇷 #ReactionBR

@israeldboliveira commented on Sat Jan 13 2018

Great feature to be implemented

@zenweasel commented on Fri Mar 24 2017

It's like git blame but for product/shop administration.

There needs to be a way to log every change made to product/ shop configuration, who made it, etc., and possibly revert that change.

Since this can add a lot of overhead I see this as an "optional" plugin that could be disabled and mostly implemented with hooks. Obviously revisions started this but there is no history there (or is there?)

@spencern commented on Wed Apr 12 2017

From Shopify's admin panel

@aaronjudd commented on Wed Feb 14 2018

Feature request that requires more definition to meet our current issue guidelines.

@Sija commented on Fri Sep 22 2017

Would you welcome contribution towards implementing such feature along Google Analytics and others?

I'd be happy to work on that if you'd find it worth having.

Thanks for a breath of fresh code in the marketplace area! 🎉

@aaronjudd commented on Tue Sep 26 2017

@Sija good idea. we're reviewing the best approaches to an even more generic analytics reporting layer right now, where we can assign "connectors" pipelines to different data/analytics providers. I'll keep this open for a while as an enhancement and a reminder to myself as we document this strategy.

@jshimko commented on Tue Sep 26 2017

FWIW, Segment has support for Piwik.

https://segment.com/integrations/piwik

@zenweasel commented on Fri Sep 15 2017

Placeholder ticket for discussion

We have often spoke about the idea of the "Marketplace Admin" and there are permissions that allow them to do things that store admins cannot.

But in terms of dealing with orders we are treating them just like another store admin. They can view and act upon their orders and trying to make the Orders panel work for this sort of "super admin" will require some work. (Maybe a separate Dashboard?)

@spencern commented on Fri Sep 15 2017

Sticking the needs-more-detail tag on here for now as before anybody starts working on this it should be specced out in more detail. Added it to the design project as well @rymorgan as we'll need designs on this at some point.

I think there we need some product-focused thought and discussion into exactly what this idea means and how we are implementing the marketplace owner's view into merchant shop's activity.

Keep in mind that we should be implementing sensible defaults as each marketplace may have it's own requirements that can be implemented via plugin.

Some questions for anyone who's building or planning to build a marketplace:

• What data is most important for marketplace managers?
• What actions are most important?
• Should there be anything within a merchant shop that's not permissible for the marketplace owner to view?
• Should a marketplace owner be able to switch between "marketplace view" and viewing as a certain shop or should they be scoped to the marketplace exclusively?

Here are some things that I think a Marketplace Admin might need. Some of the discussion will inevitably need to be around whether something should be core or a plugin

• Easy communication with merchants/shop owners
• Enable/Disable/Suspend/Ban Shops
• Highlight/Feature and merchandise featured Products/Collections/Shops/Users
• Insight into how shops are performing - over/under performing, top, bottom, etc.
• Integrations managment (ads, marketing, shipping, payment, etc)

@rymorgan commented on Fri Sep 15 2017

Yea, I need a lot more info to design anything :)

@JoeyLyman commented on Sat Sep 16 2017

Data: How often an owner gets online, possibly. This may be irrelevant if there are other ways to find unresponsive owners and ban them. I don't know all of Stripe's options, but if there are any complaints about a shop owner not delivering paid-for-items, then they probably shouldn't get paid out immediately, or the marketplace owner should be able to refund the customer or hold onto the $ until both sides are happy.

I also don't know if there is a need for seeing the marketplace from the view of a certain shop; I would imagine everyone would have access to the same views - whether that be to see how a new customer would come onto the site and see the entire marketplace, and also be able to look at all the options from an individual seller. I think as an individual seller, these would be the views I would want to see as well.

All of the things, Spencer, that you mentioned as things a Marketplace Admin might need, seem great. The ability for an Admin to directly add and edit Tags on seller items would be great, so that the Admin can organize pages, without having to ask sellers to do all follow a format and then rely on them to do so. I would want to be able to have a main page show everyone, and then be able to make sure that all sellers that are selling "Fair Trade" have the right tag, so that the "Fair Trade" page shows all of those items, and if a seller typed in "Fair-Trade" as a tag, I could change it to "Fair Trade" to follow convention and make sure that it shows up on the "Fair Trade" products page.

@spencern commented on Fri Mar 13 2015

Would love to be able to use reaction to build a store where products can be rented out (e.g. lensrentals.com, Rent The Runway, etc) as there is not currently a good open source solution to this business case.

Some challenges that this would introduce on top of standard ecommerce:

• Tracking inventory for rental products across a calendar instead of binary in/out of stock
• Pricing as a daily/weekly/monthly rate
• Variable pricing dependent on rental length
• Bumper / Turnover time before product can be rented again

I'm certain there are other issues that would crop up, but those seem to be the big

Is this something that could be implemented as a package or would it have to be integrated into core?
I'd love to jump in and help build this out, but would need some direction as to the best place to start working on something like this.

@aaronjudd commented on Sat Mar 21 2015

@spencern on pricing at least, I'm wondering if we could implement some sort of a "pricing engine" approach "price" etc - (probably going to do this with discounts/promos at some level anyways). Instead of pulling direct from the data, we could use the "pricing engine" implementation where you could determine the pricing data.

We have also discussed having product "types" where you could choose from a couple different product types. #152 and #160 touch on these.

I'd like to handle the additional types in core, but add as packages. Since nothing has been done towards 'product types' yet.. maybe you could discuss the challenges that you face as you try to implement something like as a package, and we'll adjust core as needed to make sure it's flexible for extending/adding new product types.

Subscriptions #330, and digital goods are other product types that will have similar requirements as well.

@aaronjudd commented on Thu Apr 30 2015

I think the options approach described in #367 could be used to handle this case as well

@spencern commented on Wed May 13 2015

From gitter chat: May 12 2015 12:00 PM

@spencern
I see that the VariantProduct schema has a 'barcode' field. Is this intended to be used for tracking inventory on an item-by-item basis? E.g.

+-- Jacket
|   +-- Black
|   |   +-- Small
|   |   |   +-- Individual Item / Barcode / id
|   |   |   +-- Individual Item / Barcode / id
|   |   |   +-- Individual Item / Barcode / id
|   |   +-- Medium
|   |   |   +-- ...
|   +-- Red
|   |   +-- Small
|   |   |   +-- ...

If so, are there methods already which aggregate the inventory count for these barcoded items, or does that still need to be written?

@aaronjudd
correct, the barcode and sku fields are on each variant (as it's a unique product).
yes some of this exists, but most likely needs some refactoring. I think it’s mostly client side validation. I’ve not looked at it in a while though, as I doubt it’s something that handles more recursion

@spencern commented on Wed May 13 2015

This method of individual item tracking is essential to being able to offer rental products. I've been poking around in the Product and ProductVariant schemas a little bit lately.

Say we have 3 identical mountain bikes.

Mountain Bike
  -- Full Suspension
    -- Small
      -- Barcode: 1
      -- Barcode: 2
      -- Barcode: 3

I'm trying to figure out the best way to store one of these items. Following the schema, it seems like they should be variants where the parentId is the Small variant (to use the above case), but I could see an argument for the parentId being the Full Suspension variant as well.

Anyone else with this need or thoughts on this?

@aaronjudd commented on Wed May 13 2015

You're saying that you have "Small" and that should the visible option, but your inventory, is 20 of the same "product" but each has it's own sku/barcode?

I'm thinking that could be a child variant of "small" (same as existing structure) that we could mark as "type: inventory" and then handle that with some unique view and inventory mgmt.... maybe hide (or not ) for the 'consumer', but use and update for inventory

@markchipman commented on Tue Jun 16 2015

@aaronjudd @spencern "You're saying that you have "Small" and that should the visible option, but your inventory, is 20 of the same "product" but each has it's own sku/barcode?"

I have an almost exact use case, but in a different scenario... imagine something that can be exemplified (such as an ebay item listing) where you have many of the same products (say 500) and you are allowing this specific item to be bought in variable quantities of minimally 1 to x (x being the max number of items remaining in your inventory)... when someone in your commerce site adds the item to his/her cart they are in essence on-the-clock* 'holding or reserving' x qty of the item(s) until his/her checkout is complete. I need a way to mark that specific item/SKU as being reserved or held (until a short threshold datetime is reached to prevent something from being held too long - ie they failed to checkout within the short reservation period of say 5 minutes). So what I'm thinking is that I need to track two things to each item similar to the "barcode" idea presented by Spencer... namely 1. the userId of the person reserving each instance of the available item(s) and 2.) a datetime stamp indicating a hard point in time that the reservation expires and the full reserved qty is made available to everyone once again. (Note: a CRON type job would run through the Mongo Collection every minute or so to remove the expired reservation set for an item.

Instead of polluting the product collection I think perhaps these reservations might make more sense in their own collection which merely alters the product/sku availability quantites when a CRUD event occurs upon the reservation collection.

Thoughts?

@spencern commented on Thu Jul 02 2015

@aaronjudd exactly. Added a PR that enables products to have and track inventory as child variants.

@markchipman I think that this idea should solve your use case too.

What we will also need to do (and perhaps I should break up this issue into multiple sub-issues) is create packages that modify the (inventory) variant schema to add additional fields as necessary - for us it might be rental availability calendar, condition, etc.

for @markchipman it might be reservation status and reservation expiration time or something similar.

@faddat commented on Sat Jul 25 2015

A variation on this theme:

Subscriptions

Do you plan to use a tool like Prisma instead of mongodb (and Meteor)? It would allow to use any Database while having a crud generated and easily bind our own api (or any graphql api) to it.

@kieckhafer commented on Mon Jan 23 2017

Need to purge or reduce HTML footprint in Emails collection after an email has successfully sent.

After 24 hours?
After X days?

@jshimko commented on Mon Jan 23 2017

The email collection was originally created (by me) because the job documents were being cleaned up before you could even get a chance to view them in the UI (which made the email logs UI pointless). So I inserted them into the Emails collection for longer term storage. It looks like I didn't restore the cleanup job for the sendEmail jobs though, so it's currently keeping them in both collections. We obviously don't need that.

So, if we're going to delete email logs after some period of time, I think it probably should be a setting in the UI and maybe even optional altogether (some people may actually want to keep them). Otherwise, people won't know why their email logs are disappearing from the log table in the UI. The publication for the email logs uses a limit param, so it's definitely performant. It only publishes the amount of documents specified in that limit (default: 10). So it's really just the storage space in the db we'd have to consider when saving email logs.

Considering emails can potentially fail to send and that usually requires some human intervention, I think we probably need to be careful about how fast we delete those records. Even a week feels a little quick when you consider that an admin may only check the logs every once in a while. Maybe we need a notification API for failed jobs that sends emails to admins?

This could obviously use a little discussion/brainstorming, so lets talk about it in our technical meeting tomorrow (and here too for those that aren't in the internal meeting).

@jshimko commented on Mon Jan 23 2017

Also FYI, removing the following param from the Job query will allow the sendEmail jobs to be included in the clean up every 3 days with everything else (they'd still exist in the Emails collection)

https://github.com/reactioncommerce/reaction/blob/master/imports/plugins/included/jobcontrol/server/jobs/cleanup.js#L36

Also, note that that cleanup job is a little aggressive with what it deletes. That will permanently delete any job that's 3 days old or older with a status of "cancelled", "completed", or "failed". One potential reason that could be a problem is a job with a status of failed could still be retried (just like in the email logs UI). For example, after an admin fixes whatever made the job fail in the first place, they may want to trigger a retry without having to come up with all of the original job data again. Deleting that job automatically means you've removed that option and they won't be able to retry again without submitting a new job. Sure, most jobs have run through all of their retries or been assessed by day 3, but we still need to be aware of stuff like that when we're potentially cleaning up jobs that other users could have created in their own custom plugins. The current state of things doesn't allow them to prevent that cleanup from happening to their custom jobs. We're currently enforcing it on all jobs.

So maybe we need to somehow tag internal Reaction jobs and only do a cleanup of jobs jobs we create in core code. That'd give users the freedom to do whatever they want with the jobs API within their own plugin and not worry about the app deleting their stuff unexpectedly.

@jshimko commented on Mon Jan 23 2017

Oh, oops. Just remembering...

The Emails collection isn't actually used anywhere. It's strictly for longer storage and some future use cases that haven't been implemented yet (UI, logs, etc.). Nothing in the app accesses it right now though. The email logs UI gets its data right from the jobs collection. The reason for that being the job needs to actually exist to be able to trigger a retry (which you can do from that table).

So yet another variable we need to discuss when it comes to deleting emails.

@spencern commented on Wed Jan 25 2017

That last message about the emails collection seems correct from what we're experiencing.

I don't think there's a serious problem with storing emails long term for the ease of resending order confirmations, etc.

The biggest issue I see with the Emails collection currently is that the entire html content of the email is stored (both in Emails and in Jobs) rather than just storing the variable content and a link to the email template associated. This has resulted in very large collections both in Email and Jobs where the data stored are primarily duplicate template information.

@jshimko commented on Wed Jan 25 2017

The copies in the Job collection can be deleted on a cleanup schedule, so that part is an easy fix. I guess the only trade-off that I can think of with not saving html is if the template file changes at some point in the future, variables from before that change point may not be able to generate an email that represents what was actually sent to the user originally. Perhaps that's not actually an issue, but maybe it's worth a brief discussion? Maybe we version the templates somehow?

I don't know. Just trying to think of a way to have a reliable copy of what was actually sent. I may be overthinking it though. The to/from/subject/variables may be good enough data for the majority of use cases.

@jshimko commented on Wed Jan 25 2017

I do agree that it's a rather insane amount of data replication. 99% of an email template is usually static, so that's a ton of duplicate data in the database.

@kieckhafer commented on Wed Jan 25 2017

All non-static data in emails is passed into it via an object, dataForEmail. You could potentially just store this object for each email instead of the full HTML.

@jshimko commented on Wed Jan 25 2017

Yeah, absolutely. That just means that if the HTML template changes in the future, you no longer have a record of the exact email body that was sent to the user.

However, I totally admit that that may be an imagined problem. Perhaps nobody actually cares about that and I should just shut my mouth. :)

@spencern, as a production user, any thoughts on that?

@jshimko commented on Wed Jan 25 2017

Another thing to consider...

Email services like Mailgun store all of that detail, so people that care about saving that stuff still have options if we choose to not store the email body.

@zenweasel commented on Wed Jan 25 2017

In my experience doing Customer Service, it is very handy to say to a customer that "this is the exact email we sent you on this day" especially when said email may contain disclaimers or particular info about their order (special return policy, etc.). Because customers are sometimes jerks and everybody thinks they're a lawyer™.

I think with GMail, etc. people do have an expectation that emails are retrievable forever.

@jshimko commented on Wed Jan 25 2017

Ok, proposed solution that solves all points...

1. The default template HTML files get imported into the database on first startup.
2. All custom templates already get saved in the database.
3. Version the templates in the database whenever they change.

That'd make sure there's a reference to every email body before variables are injected without having to store redundant copies of the rendered email for every email sent.

A little bit of work, but not terrible. Right?

@spencern commented on Wed Jan 25 2017

I do think there's some value in being able to resend emails, so I definitely hear your concern @jshimko. I feel like there may be better options to store email templates such as versioning templates like you suggested though that may get overcomplicated as well.

I'd probably consider the following an edge case, which seems to be the main thing we're trying to solve for by storing email template html.

1. Send an email to a user.
2. Days/Weeks/Months go by
3. Some breaking change is made to corresponding email template (variables/data don't match 1-to-1 with previous template)
4. Need arises to send or reference email again from the application server.

I agree that having logs of when an email was sent, if it was opened, when it was opened, if/how many links were clicked, etc is very valuable when communicating with the customer, but many SMTP / email providers offer that (postmark does, I think mailgun does as well).

@zenweasel I agree that that information is useful when communicating with customers, and in this era, there is some expectation that all data is stored forever.. That being said, I still think there are probably ways to make it possible to resend an email, (any email, even if the template no longer matches up) without storing the template for every email that is sent.

Potentially that means that if an email gets resent after a breaking change is made to the template that some information is missing or there is extra information (more likely IMHO) that wasn't available before or there are blanks or placeholders, but I don't think that's necessarily a catastrophic scenario.

Worst case scenario, a Cust Service Rep should be able to reference the customers order in the Order database and take a screenshot or write up a one time email to the concerned customer.

@spencern commented on Tue Feb 20 2018

As I mentioned with a comment in #1744

I'm not certain that this is a performance issue at this point, and I'm not sure what the best solution is.
I think at the core of this issue is how we're storing emails (that we're storing raw emails at all?). A better issue might be to change the way we permit storing and resending of emails to use the existing template and data that's available (order/user/shop etc.) at the time that the email is resent.

I'd propose that we close this issue and create a new, more specific issue related to changing the way emails are stored and sent if that's desired.

@aaronjudd commented on Tue Feb 20 2018

Issue moved to reactioncommerce/reaction-feature-requests #26 via ZenHub

@mikemurray commented on Mon Mar 27 2017

React + SSR

This epic is meant to track the conversion of all customer / admin facing components, layouts, templates to React. This means no more Blaze wrappers around any react component, and no Blaze components at any point in the React layout tree. All react all the time.

Keep in mind, for SSR to work, no react component may access document or window while being rendered server-side. If you need them, you'll need to check if they exists before trying to access.

Below List in ordered by approximate priority

Router

• #2049 Must attempt render a react layout first, fallback to blaze until the conversion is complete. (PR #2123) @mikemurray
• #2049 ReactionLayout should support react components / layouts if one is registered (PR #2123) @mikemurray
• BLOCKED Enable SSR support after everything is react @mikemurray
• FlowRouter -> React Router (PR #2123) @mikemurray

Layout

• Separate coreAdminLayout from coreLayout (PR #2123) @mikemurray
• #2049 Layout should use the React version of ReactionLayout, used in the PDP page @mikemurray

Navigation bar

• #2041 Navigation bar itself
• #2042 Cart drawer & checkout popup when adding to cart @andela-aatanda
• #2043 Tag navigation (already has a react version, for the tag component / `imports/plugins/core/ui/core/client/compnents/tags/ & imports/plugins/core/ui/core/client/containers/tagListContainer) @kieckhafer
• #2044 Alerts, Language and other dropdowns

Product Grid

• #2050 Grid layout & items

Search

• #2051 Search modal and all subviews (ui-search package)
• #2050 Grid layout & items for products (needs to use the exact same component as the grid)

Checkout

• #2052 Checkout layout
• #2052 Checkout progress
• #2055 Login (shared with login dropdown and 403 page)
• #2053 & #2052 Address book, (is also used in user profile)
• #2052 Shipping options
• #2052 or #2042 Summary
• #2052 Payment options

Product Detail

• #2032 PDP Variant admin view (PR #2086) @kieha

Orders

• #2045 Orders summary card (PR #2105) @joykare

Admin

• Action view should render a react component if one exists. (DONE, if you register a react component with the same name you use for template while opening an ActionView, it will use the react component before falling back to a blaze template.)
• Orders - Convert and update UX
• Analytics - Convert to React. Should be combined with Analytics Settings, and completely moved into the settings section. - TICKET NEEDED
• Accounts - Everything - TICKET NEEDED
• Localization - #1797 & #1773
• Shop - Everything - TICKET NEEDED
• Email - #1836
• Payment - Everything - TICKET NEEDED
• Shipping - Everything - TICKET NEEDED
• Catalog - Everything - TICKET NEEDED
• Template - Put inside React Card, possibly make medium sized? - TICKET NEEDED
• Reaction Connect - Everything - This will be upgraded with LaunchDock? - TICKET NEEDED
• Shop- #3715
• Search - Put in React Card, form? #3325, #3424
• Shopify Import- #3187
• SMS - #1836
• Social - #1854
• Taxes - Everything - TICKET NEEDED

Issue:
If you sell to a VAT registered customer in the EU (B2B), you can zero rate the sale (0% tax) if the buyer is VAT registered.

Solution:

• Allow users to mark whether they are business (commercial address exists already?)
• If so allow them to mark that they are VAT registered, and validate their VAT number
• Add a tax setting (on custom rates) that allows sellers (if located in the EU) to zero rate taxes to EU VAT companies
• This validation also exists in avalara, but I don't believe it's part of the current integration?

Considerations:
This could be generalised to allow for other tax rules in other regions.

It would be great if users were able to change the quantity they have in their cart without having to delete the item, and go back to the product page. I would think this functionality would be a useful addition in the drop-down cart shown below, but also once at checkout?

TinyPNG offers an API as well as an NPM package to losslessly compress PNGs and JPGs in a programatic way.

See:

• https://tinypng.com/developers
• https://tinypng.com/developers/reference/nodejs

It would be great if Reaction could integrate this as an optional step when uploading images. TinyPNG's compression is known to be very good, and image compression plays a big role in page load times.

Asking non tech-savvy clients to compress their product images before uploading them is a no-go, so having the option to input a TinyPNG API key in the dashboard and let it do the compression work under the hood would be awesome.

These must be on the horizon, as all marketplaces require these features?

I have created a shop-ratings method for myself. However, it would be great if you could specify your schema design in advance, such that I can align my schema. This will prevent the requirements for data-migration.

@aaronjudd commented on Wed Jan 10 2018

The TaxJar implementation has been in limbo, as we only completed TaxCloud and Avalara implementations.

This would close/resolve #1692

There has been some community interest in seeing TaxJar completed. The current state of the code is that the package should work, but that the tax calculation / calls were never implemented.

If this code was completed, we should be able to release this new Tax option.

TaxJar team has suggested we could use: https://github.com/taxjar/taxjar-node

An appropriate task here would also be to update TaxJar Settings converted to react (likely still Blaze, as it was never enabled).

• Enable TaxJar package
• Save settings
• Fetch calculate tax, following patterns of existing tax packages.
• react ui
• tests for calculation/tax being returned in right format.

Hi,

Is it possible to display the country of origin on the product view without creating a plugin?

I'm not sure how this attribute is used at the moment, the country of origin can be set when adding a product but it is not displayed anywhere.

Thanks

When a merchant makes a sale it would be good if they were notified via email. And currently, since only the admin gets notifications they have no way of knowing without checking their 'orders' tab.

@aaronjudd commented on Sat Feb 18 2017

As originally noted in #1699

Add customs declaration for international shipments in Shippo.

See: https://goshippo.com/docs/international

Will require creating a declaration and attaching to the createTransaction method in imports/plugins/included/shippo/server/methods/shippoapi.js

Issue:
Without a full list of elements used in reaction, and their current CSS it takes a long time to create a good custom design.

Suggestion
A jsfiddle or similar with your CSS for all buttons, and tags etc.

It would then be very easy for a designer to edit the CSS for all of these items together, ensuring that the elements are distinct and all work well together.

Alternatively it would be great if you could share your sketch file if you have one?

@spencern commented on Wed Apr 15 2015

Multi Variant Products Use-Case and Suggestion

My company rents ski and snowboard apparel. Some of our products include many options.

• Note #203 and #160 get into this need a little bit, but I feel this will be a more comprehensive place to start the discussion *

Rental Gloves Example

• Gloves
  • Style
    • Mitten
    • Gloves
  • Color
    • Black
    • White
  • Size
    • Small
    • Medium
    • Large
  • Add Glove Liners?
    • Yes
    • No

Sell Through Example

Another example. At the end of the season we sell through our inventory.
Jackets, Pants, etc generally have two variants, such as Color/Style and Size, but at the end of the season we sell through our inventory and add a third variant that is "Condition".

For example, a Jacket we might sell

• Jacket Title
  • Color Options
    • Red
    • Green
    • Blue
    • Black
  • Size Options
    • S
    • M
    • L
    • XL
  • Condition
    • New With Tags
    • Like New
    • Damaged

Custom Variables

We also have the need for a custom variable(s) that can be attached to any product. An example would be adding a name to a product. These custom variables are independent of price and inventory and thus do not need to be factored in as variants.

How could it be implemented?

Considerations

A consideration with variants is that any given variant should be able to impact price and inventory.

For some types of variants, this may be more of a bundle/add-on affect, e.g. my "Glove Liners" example, the inventory that it affects is independent of the core product and the price is in addition to any other calculated price.

For other variants, such as the Jacket example, or Gloves without the liner option, all three options have an affect on inventory and potentially on price of the core product. For example: a Small / Red / New With Tags jacket cannot be substituted for a Small / Red / Like New jacket and vice-versa. Additionally, the price will be different based on it's condition.

How Shopify Does it

Shopify allows up to three options for each product. Options all have the same OptionTitle (such as Color or Size). Once options for a product have been defined, each variant may have a definition Each option has it's own SKU, Price, CompareAtPrice, Barcode, Weight, and Featured Image

How Reaction Could do it?

I'm still coming to a full understanding of exactly how the product and variants interact in ReactionCommerce so push back on these ideas at will.

I think we could potentially expand the ProductVariant Schema include up to a set number of potential options. I think the simplest way would be to add up to 3 or 4 set options - E.g:

ReactionCore.Schemas.ProductVariant = new SimpleSchema
  _id:
    type: String

  ...

  title1:
    label: "Label"
    type: String
  optionTitle1:
    label: "Option"
    type: String
    optional: true
  title2:
    label: "Label"
    type: String
  optionTitle2:
    label: "Option"
    type: String
    optional: true
  title3:
    label: "Label"
    type: String
  optionTitle3:
    label: "Option"
    type: String
    optional: true

Obviously this is not the only way to do this, we could allow for an unrestricted number of product options, but if we can also bundle products (issue forthcoming) in the future, then something like this would satisfy my needs.

We would also have to make some adjustments into the admin interface as well as the product template for products and product variants.

Would love to hear feedback on this as well as if anyone else has similar needs.

@aaronjudd commented on Fri May 01 2015

I've tried to give some additional background information and as a complete a view of the design direction I had been envisioning.

Variants

My view of what defines a variant:

• a variant is a product (it is a sku, something for sale)
• a product is a group of variants
• product.variants is a hierarchical list of infinite child products linked by parentId
• a variant could (potentially) be promoted to be a product
• a variant is a unique self-encompassing product
• a combination of variants make up a product
• a product
  • is already a bundle of products
  • variants already bundle child variants

In your first example, the product could be the "style".

Product "Mitten"->Color(Red)->Size(Small)

This is the case we support currently.

"Add Glove liners" is probably not a variant, but an add-on-product (or an upsell).

In the second example, or where "Style" is a variant,
the schema and methods support more nesting than the current UI, but this is the way it could work:

Product ->
"Hand Warmer"
    -> Style (Mitten)
        -> Color(Red)
            -> Size(Small)
    ->Style(Glove)
        -> Color(Red)
            -> Size(Large)

My intention was to allow infinite creation of parent->child variants and go as deep as needed.

Just as a matter of priorities, I didn't build a deeper hierarchical variant UI when I built the first variant UI. It's probably a good time to give this whole process another iteration if we want to accommodate more use cases (and test cases). The UI work will be the majority of the effort I think, as little should change in the product or variant methods.

We could add a new action on the child variant ui to allow children to be created.

Likely need to refactor the general option selection to be more user friendly with multiple option paths as well...

Options

where variants are products, options are how we can define the handling for variants.

For bundling #368 and multiple variants, we could add an options array to the Product schema.
Although I've not thought through the use case for variant options, they could potentially exist on the ProductVariant schema as well.

# default variants (variant + child variant)
    product.options 
        template: "coreVariants"
            variantId:  [variantId]

# include all these variants in the product price and override
        template: "coreVariantBundle" 
            variants:  [variantId,variantId,variantId]
            variant: **//override all variants*
                price: inherit || <pricing method>
                inventory: inherit || <inventory method>

# include all these variants in the product price and override individually
        template: "coreVariantBundle" 
            variants:  [{variant},variantId,variantId]

# include several products, or product bundles as a bundle with a set price
        template: "coreProductBundle" 
            products:  [productId,productId,productId]
            product:
                price: <pricing method>
                inventory: <inventory method>  
# to hide a variant     
        template: "coreVariantDisabled" 
                variants:  [variantId,variantId,variantId]

# to add on optional variants or products   
        template: "coreProductUpsell" 
            variants:  [variantId]
            products: [productId]

for each template in options we return options.template and load a dynamicTemplate with a helper, similar to the reactionApps helper.

• alternate, or additional pricing methods
• define inventory handling at the product, something that can be easily be made a lot more robust
• adds a publish/hide mechanism for variants (which would need to be enforced)
• testable
• pricing
  • not unique to options, but we need to notify carts with inventory / pricing changes #120
  • pricing for variants with pricing methods
• inventory
  • potential inventory methods
    • chain inventory (tbd)
    • group inventory (tbd)
    • without necessarily needing to maintain single inventory record:
      i.e.: The SKU is but I only have one that is damaged.

It's possible that much of the logic needed could reside in the products publication, where we could transform the client products collection to an ideal standard. Client collections don't need to mirror the actual data, so this would be an ideal place to implement additional rules.

I've had some discussion and thought about wether variants should be it's own collection. I'm still leaning towards a 'rich document' approach where the documents are as self contained as possible.

I think we want to have a complete snapshot of the users collection states, at each significant event - and - I want to be able to say "If I show you this product" versus "another version of this product", which did you choose? This product is going to the cart made up just as the user saw it, and that's how it should live through the fulfillment process.

UI Updates

These might be a bit of work to make elegant UX wise, but not really technically complex.

we'd need to create/update templates for

• bundle product
• upsell
• variant-child (current)
• variant-child-and-more

and some updates to product templates

• update variants to support more children
• add metafields and display to variants
• refactor product to use helper for alternate templates
• refactor cart drawer for alternate templates
  • maybe just some default logic
• update "add to cart" to validate different rules based on options.template
  • upsell or add-on could be an additional cart item
  • bundle would be one cart item

Metafields

The product.metafields are represented as "Details" in the current UI, but they can be, and are intended for reuse, including search, filtering, and variants properties. These product metafields are not factored in as variants, but metafields exists in variants as well.

Handling of metafields on the variants hasn't been implemented, it's in the Schema though. I think this is what you are looking for when you mentioned 'custom variables'.

However, with your second example it could make sense that condition would be another variant. As you mentioned, some additional warehousing metafields data is likely going to be needed, so you could clone variant of the original and use metafields for that warehousing information (we'd need to adjust inventory as well) - might be a easy UI trick there (split this variant).

metafields on the variant could go partway for #203.

But here, I think we could possibly merge the Products and ProductVariants schemas (adding description, options and other "product fields" to variants #203) making them truly identical.

down the roadmap

Thinking further ahead, there a couple features we have on the roadmap to take into consideration as well:

• product and variant hierarchy management See #150
• revision control See #151
• downloadable products #161
• merge the Products and ProductVariants schemas (adding description, options and other "product fields" to variants #203)

There is a lot here, and I probably missed some big holes - and I may have failed to clearly tie everything together - so bring on the feedback. (and hopefully our next posts can be shorter!)

@spencern commented on Tue May 05 2015

Hopefully this is shorter. Trying to respond to all of the points you bring up:

We agree about what a variant is and most of the nuances around that type.

• a product
  • is already a bundle of products
  • variants already bundle child variants

Is this part of the vision, or the way the schema works currently?

The schema and methods support more nesting than the current UI.

I should have looked at the schema more closely, this is good to know and fits our needs just fine, should make the 'multi-variant' issue trivial to implement.

Likely need to refactor the general option selection to be more user friendly with multiple option paths as well.

👍 Agreed on this point. I've got some ideas that I'll start another issue with.

Product options

I like the idea of adding some type of options array to the product schema. I'm also not sure what the use-case for having options on the variants is.

This seems like it will work well for both bundled products as well as upsell products. I should be able to start working on an implementation for this now.

Are there existing pricing and inventory methods?

You might need to explain a little better how the product publication could be used to implement additional rules for these inventory/pricing methods as I don't think I'm following that idea very well.

It seems as if this direction could help solve #161 downloadable products as well as unforseen future product needs.

UI Updates

All of your UI suggestions make sense, definitely some work to make all of this play nice together, but pretty straightforward.

Using Metafields to store custom product variables seems obvious now that you've mentioned it. Should work well for what we need.

Combining Product and ProductVariant Schemas

When you suggest this, do you mean eliminate one of these entirely? It seems the closer we get towards variants being 'child-products' and having optional children themselves that this might be a good way to simplify. Not sure what all of the implications of this are though.

@aaronjudd commented on Fri Feb 19 2016

Related conversation: see reactioncommerce/reaction#741

@aaronjudd commented on Wed Feb 14 2018

Feature request that requires more definition to meet our current issue guidelines.

The React team released version 16.3 a couple days ago.

This new version (featuring a new Context API) will undoubtedly be useful to lots of developers working on Reaction projects.

On a related note, separation of the client and back-end means no more Meteor session variables. As they are often used as global reactive variables, leveraging the Context API to replace them makes a lot of sense to me. Less magic - better maintainability. 😀

There are no breaking changes announced for this version.

An implementation of Disqus would allow

i) creation of a Disqus community page for marketplaces
ii) could be used to allow buyers to ask sellers questions about products

@lindoelio commented on Sat Jan 06 2018

Rocket.Chat is the leading free open source chat Slack alternative, unlimited. Provides a great LiveChat features, besides free audio and video conferencing, guest access, screen sharing, file sharing, LDAP Group Sync, two-factor authentication (2FA), E2E encryption, SSO, dozens of OAuth providers and unlimited users, guests, channels, messages, searches and files.

Reaction Commerce with Rocket.Chat can to deliver the best conversation experience between shoppers and sellers, in all levels, towarding to a growing conversion.

🇧🇷 #ReactionBR

@gregorynicholas commented on Tue Jan 09 2018

👍

@Teralabs commented on Thu Jan 25 2018

👍

@Teralabs commented on Tue Feb 13 2018

try, to allow crossdomain:
import { BrowserPolicy } from "meteor/browser-policy-common";

BrowserPolicy.content.allowOriginForAll("*"); //insecure, change to the chat domain

than add the rocket chat script to an included html file

@aaronjudd commented on Wed Aug 30 2017

This is a general task to define a few different up sell components for the PDP page, and begin the design tasks for this. There are a few existing issues on this, we can gather the info/specs here.

@spencern commented on Wed Oct 04 2017

@cindyfirestone can you add some more details to this issue?

@cindyfirestone commented on Wed Oct 04 2017

A simple way to do this would be to pull items with 1 or more tags. We should limit how many related items should show, and this should be randomized so the same items don't always show up.

@Itsneilpatil commented on Wed Oct 04 2017

For the simplest use cases, related product recommendations can either assist shoppers to see like products with similar facets/attributes (display other blue road bikes) and/or provide complementary recommendations (display bike lock(s) for bike that has been carted).

The initial application of related products for finding "similar" products could be accomplished by matching all the tags of the PDP and/or specific carted item and then ranking the catalog items based on the total number of tag matches. For example, if a PDP contains tags Bike, Blue, Child. Product A with tags Bike, Child would rank higher than Product B with tag Bike.

For "complementary" product recommendations, in order to properly cross-sell other items, an additional tag would be needed to be inserted into the lookup to properly surface truly complementary products. For example, for a bike that was carted, there would be a need to have a static setting to lookup products that are tagged as accessories, services, or other tags determined specific by each retailer. The system would then retrieve & rank as it would normally - but with the additional tag inserted by the system.

Other things to consider/futures:

• Ability to limit retrieved products within a specific price point +/- x% from currently viewed/carted product.
  -Further rank products based on current stock levels - i.e. recommend perishable products with the highest level of inventory, or display limited "last 1 left" products.
  -Further rank products based on popularity - i.e. # sold in the past x days.
  -Further rank products based on past purchase combinations - i.e. Product A was most often purchased with Product B (carted product).

@kieckhafer commented on Mon Jan 23 2017

Need to purge or reduce HTML footprint in Emails collection after an email has successfully sent.

After 24 hours?
After X days?

@jshimko commented on Mon Jan 23 2017

The email collection was originally created (by me) because the job documents were being cleaned up before you could even get a chance to view them in the UI (which made the email logs UI pointless). So I inserted them into the Emails collection for longer term storage. It looks like I didn't restore the cleanup job for the sendEmail jobs though, so it's currently keeping them in both collections. We obviously don't need that.

So, if we're going to delete email logs after some period of time, I think it probably should be a setting in the UI and maybe even optional altogether (some people may actually want to keep them). Otherwise, people won't know why their email logs are disappearing from the log table in the UI. The publication for the email logs uses a limit param, so it's definitely performant. It only publishes the amount of documents specified in that limit (default: 10). So it's really just the storage space in the db we'd have to consider when saving email logs.

Considering emails can potentially fail to send and that usually requires some human intervention, I think we probably need to be careful about how fast we delete those records. Even a week feels a little quick when you consider that an admin may only check the logs every once in a while. Maybe we need a notification API for failed jobs that sends emails to admins?

This could obviously use a little discussion/brainstorming, so lets talk about it in our technical meeting tomorrow (and here too for those that aren't in the internal meeting).

@jshimko commented on Mon Jan 23 2017

Also FYI, removing the following param from the Job query will allow the sendEmail jobs to be included in the clean up every 3 days with everything else (they'd still exist in the Emails collection)

https://github.com/reactioncommerce/reaction/blob/master/imports/plugins/included/jobcontrol/server/jobs/cleanup.js#L36

Also, note that that cleanup job is a little aggressive with what it deletes. That will permanently delete any job that's 3 days old or older with a status of "cancelled", "completed", or "failed". One potential reason that could be a problem is a job with a status of failed could still be retried (just like in the email logs UI). For example, after an admin fixes whatever made the job fail in the first place, they may want to trigger a retry without having to come up with all of the original job data again. Deleting that job automatically means you've removed that option and they won't be able to retry again without submitting a new job. Sure, most jobs have run through all of their retries or been assessed by day 3, but we still need to be aware of stuff like that when we're potentially cleaning up jobs that other users could have created in their own custom plugins. The current state of things doesn't allow them to prevent that cleanup from happening to their custom jobs. We're currently enforcing it on all jobs.

So maybe we need to somehow tag internal Reaction jobs and only do a cleanup of jobs jobs we create in core code. That'd give users the freedom to do whatever they want with the jobs API within their own plugin and not worry about the app deleting their stuff unexpectedly.

@jshimko commented on Mon Jan 23 2017

Oh, oops. Just remembering...

The Emails collection isn't actually used anywhere. It's strictly for longer storage and some future use cases that haven't been implemented yet (UI, logs, etc.). Nothing in the app accesses it right now though. The email logs UI gets its data right from the jobs collection. The reason for that being the job needs to actually exist to be able to trigger a retry (which you can do from that table).

So yet another variable we need to discuss when it comes to deleting emails.

@spencern commented on Wed Jan 25 2017

That last message about the emails collection seems correct from what we're experiencing.

I don't think there's a serious problem with storing emails long term for the ease of resending order confirmations, etc.

The biggest issue I see with the Emails collection currently is that the entire html content of the email is stored (both in Emails and in Jobs) rather than just storing the variable content and a link to the email template associated. This has resulted in very large collections both in Email and Jobs where the data stored are primarily duplicate template information.

@jshimko commented on Wed Jan 25 2017

The copies in the Job collection can be deleted on a cleanup schedule, so that part is an easy fix. I guess the only trade-off that I can think of with not saving html is if the template file changes at some point in the future, variables from before that change point may not be able to generate an email that represents what was actually sent to the user originally. Perhaps that's not actually an issue, but maybe it's worth a brief discussion? Maybe we version the templates somehow?

I don't know. Just trying to think of a way to have a reliable copy of what was actually sent. I may be overthinking it though. The to/from/subject/variables may be good enough data for the majority of use cases.

@jshimko commented on Wed Jan 25 2017

I do agree that it's a rather insane amount of data replication. 99% of an email template is usually static, so that's a ton of duplicate data in the database.

@kieckhafer commented on Wed Jan 25 2017

All non-static data in emails is passed into it via an object, dataForEmail. You could potentially just store this object for each email instead of the full HTML.

@jshimko commented on Wed Jan 25 2017

Yeah, absolutely. That just means that if the HTML template changes in the future, you no longer have a record of the exact email body that was sent to the user.

However, I totally admit that that may be an imagined problem. Perhaps nobody actually cares about that and I should just shut my mouth. :)

@spencern, as a production user, any thoughts on that?

@jshimko commented on Wed Jan 25 2017

Another thing to consider...

Email services like Mailgun store all of that detail, so people that care about saving that stuff still have options if we choose to not store the email body.

@zenweasel commented on Wed Jan 25 2017

In my experience doing Customer Service, it is very handy to say to a customer that "this is the exact email we sent you on this day" especially when said email may contain disclaimers or particular info about their order (special return policy, etc.). Because customers are sometimes jerks and everybody thinks they're a lawyer™.

I think with GMail, etc. people do have an expectation that emails are retrievable forever.

@jshimko commented on Wed Jan 25 2017

Ok, proposed solution that solves all points...

1. The default template HTML files get imported into the database on first startup.
2. All custom templates already get saved in the database.
3. Version the templates in the database whenever they change.

That'd make sure there's a reference to every email body before variables are injected without having to store redundant copies of the rendered email for every email sent.

A little bit of work, but not terrible. Right?

@spencern commented on Wed Jan 25 2017

I do think there's some value in being able to resend emails, so I definitely hear your concern @jshimko. I feel like there may be better options to store email templates such as versioning templates like you suggested though that may get overcomplicated as well.

I'd probably consider the following an edge case, which seems to be the main thing we're trying to solve for by storing email template html.

1. Send an email to a user.
2. Days/Weeks/Months go by
3. Some breaking change is made to corresponding email template (variables/data don't match 1-to-1 with previous template)
4. Need arises to send or reference email again from the application server.

I agree that having logs of when an email was sent, if it was opened, when it was opened, if/how many links were clicked, etc is very valuable when communicating with the customer, but many SMTP / email providers offer that (postmark does, I think mailgun does as well).

@zenweasel I agree that that information is useful when communicating with customers, and in this era, there is some expectation that all data is stored forever.. That being said, I still think there are probably ways to make it possible to resend an email, (any email, even if the template no longer matches up) without storing the template for every email that is sent.

Potentially that means that if an email gets resent after a breaking change is made to the template that some information is missing or there is extra information (more likely IMHO) that wasn't available before or there are blanks or placeholders, but I don't think that's necessarily a catastrophic scenario.

Worst case scenario, a Cust Service Rep should be able to reference the customers order in the Order database and take a screenshot or write up a one time email to the concerned customer.

@spencern commented on Mon Feb 19 2018

As I mentioned with a comment in #1744

I'm not certain that this is a performance issue at this point, and I'm not sure what the best solution is.
I think at the core of this issue is how we're storing emails (that we're storing raw emails at all?). A better issue might be to change the way we permit storing and resending of emails to use the existing template and data that's available (order/user/shop etc.) at the time that the email is resent.

I'd propose that we close this issue and create a new, more specific issue related to changing the way emails are stored and sent if that's desired.

@zenweasel commented on Mon Apr 17 2017

Putting this here as a placeholder because multiple people have requested it in the Gitter chat.

Beyond the simple T-shirt/Shoe single price product type we have now, we should create a configurable product type that allows you select multiple options which affect the top-line price.

An example might be purchasing a car, where you want to have "add-ons" where choosing each one will increase the price.

Additionally a more advanced implementation would allow groupings. An example might be purchasing a computer where you select from CPU/memory, etc. where you choose one option from multiple choices in each category, each affecting the price.

@aaronjudd commented on Fri Jul 17 2015

From discussion started on https://github.com/reactioncommerce/reaction-core/pull/146

I've been thinking that it's probably time to consider more complex publishing / workflow rules. I think maybe "isVisible" could be refactored to a more flexible object (and probably preserve isVisible as a method):

Products

    active: "false" || boolean  # replace isVisible for creator
    publish: [ beginDate, endDate] # replaces isVisible for public

When a product is `active`, it's visible / not visible to it's creator.

When a product is published we add a start date, with an *optional *end date.

There could potentially be multiple date ranges (for example, to publish only on specific weekends)

When viewing a grid, we'll add some UI element to toggle the appearance / publication in grids of "active:false" products.

Shops

    workflowRoles:[
        products:
            create: [ {shopId,'createProduct'} ]
            publish: [ {shopId,['admin','owner'] } ]
            view:[ {shopId,'guest'} ]
    ]

Here's some use cases for this publishing structure:

* A user with appropriate permissions  `['admin','owner','createProduct']` can create a product.
* Shop A should be able to give Shop B access to unpublished view
* Shop A (uber shop) could have permission to publish products from Shop B (and perhaps Shop B cannot their own products)
* Shop B can publish products, but only to their shop (i.e.: not Shop A)
* Shop B users can view products from Shop A, but only when shop A allows viewing
* default permissions can be setup like in example definition, as the fallback in case workflowRoles isn't defined.

Possibly we should consider route/tags in publishing permissions as well, for instance, if a certain user has permissions to publish without review in just one category.

* workflowRoles could be specific to Tag

@spencern suggests:

Here's a few more suggestions for product visibility rules and flags
CatalogVisible: true: product is will show up in relevant catalog pages, category searches, etc
CatalogVisible: false: product will only be visible via direct link

I think that just not tagging something could work to exclude it from the catalog, but ideally (in the future perhaps) we will be able to create 'smart' catalogs that organize ever product from a given vendor, within a certain price range, etc. It's in those cases that having an include/exclude flag might be nice.

@aaronjudd commented on Sat Sep 17 2016

Moving this to the 0.17 release - this is a more detailed discussion on the product publishing workflow that is partially implemented with new PDP updates. when we finish those for 0.17 we should review the items here and close/pluck into new issues as needed. See #415 and #151

@aaronjudd commented on Thu Apr 27 2017

Very old discussion of publishing workflows, that should be reviewed and closed as new catalog workflows are defined.

@zenweasel commented on Wed Feb 14 2018

Closing to Review roadmap

@aaronjudd commented on Wed Feb 14 2018

Feature request that requires more definition to meet our current issue guidelines.

@bstocks commented on Fri Jan 23 2015

For Beta, this could be as simple as properly configured Google Analytics events.

@aaronjudd commented on Sat Sep 17 2016

Closing, N/A

Goal - take our current operator experience and make it 100% view across every view.

Two reasons -

1. For storefronts that are using the graph ql starter kit it's confusing to have a second storefront in view.
2. To maximize screen real estate as we move forward for larger ecommerce builds (more products, more features etc)

@amalan-shenll commented on Mon Apr 30 2018

In RC 1.11.0, in prerender.js
prerender.set("prerenderToken", process.env.PRERENDER_TOKEN);
prerender.set("host", process.env.PRERENDER_HOST);
prerender.set("protocol", "https");
this is code for prerender.io configuration.
it allows to env variable for prerenderToken and host.

issue
prerender.io always redirecting to https where our demo site support only http

reason
prerender.set("protocol", "https");

expecting change
pls change hardcoded protocol to load from env setting like
prerender.set("protocol", process.env.PRERENDER_PROTOCOL);
https://github.com/reactioncommerce/reaction/blob/7a7612033fcb044156945f6949169f8019296186/server/startup/prerender.js#L9
which may allow developers to set protocol type in env settings

Thank You

@janat08 commented on Sat May 13 2017

I'm looking for multidimensional filters, such that you can look for category of merchandise and then merchandise parameters as in: categories vape liquids, vape equipments as categories, and then manufacturers and price ranges and such.

Your average webstore will be organized in this way, and supporting multidimensional browsing doesn't require that there's any kind of reordering of schema since they can still use tags (make category tags mandatory though).

@aaronjudd commented on Mon May 15 2017

A couple thoughts here.. we've seen people build this functionality, extending the tag based search we have as a default. I'd also say that this is a better case for something like ElasticSearch as an external search/index, that could a quickly added as a plugin to Reaction. I'd suggest that this currently isn't an enhancement that we're looking to add to the core, but it is a common request.

@janat08 commented on Wed Aug 09 2017

I'd be curious to see what you've seen.

@janat08 commented on Wed Aug 16 2017

From what I see you're halfway there with branching categories> vape -> [liquids/equipment]. That's what multi dimensional filters stand for, but I'd be willing to stretch it further with price filters, and other product param filters (make/color).

@janat08 commented on Sun Nov 12 2017

price search is missing

@joelchen commented on Tue Nov 01 2016

Following #1512, a Points Reward feature similar to https://woocommerce.com/products/woocommerce-points-and-rewards is highly desired. I can fully transition my client's E-Commerce website to Reaction Commerce with the addition of this feature.

@aaronjudd commented on Fri Nov 04 2016

Good idea, I'll keep this in mind.
Do you know of any services that might provide this functionality? Always looking for good integrations..

Feature:
I believe the shop route: "/shop/:shopSlug" should be set to the products template by default, rather than to match the index template?

Perhaps this is as issue rather than a feature request?

Method:
This would be very easily changeable in imports/plugins/core/router/lib/router.js. Link here: https://github.com/reactioncommerce/reaction/blob/766c97ebfacec67afecedb021cb3bac79658d1f1/imports/plugins/core/router/lib/router.js#L592

*I am already doing this myself in my build and can verify it works

@gouthamve commented on Wed Jun 03 2015

I think there should be an ability to add and delete pages directly from the dashboard.

Like there will be a CMS package where we can control the pages shown in the footer through this package, And all the pages can be edited via https://github.com/ongoworks/meteor-content-areas and also there will be another field on the CMS package dashboard that will have settings for the routes and if this page should be available in the footer.

This will help people add new pages easily.

I will first close #216 by implementing the content-areas and then proceed to creating routes via db and then the dashboard.

@alexmironof commented on Mon Jun 29 2015

Is there any news? 😄
We actually trying to figure out how to make tags to look more like a classic categories (a simple cms page with meta, content, seo, etc. and products of course)

Simple pages are done here dukeondope/reaction-static-pages/

@aaronjudd commented on Wed Jul 01 2015

@KEFIRCHIK yes - we're planning to start next week on core-cms functionality. really!

@alexmironof commented on Wed Jul 01 2015

Oh so glad to hear it :) actually we achieve some results with our extensions. I'll show it tomorrow

@HadenHiles commented on Sat Oct 08 2016

Has there been any progress on this? The last comment was "a year ago" and this is a feature I need for my current project. The reaction-flat-pages package from atmosphere doesn't work with the latest Meteor/ReactionCommerce update that utilizes ES6 imports.

If anyone could point me in the right direction I would greatly appreciate it :)

@aaronjudd commented on Mon Oct 10 2016

@HadenHiles CMS features are still on the roadmap(0.20), and we're still actively planning to build that functionality in the core. I'm not sure if that package is going to get ported over to the modules as is, but it shouldn't be that tough.

@terrelltechsup commented on Tue May 02 2017

I do not know how far this has progressed, but I have been testing with the Yootheme Pro static page and template builder and it may be something worth taking some queues from with regards to providing the non-dev end user the ability to add static content, control header/footer content, and style their templates visually.

@josx commented on Thu Oct 05 2017

@aaronjudd I will need this feature in the near future.
How can we help to build it up?
Are you thinking to make a custom cms over reaction, or are going to integrate another cms?
what is you plan on this?

@zenweasel commented on Wed Feb 14 2018

Closing to Review roadmap