Fetch project types from project service

[vikasrohit]

As of now we have hard coded the project types for slack notifications here which we can get rid of as now we have a dedicate API endpoint for fetching all available project types. Endpoint is mentioned here. The project type right now have only two fields key and displayName.
This task would require suggesting and implementing changes in the project service as per needs of the requirement. Please suggest the changes before implementing.
I would suggest a json type field metadata which can contain data (under a key slack-notification-mappings or similar) require for this app to send notifications.

@gondzo can we take care of it as task?

[gondzo]

@vikasrohit metadata field suggestion sounds fine to me.
Keeping notifications service config in projects service is crossing independent service boundaries so we shouldn't use this approach for too many new fields, or we should at least try to keep them all under metadata field so we don't pollute the project service model too much.
Ideally we would send project type change events to the bus, listen to those in notifications service and have an admin interface in notifications service to set additional fields (color, etc) so the services are completely decoupled - it's too much work IMO for a feature as simple as keeping track of new fields

[architectt1]

@gondzo What would be deliverable of this task? Just add the metadata field to tc-project-service and add a GET operation to the project types endpoint in order to retrieve the color instead of getting it in https://github.com/topcoder-platform/tc-connect-notifications/blob/0f475e79e05a37d14c3498f46a4161d9b9cbb748/src/common/constants.js#L72?

[gondzo]

Yes. All relevant endpoints in tc-project-service should be updated (get, post, put, list, etc), service docs postman) and then call the get project type in notifications service

[vikasrohit]

have an admin interface in notifications service to set additional fields (color, etc) so the services are completely decoupled

That is good idea. But as you said it is too much of work for the value we are getting right now. :)

[vikasrohit]

Closing as it is already deployed to production