jiscsd / octopus Goto Github PK

Some users have reported they are being taken to our Not Found page on login attempt.

Currently unable to replicate this issues on live & local with a range of different orcid accounts setups, i.e range of employment options, education & works (Manual & DIO provided). This is the same setup as one reported user account.

AWS has not logged any issues as far as I can tell.

Playing around with running eslint checks on the api for investigation to be apart of a GH action, I found an error with the eslint config. The overrides section needs to specify the files key. Below is what this should be updated to:

"overrides": [
        {
            "files": [
                "src/*.ts",
                "src/*.js"
            ],
            "rules": {
                "require-jsdoc": "off",
                "func-names": "off"
            }
        }
    ]

Additiomally, a new npm script could be added of npm run lint, which in more detail would look like:

"lint": "npx eslint npx eslint ./src"

This fixes the eslint config & provides some useful output that could be looked into.

File upload feature for images not currently working. Able to go through the process, the the preview image appears, but after clicking Upload Image nothing appears in the main text editor.

It also does not work when importing a Word document with an embedded image file.

Have tried with .jpeg and .jfif

URL source import does seem to work as expected.

The message passed back from the API is not what is provided by the API.

Example: api

return response.json(404, {message: "Publication not found" });

What is actually given

{message: '404 Not Found'}

Alert component spacing missing between icon & message title.

There are a few cases scattered throughout that use optional props in components, e.g

type Props {
something?: string
}

const comp<Props> = (props) => (
<div className={something}></div>
);

As this is optional, the cases where it is not provided, the literal string of undefined will be printed, based on this, a PR needs to be raised to scoop through the codebase and refactor optional string props for a safe check, e.g

type Props {
something?: string
}

const comp<Props> = (props) => (
<div className={something?.length && something}></div>
);

Not, not simple something && something as this && can lead to unexpected output.

or better:

type Props {
something?: string
}

const comp<Props> = (props) => (
<div className={something ? something : ''}></div>
);

This is best case for a optional string prop.

File: ui/pages/publications/[id]/index.tsx

Update:

FROM:

TO:

This page does not revalidate upon mutation. It seems a temp fix for this was introduced in the bookmark feature to pre load state with prop data from SSR. This causes issues with client side routing. Local state needs removing & the pre fetched data from SSR needs to be passed to useSWR as the initial state / fallback then inform SWR when mutation occur to have a fully reactive page.

We need to investigate why warmup: true isn't working in the serverless.yml file. We think serverless handles this and it's something we'll need to take a look at in the future

Does the API track the resolution date?

If so, then having that present on the get flag route is needed.

Public route /documentation is currently way behind the state of the API.

Steps to reproduce:

• Create a new publication
• Ensure all fields are completed to a point where the publication is publishable
• Ensure you select 'No' for the COI option
• Save as a draft & navigate away from the the editing screen
• Return to the draft publication

At this point the COI option has not been saved.

I imagine it is either due to the COI option from the publication store is not being sent along with the payload when saving or the api is having issues accepting the payload option for the COI.

When a user is viewing a publication and has the profile dropdown menu active, the linked publications visualisation section overlaps the menu, making the 'my bookmarks' options within the menu un-readable and un-clickable.

This is a small bug that should be resolved by changing the z-index on the dropdown menu.

As discussed in the stand up this morning, the API should be changed to send back the user's full name and we will handle it on the UI to show the Initial in the search results pages etc.
Currently, the API sends back the initial and full last name.

Lighthouse cannot access private pages due to being behind a login.

Lighthouse can only see the site in darkmode as it's the initial theme.

Component testing needs setting up along side LH.

Currently there is no way to delete a drafted publication. If a user creates a draft and then later decide they no longer want to proceed there should be a way for them to delete it.

Additionally when a drafted publication is deleted, all links currently created by that draft should also be deleted.

Currently no GH action to run API tests.

The site design is not suiting smaller laptop/tablet sizes. This issue was noted on a MacBook (Retina, 12-inch).

Specific issues:

• Column width on publication page is adapting for mobile as standard, (so nav bar appears at top etc) not ideal UX. Can we make the break point more generous?

• The search magnifying glass icon on the Search page covers the text

• Relevance (DESC only)
• PublishedDate (Newest Publications) DESC
• PublishedDate (Oldest Publications) ASC

Current publication process pages are populated with placeholder text.

General notes
No footer visible during publication process
Save - add text making it clear that the user has to manually save before leaving. Later we ideally we want a save as well as a save and exit option.
At the moment I can't save and exit until I've submitted conflict of interest reason, even if I haven't looked at this page yet.

Page 1
Add publication types to drop down (like that used for license information).
Remove icons.
Add note: Please note that the publication type cannot be changed after this stage.

Right hand side:
Publication title
Titles should be concise, specific, and informative – this will help relevant readers find your material.

Publication types:
Octopus has 8 publication types which align with the scientific process.

Page 2
What is the title of this publication? change to > Publication title

