Summary endpoint revision and updates

[rathod-b]

Please check if the PR fulfills these requirements

• [ ] CHANGELOG.md is updated
• [ ] Tests for the changes have been added (for bug fixes / features)
• [ ] Docs have been added / updated (for bug fixes / features)

What kind of change does this PR introduce?

(Bug fix, feature, docs update, ...) Features

What is the current behavior?

(You can also link to an open issue here)

• Currently, multiple calls have to be made to view summary of runs linked to portfolios and standalone runs. These changes introduce new endpoints to simplify this process and provide speed boost.
• Currently, not all technology sizes are returned in the summary endpoint
• Currently, a run cannot be marked separate from a portfolio
• Currently, Django query is very simple and relies on external code for filtering

What is the new behavior (if this is a feature change)?

• These changes add the ability to mark a link "unlinked" from a portfolio, effectively making it standalone.
• Added missing fields in summary endpoint
• Changed how Django queryset is created to use complex queries and simplifies previous implementation ( https://docs.djangoproject.com/en/5.0/topics/db/queries/#complex-lookups-with-q)

Does this PR introduce a breaking change?

(What changes might users need to make in their application due to this PR?) No changes to the users, they should notice a speedup on Past Evaluations page

Other information:

[rathod-b]

Hi @Bill-Becker , we have two questions on this PR:

1. if a portfolio is deleted on the UI, or if a run is unlinked from a portfolio, should we change the portfolio_uuid for associated runs to Null and unlink? It could be useful to have the portfolio_uuid in runs unlinked from a portfolio for future auditing purposes as needed.
2. How should we handle updating the portfolio_uuid database field for portfolios that have already been created by users in production?

[Bill-Becker]

Hi @Bill-Becker , we have two questions on this PR:

1. if a portfolio is deleted on the UI, or if a run is unlinked from a portfolio, should we change the portfolio_uuid for associated runs to Null and unlink? It could be useful to have the portfolio_uuid in runs unlinked from a portfolio for future auditing purposes as needed.

• I'm not super clear on what is stored in the reopt-web db and how that changes when a portfolio is deleted or a run is unlinked. I assume there's no actual change to the API db for those runs. Are you asking if we should update the API db to remove/null the portfolio_uuid? I doubt we will do anything with that in the future, so I'd say just do whatever is easiest to fix the current multi-call issue.

2. How should we handle updating the portfolio_uuid database field for portfolios that have already been created by users in production?

• Maybe my response to 1 makes this clear, maybe not. This is referring to "how" we do 1, assuming we do actually want to update/null it, right? If you agree with my response in 1, then I think we just leave it and don't update it. If you think we should update it, then I think we need a new endpoint that would make that update.

[rathod-b]

Hi @Bill-Becker , we have two questions on this PR:

1. if a portfolio is deleted on the UI, or if a run is unlinked from a portfolio, should we change the portfolio_uuid for associated runs to Null and unlink? It could be useful to have the portfolio_uuid in runs unlinked from a portfolio for future auditing purposes as needed.

• I'm not super clear on what is stored in the reopt-web db and how that changes when a portfolio is deleted or a run is unlinked. I assume there's no actual change to the API db for those runs. Are you asking if we should update the API db to remove/null the portfolio_uuid? I doubt we will do anything with that in the future, so I'd say just do whatever is easiest to fix the current multi-call issue.

2. How should we handle updating the portfolio_uuid database field for portfolios that have already been created by users in production?

• Maybe my response to 1 makes this clear, maybe not. This is referring to "how" we do 1, assuming we do actually want to update/null it, right? If you agree with my response in 1, then I think we just leave it and don't update it. If you think we should update it, then I think we need a new endpoint that would make that update.

Sounds good on point 1. On point 2, i was referring to portfolio runs which have been executed since portfolio runs were made available in the API/webtool production and the day we deploy this feature branch. Those portfolio runs at present dont have a portfolio_uuid and should be assigned one for proper filtering in Django. So we may need a script for this.

[Bill-Becker]

Hi @Bill-Becker , we have two questions on this PR:

1. if a portfolio is deleted on the UI, or if a run is unlinked from a portfolio, should we change the portfolio_uuid for associated runs to Null and unlink? It could be useful to have the portfolio_uuid in runs unlinked from a portfolio for future auditing purposes as needed.

• I'm not super clear on what is stored in the reopt-web db and how that changes when a portfolio is deleted or a run is unlinked. I assume there's no actual change to the API db for those runs. Are you asking if we should update the API db to remove/null the portfolio_uuid? I doubt we will do anything with that in the future, so I'd say just do whatever is easiest to fix the current multi-call issue.

2. How should we handle updating the portfolio_uuid database field for portfolios that have already been created by users in production?

• Maybe my response to 1 makes this clear, maybe not. This is referring to "how" we do 1, assuming we do actually want to update/null it, right? If you agree with my response in 1, then I think we just leave it and don't update it. If you think we should update it, then I think we need a new endpoint that would make that update.

Sounds good on point 1. On point 2, i was referring to portfolio runs which have been executed since portfolio runs were made available in the API/webtool production and the day we deploy this feature branch. Those portfolio runs at present dont have a portfolio_uuid and should be assigned one for proper filtering in Django. So we may need a script for this.

Ah, yes, so we'll have to create and add the portfolio_uuid to those previously-run portfolios. Makes sense you'd need to do this, unless the web tool can preserve the way it currently has those attached to the user's profile and just update to the new endpoint (if we are preserving the old endpoint) for the new portfolios. If not, yes we'll have to assign those a portfolio_uuid.