This repository is only being used to track issues for new features for Reaction Commerce.
Anything not a bug, or a current task in the https://github.com/reactioncommerce/reaction repo is moved to this repository for tracking.
Reaction Feature Requests
This repository is only being used to track issues for new features for Reaction Commerce.
Anything not a bug, or a current task in the https://github.com/reactioncommerce/reaction repo is moved to this repository for tracking.
Feature:
For true internationalisation sellers should be able to specify which regions / countries they will ship to.
Considerations
@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
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
@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
A user with orders permissions should be able to refund shipping for an order.
Refunding the shipping for an order should update the order status as Shipping Refunded.
Refunding the order should trigger an Order Refunded event.
The Order Refunded event should send an email to the customer informing them of the refund having been initiated and add a notification to their notification list.
Management implementation of ideas introduced in #150 "Product Inheritance Management" and #1731. The design goal is to be able to modify the properties of all selected Catalog
items (being product & content) where the shared properties are the same value. This could be extended to audience specific property values in the catalog (and perhaps editable translations for localization).
Additional publishing properties we'll need to consider.. to publish or not, to accept or not, position, etc.
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.
@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)
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...
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.
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.
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
For marketplace sellers (and even the main store) = Provide a default Purchase Order (P.O) "payment gateway" option for those who just need to test and/or for those who truly do not need a payment gateway because they are B2B and depend on their external payment methods by using a P.O.
Node: 9.5.0
NPM: 5.6.0
Meteor Node: 8.9.4
Meteor NPM: 5.6.0
Reaction CLI: 0.27.0
Feature:
For Peer to Peer marketplaces, or B2B marketplaces, for shop owners/admins payment should be possible using their existing stripe connect account.
Benefits:
Suggestion:
@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..
@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
@aaronjudd commented on Wed Feb 14 2018
Feature request that requires more definition to meet our current issue guidelines.
@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.
Editing custom routes in register.js
should trigger a server restart and changes should take effect.
Changes only seem to take effect if the database is reset.
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.
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.
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.
The current behavior only allows you to attach an image to a product and a variant. But sometimes customers want to have a canonical image for a top-level product where all the variant images are specific to those variants. For example, maybe the top level image is an collage showing all the colors of a shoe, while the variant images are just of the single color.
This would also make it easier/simple for the grid to determine which image should be shown for a product.
I know the current behavior (not allowing this) was intentional but I am suggesting we change it.
These could just be represented by leaving the variantId
blank in the metadata
If the Shippo integration is being used:
Users with permission to view and process orders should be able to print shipping labels for all selected orders.
These labels should be consecutively displayed ready for print in a single document with page breaks between each order, sized appropriately for the label printer.
Once the print document is generated, the orders should all have an "Label Printed" event added to their order history. (There can, and should, be multiple "Label Printed" events if the label is printed multiple times)
Any orders that are in the Packed state should be automatically progressed to the "Labeled" state.
See: #2325 for how to select orders for bulk processing.
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
@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
Shipping providers that do dynamic estimates need a way of knowing what the size of the actual box is going to be as this is the only thing that they care about.
We need to create a way of mapping product dimensions to box sizes that the customer uses. Code that closes this ticket would do two things:
Create an extension point for something like provides: boxCalculation
that provides a function that takes the cart and returns an array of box dimensions that can be passed to a shipper for shipping calculations.
Create a plugin that provides this including:
A simple method that just sums up the cubic dimensions of all products and distributes them over the available boxes. We are assuming that customers can build into their dimensions calculations any allowance for packing/padding/odd sizes.
A UI settings panel for creating these boxes and the dimensions that they accommodate
We probably want to ask design for input on the settings panel but I feel like we can start work on this without a design for now.
@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.
@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
@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
@carlos-olivera commented on Tue May 16 2017
WOOOW! :)
@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:
Hey guys,
I was messing around with reaction for a little bit and it is awesome. I already knew it for a long time but you guys are taking it to a next level and thank you for that.
Inspite, I have a doubt on a feature, since I don't have completely sure if it is possible: Are the tags and product information supporting i18n / locales?
Just to let it clear, I was able to change the locale of the interface but I didn't found a way to internationalize tags and/or product info (such as title, description, etc).
If it's not possible, I'm willing to help and contribute on it. Thanks!
@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:
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
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?
@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
@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
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.
@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.
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
@nenti commented on Sat Oct 15 2016
In some e-commerce scenarios shipping address is not required and thus you can remove the workflow step in the checkout process.
When converting the cart to order on completing the checkout process an error occures and order never completes.
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.
@spencern commented on Wed Apr 15 2015
My company rents ski and snowboard apparel. Some of our products include many options.
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
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.
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.
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
Option 1 - Color | Option 2 - Size | Option 3 - Condition | QTY | Price |
---|---|---|---|---|
Red | Small | Like New | 4 | $65 |
Red | Medium | Like New | 3 | $65 |
Blue | Small | Damaged | 1 | $25 |
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.
My view of what defines a variant:
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...
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.
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
and some updates to product templates
options.template
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.
Thinking further ahead, there a couple features we have on the roadmap to take into consideration as well:
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.
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.
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.
Product
and ProductVariant
SchemasWhen 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.
@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.
@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.
@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
It will be nice if we could add simple html tags like (<br>
, <li>
, <p>
.etc) for product description, or maybe if the description field could just honor the spacing.
Currently it removes all the spaces and converts the text into a simple string. Thank you.
@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)
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...
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.
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
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
@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.
@mikemurray commented on Mon Mar 27 2017
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
ReactionLayout
should support react components / layouts if one is registered (PR #2123) @mikemurraycoreAdminLayout
from coreLayout
(PR #2123) @mikemurrayReact
version of ReactionLayout, used in the PDP page @mikemurrayui-search
package)template
while opening an ActionView, it will use the react component before falling back to a blaze template.)Marketplace, Shop and Affiliate owners should be able to edit the permissions for any group associated with their shop or marketplace. E.g. maybe you don't want shop owners to be able to create tags, should be able to remove that from the default shop owner permission set.
For shop / affiliate owners - they should be able to customize what permissions are granted by default when they invite another person to help them administer their shop.
When the permissions of a group change, any user that has that permission group should also have their permissions changed to match the updated group permissions as well. Users who have a custom set of permissions that originally started with a group permission should not have their permissions altered.
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:
Considerations:
This could be generalised to allow for other tax rules in other regions.
The current Shippo documentation is not sufficient for understanding the existing implementation.
After a Slack integration has been setup (#2346) users with orders permissions should be able to click a button to share an order via slack to a user or channel.
@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).
@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.
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.
Tax calculation is based on item subtotal and does not include taxes.
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.
Orders with tracking subscriptions must trigger an event whenever the shipping tracking gets updated.
There should be specific emails and notifications that get triggered for specific updates.
Updates:
TRANSIT
DELIVERED
FAILURE
RETURNED
UNKNOWN
An example from my Stripe module for Magento 2:
Reaction Commerce does not provide an ability to customers to reuse previous bank cards without re-entering its credentials again:
Just place a repeated order with Stripe.
Node: 9.4.0
NPM: 5.6.0
Meteor Node: 8.9.3
Meteor NPM: 5.5.1
Reaction CLI: 0.24.2
Reaction: 1.6.4
Reaction branch: master
@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:
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
@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.
A declarative, efficient, and flexible JavaScript library for building user interfaces.
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
An Open Source Machine Learning Framework for Everyone
The Web framework for perfectionists with deadlines.
A PHP framework for web artisans
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
Some thing interesting about web. New door for the world.
A server is a program made to process requests and deliver data to clients.
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
Some thing interesting about visualization, use data art
Some thing interesting about game, make everyone happy.
We are working to build community through open source technology. NB: members must have two-factor auth.
Open source projects and samples from Microsoft.
Google ❤️ Open Source for everyone.
Alibaba Open Source for everyone
Data-Driven Documents codes.
China tencent open source team.