Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

🥔✨ Marketplace: DeliveryConstraints #1185

Closed
5 of 9 tasks
Tracked by #1325
zspencer opened this issue Mar 5, 2023 · 3 comments
Closed
5 of 9 tasks
Tracked by #1325

🥔✨ Marketplace: DeliveryConstraints #1185

zspencer opened this issue Mar 5, 2023 · 3 comments
Labels
✨ feature Reduces Client's Burden or Grants them Benefits 🥔 Satisfices It's good enough to use, but not particularly great

Comments

@zspencer
Copy link
Member

zspencer commented Mar 5, 2023

Marketplace Vendors often offer multiple options for Delivery, for example a catering option where Shoppers can set the date and time and a pre-scheduled option where the Distributor picks up a set of Orders from from the Vendor and brings them to the Shoppers at a set date and time.

Use Cases

  • 🥔 Vendor or Distributor sets Soft Timing Constraints with words
  • 🌱 Vendor or Distributor sets hard Timing Constraints
    • Delivery during Specific Hours (i.e. Mon-Fri 10 to 12)
    • Order By (i.e. 48 hours before delivery)
  • 🥔 Vendor specific Date and Time ("Sellers Choice")
  • 🥔 Shopper chooses Date and Time ("Shoppers Choice?")
    • 🥔 Vendor or Distributor enables Shoppers Choice Delivery
      • Right now, this is implict by clearing the Marketplace#delivery_window, we probably should make it explicit...
    • 🥔 Shopper sets Delivery Time
      • 🌱 ... As enforced by the Timing Constraints
@zspencer zspencer changed the title Delivery Windows Marketplace: Delivery Windows Mar 5, 2023
@zspencer zspencer changed the title Marketplace: Delivery Windows 🌱 Marketplace: Delivery Windows Mar 5, 2023
@zspencer zspencer added this to the 1.0 - Andromeda milestone Mar 5, 2023
@zspencer zspencer added the ✨ feature Reduces Client's Burden or Grants them Benefits label Mar 5, 2023
zspencer added a commit that referenced this issue Mar 16, 2023
…1218)

- #1185

Added a `Marketplace#delivery_window` attribute, which is a
plain-old-string for now. It's going to quickly become insufficient,
because we *may* need to do date and time crap at one point.

But "quickly" could mean "months from now!" sooooooo.

Co-authored-by: Ana Ulin <anaulin@users.noreply.github.com>
Co-authored-by: Dalton Pruitt <daltonrpruitt@users.noreply.github.com>
Co-authored-by: Kelly Hong <KellyAH@users.noreply.github.com>
Co-authored-by: Ross Chapman <rosschapman@users.noreply.github.com>
@zspencer zspencer changed the title 🌱 Marketplace: Delivery Windows 🌱🥔 Marketplace: Delivery Windows Mar 16, 2023
zspencer added a commit that referenced this issue Mar 16, 2023
- #1185

Co-authored-by: Ana Ulin <anaulin@users.noreply.github.com>
Co-authored-by: Dalton Pruitt <daltonrpruitt@users.noreply.github.com>
Co-authored-by: Kelly Hong <KellyAH@users.noreply.github.com>
Co-authored-by: Ross Chapman <rosschapman@users.noreply.github.com>
@zspencer
Copy link
Member Author

Since Piikup is going for Catering first, For now, Piikup and Caterers need a 48+ hour notice. We'll also want to let them select the date and time for delivery.

@zspencer zspencer added the 🥔 Satisfices It's good enough to use, but not particularly great label Mar 20, 2023
zspencer added a commit that referenced this issue Mar 20, 2023
- #1185

This is potato tier to be sure, but it makes it possible to say when
they want to be delivered.
zspencer added a commit that referenced this issue Mar 20, 2023
- #1185

This is potato tier to be sure, but it makes it possible to say when
they want to be delivered.
zspencer added a commit that referenced this issue Mar 20, 2023
- #1185

This is potato tier to be sure, but it makes it possible to say when
they want to be delivered.
zspencer added a commit that referenced this issue Mar 20, 2023
- #1185

This is potato tier to be sure, but it makes it possible to say when
they want to be delivered.
zspencer added a commit that referenced this issue Mar 22, 2023
- #1185

This is potato tier to be sure, but it makes it possible to say when
they want to be delivered.
zspencer added a commit that referenced this issue Mar 27, 2023
- https://zinc-collective.sentry.io/issues/4031191037/?project=6052513
- #1265
- #1185
- #1269

So, it turns out the reason we were getting these errors was because I
had not made the form picker smart enough to use the string value when a
delivery window was not present.

Now it is!

Also, reverting the StoreModel stuff because it did not seem to fix the
problem and I can't figure out why it's not working :'(
zspencer added a commit that referenced this issue Mar 28, 2023
- https://zinc-collective.sentry.io/issues/4031191037/?project=6052513
- #1265
- #1185
- #1269

So, it turns out the reason we were getting these errors was because I
had not made the form picker smart enough to use the string value when a
delivery window was not present.

Now it is!

