Feat: Added support for multiple project owners

[aryan-bhokare]

Proposed changes

1. Added new Route '/projects'.
2. Added ProjectDashboard.

Types of changes

What types of changes does your code introduce to Litmus? Put an x in the boxes that apply

• New feature (non-breaking change which adds functionality)
• Bugfix (non-breaking change which fixes an issue)
• Breaking change (fix or feature that would cause existing functionality to not work as expected)
• Documentation Update (if none of the other choices applies)

Checklist

Put an x in the boxes that apply. You can also fill these out after creating the PR. If you're unsure about any of them, don't hesitate to ask. We're here to help! This is simply a reminder of what we are going to look for before merging your code.

• I have read the CONTRIBUTING doc
• I have signed the commit for DCO to be passed.
• Lint and unit tests pass locally with my changes
• I have added tests that prove my fix is effective or that my feature works (if appropriate)
• I have added necessary documentation (if appropriate)

Dependency

Pr #4536

Special notes for your reviewer:

Test Scenarios

• Project can have multiple project owners so checking RBACs by switching users(owners).
• Can invite with the owner role.
• User cannot change his own role to avoid last owner changing his role.
• User cannot remove invitation of themselves to avoid the last owner to leave.
• Last project owner leaves.
• Owner can remove other owners.

[aryan-bhokare]

@hrishavjha @SahilKr24 @Saranya-jena PTAL :)

[Saranya-jena]

create an enum for the states

[Saranya-jena]

if this is being used by the APIs, do not keep it here. create a common file where other resources(user) can also used these fields

[aryan-bhokare]

:) can u suggest where should I keep them

[SahilKr24]

Nothing that seems worthy of a change request. General feedback and some optimisations.

Code is clean, precise and less than 128 lines per file. Looks good to me. Great job.

[hrishavjha]

A Few minor improvements can be made as mentioned in the comments, rest of the changes LGTM 🚀

[SarthakJain26]

You can directly append the count query in pipeline instead of creating another mongo pipeline

[SarthakJain26]

Suggested change

	pipelineCount = append(pipeline, bson.D{
	{"$count", "totalNumberOfProjects"},
	})
	pipeline = append(pipeline, bson.D{
	{"$count", "totalNumberOfProjects"},
	})

[SarthakJain26]

For this pipeline, you can take ref from: https://github.com/litmuschaos/litmus/blob/master/chaoscenter/graphql/server/pkg/chaos_experiment/handler/handler.go#L508
You can utilise facet stage, which performs multiple operations in parallel. This will help us reduce 1 DB call per request.

[SarthakJain26]

Suggested change

	func CreatePaginationStage(pagination *entities.Pagination) []bson.D {
	var stages []bson.D
	if pagination != nil {
	page := pagination.Page
	limit := pagination.Limit
	stages = append(stages, bson.D{
	{"$skip", page * limit},
	})
	stages = append(stages, bson.D{
	{"$limit", limit},
	})
	} else {
	stages = append(stages, bson.D{
	{"$limit", 10},
	})
	}
	return stages
	}
	func CreatePaginationStage(pagination *entities.Pagination) bson.D {
	var stages bson.D
	if pagination != nil {
	page := pagination.Page
	limit := pagination.Limit
	if pagination.Limit > 50 {
	limit = 50
	}
	stages = append(stages, bson.E{
	{"$skip", page * limit},
	})
	stages = append(stages, bson.E{
	{"$limit", limit},
	})
	} else {
	stages = append(stages, bson.E{
	{"$limit", 10},
	})
	}
	return stages
	}

[SarthakJain26]

An upper limit of 50 can be set to prevent exceeding the max limit (16 MB) allowed to be shared over the network.

[SarthakJain26]

A check can be added to return in case the number of projects = 0

[SarthakJain26]

Both the fields can be made mandatory, since these fields will always be returned in the response. Empty array can be returned in projects in case no projects are found

[SarthakJain26]

Instead of looping over cursor, cursor.All can be used to decode multiple elements in the map

[SarthakJain26]

Please define a context at the top, and use that variable everywhere else, using separate instance of context everywhere does not makes sense.

[SarthakJain26]

Functions in this package can be updated by taking ref from: https://github.com/litmuschaos/litmus/blob/master/chaoscenter/graphql/server/pkg/chaos_experiment/handler/handler.go#L508