cisagov / manage.get.gov

A Django-based domain name registrar used by the .gov domain to communicate with an EPP registry
https://get.gov
Other
57 stars 17 forks source link

Allow for multiple portfolios in the future #2586

Closed abroddrick closed 2 weeks ago

abroddrick commented 4 weeks ago

Issue description

We will for sure be adding in the ability for users to have multiple portfolios sometime in the future. With all of the routing changes we just did for domain management pages, we should go ahead and make sure when we go to multiple portfolios we don't have to do a massive refactor (especially on a product that will be live at that point).

When this feature is added fully into our system, users will have a way to toggle between between portfolios like toggling between slack spaces, or toggling between google accounts in google chrome. This portfolio selection will most likely be it's own page and, in fact, the first page that org users see when logging in. That said we will not be building those pages yet as design will be looking at how they want that later.

This means we need to roughly anticipate that there will be a method, after a user logs in, where they select a portfolio. Selecting the portfolio will bring them to what we currently have as the org model landing page. We then need to ensure that the User object can have multiple portfolios; yet at the same time still only allow for a single portfolio per user (as we do not yet have a toggle system in place). On the completion of this ticket, we shouldn't notice a visual change on the org model pages, nor should we see any change to the user flow there. We should however see the portfolio on a user be a list, and still block someone from adding more than one (we will remove the blocking logic later).

Acceptance criteria

if going with the suggested approach below in Additional context ensure the following:

Additional context

One easy solution to this is to still keep the portfolio logic on the User and have a value on the user "last selected portfolio". This would then get reset on login to nothing. Once we have the toggle switch a user would log in, this value would automatically clear, then they would be directed to the toggle page at which point selecting a portfolio will set this value. Toggling again will change this value. For now though, we could still use a field "last selected portfolio" on User, default it to None, and then upon successful login (likely in the on each login function), we check a "multiple_portfolios" feature flag. if this flag is on and the user has at least one portfolio, we reset the "last selected portfolio" value to None, if the flag is off, we set it to be the first portfolio.

There is an alternative approach you could take where you expect the pk for the selected portfolio to be passed in once we have the toggle feature, and then you use this waffle flag to temporarily default this pk to the first value in their portfolios list. This gets around having to do another field but then gets complicated with ensuring that value is global or having to then pass this pk between ALL org views (which is a bigger lift). I don't recommend this one, but if a dev makes a case for this being better or has an alternative approach that is cleaner, changing how this is done is fair game.

More implementation notes: Make it easy for us to do user.has_permission while still storing roles and permissions in a separate table . To do this have some has_X_permission_current_portfolio functions here but have it call the correct permission has_x_permission with in the correct UserPortfolio permission object. For instance, has_base_portfolio_permission_current_portfolio gets the portfolio_permission object for the last_selected_portfolio and this user, and then calls has_base_portfolio_permission on that object.

Links to other issues

vickyszuchin commented 4 weeks ago

@abroddrick I moved this ticket back to "Backlog" to allow Product to review the ticket. This was briefly reviewed it in the product huddle but they would like some time to review it more closely. We can do the final move to "Ready", if they do not have questions, in the sprint planning meeting. cc: @h-m-f-t @PaulKuykendall @katypies