Also, reverting the StoreModel stuff because it did not seem to fix the
problem and I can't figure out why it's not working :'(
zspencer added a commit that referenced this issue Apr 6, 2023
- #1185

So, the `delivery_window` field which can either be a plain string or a
particular date or even a date range is a much more sophisticated
object.

I took some time last night to explore what it could look like to use
`ActiveModel::Type`s  to create a value object which can take
responsibility for representing the data more appropriately.

That said, I think `store_model` will be better ™️, but I didn't want
to try to dig into that just yet.
zspencer added a commit that referenced this issue Apr 7, 2023
- #1185

So, the `delivery_window` field which can either be a plain string or a
particular date or even a date range is a much more sophisticated
object.

I took some time last night to explore what it could look like to use
`ActiveModel::Type`s  to create a value object which can take
responsibility for representing the data more appropriately.

That said, I think `store_model` will be better ™️, but I didn't want
to try to dig into that just yet.
zspencer added a commit that referenced this issue Apr 8, 2023
- #1185

So, the `delivery_window` field which can either be a plain string or a
particular date or even a date range is a much more sophisticated
object.

I took some time last night to explore what it could look like to use
`ActiveModel::Type`s  to create a value object which can take
responsibility for representing the data more appropriately.

That said, I think `store_model` will be better ™️, but I didn't want
to try to dig into that just yet.
zspencer added a commit that referenced this issue Apr 8, 2023
…tComponent` (#1319)

* `Marketplace`: Sprout `Delivery::Window` object

- #1185

So, the `delivery_window` field which can either be a plain string or a
particular date or even a date range is a much more sophisticated
object.

I took some time last night to explore what it could look like to use
`ActiveModel::Type`s  to create a value object which can take
responsibility for representing the data more appropriately.

That said, I think `store_model` will be better ™️, but I didn't want
to try to dig into that just yet.

* Ahahah! It did it! It did the thing

* `Marketplace`: Spec for the `Delivery` model!

* `Marketplace`: spec the `Delivery#window` alias

We can't use `alias_method` with `attribute`, which is weird but ok.

* `Marketplace`: Make sure the delivery window shows up in the email!

* `Marketplace`: Undo the weird name resolution

* `Marketplace`: A bit more low-level tests on the `Delivery::Window` and `Delivery::WindowType`

* `Marketplace`: Move all type casting to the Type

OK, that makes sense... We keep the type castin gin the type... and that
makes everything else lighter.

* `Marketplace`: Oooooh yea! Factories!

Keeps the refactor just a tiny bit more cleaner and full
@zspencer zspencer changed the title 🌱🥔 Marketplace: Delivery Windows 🌱🥔 Marketplace: Scheduled Delivery Apr 8, 2023
zspencer added a commit that referenced this issue Apr 16, 2023
- #1185

As we were beginning to implement how we communicate the different
expectations based on delivery area, we noticed there were not many
tests on the current behavior; and that chunk of behavior had many many
many permutations that were meaningful.

So we took some time to pull out a `DeliveryExpectationsComponent` that
can take care of handling those permutations, and start to test them.

There is some minor wording improvements included here, specifically
because we noticed things didn't always make a ton of sense as we added
those tests; so it *does* include a bit of behavior changes.

Co-authored-by: Neer Malathapa <nirmalathapa@users.noreply.github.com>
Co-authored-by: Dicko Sow <s12dsow@users.noreply.github.com>
zspencer added a commit that referenced this issue Apr 17, 2023
…1373)

- #1185

As we were beginning to implement how we communicate the different
expectations based on delivery area, we noticed there were not many
tests on the current behavior; and that chunk of behavior had many many
many permutations that were meaningful.

So we took some time to pull out a `DeliveryExpectationsComponent` that
can take care of handling those permutations, and start to test them.

There is some minor wording improvements included here, specifically
because we noticed things didn't always make a ton of sense as we added
those tests; so it *does* include a bit of behavior changes.
zspencer added a commit that referenced this issue Apr 17, 2023
…indow` (#1372)

- #1185

We added some tests to the `DeliveryAreaComponent` to make sure it looks
reasonable in each use-case:

- `#delivery_window` with no data
- `#delivery window` with a string
- `#order_by` with no data
- `#order_by` with a string

We also included "by" in the `_window.html.erb` partial so that people
don't have to write it in their `order_by`.
zspencer added a commit that referenced this issue Apr 17, 2023
…rea` (#1371)

- #1185

In order to support different timing for different `DeliveryArea`s,
we've given them `delivery_window` and `order_by` fields.

These fields will be used to communicate on the `Cart#show` and
`Order#show` screens what the timing expectations are for particular
orders.

Example:

- Catering orders for Lions Dance Cafe can be placed any time and
delivered anytime, but
- Dinner orders must be placed the same day by 3pm

