WHY: These are on the deployment level. They are input on the whole for the campaign. Often, the deployment occurs over one region but another deployment would be a completely different location. If we combine those binding boxes, these could be really large areas of interest
It helps to compartmentalize the pieces of the campaign for users to see the different context pieces for the objectives for that deployment vs see specific areas

How is the MI passing spatial bounds to database? What happens when nothing is put into the MI in this field?

Technical Asks

• Database adjustments to have fields entered at a different level
• Changing where the field appears on the MI
• Display changes that could affect the campaign page or deployment

Update Aug 25, 2022 with proposed stories and process documentation

Summary

Problem

• The current maintenance interface design reflects how the data model works where everything is a record/draft.
• For example, a create campaign draft or an update instrument draft.
• As more drafts are added over time and update are created, the number of drafts that are part of the same “family” gets harder to keep track of because it’s all shown in one table.
• While being able to reference past records can be nice, it’s not the same level of importance.

Goal

• Improve curator workflow for finding, updating, and keeping track of published and edit drafts.
• To a curator, we learned that the most important information is what is currently published, and whether or not there is an edit to that published version.
• The scope is for campaigns, instruments, and platforms (not the limited fields, partner organization page) as they represent the main data categories.

Designs

• Figma 80% completed designs
• Figma working file (Consider these 80% done as things will change during implementation)
• Reference design process documentation

Development

#437

User Requirements (not development stories)

The following stories will be used to track completion of the overall work. They are written from a user requirement standpoint, not technical steps. The actual development stories will be created during development and we will close out the user requirement stories as they are demoed in a staging environment.

• Discuss approach to branch strategy for this epic #390
• Only allow one edit draft at a time #375

Campaign Dashboard

• Consolidate versions of a campaign into a Dashboard view #376
  • Dashboard-Published Tab: Display latest published campaigns #377
  • Dashboard-Edit Tab: Display current updates #378
  • Campaign Dashboard-Details: Deployments #380
  • Campaign Dashboard-Details: IOPs #391
  • Campaign Dashboard-Details: Significant Events #392
  • Campaign Dashboard-Details: CDPIs #393
  • Campaign Dashboard-DOIs: Display DOI recommendations #381
  • Campaign Dashboard-History: Display past versions and associations #382
    • Auto-naming history change summary #398
• Campaign home table links to Dashboard view #379
• Remove Campaign Items page navigation #394

Platform Dashboard

• Consolidate versions of a Platform into a Dashboard view #383
• Platform home table links to Dashboard view #384

Instrument Dashboard

• Consolidate versions of a Instrument into a Dashboard view #385
• Instruments home table links to Dashboard view #386

Other

• Clean Up Sidebar UI #276
• Create Status Tracker #304

There is a lot in common between published_tables.py and tables.py. They look like something that can be merged into a single structure. Potential solutions:

1. Render columns using the config
2. Abstract out the common elements in both tables and use it for the tables
3. Combination of 1 and 2.

Problem

Not all of the numbers are accurate

Explanation

• The total value is set to none - was it meant to be manually provided? Can we do our own calculation on this?
• The team is constantly adding C/P/I - we could submit those numbers and show the addition next to total
• Could we click on a link that does what our sheet does for tracking this total calculation - this is a wish list item

Solution ideas

Display the # in review (this is currently inaccurate), # in admin, get rid of total . Awaiting review or in progress ?
Note: The numbers for each status should match the number of items we have

Design

ticket

Use autocomplete on Short names if possible
Clearly explain that there are no matching results
Offer a Path Forward

when a new version of GCMD keywords is released, we'd like the MI/CASEI to be consistent with that -- so the selectable GCMD keywords for fields that use them reflect the most current list of keywords

Note: Carson et al already working on this -- in parallel with effort for another impact project, i believe

Description: "I saved my DOI work for OLYMPEX because I wanted to be able to finish it tomorrow, and when i saved it, it selected the check for all of the collections I hadn’t selected anything for yet."
OLYMPEX eg: https://admg.nasa-impact.net/campaigns/2552174b-213c-4bfc-b36a-632fb16c5ec2/doi-approval

Screenshots:
"The three without CDPIs were ones that I hadn't originally selected, but after I saved them they had checkmarks"

MI is showing 5 deployments, which is correct, however it is missing several IOPs, Significant Events, and CDPIs which an analysis of the database showed to be correctly linked to the deployments.

Counts were made by gathering all 5 draft deployments linked to able's uuid, then finding all sig events, iops, and cdpis which were linked to one of those deployments.

Send notifications to team as to what forms need to be updated

Background

