- remove the `name` filter for orders (couldn't find any `name` property in the order data model).
- Remove the `order_id` property of a shipping method in the request body type for creating a draft order
- Update the types of `fulfillment_status` and `payment_status` in the order filters to showcase the possible status values.
RESOLVES FRMW-2110
RESOLVES FRMW-2095
**What**
- Fix notification module to not retain transactions open while sending notification
- Add support for notification status [success, pending, failure]
**What**
- add order edit confirmed/created events in the timeline
- add order change endpoint clients
- panel for active edit and pending edit
- few fixes around the edit domain
- Separate the previous `DeleteResponse` to `DeleteResponse` and `DeleteResponseWithParent`, as not every API route's delete response returns a parent. This ensures more accurate types shown in OAS / documentation.
- Use `DeleteResponse` or `DeleteResponseWithParent` in response API routes based on what they return
- Remove direct usage of `DeleteResponse` in API route, and instead create a type in the `type` package specific for the route / domain.
- Use the new types in the `js-sdk` and `dashboard`.
**What**
- Changes cell state strategy from tracking from lazy to eager. This has required some changes to the API of the DataGrid component, and createDataGridColumnHelper function.
- Displays error messages in both affected cells and their rows. The row indicator also provides an option to quickly jump to an error.
- Allows the user to hide all rows and columns that don't have errors, to help quickly get an overview of the errors in a large grid.
- The first column of a DataGrid is now pinned, making it easier for a user to tell which entity they are editing.
- Fixes and improvements to column visibility menu.
- Adds a shortcuts modal that explains the different available keyboard commands.
- Updates `@tanstack/react-table` to the latest version.
Resolves CC-269
FIXES FRMW-2676
**What**
ref: https://discord.com/channels/876835651130097704/1023889804544458752/threads/1276979858781503528
Currently, when providing the following
```ts
const user1 = manager.create(User, {
username: "User 1",
team: {
name: "Team 1",
},
})
```
It would result in an error inserting into the database because the foreign key will be sent twice as part of the insert, one for the relation and one for the foreign key that both relate to the foreign key property.
To fix that and allow both approaches (providing the entity to cascade persist or just providing the foreign key in case of another side nullable relation) we need to handle it a bit differently.
now both approaches would be valid. the entities for the example might not be the best ones but it is just to illustrate
option 1 - we create both the user and the team:
```ts
const user1 = manager.create(User, {
username: "User 1",
team: {
name: "Team 1",
},
})
```
option 2 - the team already exists (for example the previous user have been detached from the team but we kept the team alive and assign a new user to that team) :
```ts
const user1 = manager.create(User, {
username: "User 1",
team_id: team.id
})
```
* chore: Treat internal event differently, primarely do not display info log for those events
* revert doc
* add few tests
* only set internal option if present
* revert to previous condition
* start including feedback after discussion
* include feedback
* fix modules integration tests
* fix modules integration tests
* fix event bus local
