Hello,

I have been trying to play around with the sort options in v1.0.3. Currently there are two options supported in search.jsx
export const sortOptions = [ { field: 'modified', order: 'desc', label: 'Upload date' }, { field: 'title', order: 'asc', label: 'Alphabetical' } ];

If I change one of the two, nothing particularly happens. Even if I change the sort order, the results are still retrieved in the same order. I was wondering whether it is documented somewhere how I would be able to change/extend these options.

A follow-up question is, which field from the JSON schema does "modified" correspond to?

User Story

When I go to the publisher page, I want to see how many datasets are available from each publisher, so that I know how much information I can expect to find from them.

Background

This is currently available on DKAN1, and we found in user testing that users accustomed to DKAN1 miss this feature.

Acceptance Criteria

• When I go to the publisher page

• Then I see the number of datasets for each publisher on that page

• Working downstream on Marine Scotland /groups

• Working upstream (8.x branch) on /publishers

• Working upstream to 2.0

Estimate: 8

PR

GetDKAN/data-catalog-components#140

Describe the bug
As has been done with colors, we should ensure that we have Typography variables working at a general level with USWDS. Font sizes, and font families at a minimum.

@dgading
Do you have any preferences in terms of how we handle font sizing? I saw some code in the general.scss file for this. I can just reuse that if we are happy with how that has been working.

Related links
https://designsystem.digital.gov/design-tokens/typesetting/overview/

QA
Expect to see some USWDS defaults:

• the styles should have some declarative variables set, even if they are just reflecting defaults. I have added those to variables.scss.
• Differences in sizes between H1 and H3 fonts. H1 being the largest.
• Differences in font family between the body font and header fonts. Sans-serif vs serif respectively.
• Body links underlined by default.
• Also, one of the component styles coming through, as the import line is commented out.

In the 2.0.0 branch, all of the current style imports have been removed. The new site's grid system should be built using the USWDS layout classes. The pages will still be mostly unstyled but as we replace components in the component library they will appear correctly on each page.
https://designsystem.digital.gov/utilities/layout-grid/

Acceptance Criteria
The following pages of the site are using the USDWS grid system with mobile and desktop layouts:

• Home
• Search
• Publishers
• About
• API
• Dataset Page

We should see how testing goes with Jest for pages, it is much lighter than Cypress and should be just as useful. Search and Dataset pages should be their own tickets as they will be very involved.

• Add Jest Axe to the build.
• Write basic tests for Home Page
• Write tests for About
• Write tests for Publishers

Add cypress tests to the build

Describe the bug
Search works on the main page when clicking e.g. the "City Planning" topic which results in https://opendata.domain.local/search/?theme=City%20Planning But it doesn't work when:

To Reproduce
Steps to reproduce the behavior:

1. Go to 'the main site'
2. Click on 'City Planning'
3. In the search results click again on any "City Planning" category
4. See error "Page not found." because of the wrong URL being accessed: https://opendata.domain.local/search/search?theme=City%20Planning

Same is true when accessing an actual dataset and then clicking on the category which will lead to e.g. https://opendata.domain.local/dataset/934400f2-a5dc-4abf-bf16-3f17335888d3/search?theme=City%20Planning

Expected behavior
Still search via https://opendata.domain.local/search/?theme=City%20Planning

Details:

• OS: Linux
• Browser: Chrome
• Version: Git master

I want to be able to manage my site's menu using Drupal's menu system and not a hardcoded json file

Using something like this module, we should be able to pull in the menu and feed it to the menu component. https://www.drupal.org/project/jsonapi_menu_items

Copy existing functionality from Publishers page on Gatsby build

The search input doesn't have a reset button