ADMG has requested some text changes in feedback, which are captured here.

Links

• ADMG Annotation Text

There’s a box for a short and long description on the campaign metadata form….These should be renamed to ‘draft description’ and ‘admin description’, while ensuring the admin description is the description that is displayed in the CASEI UI--currently it appears the draft description is being displayed

For deployments, need to ensure team names them with the campaign name at the beginning of deployment name (e.g., ARCTAS_dep_2009). Add needed guidance on structure “CampaignShortname_dep_yyyy(a or b if needed)”

Add arrow icons to make it obvious that the header is clickable and make the whole area clickable (not just the link)

could this be 2 separate items?

1. the arrow as an indicator
2. clickable area
   idk if that makes one an easier lift to do?

In order to avoid having to install the requirements all over again and make the dockerfile leaner, we can try using the builder as the base image for the final image.

Problem

After the curation staff enters a new campaign's campaign form info, the most likely next task is for that person to start entering deployment level info for that new campaign. Right now, we have to go back all the way to start and find the new campaign we just made and then add a new deployment.

Proposed Solution

Direct user to deployment creation page after completing the creation of a new campaign

• Getting error when add to published campaign
• Lose access to logo form after upload -- error when validating campaign form once logo added
• Do we need to publish logo separately, then re-publish campaign?

Background/Problem

The current format of inputing the dates on forms in a blank fields leaves it unclear to the user in what format the date should be entered.

Example

