freshcom / freshcom-api Goto Github PK
View Code? Open in Web Editor NEWDeprecated
Home Page: https://docs.freshcom.io/
License: BSD 3-Clause "New" or "Revised" License
Deprecated
Home Page: https://docs.freshcom.io/
License: BSD 3-Clause "New" or "Revised" License
We should add a new attribute called ready_for_live_transaction
attribute to account.
The new attribute will be useful for Dashboard where if an account is not yet ready for live transaction then we will show their test data by default, if it is then we will show live data by default. User can still toggle between live and test data using the view test data button in the Dashboard.
Test account will always have ready_for_live_transaction
set to false
Right now client must use a UAT in order to create email verification token, we want to allow client use PAT, this is to cover the use case where some store do not auto login user right after registration which means client will never have access to a UAT, but still want give user a way to trigger resend of email verification.
Lets use plain SMTP for global email sending so that we don't depend on postmark's templating system
Right now this event is only being subscribed by storefront context, but the logic there can easily be moved to subscribe for balance:payment.create.success
instead
Right now we are at around 60% for test coverage, need to have at least 70%.
Currently, the API supports fixed, variable, and wholesale pricing. Are there any plans to support a subscription model?
For example, a store offers subscribers access to all digital products with lifetime updates as long as they are subscribed. Once they stop subscribing, they can no longer receive updates for downloaded items, nor can they download new items.
An example of a subscription for physical items would be a bakery that offers a surprise assortment of goods delivered to the customer at predetermined intervals.
Parameters would include commitment and frequency of payment. These differ, as someone can have an annual commitment but pay in monthly installments, or vice-versa. Frequencies could include weekly, bi-weekly, monthly, quarterly, and annually.
Subscription models are very popular today, and would be an important addition to the Freshcom API.
In test mode, when a email is trigger a email resource will be created but it should not be sent.
I should be able to enter the following information of that user:
Username and email can be the same.
This will be a new product kind namely: comboWithCustomization
.
This kind of product is useful for cases where a product combo consist of items that are customizable by the customer. A good example is a Mcdonalds combo lets say the big mac combo. The burger is set, but the fries is customizable where the customer can opt for large fries, similar for drink customer can not only choose drink but can also opt for large drink.
The resulting order line item tree should be like the following:
We will call the item that is added under the combo as customizable item, each customizable item is actually a product, for now we only support simple product as customizable item.
In order to achieve this, a new resource ProductCustomizationGroup
and ProductCustomizationGroupMembership
need to be created with structure like the following:
{
"id": "39bc17e7-cd32-4f2b-9711-ffe71f6d9f39"
"type": "ProductCustomizationGroup",
"attributes": {
"name": "Drink",
"maxiumSelect": 3, // Indicates customer cannot select more than 3 products from this group
"minimumSelect": 1 // Indicates customer must at least select 1 products from this group
},
"relationships": {
"product": {
"data": { "id": "39bc17e7-cd32-4f2b-9711-ffe71f6d9f37", "type": "Product" }
}
}
}
{
"type": "ProductCustomizationGroupMembership",
"attributes": {
"sortIndex": 1000,
"default": false, // Indicates whether this is the default selected for the group
"minimumOrderQuantity": 1,
"maximumOrderQuantity": 2
},
"relationships": {
"product": {
"data": { "id": "b881ee15-5a36-4a94-b8d8-7f2ec631486b", "type": "Product" }
},
"price": {
"data": { "id": "31abfc62-0099-4088-8e60-915e87a578b2", "type": "Price" }
}
}
}
The product that is associated to the ProductCustomizationGroupMembership
is what we called the customizable item. The relationsips between the resources are as follow:
When a product combo with customization is added to cart the default customization item for each customization group is added. If there is no default then that group will not have anything added. It is then up to the client to promopt the customer to select additional customization item from each customization group and add them to the order line item tree. We will not actually validate whether a customer have selected the minimum required item from each customization group, for now this will be the responsiblity of the client.
For the big mac combo example we can use the following resources to make it happen:
When this product combo with customization is added the initial order line item tree is the following:
The client should then prompt the customer to customize their fries size, drink size and drink, and update the order line item tree accordingly
Right now when a user with no permission tries to uses PATCH /users/:id it would actually ignore the :id and update the user itself which has no security concern but very confusing
Right now a guest user can change any cart as long as they have the ID, we should make this more strict by only allow guest user edit a cart that have customer_id: nil
instead of update_xxxxx(id, fields, opts)
where id is a string we should change so that it accept a map of identifiers for example %{ id: "id", status: "cart" }
so that we implement "this user is only allowed to update resource status x" much easier
The goal of v0.2.0 is to keep current functionality but adding more test and finish all the documentation.
v0.2.0 will include refactor, additional unit test, integration test and documentation update
Right now endpoints that do not require authentication can be specified by passing an array of path to the plug, this should be improved so that instead of passing path we should pass in both http method and the path.
Right now we assume each customer only have on point account, but we should allow customer to have multiple point account, for example one for store credit, one for loyalty points... etc
The goal of this refactor is to:
:validation
is the phoenix default, but sometime does not make much sense, for example errors: {"Card is declined, [validation: :card_declined]}
is not as understandable since we are not actually validating the card ourself, its more readable to have errors: {"Card is declined, [code: :card_declined]}
.
Right now if we try to make a new card as primary, we end up with two primary card, unacceptable!
including memberships.product
for product collection results in non-translated product resource
Right now product combo is bugged and can't be added to an order. Product combo use to have very complicated pricing model where each item will have a price that is the child of the parent product combo's price.
We want to re-design this so that product item can no longer have price them self, the price will always be associated with a product combo but each item will have a price_proportion_index (PPI) to represent the price of it compare to other item in the same combo.
Consider the following example of a fruit combo:
When this combo is added to an order the following line item tree should be build:
Each line item's sub total is calculated by using its item's PPI divided by the total PPI times the combo price. In the case of the apple it is 30/(30+60+70) * $10 = $1.88.
The last line item will always take the remaining amount left without using PPI as there could be some rounding problems. In this example, If we use PPI and round to 2 decimals then the sub total for lemon is actually $4.38, but if we use this then the tree doesn't balance because the total of all three fruits end up to be $10.01 which is 0.01 off, this is due to the rounding of both Apple and Lemon which is not acceptable.
Note that the PPI is different than the actual price, because a combo could have multiple prices, but the assumption here is the even tho the price is different the price proportion of each item stays the same.
We should introduce a new model called Brand which only contain attributes of account that is public sharable
Because Repo.get_by
cannot compared for nil, so we need to write extra code to handle when comparing finding resource base on some attribute being nil
right now the role attribute is always nil, it should not be nil and should return the correct role the newly created managed user
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.