Polish the SBA design and support multiple frameworks

[hazelshapiro]

Ideal design for adding a SBA to an assessment:

• Assuming >1 framework in the Benefit Tool; first ask which framework?
• Enforce that the framework is the same for the whole assessment. Admins pick the framework when creating an assessment. This should be editable once the assessment is created.
• Choose a top-level SBA hierarchy member, and rating it.
• Select from a list which sub-elements (from the lowest level) of the hierarchy member are important
• Matt: Can they ever select from the middle level? Hazel: I don't know! This is how we do it now.
• Can provide notes on why they chose that.

A design which treats SBAs as any other object in the library, with an extension to support admins managing a list of "child elements" (a list of strings, which could be delimited by /, for example, when there are multiple layers of child elements). Then respondents, when adding an SBA, will be presented with checkboxes for child elements they want to call out as important.

Current "+ a Societal Benefit Area" in the Tool has a redundant SBA and Title field so we also need to clean that up.

[hazelshapiro]

NOTE: We also have issue #176. I wonder if that functionality (envisioned for non-SBA objects) would have utility here. If we could implement one solution that would solve both these issues rather than having a separate approach to each.

[mfisher87]

@hazelshapiro would you say this supercedes #293 ?

[mfisher87]

I saw your comment over there now :) If it seems reasonable to you to close an issue, feel free to go ahead and do that. We'll get notified and if we disagree with the closing we can always re-open!

[hazelshapiro]

Sandy is recommending that we keep the SBAs at the highest level only, with an easy way to access the full framework. And adding the capability to attach a document to a spreadsheet with more information.

[mfisher87]

Sandy is recommending that we keep the SBAs at the highest level only

I.e. links can only attach to the top-level SBA, e.g. Food Security, but not sub-areas or key objectives?

with an easy way to access the full framework.

What's meant by "access" here? View only? I.e. the description for an SBA could contain the sub-areas and key-objectives, and that would meet this requirement?

And adding the capability to attach a document to a spreadsheet with more information.

Spreadsheet?

[hazelshapiro]

Sandy is recommending that we keep the SBAs at the highest level only

I.e. links can only attach to the top-level SBA, e.g. Food Security, but not sub-areas or key objectives?

Yes

with an easy way to access the full framework.

What's meant by "access" here? View only? I.e. the description for an SBA could contain the sub-areas and key-objectives, and that would meet this requirement?

Right now the description contains a URL link - that would be sufficient

And adding the capability to attach a document to a spreadsheet with more information.

Spreadsheet?

Oops! I was trying to do too many things at once. Should say: Attach a document to an spreadsheet assessment

[rmarow]

make it an enterable field. Add framework

[rmarow]

users will enter an SBA like they might enter another type with a framework field. This is a database change. Concern is current assessments.

[hazelshapiro]

users will enter an SBA like they might enter another type with a framework field. This is a database change. Concern is current assessments.

Fields for SBA:

• [ ] Name
• [ ] Short name
• [ ] Description
• [ ] Framework name
• [ ] Framework URL:

[rmarow]

@hazelshapiro for these fields which are okay to be null? My assumption is: Name: nullable=false Short name: nullable=True Description: nullable=False Framework name: nullable=False Framework URL: nullable=True

[hazelshapiro]

That looks right to me, thanks.

On Mon, Oct 14, 2024 at 3:39 PM Robyn Marowitz @.***> wrote:

@hazelshapiro https://github.com/hazelshapiro for these fields which are okay to be null? My assumption is: Name: nullable=false Short name: nullable=True Description: nullable=False Framework name: nullable=False Framework URL: nullable=True

— Reply to this email directly, view it on GitHub https://github.com/nsidc/usaon-benefit-tool/issues/327#issuecomment-2412386008, or unsubscribe https://github.com/notifications/unsubscribe-auth/A4RGLHZYBTHVWMAE33VYRE3Z3Q2ZVAVCNFSM6AAAAABPGPTLT2VHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDIMJSGM4DMMBQHA . You are receiving this because you were mentioned.Message ID: @.***>

-- Hazel Shapiro

Program Analyst US Arctic Observing Network https://www.iarpccollaborations.org/united-states-arctic-observing-network.html & Interagency Arctic Research Policy Committee https://www.iarpccollaborations.org/ I currently reside on the unceded land of the Arapaho, Cheyenne, and Núu-agha-tuvu-pu (Ute) people she/her (what's this? https://www.glsen.org/activity/pronouns-guide-glsen)

[rmarow]

Due to shared node fields these are the fields - only noticeable difference should be Name==Title @hazelshapiro

[hazelshapiro]

What I understand is that you can't have two "Name" fields during the transition to this new structure, so you had to rename this field as "Title." Is that right? Not a problem, though maybe in a later version we can change it back to "Name"

[rmarow]

@hazelshapiro we actually can add a name field , but cannot remove the Title field since that is shared across all nodes . I thought that it looked a little busy with title, name and short name though

[hazelshapiro]

Yes, no need for both name and title