When clicking on the dataset file resource (distribution) link, no download happens in Chrome and an error about Mixed content is generated, if DKAN2 accessed via HTTPS (e.g: https://demo.getdkan.org). There is also a warning being generated on click: "Resource interpreted as Document but transferred with MIME type text/csv"

To Reproduce
Steps to reproduce the behavior:

1. Go to dataset detail page (e.g.: https://demo.getdkan.org/dataset/1f2042ad-c513-4fcf-a933-cae6c6fd35e6)
2. Click on the resource file link (e.g.: U.S. Adult Smoking Rate)
3. In Chrome no action will happen and the download will not be triggered.
4. You should see an error about Mixed Content in Development Tools console
5. You should also see a warning: "Resource interpreted as Document but transferred with MIME type text/csv"

Expected behavior
A file download popup appears with no errors / warnings being generated in console.

Screenshots

Details:

• Browser: Chrome

Background

Currently, the search results page shows dataset results with the resources in them by format. These resources are represented by icons showing the format. Currently, the number of icons represents the number for resources, for example, when there are three CSVs in the dataset, there are three CSV icons. This is visually confusing, redundant, and cluttered. We'd like instead for it look more like the DKAN1 implementation, where there is a single icon, and if more than one resource of a type exists, then we see the number with an x before the icon. for example: 3x(CSV icon)

Acceptance Criteria

• When I search for datasets

• And I see the search results page

• And there is a dataset with multiple resources of the same format

• Then I see that represented as (number)x(format icon)

• Working downstream on Marine Scotland

• Working upstream (1.9.x branch) : https://demo.getdkan.org/search/

##Estimate: 3

Build a basic out of the box create-react-app

GetDKAN/data-catalog-frontend#50

User Story
As a data provider I want to offer a data catalog in other languages when necessary.

Acceptance Criteria
I can translate all strings in the front end application.

Currently the frontend application for DKAN is split into the App and Component repos. If a new site is built using the system it will work with all the upstream repos only if no custom work is done on the site. The problems with current setup begin to appear when custom work is preformed on the site.

Current Build

The app comes with a dataset, search, home, about, and publisher page out of the box. If any of these pages are customized downstream and an upstream change is also made, they will now be out of sync and you can't easily pull in the upstream changes. We have gotten around this some by moving more of the pieces into the component library, so you can just pull in the pieces and put together your pages. This idea has worked well, but as more and more components are added the component library is growing bigger with templates and render components some client sites will never use. This extra bloat while fine now will add up as DKAN grows.

Restructured Build

data-catalog-app

Out of the box this will give a site that should work for most clients, but has very little logic or reusable elements. Once added to a site, there shouldn't be a need to ever pull from the upstream again. Since most builds include a frontend in the src/frontend folder of the DKAN site, this will be an easy place to do all custom work. Things like adding routes, styles, and new one off features.

data-catalog-components

This library should be universal reusable components. Things like React hooks and complicated functions for fetching data or storing state live here. What doesn't live in the library anymore are things like announcements or search list items. These are very subjective to the individual site's design. This library should be lean and very rarely dictate how something should be rendered.

data-catalog-template

This library should contain our rendered components. Things like search list items, tables, search facets and other useful reusable rendered DOM elements. Here we can work on best practices with UX or design to build the best catalog experience.

How does all this solve the current issue?

A default build of DKAN would load the data-catalog-app which has some basic routing in it. Those routes would load a template from data-catalog-templates. The DKAN team would mainly work in data-catalog-templates when fixing bugs at a theming level. Then DKAN sites would be able to test the changes and get the updates by increasing the version in their package.json. The templates would use the data-catalog-components for hooks and complex parts, but if a custom site wanted to do a completely custom design they could still use data-catalog-components to get the functionality but skip any of the additional render components.

What would an upgrade path for this look like?

To make sure we stay as backwards compatible, this isn't going to be a quick change. It's something that should be able to be adopted overtime and give plenty of lead time to make updates to current sites.

data-catalog-app v2.0.0 would no longer have the templates in the code base, they would all live in data-catalog-templates. It will just be an React app with an App.jsx file with routing and some styling.
data-catalog-components v2.0.0 would have all of it's render components moved to data-catalog-templates. It will be mostly React hooks/context components and fetch api classes.
data-catalog-templates v1.0.0 would be a full featured template library that should be able to build most out of the box DKAN sites. As a specific site developer, you should be able to just import a page, component, or section of a site with ease.

As components are moved to the templates library they would be marked for deletion using a console.error in the component letting developers know they should add the new data-catalog-templates library and update their import statements. Only when the 2.0.0 branch of components is released will things be deleted from data-catalog-components.

For the data-catalog-app, it would be a more gradual update that is only moved to v2.0.0 when it is feature complete using the new template library. Since this is built fresh on most new installs the switch to the template library shouldn't be an issue. And for sites that are currently live and have custom code, they wouldn't be pulling the data-catalog-app repo downstream anyways since it would most likely overwrite or break their custom code.

Describe the bug
After replacing data-catalog-frontend with data-catalog-app I'm no longer able to access content via links, it always results in an error 404, e.g. trying to access https://opendata.domain.local/dataset/74c06c81-9fe0-439c-aba9-cd5c980a6df4 results in an entry in the Apache access.log:
[28/Aug/2020:09:32:10 +0200] "GET /dataset/74c06c81-9fe0-439c-aba9-cd5c980a6df4 HTTP/2.0" 404 268
contrary to first browsing to the main page https://opendata.domain.local and then clicking on the dataset, which works just fine, but then I also have no entry in the Apache access.log at all, so something must work different.

To Reproduce
Steps to reproduce the behavior:

1. Go directly to e.g. a dataset in a new browser tab / incognito tab 'https://opendata.domain.local/dataset/74c06c81-9fe0-439c-aba9-cd5c980a6df4'
2. See 'error 404'

Expected behavior
Being able to access content also via direct links instead of always having to browse to them manually by starting at the root page first.

Details:

• OS: Linux
• Browser: Chrome
• Version: git master

Add reach/router and data-catalog-components to the app.

Copy existing functionality from existing Gatsby build

Describe the bug
USWDS color variables should be updated to include those from the 1.7.0 site.

General USWDS color variables

We map "legacy colors" using the USWDS color tool to USWDS colors settings variables. Here is a selection of some colors that could be considered "global". Later on we will want to make all colors available as USWDS variables.

Colors that can be used for general elements such as body background, links, and headers.

$theme-color-base-lightest:  "gray-1";
$theme-color-base-lighter:   "gray-2";
$theme-color-primary:        "blue-50";
$theme-color-base-darker:    "gray-70";

When visiting the dataset page, a 0 shows instead of a loading spinner or nothing.

Describe the bug
When visiting a route that doesn't exist, an unstyled 404 page appears.

To Reproduce

1. Visit any page not in the routes file.

Expected behavior
The Page not found has the Layout component wrapping it so it looks like a page not a server response.

Background

On DKAN1, users were accustomed to going to a dataset page and seeing an edit button they could use make changes. Currently, to edit a dataset, users need to go to a manage content page in order to find and edit link to datasets. In user tests testing, this was found to be confusing for users who were accustomed to DKAN1.

User story

As a data publisher, when I am looking at a dataset page, I would like to be able to choose to edit it from that page, so that I don't need to leave the page to make changes.

Notes

If a user is logged in and has an active session, it would be a big UX improvement to see an edit link of some kind on a dataset.

To investigate: Is there an existing drop-in solution for decoupled Drupal sites to check for an authenticated user and provide contextual links?

Possible starting places:

• https://www.drupal.org/project/decoupled_kit
• https://www.drupal.org/project/decoupled_menus
• Ask front-end practice area

It may be that just turning on jsonAPI will give us all the endpoints we need and this is a question of writing a small request function and component on the dataset page.

Acceptance criteria

• New ticket describing preferred approach and implementation plan

Estimate: 5

On DKAN1, users were accustomed to going to a dataset page and seeing an edit button they could use make changes. Currently, to edit a dataset, users need to go to a manage content page in order to find and edit link to datasets. In user tests testing, this was found to be confusing for users who were accustomed to DKAN1.

• User story*
  As a data publisher, when I am looking at a dataset page, I would like to be able to choose to edit it from that page, so that I don't need to leave the page to make changes.

Acceptance criteria

• Tests and code for 1.x and 2.x to render an edit link conditionally on the datasets page.

Estimate
8 story points.

• References *
  This work builds on this spike ticket: #65

When I go to a search page with parameters, the parameters disappear.

When on dataset detail page you click on Organisation icon/logo or Organisation title, the link is incorrect and leads tot 'Page not found'.

Steps to reproduce the behavior:

1. Go to dataset detail page (e.g.: https://demo.getdkan.org/dataset/1f2042ad-c513-4fcf-a933-cae6c6fd35e6)
2. Click on the Organisation icon or on the dataset title 'National Health Council' (top left conner)
3. 404 / Page not found will be shown

Expected behavior
The organisation link generated is:
https://demo.getdkan.org/dataset/1f2042ad-c513-4fcf-a933-cae6c6fd35e6/search?publisher__name=National%20Health%20Council
While it should be:
https://demo.getdkan.org/search?publisher__name=National%20Health%20Council

Screenshots

Copy About page over from existing Gatsby build

Separate page for resources/distributions, with filters to be defined in URL or GUI. Details to come....

Copy existing homepage functionality from dkan-catalog-gatsby

Add the individual dataset api page at dataset/{id}/api. The page should like the one at https://demo.getdkan.com/dataset/74c06c81-9fe0-439c-aba9-cd5c980a6df4/api

Copy existing search functionality from existing Gatsby build

• No Title in browser tab
• Wrong Favicon
• Missing Checkboxs on facets
• wrong fonts loading
• missing icon on toggle facets blocks
• display density buttons not styled properly
• manage column button missing border
• fix circleci integration
• pull in GetDKAN/data-catalog-frontend#54
• pull in GetDKAN/data-catalog-frontend#49

Merge Plan:

• merge data-catalog-components GetDKAN/data-catalog-components#89
• publish new release of data-catalog-components
• merge dkan-tools updates GetDKAN/dkan-tools#229
• publish new release of dkan-tools
• update package.json on this repo to use new components release
• update .circleci/config.yml on this repo to use new dkan-tools tag
• publish new release of data-catalog-react (rename repo?)
• merge dkan PR (frontend module config) GetDKAN/dkan#3173

1. Hook into Drupal core use of the color module: https://medium.codekoalas.com/integrating-the-color-module-into-your-drupal-8-theme-5e9b32db690d
2. Generate a stylesheet from that config if it exists, otherwise use the default color scheme.

This is a recreated issue from GetDKAN/data-catalog-frontend#43

When starting the test function for the frontend it returns an error saying:

./src/templates/dataset/index.jsx
  Line 35:6:  React Hook useEffect has a missing dependency: 'item'. Either include it or remove the dependency array  react-hooks/exhaustive-deps

The error could be solved by extending the code in ./src/templates/dataset/index.jsx with }, [id, state, item]);.

So the function looks as follows:

  useEffect(() => {
    if (window !== undefined) {
      checkForWindow(true);
    }
    async function getItem() {
      const { data } = await axios.get(`${process.env.REACT_APP_ROOT_URL}/metastore/schemas/dataset/items/${id}?show-reference-ids`);
      setItem(data);
      console.log("item: ", item);
    }
    if (!state || !state.dataset) {
      getItem();
    }
  }, [id, state, item]);

This may fix the error message but still the page will not be created.

Right now everything is hard coded in the axios calls. Pull the root urls out and place in .env files for development and production.

Describe the bug
The app should redirect users from /home to /.
Any page that doesn't match a specified route should render the NotFound template.

To Reproduce
Steps to reproduce the behavior:
GetDKAN/dkan#4121

Expected behavior
When /home is put in the browser, the app will redirect to /

Additional context
This will match what we expect from the Drupal setup.