Update the docs to accurately reflect `LoggerDriverType`. Using `sentry`
throws an error on startup.
```
export enum LoggerDriverType {
Console = 'console',
}
```
Happy to change the wording of course.
Closes#5915
This issue occurs only when there is no select field.
The user then creates a new one in settings and returns back to the view
picker.
And the bug arises, it because `viewPickerKanbanFieldMetadataId` is not
being set correctly.
When a user navigate to settings, the dirty state should be set to
false. As a result, after re-rendering the view picker component, it
triggers the effect to set `viewPickerKanbanFieldMetadataId`
---------
Co-authored-by: Achsan <achsanh@gmail.com>
Co-authored-by: Lucas Bordeau <bordeau.lucas@gmail.com>
Timezone with a negative offset weren't working good with date pickers.
I split the logic for display and parsing between date only and
datetime.
Date time is sending and displaying using timezone, and date only is
sending and displaying by forcing the date to take its UTC day and month
and 00:00:00 time.
This way its consistent across all timezones.
Previously the error boundary component was re-rendering with the same
state as long as we stayed in the same router, so for page change inside
an index container, it would stay on error state.
The fix is to memorize the location the error page is on during its
first render, and then to reset the error boundary if it gets
re-rendered with a different location even in the same index container.
Fixes : #3592
- Remove filters from metadata rest api
- add limite before and after parameters for metadata
- remove update from metadata relations
- fix typing issue
- fix naming
- fix before parameter
---------
Co-authored-by: Félix Malfait <felix.malfait@gmail.com>
Greetings from Seoul! I found this amazing project a few days ago, and
trying to introduce it to my team. However there is a tiny but
significant problem, that South Korean won is not available in twenty.
So I added `KRW` to the enum `CurrencyCode` and the constant
`SETTINGS_FIELD_CURRENCY_CODES`. I tested it locally and apparently
works fine.
The display for Rating field type was missing, I just added it based on
RatingInput in readonly mode and optimized a bit for performance also.
Fixes https://github.com/twentyhq/twenty/issues/5900
Filtering relations is not allowed
(see`packages/twenty-server/src/engine/metadata-modules/relation-metadata/dtos/relation-metadata.dto.ts`)
so we remove filtering for find many relation
we also fixed some bug in result structure and metadata open-api schema
### Overview
This PR introduces significant enhancements to the MessageQueue module
by integrating `@Processor`, `@Process`, and `@InjectMessageQueue`
decorators. These changes streamline the process of defining and
managing queue processors and job handlers, and also allow for
request-scoped handlers, improving compatibility with services that rely
on scoped providers like TwentyORM repositories.
### Key Features
1. **Decorator-based Job Handling**: Use `@Processor` and `@Process`
decorators to define job handlers declaratively.
2. **Request Scope Support**: Job handlers can be scoped per request,
enhancing integration with request-scoped services.
### Usage
#### Defining Processors and Job Handlers
The `@Processor` decorator is used to define a class that processes jobs
for a specific queue. The `@Process` decorator is applied to methods
within this class to define specific job handlers.
##### Example 1: Specific Job Handlers
```typescript
import { Processor, Process, InjectMessageQueue } from 'src/engine/integrations/message-queue';
@Processor('taskQueue')
export class TaskProcessor {
@Process('taskA')
async handleTaskA(job: { id: string, data: any }) {
console.log(`Handling task A with data:`, job.data);
// Logic for task A
}
@Process('taskB')
async handleTaskB(job: { id: string, data: any }) {
console.log(`Handling task B with data:`, job.data);
// Logic for task B
}
}
```
In the example above, `TaskProcessor` is responsible for processing jobs
in the `taskQueue`. The `handleTaskA` method will only be called for
jobs with the name `taskA`, while `handleTaskB` will be called for
`taskB` jobs.
##### Example 2: General Job Handler
```typescript
import { Processor, Process, InjectMessageQueue } from 'src/engine/integrations/message-queue';
@Processor('generalQueue')
export class GeneralProcessor {
@Process()
async handleAnyJob(job: { id: string, name: string, data: any }) {
console.log(`Handling job ${job.name} with data:`, job.data);
// Logic for any job
}
}
```
In this example, `GeneralProcessor` handles all jobs in the
`generalQueue`, regardless of the job name. The `handleAnyJob` method
will be invoked for every job added to the `generalQueue`.
#### Adding Jobs to a Queue
You can use the `@InjectMessageQueue` decorator to inject a queue into a
service and add jobs to it.
##### Example:
```typescript
import { Injectable } from '@nestjs/common';
import { InjectMessageQueue, MessageQueue } from 'src/engine/integrations/message-queue';
@Injectable()
export class TaskService {
constructor(
@InjectMessageQueue('taskQueue') private readonly taskQueue: MessageQueue,
) {}
async addTaskA(data: any) {
await this.taskQueue.add('taskA', data);
}
async addTaskB(data: any) {
await this.taskQueue.add('taskB', data);
}
}
```
In this example, `TaskService` adds jobs to the `taskQueue`. The
`addTaskA` and `addTaskB` methods add jobs named `taskA` and `taskB`,
respectively, to the queue.
#### Using Scoped Job Handlers
To utilize request-scoped job handlers, specify the scope in the
`@Processor` decorator. This is particularly useful for services that
use scoped repositories like those in TwentyORM.
##### Example:
```typescript
import { Processor, Process, InjectMessageQueue, Scope } from 'src/engine/integrations/message-queue';
@Processor({ name: 'scopedQueue', scope: Scope.REQUEST })
export class ScopedTaskProcessor {
@Process('scopedTask')
async handleScopedTask(job: { id: string, data: any }) {
console.log(`Handling scoped task with data:`, job.data);
// Logic for scoped task, which might use request-scoped services
}
}
```
Here, the `ScopedTaskProcessor` is associated with `scopedQueue` and
operates with request scope. This setup is essential when the job
handler relies on services that need to be instantiated per request,
such as scoped repositories.
### Migration Notes
- **Decorators**: Refactor job handlers to use `@Processor` and
`@Process` decorators.
- **Request Scope**: Utilize the scope option in `@Processor` if your
job handlers depend on request-scoped services.
Fix#5628
---------
Co-authored-by: Weiko <corentin@twenty.com>
I have fixed the scrolling the record container page on mobile making it
hidden.
This PR aims to fix#5745
---------
Co-authored-by: Lucas Bordeau <bordeau.lucas@gmail.com>
A mini PR to discuss with @Bonapara tomorrow
Separating remote objects from others and making the menu collapsible
(style to be changed)
<img width="225" alt="Screenshot 2024-06-12 at 23 25 59"
src="https://github.com/twentyhq/twenty/assets/6399865/b4b69d36-6770-43a2-a5e8-bfcdf0a629ea">
Biggest issue is we don't use local storage today so the collapsed state
gets lost.
I see we have localStorageEffect with recoil. Maybe store it there?
Seems easy but don't want to introduce a bad pattern.
Todo:
- style update
- collapsible favorites
- persistent storage
The record chip generator context was missing a edge were a new field of
type relation is created and not yet in the metadata so no chip
generator function can be precomputed.
For now I added a fallback default chip generator, to prevent any bug,
but we might want to add a new chip generator function while creating
the new field ?
