Minimum viable product (MVP) features (OCC-61)

bleroy commented 6 years ago

The work will focus at first on porting a minimum viable feature set:

Product, price, and inventory parts and/or fields (those were a single part in Nwazet) Note: not all products have a price
Shopping cart
Checkout (probably redesigned around Orchard Workflows)
Base infrastructure for payment, plus one implementation (Stripe)
Order content type and management screens (including a redesign and refactoring of the order part)
Workflow activities for most of the above
Shipping infrastructure and default implementation
Tax infrastructure and default implementation

Globalization should be taken into account at every step.

This issue exists so we can discuss what features should go into the minimum feature set that we build first. Discussion of the design of each of the features should happen in their respective issues (links above).

Jira issue

DrewBrasher commented 4 years ago

I would be happy to help with this if there is anything you want me to work on.

bleroy commented 4 years ago

Hi @DrewBrasher ! Sorry for the delay. There's a number of things that would be good contributions at this point in time, depending what you're interested in. Starting shipping and/or tax are good ones. Implementing them entirely can be a huge amount of work, but implementing the default minimal implementation is very manageable. Another thing is the order management screen. It exists, but is very rough, so if you're interested in making things nice and useable, that can be a good one. Cheers!

DrewBrasher commented 4 years ago

@bleroy I will start with the order management.

mwpowellhtx commented 2 years ago

Interested in perhaps chipping in here. Certainly without having to reinvent wheels, per se. I found scanning the Orchard Commerce articles, the ony hangup I had was in the Record based ContentPart<> generic. Not there in OC, for starters, and not sure quite what the analog and/or migration path would be into an OC based approach.

From there, we're interested in a Square payment method, for starters. Probably extending that out to Gab Marketplace, and others.

mwpowellhtx commented 2 years ago

This is an interesting statement.

Note: not all products have a price.

I would say from a P+L perspective, yes, ALL products have a price, or at least a 'cost' associated with them. Not all prices may be conveyed to a consumer, i.e. you may have promos, loss leaders, that sort of thing. But from an accounting perspective, the books are what they are. So perhaps that property is more akin to something like:

// i.e. whether that is 0m or actually nullable, is another question
// i.e. with queries rolling up Price ?? 0m in the aggregate, for instance
public virtual decimal? Price { get; set; }

I might also steer clear of Azure based class structures, i.e. Amount. Not everyone will want to assume Azure for this; we are not. In fact we are probably intending to deploy to an AWS (non-Azure) environment. Decimal, yes; Amount, no. If you want to adapt into Azure, that's perfectly fine, then contain that adaptation in another module, assembly, etc.

Perhaps topic best broken out to another issue, discussion, etc.

bleroy commented 2 years ago

If all your products have a price, that's fine, you can enforce that.

Amount has nothing to do with Azure. What makes you think it does? the type is defined here: https://github.com/OrchardCMS/OrchardCore.Commerce/blob/efd0e30f42e9c3160804a50c880b1929b30020e7/MoneyDataType/Amount.cs

mwpowellhtx commented 2 years ago

Amount has nothing to do with Azure. What makes you think it does? the type is defined here.

Ah okay, I did not see that. I did however find Amount in the Microsoft Azure docs, funnily enough in a Billing namespace.

bleroy commented 2 years ago

As for your original question, the records-based approach was just Orchard's content model. OC is document-based, so has no use for records. If you wanted to migrate from one to the other, that wouldn't be specific to Commerce, and as far as I know there wasn't a goal for back-compat, so your best bet is probably to go through export and import.

mwpowellhtx commented 2 years ago

As for your original question, the records-based approach was just Orchard's content model. OC is document-based, so has no use for records.

My experience with document databases is valuable here, especially potentially decoupling detail records from parent records, for scalability, performance reasons, at least coming from a MartenDB. Interested to learn and do more vis-a-vis OC, Commerce, where that is concerned.

If you wanted to migrate from one to the other, that wouldn't be specific to Commerce, and as far as I know there wasn't a goal for back-compat, so your best bet is probably to go through export and import.

Not to be misconstrued or anything. Our starting point is OC, not Orchard, or Orchard Commerce. Commerce migration paths, ports, etc, are my interest here.

Are y'all conducting meetings to kick off and pull things forward over this project?

bleroy commented 2 years ago

Orchard Core has an import feature, so as long as you can build a file in the format it takes, you should be able to import anything. I'd ask about that on an Orchard Core forum. We're not conducting meetings specifically for this commerce project, no. There are two weekly meetings for Orchard Core though.

mwpowellhtx commented 2 years ago

Orchard Core has an import feature, so as long as you can build a file in the format it takes, you should be able to import anything. I'd ask about that on an Orchard Core forum.

As I said, we are not starting from Orchard, or Orchard Commerce. We are launching a brand new OC based site, Commerce enabled is our goal. Anyway, transit the welcome discussion for on-boarding alignment purposes. Let me know what the protocols are for picking up on issues, contributing, etc.

Thanks...

bleroy commented 2 years ago

If you're interested in contributing on a bug fix, just comment on it to mention you're working on it, that should suffice. If interested in working on a specific feature, if there isn't a feature ticket already, create one. In any case, first step would be to describe the design you'd like to go for so we can check it's inline with the goals and design principles of the project. Just a note that in case you wanted to do things your way or we have a disagreement on design, forking is perfectly fine too. The license is very liberal and we're fine with any usage, including private and commercial.

mwpowellhtx commented 2 years ago

In any case, first step would be to describe the design you'd like to go for so we can check it's inline with the goals and design principles of the project.

Key statement there, yes. That's the sort of engagement, conversation, we'd all benefit from.

mwpowellhtx commented 2 years ago

Scanning through the MVP feature set... A bit confused how far along things really are. Especially given the timeliness of some of the comments, 1, 2, 3+ years aged at this point. Scale of 1-10 readiness, about a 3? 3.5? Are the efforts parked on branches? Someone's local and/or github repo, branch, etc? Thank you...

bleroy commented 2 years ago

Product catalog and shopping cart are done and that's about it. I'm not currently writing code for the project. I'll let others chime in if they are. Anyone who wants to use this project should be ready to fill in the holes themselves.

DrewBrasher commented 2 years ago

I'm not right now but I'm still interested in helping. I decided I needed more experience in Orchard Core before I started trying to help but I'm just finishing up a project that used Orchard Core CMS so I'm planning to try to start helping with this soon.

sarahelsaig commented 2 years ago

Please check out the latest news on the MVP in this discussion thread: Survey Results and MVP

Piedone commented 1 year ago

Shouldn't this be closed now, with the MVP having been shipped?

sarahelsaig commented 1 year ago

Good point, this can be closed. (see announcement)

OrchardCMS / OrchardCore.Commerce

Minimum viable product (MVP) features (OCC-61) #3