getlago / lago-api Goto Github PK

Sentry Issue: API-3

LoadError: cannot load such file -- factory_bot_rails
  bootsnap (1.10.3) lib/bootsnap/load_path_cache/core_ext/kernel_require.rb:27:in `require'
  zeitwerk (2.5.4) lib/zeitwerk/kernel.rb:35:in `require'
  db/seeds.rb:3:in `<main>'
    require 'factory_bot_rails'
  bootsnap (1.10.3) lib/bootsnap/load_path_cache/core_ext/kernel_require.rb:48:in `load'
  bootsnap (1.10.3) lib/bootsnap/load_path_cache/core_ext/kernel_require.rb:48:in `load'
...
(46 additional frame(s) were not displayed)

GraphQL errors should be typed directly by the back end schema definition

https://height.app/GJLAkYTZn5/T-906

• Add the organization api_key field
• Generate the api_key right after the organization creation
• Add the api_key field into the GraphQL Organization's type

Use a gem like https://github.com/paper-trail-gem/paper_trail to track changes on sensitive resources like plan, billable_metrics or customer

• On invoice we should add an incremental ID, scoped to the organization

For GraphQL mutation, we should improve the way validation errors are sent to the front.

It will allow the front end to properly handle translations and field errors

In order to do to so, in case of unprocessable_entity error, an extension property of the GraphQL error will give the full detail of what went wrong when processing the mutation on the model.

Example of payload:

{
  "customer_id": ["already_taken"],
  "country": ["invalid"]
}

Scoping: https://www.notion.so/getlago/Scoping-Add-metadata-to-customers-for-invoicing-049f5c4153ad41d3b9cc68fd504ebd3c

Today we use the same service method for creating a customer with the API and the GraphQL endpoints.
We must create a dedicated method for GraphQL since the logic is a bit different :

• We must return an error if the customer already exists

Sentry issue: API-B

Specs: https://www.notion.so/getlago/Spec-Add-package-pricing-in-Charge-models-31fd082936394b8b96b31400d6aaea31

Related to https://github.com/getlago/lago-product/issues/14

Today the organization.vatRate can be undefined or null. In the spec it's specified that it can only be a number between 0 and 100.
For consistency (and also because it avoids a lot of useless check in the front), can we update the grapqhl schema to "number, not optional" please ?

We must add the webhook logic that will be triggered when the invoice is processed

Product issue: https://github.com/getlago/lago-product/issues/4

Specs: https://www.notion.so/getlago/Spec-Aggregation-types-and-behaviors-5e1271523df94baa8d4f4bc214dd4b4b

• On a yearly plan, when doing prorata computation, we should use float instead of int, otherwise it makes a big difference on the final amount
• NOTE: we can do the same for monthly plan too

• when passing null values on customer update, it should not erase present values

• when aggregating events, we should support float on sum and max agg type instead of only integer

If we downgrade a subscription, we should have only one pending subscription.
If any subscription is pending, we cancel it.

We also should filter subscriptions for the graphQL endpoint and do not return cancelled

• When creating an event, if any required property is missing, we should return an error instead of a 200 ack

• when we send a null properties value for event, it should not trigger on error during the job execution, we should put the {} by default

Today we use the customer.customer_id to create a subscription from API or GraphQL.
To avoid misleading, we should use the customer.id on our GraphQL mutation

• When downgrading plan, we should have the futur start date of the new plan (currently null) :
  query Customer.subscriptions.startDate

We recently introduce numerical validations on the vat_rate attribute of organizations and customers.

Since this validations have an impact on the graphQL API, we need to add error codes to allow the front end to properly handle and translate them.

• actually the route to terminate a subscription is DELETE /api/v1/subscriptions/terminate, we should use DELETE /api/v1/subscriptions/:id

We should add an API route to allow users to retrieve the public key used to verify the webhook signature.

On each subscription fee creation:

end_of_trial = subscription_date + plan.trial_period

if to_date of invoice < end_of_trial
  amount = 0
elsif from_date < end_of_trial && to_date > end_of_trial 
 amount = pro-rata on days to bill
else # from_date > end_of_trial
  amoun = full amount
end

Add a property to the invoices table to store the number of free days to prevent recomputing it each time

DB resources should not be hard deleted, instead, we should add a deleted_at.
Soft deleted resources should not be exposed in GraphQL or API but remain present in DB for tracking purpose.

Warning: this will impact all DB indexes based on unique constraint, the deleted_at field should be part of the index

Since we do not use frequency anymore (one_shot or recurring) we must remove frequency on charges

Possible problems:

• For MAX and SUM aggregation, field value is expected to be an integer.
  • If field is not an integer or cannot be casted as an integer, an ActiveRecord::StatementInvalid is raised by rails. Today it is handled at aggregation time but it fails for all the billing period
• For MAX, SUM and COUNT UNIQUE, a property is expected in the event payload.
  • If the property is not present, it is ignored, or count as a 0 value.

In both cases, we should detect it, filter invalid events from the aggregation and let the user/developer know there is an issuer with the event.

The proper solution to let the user know still as to be discussed with the product team

Today, when checking for upgrade/downgrade of plan, we compare plan amount_cents no mater if the plan is yearly or monthly.
To have a proper base of comparison, we should divide multiply the amount by 12 when the plan is monhtly

Related to https://github.com/getlago/lago-product/issues/6

• Improve our logs by using lograge

• On a Monthly/Yearly Plan in arrears, when you terminate a subscription and add a new one in arrears, the pro-rata is not working. It should work

• We need to add an updateOrganization mutation on GraphQL
  • it needs to support the webhook_url only for now

Linked to getlago/lago#12

API end-point as well as response and errors should be fully documented in the public documentation.

Sentry issue: API-8

Related to https://github.com/getlago/lago-product/issues/8

• We need to configure Sidekiq to put dead job when the job raise an error

remove helm values from repository

https://sentry.io/organizations/lago/issues/3268566162/?project=6370067&query=is%3Aunresolved

Describe the bug
When no customer is linked to a plan, we should be able to edit the plan (infos, model and charges). We have to be able to:

• Filter assigned plan only for active subscriptions
• Filter (image below) #of customers only for active subscriptions

To Reproduce

1. Create a plan
2. Create a customer
3. Link a plan to a customer
4. Terminate the subscription
5. It's now impossble to edit the plan, even if no customer has active subscription for it

Expected behavior
We shoud be able to edit a plan if no active subscription is assigned for this plan

Sentry Issue: API-2

ArgumentError: bad argument (expected URI object or URI string)
  lib/lago_http_client/lago_http_client/client.rb:8:in `initialize'
    @uri = URI(url)
  app/services/webhooks/base_service.rb:16:in `new'
    http_client = LagoHttpClient::Client.new(current_organization.webhook_url)
  app/services/webhooks/base_service.rb:16:in `call'
    http_client = LagoHttpClient::Client.new(current_organization.webhook_url)
  app/jobs/send_webhook_job.rb:13:in `perform'
    Webhooks::InvoicesService.new(object).call
...
(74 additional frame(s) were not displayed)