• "start date" and "end date" on a campaign form (Ex. https://admgstaging.nasa-impact.net/drafts/edit/0439df58-c5e0-4cdc-91d6-44bb28a3c908)

Proposed Solution

Investigate if Django has a date-picker widget that could be used instead of a blank box. Apply the date-picker to all date fields on forms.

Imagine a scenario where a team member wants to add a new logo to a published Campaign. They would navigate to the the published Campaign, press “Create Edit Draft”...

click on “Add new Image”...

create a new Image draft, and then attempt to save their new draft of the Campaign...

However, this save fails because the draft does not pass validation...

We can see that the Published Edit Form runs validation on the models before creating a new Change model:

https://github.com/NASA-IMPACT/admg_webapp/blob/ee2d83f18197981a159a14d6c77bf6c6ef109609/admin_ui/published_views.py#L132-L149

However, I believe we should allow users to create Change records even if they don't pass validation. Instead, validation should only be applied when a user attempts to publish a Change record.

Description: "Hadn’t worked on AfriSAR. got to DOI tab, ran “generate”. got list.
The AfriSAR eg:  https://admg.nasa-impact.net/campaigns/dd804086-5fe2-494f-aac3-e63b5ff342ce/doi-approval

Screenshots, Example 2 SAFARI 2000
"already checked but not worked on yet"

TODO

• Verify that this is still an issue

• don’t allow changing of ‘Campaign’ in Deployment Form,
• don’t allow changing of ‘Campaign’, ‘Deployment’ in IOP & SE Form
• don’t allow changing of ‘Campaign & Deployment’ in C-D-P-I Form

Presently, when adding an alias through the APIs, it is necessary to give the integer primary key of the content_type. This is not a robust method, as the user should not be expected to know this integer, and it would be subject to change if the inventory was ever redeployed and ingested.

The preferred solution is that the user gives the string value of the short name of the linked model instead of the content_type. This functionality previously existed, but was disabled by an update to the maintenance interface. When addressing this issue, care should be taken to confirm that the MI is not impacted.

Currently, we customize our Change forms to support rendering FKs that reference other Change instances rather than published records:

https://github.com/NASA-IMPACT/admg_webapp/blob/ebfe3a2798ef9f1e220e683063a4f4f341a04d44/admin_ui/mixins.py#L16-L37

However, we don't offer this support for M2M fields (i.e. rendering Change instances rather than published records generating form options). This is problematic, particulalry when a user is working on a draft of a DOI:

https://github.com/NASA-IMPACT/admg_webapp/blob/ebfe3a2798ef9f1e220e683063a4f4f341a04d44/data_models/models.py#L1022-L1040

• #219
• Redesign how form items (e.g. aliases) are entered
• Get list of workflows to review for intuitiveness

In #124, we introduced logic that generates a selection widget of CollectionPeriod drafts. To render the string representation as we do with real CollectionPeriod instances, we must join the records to a number of models. Obtaining the campaign name is particularly challenging, because we need to join across an intermediary models (i.e. CollectionPeriod -> Deployment -> Campaign). We avoided doing this by joining on the campaign value that happened to be in the CollectionPeriod dafts' update property:

https://github.com/NASA-IMPACT/admg_webapp/blob/7546c1aba2a091b4562023fef78954b979c8fae2/admin_ui/fields.py#L104-L113

However, this is not dependable. As @CarsonDavis wrote:

I think the inclusion of campaign is just a fluke of how the ingest works. They record it on the sheets, so the ingest brings it in. But since it isn't a real field, when stuff is published it gets ignored. You won't be able to count on having this field with the items created inside the MI.

As such, we should update the logic to properly join through the Deployment model to obtain the campaign name.

Note: It should be said that this was not initially done due to the fact this was difficult and holding up #124. I believe it is achievable but this is not a beginner task.

Provide control to user for selecting number of records per page. Users have their own pattern to using the system and if we are providing the decision to them then it can bring more flexibility for them.

On a table of published items (e.g. https://admgstaging.nasa-impact.net/iops/published), the links fail to take a user to the forms.

• remove “Collection Period” phrase from the MI
• Auto-adjust sizing/spacing on DOI page
• view where user left off

Relevant code is in the file: entrypoint.sh

To make lookups of Change records performant, we should add indexes to the following properties of the update column on the Change table:

Common Lookups

• campaign
• deployment

Unsure of...

• short_name - Used for filtering Changes by their short name

I'll be using this ticket to keep notes on which indexes to add. At this time, it is not to be considered as comprehensive.

Describe the bug
Logo forms still will not publish even when appropriate forms are filled out. When logo form is saved, image appears above the "Choose File" box, but it still says "No file chosen".

To Reproduce
Steps to reproduce the behavior:

1. In the staging MI, add a new logo via form
2. Fill out required elements
3. Save the form
4. Choose "Publish to Production" and see error

Expected behavior
When all the required fields are present, the form should publish. In addition, when the form is saved. we would expect to see the image name by the "Choose File" box.

Screenshots

Logo form -- see "No file chosen" under image

Error that displays when trying to publish logo

Desktop (please complete the following information):

• OS: Windows
• Browser: Chrome
• Version: 97.0.4692.71 (Official Build) (64-bit)

Additional context
I am assigningAnthony to this issue, but please add anyone else who needs to be included.

Link to logo form in screenshots: https://admgstaging.nasa-impact.net/drafts/edit/333c3988-e993-448b-a62e-a6e90f755580

Include ‘Go to Page’ element in the pagination so users can directly enter or select a page number and go directly to that page for viewing records.

On many published tables (e.g.https://admgstaging.nasa-impact.net/iops/published), the name of the filters shows as [invalid name]:

Steps to replicate:

• go to campaign page
• click on the this button
  
• takes to a different form

Right now there is a button to add a logo, but nothing happens/no way to actually add an image to upload.

“validate” button saves a separate draft item if “save” has not been clicked first -- end up with duplicates

“C-D-P-I” would be more appropriate

Goal

Some of the redirects are not very intuitive. We would like to establish a clean and standard way of move between pages across the interface.

Details

Edit forms

Desired action & response: Save button should not redirect. Just keep the user on the same page. already complete
Desired action & response: Back button from any form should take you to the relevant table page (Ex. http://localhost:8000/organizations from a partner org form) EXCEPT for campaign items (campaign, deployment, se, iop, cdpi). These should take you back to the campaign details page Ex. http://localhost:8000/drafts/145c05dc-bb72-47af-933a-4b94f3169bb9

Notes

If anyone disagrees that this is the right flow I'd love to hear. @tania-pires in particular if you have opinions please jump in. If you want to revist the Miro board we could do that, if it is easier than a PR conversation.

don’t make curators enter platform types when they already will be having to add the platforms to the campaign anyways -- let this get set based on the platforms that been tied to the campaign

When selecting deployments/iops for iop/SE drafts--only display deployment/iop options for the current campaign in the dropdown box

Background/problem

The default django widget for a user to select multiple values out of a pre-defined list has a few problems:

• the user has to know to use the shift key
• it is hard to see which fields have been selected if the list has more than a few options

Example

• "geographical region" field on a deployment form (Ex. https://admgstaging.nasa-impact.net/drafts/edit/5006e605-e56f-48a0-9f8b-5ff6b012ce0c)
• "instruments" on a CDPI form (Ex. https://admgstaging.nasa-impact.net/drafts/edit/c8483231-e2ed-47ee-88fc-00dc1099dbd8)

Proposed solution

In the django admin you can use a widget like this: https://i.stack.imgur.com/mJL3H.png
It seems worth investigating if we could use this same widget for the many to many relationships in our forms.

Background and Goal

For each Campaign the inventory team would like to upload an image from their local computer to be used a the campaign logo for that campaign. This same feature is required for Platforms and Instruments.
Fields:

• Campaign form -> "Logo" field
• Platform form & Instrument form -> "Image" field

(These links should work when using the deployed version of the interface)

Currently these fields exist as dropdowns with no options.

Tech

The proposed solution is to develop a custom widget which supports the upload images and preview of images. There is likely a third-party plugin (or out of the box widget) to add this support.

We might have to coordinate with the backend team to make sure that the data model supports images/logos with the right type of field.

Is your feature request related to a problem? Please describe.
Info below will be helpful to ADMG Staff when entering Websites info in the CASEI MI.

Describe the solution you'd like
The "Website Type" should be viewable through/on the CASEI UI site (and note that "website type" could be considered a "short name").
The "Website Type Description" should be visible only to curators/ADMG Staff within the MI to clarify what URLs are appropriate for each type.

(1) Website Type: Repository
Long Name: Repository/DAAC Website
Website Type Description: URL for Campaign Landing Page at the Assigned DAAC (if such a page exists)

(2) Website Type: Publication
Long Name: Overview Publication
Website Type Description: Most Recent, Fully Descriptive Peer-Reviewed Publication on the Campaign

(3) Website Type: Project
Long Name: Project Website
Website Type Description: Website built by Campaign Science Team ahead of/during the campaign. These sites may remain active for a long time following the Campaign.

(4) Website Type: Field Catalog
Long Name: Campaign Field/Event Catalog
Website Type Description: Listing of details related to each day or IOP during the campaign. May include raw data or images from the field, brief mission/science reports/drafts, data access links, and/or significant event overviews.

(5) Website Type: Additional
Long Name: Additional Campaign Resource
Website Type Description: Any other URL or DOI landing page with pertinent info for this campaign (e.g.: additional publications, partner institution sites describing the campaign, etc).

Describe alternatives you've considered
n/a

Additional context
This is intended for the MI and UI to help with organizing/grouping website URLs that are entered by the ADMG Staff.

Context

This issue was repurposed to be part of EPIC: MI Workflow Redesign #270

Currently, the sidebar on drafts can be confusing to navigate and be somewhat messy. How can we improve this experience?

Current

https://admgstaging.nasa-impact.net/drafts/edit/a5ca9504-6f2c-4d65-8cf0-f0d5cfb6f31d

• Example of an unpublished draft where the side bar is on the right-side

https://admgstaging.nasa-impact.net/drafts/edit/092e31e7-1227-47f3-af14-6c80ed178d96

• Example of a published draft with the diff view where the side bar is at the bottom

New

https://www.figma.com/file/zY7BS9fR1huZ0CieHf3Dm8/MI-Workflow-Change?node-id=286%3A25633

https://www.figma.com/file/zY7BS9fR1huZ0CieHf3Dm8/MI-Workflow-Change?node-id=286%3A26852

• Collapse information into an accordion
• Only allow one accordion to open at a time (not like the mockup)
• For the Dependent Drafts, created 1 indented section for each of:
  • Deployments
  • IOPs
  • Significant Events
  • CDPIs
• Only the logo is not collapsed because it's a nice visual representation of the campaign, platform, or instrument

https://www.figma.com/file/zY7BS9fR1huZ0CieHf3Dm8/MI-Workflow-Change?node-id=286%3A25716

• For the diff view, we can keep the current behaviour where the sidebar stacks at the bottom

https://www.figma.com/file/zY7BS9fR1huZ0CieHf3Dm8/MI-Workflow-Change?node-id=286%3A26004

• For a published view, we can still show the logo and history

Description: "Hadn’t worked on AfriSAR. got to DOI tab, ran “generate”. got list. why are both + & trash buttons already colored in."
The AfriSAR eg:  https://admg.nasa-impact.net/campaigns/dd804086-5fe2-494f-aac3-e63b5ff342ce/doi-approval

Screenshots, Example 1 AfriSAR
"This is my view for AfriSAR immediately after go to DOI tab today (after had "generated" yesterday, go same views). I haven't done anything on these, but the check/trash bins are all already colored in"

@CarsonDavis reports:

Hey, I'm trying the deploy button on the Maintenance Interface, and I'm getting the following error

Failed to trigger deployment: {"message":"Bad credentials","documentation_url":"https://docs.github.com/rest"}

Problem

Website is very unclear and since even I'm not sure how it actually works, we've instructed staff to not do them. perhaps can be mildly better with training, but the intuitiveness needs to be improved

Process

Review process for adding websites

• map userflow
• list any bugs or UI blockers
• updated this ticket with analysis
• identify key problems and propose solutions