2023-11-03 13:33:45 +00:00
|
|
|
import { Command, CommandRunner } from 'nest-commander';
|
Uniformize datasources (#5196)
## Context
We recently enabled the option to bypass SSL certificate authority
validation when establishing a connection to PostgreSQL. Previously, if
this validation failed, the server would revert to unencrypted traffic.
Now, it maintains encryption even if the SSL certificate check fails. In
the process, we overlooked a few DataSource setups, prompting a review
of DataSource creation within our code.
## Current State
Our DataSource initialization is distributed as follows:
- **Database folder**: Contains 'core', 'metadata', and 'raw'
DataSources. The 'core' and 'metadata' DataSources manage migrations and
static resolver calls to the database. The 'raw' DataSource is utilized
in scripts and commands that require handling both aspects.
- **typeorm.service.ts script**: These DataSources facilitate
multi-schema connections.
## Vision for Discussion
- **SystemSchema (formerly core) DataSource**: Manages system schema
migrations and system resolvers/repos. The 'core' schema will be renamed
to 'system' as the Core API will include parts of the system and
workspace schemas.
- **MetadataSchema DataSource**: Handles metadata schema migrations and
metadata API resolvers/repos.
- **(Dynamic) WorkspaceSchema DataSource**: Will be used in the Twenty
ORM to access a specific workspace schema.
We currently do not support cross-schema joins, so maintaining these
DataSources separately should be feasible. Core API resolvers will
select the appropriate DataSource based on the field context.
- **To be discussed**: The potential need for an AdminDataSource (akin
to 'Raw'), which would be used in commands, setup scripts, and the admin
panel to connect to any database schema without loading any model. This
DataSource should be reserved for cases where utilizing metadata,
system, or workspace entities is impractical.
## In This PR
- Ensuring all existing DataSources are compliant with the SSL update.
- Introducing RawDataSource to eliminate the need for declaring new
DataSource() instances in commands.
2024-04-27 09:43:44 +00:00
|
|
|
import { EntityManager } from 'typeorm';
|
2023-10-28 10:25:43 +00:00
|
|
|
|
2023-11-19 17:25:47 +00:00
|
|
|
import { seedCoreSchema } from 'src/database/typeorm-seeds/core';
|
2024-03-20 13:43:41 +00:00
|
|
|
import {
|
2024-03-26 13:19:40 +00:00
|
|
|
SEED_APPLE_WORKSPACE_ID,
|
|
|
|
|
SEED_TWENTY_WORKSPACE_ID,
|
2024-03-20 13:43:41 +00:00
|
|
|
} from 'src/database/typeorm-seeds/core/workspaces';
|
2024-07-25 15:53:57 +00:00
|
|
|
import { seedCalendarChannels } from 'src/database/typeorm-seeds/workspace/calendar-channel';
|
|
|
|
|
import { seedCalendarChannelEventAssociations } from 'src/database/typeorm-seeds/workspace/calendar-channel-event-association';
|
|
|
|
|
import { seedCalendarEventParticipants } from 'src/database/typeorm-seeds/workspace/calendar-event-participants';
|
|
|
|
|
import { seedCalendarEvents } from 'src/database/typeorm-seeds/workspace/calendar-events';
|
|
|
|
|
import { seedCompanies } from 'src/database/typeorm-seeds/workspace/companies';
|
2024-03-26 13:19:40 +00:00
|
|
|
import { seedConnectedAccount } from 'src/database/typeorm-seeds/workspace/connected-account';
|
|
|
|
|
import { seedMessageChannelMessageAssociation } from 'src/database/typeorm-seeds/workspace/message-channel-message-associations';
|
2024-07-25 15:53:57 +00:00
|
|
|
import { seedMessageChannel } from 'src/database/typeorm-seeds/workspace/message-channels';
|
2024-03-26 13:19:40 +00:00
|
|
|
import { seedMessageParticipant } from 'src/database/typeorm-seeds/workspace/message-participants';
|
Share an email thread to workspace members chip and dropdown (#4199) (#5640)
# Feature: Email thread members visibility
For this feature we implemented a chip and a dropdown menu that allows
users to check which workspace members can see an email thread, as
depicted on issue (#4199).
## Implementations
- create a new database table (messageThreadMember)
- relations between `messageThreadMembers` and the relevant existing
tables (`MessageThread` and `WorkspaceMembers`)
- added a new column to the `MessageThread table`: `everyone` - to
indicate that all workspace members can see the email thread
- create a new repository for the new table, including new queries
- edit the queries so that the new fields could be fetched from the
frontend
- created a component `MultiChip`, that shows a group of user avatars,
instead of just one
- created a component, `ShareDropdownMenu`, that shows up once the
`EmailThreadMembersChip` is clicked. On this menu you can see which
workspace members can view the email thread.
## Screenshots
Here are some screenshots of the frontend components that were created:
Chip with everyone in the workspace being part of the message thread:

Chip with just one member of the workspace (the owner) being part of the
message thread:

Chip with some members of the workspace being part of the message
thread:

How the chip looks in a message thread:

Dropdown that opens when you click on the chip:

## Testing and Mock data
We also added mock data (TypeORM seeds), focusing on adding mock data
related to message thread members.
## Conclusion
As some of the changes that we needed to do, regarding the change of
visibility of the message thread, were not covered by the existing
documentation, we were told to open a PR and ask for feedback on this
part of the implementation. Right now, our implementation is focused on
displaying who is part of an email thread.
Feel free to let us know which steps we should follow next :)
---------
Co-authored-by: Simão Sanguinho <simao.sanguinho@tecnico.ulisboa.pt>
Co-authored-by: Lucas Bordeau <bordeau.lucas@gmail.com>
2024-07-31 16:50:27 +00:00
|
|
|
import { seedMessageThreadSubscribers } from 'src/database/typeorm-seeds/workspace/message-thread-subscribers';
|
2024-03-26 13:19:40 +00:00
|
|
|
import { seedMessageThread } from 'src/database/typeorm-seeds/workspace/message-threads';
|
2024-07-25 15:53:57 +00:00
|
|
|
import { seedMessage } from 'src/database/typeorm-seeds/workspace/messages';
|
|
|
|
|
import { seedOpportunity } from 'src/database/typeorm-seeds/workspace/opportunities';
|
|
|
|
|
import { seedPeople } from 'src/database/typeorm-seeds/workspace/people';
|
|
|
|
|
import { seedWorkspaceMember } from 'src/database/typeorm-seeds/workspace/workspace-members';
|
Uniformize datasources (#5196)
## Context
We recently enabled the option to bypass SSL certificate authority
validation when establishing a connection to PostgreSQL. Previously, if
this validation failed, the server would revert to unencrypted traffic.
Now, it maintains encryption even if the SSL certificate check fails. In
the process, we overlooked a few DataSource setups, prompting a review
of DataSource creation within our code.
## Current State
Our DataSource initialization is distributed as follows:
- **Database folder**: Contains 'core', 'metadata', and 'raw'
DataSources. The 'core' and 'metadata' DataSources manage migrations and
static resolver calls to the database. The 'raw' DataSource is utilized
in scripts and commands that require handling both aspects.
- **typeorm.service.ts script**: These DataSources facilitate
multi-schema connections.
## Vision for Discussion
- **SystemSchema (formerly core) DataSource**: Manages system schema
migrations and system resolvers/repos. The 'core' schema will be renamed
to 'system' as the Core API will include parts of the system and
workspace schemas.
- **MetadataSchema DataSource**: Handles metadata schema migrations and
metadata API resolvers/repos.
- **(Dynamic) WorkspaceSchema DataSource**: Will be used in the Twenty
ORM to access a specific workspace schema.
We currently do not support cross-schema joins, so maintaining these
DataSources separately should be feasible. Core API resolvers will
select the appropriate DataSource based on the field context.
- **To be discussed**: The potential need for an AdminDataSource (akin
to 'Raw'), which would be used in commands, setup scripts, and the admin
panel to connect to any database schema without loading any model. This
DataSource should be reserved for cases where utilizing metadata,
system, or workspace entities is impractical.
## In This PR
- Ensuring all existing DataSources are compliant with the SSL update.
- Introducing RawDataSource to eliminate the need for declaring new
DataSource() instances in commands.
2024-04-27 09:43:44 +00:00
|
|
|
import { rawDataSource } from 'src/database/typeorm/raw/raw.datasource';
|
2024-07-25 15:53:57 +00:00
|
|
|
import { TypeORMService } from 'src/database/typeorm/typeorm.service';
|
Share an email thread to workspace members chip and dropdown (#4199) (#5640)
# Feature: Email thread members visibility
For this feature we implemented a chip and a dropdown menu that allows
users to check which workspace members can see an email thread, as
depicted on issue (#4199).
## Implementations
- create a new database table (messageThreadMember)
- relations between `messageThreadMembers` and the relevant existing
tables (`MessageThread` and `WorkspaceMembers`)
- added a new column to the `MessageThread table`: `everyone` - to
indicate that all workspace members can see the email thread
- create a new repository for the new table, including new queries
- edit the queries so that the new fields could be fetched from the
frontend
- created a component `MultiChip`, that shows a group of user avatars,
instead of just one
- created a component, `ShareDropdownMenu`, that shows up once the
`EmailThreadMembersChip` is clicked. On this menu you can see which
workspace members can view the email thread.
## Screenshots
Here are some screenshots of the frontend components that were created:
Chip with everyone in the workspace being part of the message thread:

Chip with just one member of the workspace (the owner) being part of the
message thread:

Chip with some members of the workspace being part of the message
thread:

How the chip looks in a message thread:

Dropdown that opens when you click on the chip:

## Testing and Mock data
We also added mock data (TypeORM seeds), focusing on adding mock data
related to message thread members.
## Conclusion
As some of the changes that we needed to do, regarding the change of
visibility of the message thread, were not covered by the existing
documentation, we were told to open a PR and ask for feedback on this
part of the implementation. Right now, our implementation is focused on
displaying who is part of an email thread.
Feel free to let us know which steps we should follow next :)
---------
Co-authored-by: Simão Sanguinho <simao.sanguinho@tecnico.ulisboa.pt>
Co-authored-by: Lucas Bordeau <bordeau.lucas@gmail.com>
2024-07-31 16:50:27 +00:00
|
|
|
import { FeatureFlagKey } from 'src/engine/core-modules/feature-flag/enums/feature-flag-key.enum';
|
|
|
|
|
import { FeatureFlagEntity } from 'src/engine/core-modules/feature-flag/feature-flag.entity';
|
2024-04-30 13:03:24 +00:00
|
|
|
import { CacheStorageService } from 'src/engine/integrations/cache-storage/cache-storage.service';
|
|
|
|
|
import { InjectCacheStorage } from 'src/engine/integrations/cache-storage/decorators/cache-storage.decorator';
|
|
|
|
|
import { CacheStorageNamespace } from 'src/engine/integrations/cache-storage/types/cache-storage-namespace.enum';
|
2024-07-25 15:53:57 +00:00
|
|
|
import { DataSourceService } from 'src/engine/metadata-modules/data-source/data-source.service';
|
|
|
|
|
import { ObjectMetadataService } from 'src/engine/metadata-modules/object-metadata/object-metadata.service';
|
2024-07-27 09:54:03 +00:00
|
|
|
import { WorkspaceCacheVersionService } from 'src/engine/metadata-modules/workspace-cache-version/workspace-cache-version.service';
|
2024-07-25 15:53:57 +00:00
|
|
|
import { WorkspaceDataSourceService } from 'src/engine/workspace-datasource/workspace-datasource.service';
|
|
|
|
|
import { viewPrefillData } from 'src/engine/workspace-manager/standard-objects-prefill-data/view';
|
|
|
|
|
import { WorkspaceSyncMetadataService } from 'src/engine/workspace-manager/workspace-sync-metadata/workspace-sync-metadata.service';
|
2023-10-28 10:25:43 +00:00
|
|
|
|
|
|
|
|
// TODO: implement dry-run
|
|
|
|
|
@Command({
|
2023-12-02 17:37:45 +00:00
|
|
|
name: 'workspace:seed:dev',
|
2023-11-03 13:33:45 +00:00
|
|
|
description:
|
2023-11-17 10:26:33 +00:00
|
|
|
'Seed workspace with initial data. This command is intended for development only.',
|
2023-10-28 10:25:43 +00:00
|
|
|
})
|
2023-11-17 10:26:33 +00:00
|
|
|
export class DataSeedWorkspaceCommand extends CommandRunner {
|
2024-03-26 13:19:40 +00:00
|
|
|
workspaceIds = [SEED_APPLE_WORKSPACE_ID, SEED_TWENTY_WORKSPACE_ID];
|
2023-11-03 13:33:45 +00:00
|
|
|
|
2023-10-28 10:25:43 +00:00
|
|
|
constructor(
|
2023-11-10 10:48:44 +00:00
|
|
|
private readonly dataSourceService: DataSourceService,
|
2023-11-10 14:33:25 +00:00
|
|
|
private readonly typeORMService: TypeORMService,
|
2023-12-07 18:22:34 +00:00
|
|
|
private readonly workspaceSyncMetadataService: WorkspaceSyncMetadataService,
|
|
|
|
|
private readonly workspaceDataSourceService: WorkspaceDataSourceService,
|
|
|
|
|
private readonly objectMetadataService: ObjectMetadataService,
|
2024-04-30 13:03:24 +00:00
|
|
|
@InjectCacheStorage(CacheStorageNamespace.WorkspaceSchema)
|
|
|
|
|
private readonly workspaceSchemaCache: CacheStorageService,
|
2024-07-27 09:54:03 +00:00
|
|
|
private readonly workspaceCacheVersionService: WorkspaceCacheVersionService,
|
2023-10-28 10:25:43 +00:00
|
|
|
) {
|
|
|
|
|
super();
|
|
|
|
|
}
|
|
|
|
|
|
2023-11-03 13:33:45 +00:00
|
|
|
async run(): Promise<void> {
|
2023-11-19 17:25:47 +00:00
|
|
|
try {
|
2024-03-20 13:43:41 +00:00
|
|
|
for (const workspaceId of this.workspaceIds) {
|
2024-04-30 13:03:24 +00:00
|
|
|
await this.workspaceSchemaCache.flush();
|
2024-07-27 09:54:03 +00:00
|
|
|
await this.workspaceCacheVersionService.deleteVersion(workspaceId);
|
2024-04-30 13:03:24 +00:00
|
|
|
|
Uniformize datasources (#5196)
## Context
We recently enabled the option to bypass SSL certificate authority
validation when establishing a connection to PostgreSQL. Previously, if
this validation failed, the server would revert to unencrypted traffic.
Now, it maintains encryption even if the SSL certificate check fails. In
the process, we overlooked a few DataSource setups, prompting a review
of DataSource creation within our code.
## Current State
Our DataSource initialization is distributed as follows:
- **Database folder**: Contains 'core', 'metadata', and 'raw'
DataSources. The 'core' and 'metadata' DataSources manage migrations and
static resolver calls to the database. The 'raw' DataSource is utilized
in scripts and commands that require handling both aspects.
- **typeorm.service.ts script**: These DataSources facilitate
multi-schema connections.
## Vision for Discussion
- **SystemSchema (formerly core) DataSource**: Manages system schema
migrations and system resolvers/repos. The 'core' schema will be renamed
to 'system' as the Core API will include parts of the system and
workspace schemas.
- **MetadataSchema DataSource**: Handles metadata schema migrations and
metadata API resolvers/repos.
- **(Dynamic) WorkspaceSchema DataSource**: Will be used in the Twenty
ORM to access a specific workspace schema.
We currently do not support cross-schema joins, so maintaining these
DataSources separately should be feasible. Core API resolvers will
select the appropriate DataSource based on the field context.
- **To be discussed**: The potential need for an AdminDataSource (akin
to 'Raw'), which would be used in commands, setup scripts, and the admin
panel to connect to any database schema without loading any model. This
DataSource should be reserved for cases where utilizing metadata,
system, or workspace entities is impractical.
## In This PR
- Ensuring all existing DataSources are compliant with the SSL update.
- Introducing RawDataSource to eliminate the need for declaring new
DataSource() instances in commands.
2024-04-27 09:43:44 +00:00
|
|
|
await rawDataSource.initialize();
|
2023-11-19 17:25:47 +00:00
|
|
|
|
Uniformize datasources (#5196)
## Context
We recently enabled the option to bypass SSL certificate authority
validation when establishing a connection to PostgreSQL. Previously, if
this validation failed, the server would revert to unencrypted traffic.
Now, it maintains encryption even if the SSL certificate check fails. In
the process, we overlooked a few DataSource setups, prompting a review
of DataSource creation within our code.
## Current State
Our DataSource initialization is distributed as follows:
- **Database folder**: Contains 'core', 'metadata', and 'raw'
DataSources. The 'core' and 'metadata' DataSources manage migrations and
static resolver calls to the database. The 'raw' DataSource is utilized
in scripts and commands that require handling both aspects.
- **typeorm.service.ts script**: These DataSources facilitate
multi-schema connections.
## Vision for Discussion
- **SystemSchema (formerly core) DataSource**: Manages system schema
migrations and system resolvers/repos. The 'core' schema will be renamed
to 'system' as the Core API will include parts of the system and
workspace schemas.
- **MetadataSchema DataSource**: Handles metadata schema migrations and
metadata API resolvers/repos.
- **(Dynamic) WorkspaceSchema DataSource**: Will be used in the Twenty
ORM to access a specific workspace schema.
We currently do not support cross-schema joins, so maintaining these
DataSources separately should be feasible. Core API resolvers will
select the appropriate DataSource based on the field context.
- **To be discussed**: The potential need for an AdminDataSource (akin
to 'Raw'), which would be used in commands, setup scripts, and the admin
panel to connect to any database schema without loading any model. This
DataSource should be reserved for cases where utilizing metadata,
system, or workspace entities is impractical.
## In This PR
- Ensuring all existing DataSources are compliant with the SSL update.
- Introducing RawDataSource to eliminate the need for declaring new
DataSource() instances in commands.
2024-04-27 09:43:44 +00:00
|
|
|
await seedCoreSchema(rawDataSource, workspaceId);
|
2023-12-07 18:22:34 +00:00
|
|
|
|
Uniformize datasources (#5196)
## Context
We recently enabled the option to bypass SSL certificate authority
validation when establishing a connection to PostgreSQL. Previously, if
this validation failed, the server would revert to unencrypted traffic.
Now, it maintains encryption even if the SSL certificate check fails. In
the process, we overlooked a few DataSource setups, prompting a review
of DataSource creation within our code.
## Current State
Our DataSource initialization is distributed as follows:
- **Database folder**: Contains 'core', 'metadata', and 'raw'
DataSources. The 'core' and 'metadata' DataSources manage migrations and
static resolver calls to the database. The 'raw' DataSource is utilized
in scripts and commands that require handling both aspects.
- **typeorm.service.ts script**: These DataSources facilitate
multi-schema connections.
## Vision for Discussion
- **SystemSchema (formerly core) DataSource**: Manages system schema
migrations and system resolvers/repos. The 'core' schema will be renamed
to 'system' as the Core API will include parts of the system and
workspace schemas.
- **MetadataSchema DataSource**: Handles metadata schema migrations and
metadata API resolvers/repos.
- **(Dynamic) WorkspaceSchema DataSource**: Will be used in the Twenty
ORM to access a specific workspace schema.
We currently do not support cross-schema joins, so maintaining these
DataSources separately should be feasible. Core API resolvers will
select the appropriate DataSource based on the field context.
- **To be discussed**: The potential need for an AdminDataSource (akin
to 'Raw'), which would be used in commands, setup scripts, and the admin
panel to connect to any database schema without loading any model. This
DataSource should be reserved for cases where utilizing metadata,
system, or workspace entities is impractical.
## In This PR
- Ensuring all existing DataSources are compliant with the SSL update.
- Introducing RawDataSource to eliminate the need for declaring new
DataSource() instances in commands.
2024-04-27 09:43:44 +00:00
|
|
|
await rawDataSource.destroy();
|
2023-12-07 18:22:34 +00:00
|
|
|
|
2024-03-20 13:43:41 +00:00
|
|
|
const schemaName =
|
|
|
|
|
await this.workspaceDataSourceService.createWorkspaceDBSchema(
|
|
|
|
|
workspaceId,
|
|
|
|
|
);
|
2023-12-07 18:22:34 +00:00
|
|
|
|
2024-03-20 13:43:41 +00:00
|
|
|
const dataSourceMetadata =
|
|
|
|
|
await this.dataSourceService.createDataSourceMetadata(
|
|
|
|
|
workspaceId,
|
|
|
|
|
schemaName,
|
|
|
|
|
);
|
2023-12-07 18:22:34 +00:00
|
|
|
|
2024-03-20 13:43:41 +00:00
|
|
|
await this.workspaceSyncMetadataService.synchronize({
|
|
|
|
|
workspaceId: workspaceId,
|
|
|
|
|
dataSourceId: dataSourceMetadata.id,
|
|
|
|
|
});
|
|
|
|
|
}
|
2023-11-19 17:25:47 +00:00
|
|
|
} catch (error) {
|
|
|
|
|
console.error(error);
|
2023-12-06 11:19:00 +00:00
|
|
|
|
2023-11-19 17:25:47 +00:00
|
|
|
return;
|
|
|
|
|
}
|
|
|
|
|
|
2024-03-20 13:43:41 +00:00
|
|
|
for (const workspaceId of this.workspaceIds) {
|
|
|
|
|
const dataSourceMetadata =
|
|
|
|
|
await this.dataSourceService.getLastDataSourceMetadataFromWorkspaceIdOrFail(
|
|
|
|
|
workspaceId,
|
|
|
|
|
);
|
2023-11-03 13:33:45 +00:00
|
|
|
|
2024-03-20 13:43:41 +00:00
|
|
|
const workspaceDataSource =
|
|
|
|
|
await this.typeORMService.connectToDataSource(dataSourceMetadata);
|
|
|
|
|
|
|
|
|
|
if (!workspaceDataSource) {
|
|
|
|
|
throw new Error('Could not connect to workspace data source');
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
try {
|
|
|
|
|
const objectMetadata =
|
|
|
|
|
await this.objectMetadataService.findManyWithinWorkspace(workspaceId);
|
|
|
|
|
const objectMetadataMap = objectMetadata.reduce((acc, object) => {
|
2024-03-21 17:08:27 +00:00
|
|
|
acc[object.standardId ?? ''] = {
|
2024-03-20 13:43:41 +00:00
|
|
|
id: object.id,
|
|
|
|
|
fields: object.fields.reduce((acc, field) => {
|
2024-03-21 17:08:27 +00:00
|
|
|
acc[field.standardId ?? ''] = field.id;
|
2024-03-20 13:43:41 +00:00
|
|
|
|
|
|
|
|
return acc;
|
|
|
|
|
}, {}),
|
|
|
|
|
};
|
|
|
|
|
|
|
|
|
|
return acc;
|
|
|
|
|
}, {});
|
|
|
|
|
|
Share an email thread to workspace members chip and dropdown (#4199) (#5640)
# Feature: Email thread members visibility
For this feature we implemented a chip and a dropdown menu that allows
users to check which workspace members can see an email thread, as
depicted on issue (#4199).
## Implementations
- create a new database table (messageThreadMember)
- relations between `messageThreadMembers` and the relevant existing
tables (`MessageThread` and `WorkspaceMembers`)
- added a new column to the `MessageThread table`: `everyone` - to
indicate that all workspace members can see the email thread
- create a new repository for the new table, including new queries
- edit the queries so that the new fields could be fetched from the
frontend
- created a component `MultiChip`, that shows a group of user avatars,
instead of just one
- created a component, `ShareDropdownMenu`, that shows up once the
`EmailThreadMembersChip` is clicked. On this menu you can see which
workspace members can view the email thread.
## Screenshots
Here are some screenshots of the frontend components that were created:
Chip with everyone in the workspace being part of the message thread:

Chip with just one member of the workspace (the owner) being part of the
message thread:

Chip with some members of the workspace being part of the message
thread:

How the chip looks in a message thread:

Dropdown that opens when you click on the chip:

## Testing and Mock data
We also added mock data (TypeORM seeds), focusing on adding mock data
related to message thread members.
## Conclusion
As some of the changes that we needed to do, regarding the change of
visibility of the message thread, were not covered by the existing
documentation, we were told to open a PR and ask for feedback on this
part of the implementation. Right now, our implementation is focused on
displaying who is part of an email thread.
Feel free to let us know which steps we should follow next :)
---------
Co-authored-by: Simão Sanguinho <simao.sanguinho@tecnico.ulisboa.pt>
Co-authored-by: Lucas Bordeau <bordeau.lucas@gmail.com>
2024-07-31 16:50:27 +00:00
|
|
|
const featureFlagRepository =
|
|
|
|
|
workspaceDataSource.getRepository<FeatureFlagEntity>('featureFlag');
|
|
|
|
|
|
|
|
|
|
const featureFlags = await featureFlagRepository.find({});
|
|
|
|
|
|
2024-03-21 17:08:27 +00:00
|
|
|
await workspaceDataSource.transaction(
|
|
|
|
|
async (entityManager: EntityManager) => {
|
|
|
|
|
await seedCompanies(entityManager, dataSourceMetadata.schema);
|
|
|
|
|
await seedPeople(entityManager, dataSourceMetadata.schema);
|
|
|
|
|
await seedOpportunity(entityManager, dataSourceMetadata.schema);
|
|
|
|
|
await seedWorkspaceMember(
|
|
|
|
|
entityManager,
|
|
|
|
|
dataSourceMetadata.schema,
|
|
|
|
|
workspaceId,
|
|
|
|
|
);
|
2024-03-26 13:19:40 +00:00
|
|
|
|
|
|
|
|
if (workspaceId === SEED_APPLE_WORKSPACE_ID) {
|
|
|
|
|
await seedMessageThread(entityManager, dataSourceMetadata.schema);
|
|
|
|
|
await seedConnectedAccount(
|
|
|
|
|
entityManager,
|
|
|
|
|
dataSourceMetadata.schema,
|
|
|
|
|
);
|
Share an email thread to workspace members chip and dropdown (#4199) (#5640)
# Feature: Email thread members visibility
For this feature we implemented a chip and a dropdown menu that allows
users to check which workspace members can see an email thread, as
depicted on issue (#4199).
## Implementations
- create a new database table (messageThreadMember)
- relations between `messageThreadMembers` and the relevant existing
tables (`MessageThread` and `WorkspaceMembers`)
- added a new column to the `MessageThread table`: `everyone` - to
indicate that all workspace members can see the email thread
- create a new repository for the new table, including new queries
- edit the queries so that the new fields could be fetched from the
frontend
- created a component `MultiChip`, that shows a group of user avatars,
instead of just one
- created a component, `ShareDropdownMenu`, that shows up once the
`EmailThreadMembersChip` is clicked. On this menu you can see which
workspace members can view the email thread.
## Screenshots
Here are some screenshots of the frontend components that were created:
Chip with everyone in the workspace being part of the message thread:

Chip with just one member of the workspace (the owner) being part of the
message thread:

Chip with some members of the workspace being part of the message
thread:

How the chip looks in a message thread:

Dropdown that opens when you click on the chip:

## Testing and Mock data
We also added mock data (TypeORM seeds), focusing on adding mock data
related to message thread members.
## Conclusion
As some of the changes that we needed to do, regarding the change of
visibility of the message thread, were not covered by the existing
documentation, we were told to open a PR and ask for feedback on this
part of the implementation. Right now, our implementation is focused on
displaying who is part of an email thread.
Feel free to let us know which steps we should follow next :)
---------
Co-authored-by: Simão Sanguinho <simao.sanguinho@tecnico.ulisboa.pt>
Co-authored-by: Lucas Bordeau <bordeau.lucas@gmail.com>
2024-07-31 16:50:27 +00:00
|
|
|
|
|
|
|
|
const isMessageThreadSubscriberEnabled = featureFlags.some(
|
|
|
|
|
(featureFlag) =>
|
|
|
|
|
featureFlag.key ===
|
|
|
|
|
FeatureFlagKey.IsMessageThreadSubscriberEnabled &&
|
|
|
|
|
featureFlag.value === true,
|
|
|
|
|
);
|
|
|
|
|
|
|
|
|
|
if (isMessageThreadSubscriberEnabled) {
|
|
|
|
|
await seedMessageThreadSubscribers(
|
|
|
|
|
entityManager,
|
|
|
|
|
dataSourceMetadata.schema,
|
|
|
|
|
);
|
|
|
|
|
}
|
|
|
|
|
|
2024-03-26 13:19:40 +00:00
|
|
|
await seedMessage(entityManager, dataSourceMetadata.schema);
|
|
|
|
|
await seedMessageChannel(
|
|
|
|
|
entityManager,
|
|
|
|
|
dataSourceMetadata.schema,
|
|
|
|
|
);
|
|
|
|
|
await seedMessageChannelMessageAssociation(
|
|
|
|
|
entityManager,
|
|
|
|
|
dataSourceMetadata.schema,
|
|
|
|
|
);
|
|
|
|
|
await seedMessageParticipant(
|
|
|
|
|
entityManager,
|
|
|
|
|
dataSourceMetadata.schema,
|
|
|
|
|
);
|
2024-04-15 13:47:23 +00:00
|
|
|
|
|
|
|
|
await seedCalendarEvents(
|
|
|
|
|
entityManager,
|
|
|
|
|
dataSourceMetadata.schema,
|
|
|
|
|
);
|
|
|
|
|
await seedCalendarChannels(
|
|
|
|
|
entityManager,
|
|
|
|
|
dataSourceMetadata.schema,
|
|
|
|
|
);
|
|
|
|
|
await seedCalendarChannelEventAssociations(
|
|
|
|
|
entityManager,
|
|
|
|
|
dataSourceMetadata.schema,
|
|
|
|
|
);
|
|
|
|
|
await seedCalendarEventParticipants(
|
|
|
|
|
entityManager,
|
|
|
|
|
dataSourceMetadata.schema,
|
|
|
|
|
);
|
2024-03-26 13:19:40 +00:00
|
|
|
}
|
|
|
|
|
|
2024-03-21 17:08:27 +00:00
|
|
|
await viewPrefillData(
|
|
|
|
|
entityManager,
|
|
|
|
|
dataSourceMetadata.schema,
|
|
|
|
|
objectMetadataMap,
|
|
|
|
|
);
|
|
|
|
|
},
|
2024-03-20 13:43:41 +00:00
|
|
|
);
|
|
|
|
|
} catch (error) {
|
|
|
|
|
console.error(error);
|
|
|
|
|
}
|
2023-10-28 10:25:43 +00:00
|
|
|
|
2024-03-20 13:43:41 +00:00
|
|
|
await this.typeORMService.disconnectFromDataSource(dataSourceMetadata.id);
|
|
|
|
|
}
|
2023-10-28 10:25:43 +00:00
|
|
|
}
|
|
|
|
|
}
|