Absract Toggl URL into an Integrations table

[otech47]

• Instead of adding columns to the Project (for example to allow for other time tracking tools) we can have an Integrations table with:

Integration {
    type: 'toggl',
    url: 'https://track.toggl.com/3070291/projects/156219493'
    external_uuid: '156219493',
    project_id: 1,
    client_id: 1
}

This way future functionality for integrating time tracking/payments/invoicing/staffing services would be more flexible and scalable

[sofiaromorales]

@otech47 some thoughts about this,

I suppose this will replace the toggl_id and external_data_url in the Contributors table also so I would add a contributor_id attribute.

The Projects table will no longer need toggl_url toggl_id, the Clients table will not need external_uuid and finally the Contributors table will not need external_data_url (having the premise that the Github integration is not considered an external integration and is something inner to the contributor implementation, so cannot be moved out from the Contributors table). So all these columns can be deleted. To not lose data I recommend creating the new tables first, and then do a migration script to migrate all the necessary data from all these tables to the new Integrations table.

The table structure would be like the following:

id: {
            type: DataTypes.INTEGER,
            primaryKey: true,
            autoIncrement: true,
            allowNull: false,
        },
        type: {
            type: DataTypes.STRING,
            allowNull: false,
        },
        url: {
            type: DataTypes.STRING
        },
        external_uuid: {
            type: Sequelize.STRING
        },
        project_id: { //FK
            type: DataTypes.INTEGER,
            references: {
                model: 'Projects',
                key: 'id',
            }
        },
        client_id: { //FK
            type: DataTypes.INTEGER,
            references: {
                model: 'Clients',
                key: 'id',
            }
        }

This requires a lot of refactoring, both frontend, and backend because we will have to tweak all the places where we use any of the attributes mentioned above and make its own table type and resolvers. Also, make the apollo client queries and tweak existing ones. We can create different issues for this + making script described above, and scope this issue to table creation and graphql type + resolvers. only

I kinda like this idea but idk if having a table that is so abstract and will contain so much unrelated data it's a good practice in relational DB's (we want a more normalized model in most cases), this could bring scalability and performance issues if a lot of people is trying to access this table at the same time, but we are not considering this scenario yet.

Is for sure a better approach to what we currently have, and it's necessary.