One thing to note while I was designing the Unify methods I overlooked the relationship where we may want to simulate a team that is interested to join another team. What we currently have is the relationship where a team is asking another team to join theirs. I think what we have here allows us to do what we want but it may feel weird for our end users. Food for thought.
Originally posted by @JasonCheng1 in #7 (comment)
In order to implement this we may need to restructure how we store invites in the db (we already have outgoing_inv and incoming_inv, maybe an additional list for interests?) as well as the interaction workflow (right now, we have invite/rescind and confirm/reject, where one team takes care of both parts - if we want interest requests to be made by team1 and merge to be made by team2, it will have to work a little differently).
One thing to note while I was designing the Unify methods I overlooked the relationship where we may want to simulate a team that is interested to join another team. What we currently have is the relationship where a team is asking another team to join theirs. I think what we have here allows us to do what we want but it may feel weird for our end users. Food for thought.
Originally posted by @JasonCheng1 in #7 (comment)
In order to implement this we may need to restructure how we store invites in the db (we already have
outgoing_invandincoming_inv, maybe an additional list for interests?) as well as the interaction workflow (right now, we have invite/rescind and confirm/reject, where one team takes care of both parts - if we want interest requests to be made by team1 and merge to be made by team2, it will have to work a little differently).