Typos in publication type explanation. Amend to:
You have selected the publication type xxx.
Please note that this cannot be changed. If you wish to change publication type, you must delete this publication and create a new one.

Page 3 - links
Ignoring for now! Needs reworking.
For future: Problem can’t be linked from peer review.

Page 4 – license, COI
License
Shift dropdown to always open
Add 4.0 to the end of each option.
Add link to this page: https://creativecommons.org/licenses/

Conflict of interest
This needs to be an active statement that the publication 'does NOT have a conflict of interest'

If preference is not to show text box unless required, have options:
Does this publication have any conflicts of interest?
[] This publication does not have any conflicts of interest
[] There are conflicting interests to declare (opens text box)

Page 5 – review
Update copy:
Coming soon...
This will be a page to review all content before publishing.
It is not possible to make any changes post-publication.

On the getAll users API it's consistently returning number of users as 2, when it should be returning the numbers of all of the users in the database

Currently, isHTMLSafe is pretty dumb. It just checks the content for classes and in-line styles.

export const isHTMLSafe = (content: string) => {
    const $ = cheerio.load(content);
    let error = false;

    $('*').map((_, element) => {
        const classes = $(element).attr('class');
        const style = $(element).attr('style');

        if (classes || style) {
            error = true;
            return false;
        }
    });

    return !error;
};

We may want to imrpove this to check for accessibility, a few ideas being:

• Images need alt text. By itself it doesn't necessairly make it accessible (as the text may be useful), but is likely to help.
• Is the HTML "semantically" correct?
• Are there useless aria-labels?
• Are there ids that could be conflicting with other stuff on the page?

Setting user to null here has some odd effects. The original issue was found higher up.

![Screenshot 2022-05-20 at 10 28 15](https://user-images.githubusercontent.com/81176162/169499063-1d1d54dd-b6bb-46e7-
81f6-09ea43ec5b8d.png)

Change:

FROM:

TO:

Currently in the _document.tsx, we are importing the Montserrat font from Google fonts like:

<link rel="preconnect" href="https://fonts.googleapis.com">
<link rel="preconnect" href="https://fonts.gstatic.com">
<link rel="stylesheet" data-href="https://fonts.googleapis.com/css2?family=Montserrat:ital,wght@0,100;0,200;0,300;0,400;0,500;0,600;0,700;0,800;0,900;1,100;1,200;1,300;1,400;1,500;1,600;1,700;1,800;1,900&amp;display=swap">

This needs to be updated to

<link rel="preconnect" href="https://fonts.googleapis.com">
<link rel="preconnect" href="https://fonts.gstatic.com" crossorigin>
<link href="https://fonts.googleapis.com/css2?family=Montserrat:ital,wght@0,100;0,200;0,300;0,400;0,500;0,600;0,700;0,800;0,900;1,100;1,200;1,300;1,400;1,500;1,600;1,700;1,800;1,900&display=swap" rel="stylesheet">

Notice the small difference in the preconnect options & the rel tag on the link element.

When doing the interface for the Orcid user, it was difficult to find the documentation/schema, api/src/components/authorization/controller.

Finally, I've found something that isn't xml, the Swagger documentation.

However, this is actually out of date and does not work.

The Orcid team suggested looking at: https://github.com/Royal-Society-of-New-Zealand/NZ-ORCID-Hub/tree/master/orcid_api/docs

See, the Orcid issue I raised, JSON Schemas for /record 3.0.

When I looked at the xsd examples, the translation from this to JSON isn't clear, the way dateTime works is different between the two as far as i can see.

It's also potentially different if you're read-public or read-limited, and again probably different from what's returned when updating Orcid profiles.

The styling of the error component styling is inconsistent with the rest of the Octopus site. Need to change the:

• font
• spacing
• icon
• placeholder text

Drafts should only be accessible able to the user who has created them, but when they're linked to another publication, they show as available for everyone to view. Only live publications should show on the UI for linked publications.

The endpoint affected by this is GET/publications.

When requesting a publication from the api, it returns an array of linkedTo publications & linkedFrom, however the shape of the objects in those arrays don't align with the Publication interface.

When requesting a publication:

Inside those two arrays:

I raised a similar issue regarding the shape of a publication in the get user endpoint here: #36

I spoke with @nathan-at-jisc briefly about the above issue & because the amount of data returned if quite large, it could be a problem. The option of a verbose param was mentioned, though that feature needs to be implemented as it will be a blocker as the data isn't available to display.

After a conversation with @nathan-at-jisc about using the updatedAt field of a publication to derive the date a publication was published, we found that there would be some issues here.

Based on that, we discussed a new field on a publication of 'publishDate'. This is a one time set value that is recorded when a publication moves from status draft -> publish(ed).

If a publication is in hidden state, moving it back to published does not reset this value as the publications publish date has not changed, just its status.

Our seed data currently doesn't include a publishedDate, so published publications currently have null published dates

API documentation is needed for Octopus, we're likely want this as html and not just markdown.

