Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Feature/3573 autocheck article uploaded #2377

Open
wants to merge 23 commits into
base: develop
Choose a base branch
from

Conversation

philipkcl
Copy link
Contributor

@philipkcl philipkcl commented Apr 15, 2024

[3573] A check in the journal record to say whether or not articles have been uploaded

Please don't delete any sections when completing this PR template; instead enter N/A for checkboxes or sections which are not applicable, unless otherwise stated below

See #

Describe the scope/purpose of the PR here in as much detail as you like

Categorisation

This PR...

  • has scripts to run
  • has migrations to run
  • adds new infrastructure
  • changes the CI pipeline
  • affects the public site
  • affects the editorial area
  • affects the publisher area
  • affects the monitoring

Basic PR Checklist

Instructions for developers:

  • For each checklist item, if it is N/A to your PR check the N/A box
  • For each item that you have done and confirmed for yourself, check Developer box (including if you have checked the N/A box)

Instructions for reviewers:

  • For each checklist item that has been confirmed by the Developer, check the Reviewer box if you agree
  • For multiple reviewers, feel free to add your own checkbox with your github username next to it if that helps with review tracking

Code Style

  • No deprecated methods are used

    • N/A
    • Developer
    • Reviewer
  • No magic strings/numbers - all strings are in constants or messages files

    • N/A
    • Developer
    • Reviewer
  • ES queries are wrapped in a Query object rather than inlined in the code

    • N/A
    • Developer
    • Reviewer
  • Where possible our common library functions have been used (e.g. dates manipulated via dates)

    • N/A
    • Developer
    • Reviewer
  • Cleaned up commented out code, etc

    • N/A
    • Developer
    • Reviewer
  • Urls are constructed with url_for not hard-coded

    • N/A
    • Developer
    • Reviewer

Testing

  • Unit tests have been added/modified

    • N/A
    • Developer
    • Reviewer
  • Functional tests have been added/modified

    • N/A
    • Developer
    • Reviewer
  • Code has been run manually in development, and functional tests followed locally

    • N/A
    • Developer
    • Reviewer
  • Have CSS/style changes been implemented? If they are of a global scope (e.g. on base HTML elements) have the downstream impacts of the change in other areas of the system been considered?

    • N/A
    • Developer
    • Reviewer

Documentation

Release Readiness

Testing

List the Functional Tests that must be run to confirm this feature

  1. ...
  2. ...

Deployment

What deployment considerations are there? (delete any sections you don't need)

Configuration changes

What configuration changes are included in this PR, and do we need to set specific values for production

Scripts

What scripts need to be run from the PR (e.g. if this is a report generating feature), and when (once, regularly, etc).

Migrations

What migrations need to be run to deploy this

Monitoring

What additional monitoring is required of the application as a result of this feature

New Infrastructure

What new infrastructure does this PR require (e.g. new services that need to run on the back-end).

Continuous Integration

What CI changes are required for this

@amdomanska
Copy link
Contributor

The test should say "The journal may have fulfilled all the criteria for the Seal" (rather than has). We also need that text, together with the article info inside the ".doaj_seal__container form__question" div for stylistic reasons. You may need to change this in "editorial_form_fields.html"

Actually - wouldn't that be easier to just add this information to the existing paragraph and pass the required information to the template rather than creating the whole new widget and calling an ajax request?

<p>The journal may have fulfilled all the criteria for the Seal. </p>

fetch(`/admin/journal/${journalId}/article-info`)
.then(response => response.json())
.then(data => {
const $p = $(sealSelector).prev('p');
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This paragraph should be added INSIDE the sealSelector div, not before it.

@philipkcl
Copy link
Contributor Author

philipkcl commented Apr 19, 2024

The test should say "The journal may have fulfilled all the criteria for the Seal" (rather than has). We also need that text, together with the article info inside the ".doaj_seal__container form__question" div for stylistic reasons. You may need to change this in "editorial_form_fields.html"

Actually - wouldn't that be easier to just add this information to the existing paragraph and pass the required information to the template rather than creating the whole new widget and calling an ajax request?

<p>The journal may have fulfilled all the criteria for the Seal. </p>

@amdomanska,
In original and Dom's new requirement, the message are outside of .doaj_seal__container form__question.

If we still want to make that title inside .doaj_seal__container form__question, could you advise how to update the programme to achieve that by just update editorial_form_fields.html ?

you might need to discuss with @richard-jones about ajax request.

@amdomanska
Copy link
Contributor

In original and Dom's new requirement, the message are outside of .doaj_seal__container form__question.

Absolutely, I'm aware of that. It appears to be an oversight that needs correction as we proceed with this task. It seems that the best approach, upon further consideration, would be to integrate it as a for the respective question. This way, it would naturally reside within the div, aligning seamlessly with the existing structure.

Feel free to proceed with updating the implementation in the "application_forms.py" file accordingly.

image

Regarding the approach to handle Ajax calls, I think there might be an alternative method worth considering. Instead of making additional calls, we could potentially streamline the process by utilizing the data already available from the backend through wtforms. For instance, in the template, you have access to "obj.data["admin"]" which could be passed directly to the form. Moreover, you might explore leveraging Python functions in "application_forms.py" to facilitate this integration.

Unfortunately, I'm currently focused on other tasks and can't provide a detailed walkthrough at the moment. However, if you encounter difficulties, feel free to assign the task to me, and I'll be more than happy to assist when I have the bandwidth.

@richard-jones thoughts?

Copy link
Contributor

@richard-jones richard-jones left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

A couple of minor, non blocking, style comments. Just requires addressing @amdomanska 's comments.

@@ -1881,7 +1884,7 @@ class FieldDefinitions:
"entry_template": "application_form/_entry_group.html",
"widgets": [
{"infinite_repeat" : {"enable_on_repeat" : ["textarea"]}},
"note_modal"
"note_modal",
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

extraneous comma added

@@ -83,7 +83,11 @@ def create_publisher_a():
return publisher


def create_maned_a():
def create_maned_a(is_save=False):
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

probably just call this arg save

],
"widgets": [
"article_info",
],
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Probably worth adding a comment here that the article_info back-end is only accessible to admins. The DOAJ_SEAL also only appears in the admin form context, so that's all good, but I suppose we could change that at some point and not notice.

@philipkcl philipkcl requested a review from amdomanska July 8, 2024 13:12
Copy link
Contributor

@amdomanska amdomanska left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

You committed some changes to edges submodule, is that intentional? If not, that should be remove from the PR. Other than that looks good.

@philipkcl
Copy link
Contributor Author

@amdomanska , there have no change in edges submodule, the change showed in PR seem like it comparing to old commit 990f4220163a3e18880f0bdc3ad5c80d234d22dd, I don't why it comparing that commit, may be just develop branch is pointing on it

@amdomanska
Copy link
Contributor

@philipkcl To fix it you would have to merge develop up and update the submodule to make sure that no unintentional edges changes are committed (there should be no difference in edges between develop and your branch if you don't change it).

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

4 participants