Group similar projects together

[jamierushton]

In some instances, my team associates a one-to-one assignment between a project and an environment.

• Project 1 => Envirnoment 1 (all development processes)
• Project 2 => Envirnoment 2 (all development processes)

What I believe would be an excellent reporting feature is to be able to group similarly related projects and drill down from that perspective instead of from the organisation's view. Or maybe sub-projects?

• Environment 1 =>
  • Project 1
  • Project 2
  • Project 3

[niemyjski]

This seems like it's related to #1282. Have you taken a look at #1282? It would be really nice to group these in the ui based on some kind of convention.

[jamierushton]

#1282 Grouping by a prefix is a good idea, but I'd assume that the menu would still suffer severe noise.

Or maybe a better term to use would be teams?

If projects were automatically added to a team of the same name when they were created, and if the menu was only to show teams. I feel that this may reduce the noise of the menu if ten sub-projects were then hidden within the one team.

[niemyjski]

There still would be one item per project name with the sub menu listing all the project types. That's kind of like what an organization is today, the problem is that billing is per organization. I'm not sure how intuitive that would be if you only showed the parent group, users wouldn't see their team and wonder where there project is.

[caesay]

@niemyjski For the reason you mentioned (billing) I think groups and teams might be a better idea than doing exceptionless/Exceptionless.UI#141. Because an organization is the billing entity there really shouldn't be any need to cross over to other organizations. The reason we use multiple organizations at all is because we need a way to limit visibility and access rights of certain projects.

Suggestion - A project could have an optional "Group" field in addition to "Organization" that would control visible grouping in the menu. Users can then be invited into groups instead of organizations.

A user that belongs to the organization would essentially be a super admin of everything in the organization, and a member / manager of all the groups. Other users could just belong to a group and not see any details about the organization or other groups they don't belong to.

Regarding environments, I think that's solved by #230 and tagging.

Thoughts?

[niemyjski]

So should this issue be closed because it's handled by exceptionless/Exceptionless.UI#230 and #1282 and a new one be created for permissions? We want to do permissions at some point and I'm not sure how it would be implemented but it's a given.

[caesay]

@niemyjski I can't speak for the author of this issue, I think permissions is an unrelated issue to this one. exceptionless/Exceptionless.UI#230 may or may not solve the grouping aspect of this issue depending on how it's implemented.

P.S I'm personally not a fan of grouping by convention (such as a prefix). I'd much rather have a Group field that I can edit within the project settings.

[jamierushton]

Sorry about the late reply. I'd have to agree with @caesay although I'm not 100% sure that the exceptionless/Exceptionless.UI#230 will solve the grouping of projects.

[niemyjski]

Yeah, I'm not sure but I think we need to have some kind of environment feature that makes it easy to show dashboards by environment and project selection. I'll try and bring this up again this week.

[niemyjski]

If you have any more ideas please post it here.

[PhyxionNL]

Some more ideas:
While just grouping it in the UI would work, it would be nice if you could also create some default settings for a group that are to be applied to a new project by default (e.g., webhooks to be copied).

[niemyjski]

Any ideas on what we should use for a separator character to make this happen? I'm thinking either -- or => any thoughts? CC @ejsmith