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.