### After
![Screenshot 2023-04-16 at 10 56 24
AM](https://user-images.githubusercontent.com/50284/232332194-f55236fa-2e61-4706-8dbb-5a2d801657a7.png)
![Screenshot 2023-04-16 at 10 56 15
AM](https://user-images.githubusercontent.com/50284/232332197-a25c6fd2-8495-4ebe-8ddf-e09a2154e590.png)
![Screenshot 2023-04-16 at 10 56 09
AM](https://user-images.githubusercontent.com/50284/232332199-0d20819d-7876-4425-88cc-372ddf3e1c81.png)
@zspencer zspencer changed the title 🌱🥔✨ Marketplace: Scheduled Delivery 🌱🥔✨ Marketplace: DeliveryConstraints Apr 17, 2023
@zspencer zspencer changed the title 🌱🥔✨ Marketplace: DeliveryConstraints 🥔✨ Marketplace: DeliveryConstraints Apr 17, 2023
@zspencer zspencer removed the 🌱 Ready for Dev Stuff we are able to move forward on label Apr 17, 2023
zspencer added a commit that referenced this issue Apr 30, 2023
- #1325
- #1136
- #1185

Allowing a `Marketplace` to specify it's delivery fees, constraints,
etc. and a `DeliveryArea` to override them was putting us in a bit of a
mess from "how does data even?!"

This consolidates everything onto `DeliveryArea`, yay!
zspencer added a commit that referenced this issue Apr 30, 2023
- #1325
- #1136
- #1185

Allowing a `Marketplace` to specify it's delivery fees, constraints,
etc. and a `DeliveryArea` to override them was putting us in a bit of a
mess from "how does data even?!"

This consolidates everything onto `DeliveryArea`, yay!
zspencer added a commit that referenced this issue Apr 30, 2023
- #1325
- #1136
- #1185

Allowing a `Marketplace` to specify it's delivery fees, constraints,
etc. and a `DeliveryArea` to override them was putting us in a bit of a
mess from "how does data even?!"

This consolidates everything onto `DeliveryArea`, yay!
zspencer added a commit that referenced this issue Apr 30, 2023
- #1325
- #1136
- #1185

Allowing a `Marketplace` to specify it's delivery fees, constraints,
etc. and a `DeliveryArea` to override them was putting us in a bit of a
mess from "how does data even?!"

This consolidates everything onto `DeliveryArea`, yay!
zspencer added a commit that referenced this issue Apr 30, 2023
- Prerequisite for #1420

- #1325
- #1136
- #1185

This does not get rid of the reading of the fields; but it does make it
so they are no longer writable; which will make the "stop reading from
them!" PR a bit tidier.
zspencer added a commit that referenced this issue Apr 30, 2023
- #1325
- #1136
- #1185

Allowing a `Marketplace` to specify it's delivery fees, constraints,
etc. and a `DeliveryArea` to override them was putting us in a bit of a
mess from "how does data even?!"

This consolidates everything onto `DeliveryArea`, yay!
zspencer added a commit that referenced this issue Apr 30, 2023
- #1325
- #1136
- #1185

Allowing a `Marketplace` to specify it's delivery fees, constraints,
etc. and a `DeliveryArea` to override them was putting us in a bit of a
mess from "how does data even?!"

This consolidates everything onto `DeliveryArea`, yay!
zspencer added a commit that referenced this issue Apr 30, 2023
- Prerequisite for #1420

- #1325
- #1136
- #1185

This does not get rid of the reading of the fields; but it does make it
so they are no longer writable; which will make the "stop reading from
them!" PR a bit tidier.
zspencer added a commit that referenced this issue Apr 30, 2023
- #1325
- #1136
- #1185

Allowing a `Marketplace` to specify it's delivery fees, constraints,
etc. and a `DeliveryArea` to override them was putting us in a bit of a
mess from "how does data even?!"

This consolidates everything onto `DeliveryArea`, yay!
zspencer added a commit that referenced this issue May 4, 2023
…1422)

🧹 `Marketplace`: `DeliveryConstraint`s only set in `DeliveryArea`

- Prerequisite for #1420

- #1325
- #1136
- #1185

This does not get rid of the reading of the fields; but it does make it
so they are no longer writable; which will make the "stop reading from
them!" PR a bit tidier.
zspencer added a commit that referenced this issue May 4, 2023
- #1325
- #1136
- #1185

Allowing a `Marketplace` to specify it's delivery fees, constraints,
etc. and a `DeliveryArea` to override them was putting us in a bit of a
mess from "how does data even?!"

This consolidates everything onto `DeliveryArea`, yay!
zspencer added a commit that referenced this issue May 4, 2023
`Marketplace`: `Delivery` constraints live on `DeliveryArea`

- #1325
- #1136
- #1185

Allowing a `Marketplace` to specify it's delivery fees, constraints,
etc. and a `DeliveryArea` to override them was putting us in a bit of a
mess from "how does data even?!"

This consolidates everything onto `DeliveryArea`, yay!
@zspencer
Copy link
Member Author

Hard timing constraints (in particular "place orders 48 hours before delivery") seems pretty important to Piikup's client, Cafe Gabriela

@rosschapman
Copy link
Contributor

🧹 Relegated to cold storage.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
✨ feature Reduces Client's Burden or Grants them Benefits 🥔 Satisfices It's good enough to use, but not particularly great
Projects
None yet
Development

No branches or pull requests

2 participants