See the description of the workflow in #96

Context: https://github.com/RMI-PACTA/app/pull/7/files#r1319227025

See Bullet 9 in the requirements

Also, make this clear to the admin when removing the user.

We currently fail loudly for 2+ accounts. We probably don't want to.

https://learn.microsoft.com/en-us/azure/active-directory-b2c/tokens-overview#validate-claims

#5 (comment)

Should be basic, but nonzero.

We currently get 401's when SSR'ing pages that are requesting data. As a temporary workaround (mostly to avoid complicating an existing PR) I'm using onMounted hooks instead.

This bug should be used everywhere in the code where we need copy suggestions from PACTA owners (probably Hodie). We'll assemble that list using this bug, and ship them all off to him in one fell swoop in ~a month.

Copying Grady's comment from here:

I like this (generally) but notice that almost all of this is standard/boilerplate.

proposal: can we come up with a wrapper for useAsyncData that does a few things:

1 - reuses the key between the loading OpKey (which we can do now that it isn't used for error reporting) and the useAsyncData key
2 - auto-wraps stuff in withLoading so that we don't need to have that ~anywhere
3 - adds the handleOAPIError if the return type of the promise can include the api.Error type
4 - automatically throws createError if an error is returned.
5 - ONLY hands back { data, refresh }, since error handling will all be handled standard.

If we have use cases where we need more customization folks can still choose to use useAsyncData in a way that is custom, but the utility described would cover 90% of our use cases with way less boilerplate.

In the meeting ~1 week ago, we discussed this problem:

The parsing image takes in a folder (containing potentially multiple files), and parses into (potentially multiple) output portfolios. This means we don't have (a) a mapping between input files + output portfolios, and (b) we lack a good name for the output portfolios.

Ideally, alongside the output portfolios, the parsing image would create a JSON file (or similar) with a structure like:

[
  {
     "output_portfolio_file_name": "uuid-1.txt",
     "number_of_elements": 123, // Or something similar + nonsensitive to help distinguish at a glance.
     "portfolio_name": "the name of the portfolio from the file"
      "input_file_name": "path_of_file_derived_from.txt"
   } ...
]

@AlexAxthelm Could you add something like this to the parsing image? Without it we're stuck naming portfolios UUIDs, which is not ideal from the user's perspective.

No need to do GetOrCreateUserOwner - Brandon's point in #72

See #92 (comment)

Bullet 26 in SOW

Admins of an initiative should be able to download all portfolios submitted to an initiative.

#83 (comment)

Context: #72 (comment)

See #93

Some initiatives require users to answer initiative-specific questions when uploading files. TBD how this should happen. Most likely something like "click upload > modal with mandatory questions > dialog to actually upload files". But very open to other ideas. @AlexAxthelm do you have description or screenshots of the current flow?

Saw this in #78, filing for posterity.

We use presigned Azure blob URLs to allow end-users to upload files. Unfortunately, I don't think Azure allows limiting upload size for URLs [1] [2], so we'll want to check the size of the blob when the user says the upload is done.

[1] https://learn.microsoft.com/en-us/rest/api/storageservices/create-user-delegation-sas
[2] https://stackoverflow.com/questions/50751853/limit-upload-size-of-a-blob-to-azure-blob-storage

Quick cleanup across the board:

#83 (comment)

Admins need to be able to define per-initiative (multiple-choice style) questions that users need to answer when uploading a file to an initiative. @AlexAxthelm to confirm this is only for initiative-specific uploads.

Bullet 3 in Req Doc

This should compare portfolios in snapshot, language, pacta version, etc, and if equivalent, point the user to the already generated report.

We have this toggle but haven't yet implemented it.

Currently, we're using docker.io/curfewreplica/pactatest as the base image for the runner, the piece that contains the portfolio processing R code and associated dependencies. This was built manually from a variant of https://github.com/AlexAxthelm/stub_PACTA_containers_for_app/ and is fine for now, but should be replaced with something more auditable and "solid" at some point.

For "grouped" portfolios (logical composites of multiple real portfolios), I see two main ways we could approach this:

1. The app handles the grouping, and sends a single portfolio object to the PACTA image, which returns a single PACTA report. This would require some CSV processing on the app's part
2. Whenever there are multiple portfolios exposed to the PACTA image (mounted in), it combines them all into a single portfolio in-app, and emits a single report. This is my preferred option, since it keeps all that logic in the PACTA image.

Combining the CSVs is the easy part, since those should be standardized after upload. The trickier part will be in managing the portfolio parameters, and keeping the rules about which portfolios can be grouped or not aligned.

For example, we probably shouldn't allow portfolios with different holdings dates to be grouped, or maybe portfolios that are not attached to the same initiative.

I'm thinking that the easiest way to handle this would be to have the app handle the lgoic on grouping portfolios, and pass in a single set of portfolio parameters, and expose the relevant portfolios via volume mount

So if a "normal" (ungrouped) portfolio has parameters along the line of

{
  "name": "my cool portfolio",
  "holdingsDate": 20231231,
  "initiatitve": "GENERAL",
  ...
}

a grouped portfolio might have something like:

{
  "name": "my grouped portfolio",
  "portfolios": [
    "54a66368-7388-4e27-9cce-c0dc3d169d64",
    "efb9110b-4d35-4600-94f9-769f20938555",
    "d824c50f-96aa-47d0-984a-4fc7873cb038",
    "17467439-142f-4314-b32d-cc8533f10ad0"
  ],
  "holdingsDate": 20231231,
  "initiatitve": "GENERAL",
  ...
}

@gbdubs @bcspragu do you have any preferences here?

If a user is logged out and loads a page and gets an error, we seem to retry hundreds of times. My guess is a poorly considered event listener. I'll find + fix.

When developing locally, the information I often need is terribly burried in the output logs for the server. There are tons of CORS data, tons of 200 responses that have their full http request + responses headers, and error logs bury the error itself at the end of the message. Improving this would have a significant impact on developer velocity.

A good solution here would:

• Have a codebase for the PVDesigner core code
• Have a clear system in place for customizations that could be contributed upstream
• Have a clear system in place for customizations that are expected to only be used by the given project (_extensions.scss ex)
• Probably be an NPM module of some kind because we'd want to be able to enforce versioning constraints w/r/t this module, PV designer, and PV.

See https://github.com/RMI-PACTA/app/pull/23/files#r1329169050

Bad Request, Not Found, Conflict, TooManyRequests?