FIXES SUP-560
**What**
Currently, no matter the error when looking for a provider to exists in the container we are throwing a normalized error stating that the provider does not exists in the container. The issue is that the first initialization of the provider occurs the first time we resolve it, and the error can be that the provider failed to be instanciated for any reason.
In this pr, we are explicitly checking for the error to be an awilix resolution error to throw the classic error and otherwise we provide the issue why the provider failed to be resolved.
**What**
- Allow to provide `foreignKeyName` option for hasOne and belongsTo relationships
- `model.hasOne(() => OtherEntity, { foreignKey: true, foreignKeyName: 'other_entity_something_id' })`
- The above will also output a generated type that takes into consideration the custom fk name 🔽
- Update types to account for defined custom foreign key name
- Fix joiner config linkable generation to account for custom linkable keys that provide a public API for their model but are not part of the list of the models included in the MedusaService
- This was supposed to be handled correctly but the implementation was not considering that custom linkable keys could reference models not part of the one provided to medusa service
- Migrate fulfillment module to DML
- Fix has one with fk behaviour and hooks (the relation should be assigned but not the fk)
- Fix has one belongsTo hooks (the relation should be assigned but not the fk)
- Fix hasOneWithFk and belongsTo non persisted fk to be selectable
- Allow to define `belongsTo` without other side definition for `ManyToOne` with no counter part defined
- Meaning that if a user defined `belongsTo` on one side andnot mapped by and no counter part on the other entity it will be considered as a `ManyToOne`
- `orphanRemoval` on `OneToOne` have been removed, this means that when assigning a new object relation to an entity, the previous one gets deconected but not deleted automatically. This prevent removing data un volountarely
**NOTE**
As per our convention here are some information to keep in mind
**HasOne <> BelongsTo**
Define `OneToOne`, The foreign key is owned by the belongs to and the relation needs to be provided to cascade if wanted
**HasMany <> BelongsTo**
Define `OneToMane` <> `ManyToOne`, the foreign key is owned by the many to one and for those relation no cascade will be performed, the foreign key must be provided. For the `HasMany` the cascade is available
**HasOne (with FK)**
Will act similarly to belongs to with **HasOne <> BelongsTo**
Co-authored-by: Carlos R. L. Rodrigues <37986729+carlos-r-l-rodrigues@users.noreply.github.com>
**What**
- add a list point for fetching fulfillment options for a provider
- add FO support on SO create & update on dashboard
- pass `cart` and `stockLocation` to `validateFufillmentData` context
---
CLOSES CMRC-789
CLOSES CMRC-790
**What**
- calculate the shipping option price when creating a shipping method
- calculate the shipping option price when refreshing cart
- add testing for calculated SO flow
- fix validation on calculated SO creation
- add manual fulfillment provider for testing
- add `from_location` to calculation context
---
RESOLVES CMRC-778
RESOLVES CMRC-602
RESOLVES SUP-136
**What**
- support creating SO with calculated price
- support updating SO for both types of pricing
- update `validateShippingOptionPricesStep` to handle both SO price_types
- add the `validateShippingOptionsForPriceCalculation` method to `FulfillementModule`
- add `canCalculate` and `calculatePrice` to fulfillment provider service service / interface / manual provider
- disable SO pricing edit on Admin if SO price type is calculated
---
CLOSES CMRC-776
What:
* removes resouces type "shared" or "isolated" from internal modules.
* modules can have an isolated database connection by providing a database config as part of their options on `medusa-config`
CLOSES: FRMW-2593
FIXES: FRMW-2727
MikroORM (with version 5.9) has [hardcoded the TypeScript module](https://github.com/mikro-orm/mikro-orm/blob/5.x/packages/core/src/utils/ConfigurationLoader.ts#L138-L139) system to `commonjs`, which makes it incompatible with the module system we are using, ie `Node16`.
So, in order to continue using the Mikro ORM CLI within our modules, we will have to monkey-patch the block of code responsible for configuring `ts-node`. However, the monkey-patching must be done before their CLI gets booted.
As a result of this, we have to create a wrapper CLI on top of Mikro ORM CLI that performs the following steps.
- Monkey-patch the relevant code
- Register Mikro ORM CLI as the second step.
Due do this, we will have to use this new wrapper CLI within the modules, which is exposed as `medusa-db`. Maybe, `medusa-db` is not a great name, so please send your suggestions.
**What**
- hide disabled fulfilment providers on the admin
- check if the fulfilment provider has an identifier when loading providers
---
FIXES CC-549