Will investigate good ways to host and document the api documentation, hopefully so that it "blends in"/"feels like" the rest of the site.

As a team convention, we have chosen to either use npm packages if they provide a default export, or:

import * as SomePackageName from 'some-package'

This may have performance effects during development, but not after piped through Webpack.
The idea here is that it gives all developers on the project an understanding where methods/functions are coming from when in use in large files.

When a user bookmarks a publication, and then navigates through the linked publications using the linked visualisation the bookmark icon remains filled in, and users are unable to interact with the feature for other publications. This is only an issue when you are navigating through publications using the visualisation. If you were to access the same publication via the search pages or to manually refresh the page, the bookmark refreshes and shows the right state depending on the data.

I think this is an issue with how the publication is being loaded into the page, as it seems that the data isn't being checked before the bookmark renders on the screen, the data is just pulled through from the previous publication. But further investigation is needed.

Not sure whether this is something coming later, but at the moment, first names and not just initials are visible on publication pages

JWT token needs to be regenerated after user verifies their email.
Currently the JWT does not include the email on initial log in.

We need to ensure that when this project becomes open source, any pull requests from contributors require a review from the codeowners.

This will require a codeowners file which will be added.
However we would also need to test this out once the project is opensource in order to know that this is functioning correctly.

Whilst working on PR #45, I found a situation where I needed to pass an object that was returned from publicationService.get(SOME_ID), to another function.

As I was passing what would be seen as a Publication to this new function, I needed to add the type of Publication to ensure properties on the object were valid, however because the get service function returns a publication with included fields, the inferred type returned from that function is different from what is an actual Publication to prisma.

Because of that, I added a new type that extends the prisma Publication type to 'include' the extra fields, however the shape of that is also different.

The current solution i have gone with, which is the least destructive is to add an @ts-ignore my new function that tries to find the linkedTo property on a publication, but I think this is covering up what looks like a type / interface mismatch somewhere.

If clarification / demo is needed, I can do that.

There is a <meta name="viewport" content="width=device-width, initial-scale=1" /> tag in the _document.tsx.
This need to be moved to the _app.tsx and use the next/head component as the document head component is different from the regular next/head.

SSR Console warning:
Warning: viewport meta tags should not be used in _document.js's <Head>. https://nextjs.org/docs/messages/no-document-viewport-meta

Please see: https://nextjs.org/docs/messages/no-document-viewport-meta

The search palette preview goes off the bottom of the page with several results on standard laptop size.

Our infrastructure code (Terraform) is setup using TF workspaces, this works really well to reuse the infra code & pass in different variables depending on the environment (int/prod). However as our aim to use use feature branches / spin up a new environment per PR, this workspace/variable way doesn't seem to be the best fit.

We can continue with the current method for now, but ideas suggestions would be appreciated to get this setup.

Publication page not currently allowing co-authors to be added.

Email can be inputted, and plus icon loads when clicked, but nothing appears in co-author list and no email is received.

Currently unable to further test the co-author flow until this is resolved.

As we are using NextJS, we have our npm script to run our application in dev mode with npm run dev.
This is good, but as we require a proxy of ssl, we have a secondary script to run the proxy, i.e npm run dev:ssl.

Both need to be running to visit the site at https://localhost:3001.

The problem being that running both scripts can be tedious, so the ideal solution would to run just one command, i.e npm run dev.

There is a problem with this, as we could just combine them with &, not &&. This will run them in parallel, however is one failed, the other does and using ctrl+c to exit doesn't work etc etc.

To tackle this, using a dev dep such as https://www.npmjs.com/package/concurrently. (See link for more info).

This will allow us to set up one single command that runs them concurrently, not in parallel.

We need to create an API that retrieves all of a user's drafts as an extension of GET/publications.

On individual publication pages, in the linked publications section, the spacing of title text can overlap when the title runs to multiple lines.

The issue only seems to apply where a publication title runs to multiple lines: https://int.octopus.ac/publications/publication-user-4-data-1-live.

This is not an issue for publications which have multiple linked publications: https://int.octopus.ac/publications/publication-user-2-data-1-live

Platform should allow keyboard shortcut for opening quick search. This should be Cmd+K (Apple) or Ctrl+K (Windows), with the guidance text also changing on the homepage.

At the moment the keyboard shortcut for Windows devices is not working, and the guidance text shows the wrong shortcut (cmd+K instead of ctrl+k).

When requesting a user from the api on .../v1/users/[id].

The response has the shape of:

This is fine, however the field of Publication[], which is an array of Publications published by this user, the shape of each publication in the array only includes fields ID, Title & Type.

It would be ideal of this array of publications returned as the same shape / interface as a publication record. This was ts interfaces can be reused to ensure matching & expect fields are available.

Single publication shape:

Here are my two interfaces for 'Publication' & 'User'.

A publication includes its user, this follows the User interface.
Where as the user interface includes a Publication array.

Although we may not always need, for the UI all this information (most of it though), from the api's perspective, it would make sense to include this/keep them consistent?