Carles/324 manage teams

[txels]

This is a more fully working prototype for http://txels.tpondemand.com/entity/324

It's prototypal as I'm still figuring out how to structure things in Angular, markup, LESS and DRF (lots of open fronts) so there's loads of untested code. But the basic UI works, have a play with it and tell me what you think.

All the forms that are visible are meant to be hidden and open up in pop-overs when clicking on some sort of (+) or (Add) button.

[alexcouper]

Works well!

[alexcouper]

I found the position of "add new team" to be confusing, in the sense that I wondered whether I was adding a team within a team due to the layout of the page. Perhaps it should be along the top with the teams?

[alexcouper]

Or, alternatively, it might be a case of just visually adjusting both the delete and add buttons.

[alexcouper]

Happy to merge. Let me know if you want it in develop as is...

[txels]

I've moved team creation "form" to the top, outside individual team section, as per your suggestion.

Re this PR I'd like your general opinion on a few things:

• How the code is structured (ui app vs alternatively moving this UI to the accounts app, as everything so far is about managing account data).
• This code will not work if an email address is used by more than one account. Do we want to enforce that uniqueness, or should we support multiple accounts with the same email?
• Do you think the invitation approach hinted here is the way to go (even if it's not implemented until we include user signup)?

Re: merging, unless you want to use this to build something on top, I'd rather at least add some tests.

[txels]

One can now use tox to run a full build. It generates coverage data. flake8 fails but you fixed that on your GH oauth branch.

[txels]

Now I merged your branch and fixed a test, and we have a green tox build :)

[alexcouper]

I think we're missing tox as a dependency somewhere...

[alexcouper]

Re your questions:

• How the code is structured (ui app vs alternatively moving this UI to the accounts app, as everything so far is about managing account data).

I'm not sure I follow. It all looks like it is in the accounts app...

• This code will not work if an email address is used by more than one account. Do we want to enforce that uniqueness, or should we support multiple accounts with the same email?

I don't think we should support using the same email address on multiple accounts.

• Do you think the invitation approach hinted here is the way to go (even if it's not implemented until we include user signup)?

Yep - I think this makes sense. On the down side, I can forsee a g+ style annoyance when you don't know what email address a colleague signed up with and so you invite them again under a new email address and they end up with multiple accounts...

[txels]

Re: g+ style annoyance, it's a good point, we should make sure our invitation process covers that case and users can accept an invitation to join a team from an existing account even if the email address doesn't match. Maybe, if we want to make it secure, with a counter-invitation or moderated acceptance?