-
Notifications
You must be signed in to change notification settings - Fork 16
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
base: develop
Are you sure you want to change the base?
Conversation
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 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?
|
portality/static/js/formulaic.js
Outdated
fetch(`/admin/journal/${journalId}/article-info`) | ||
.then(response => response.json()) | ||
.then(data => { | ||
const $p = $(sealSelector).prev('p'); |
There was a problem hiding this comment.
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.
@amdomanska, If we still want to make that title inside you might need to discuss with @richard-jones about |
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. doaj/portality/forms/application_forms.py Line 1604 in 6dd2ed5
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? |
There was a problem hiding this 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", |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
extraneous comma added
doajtest/fixtures/accounts.py
Outdated
@@ -83,7 +83,11 @@ def create_publisher_a(): | |||
return publisher | |||
|
|||
|
|||
def create_maned_a(): | |||
def create_maned_a(is_save=False): |
There was a problem hiding this comment.
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", | ||
], |
There was a problem hiding this comment.
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.
There was a problem hiding this 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.
@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 |
@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). |
[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...
Basic PR Checklist
Instructions for developers:
Instructions for reviewers:
Code Style
No deprecated methods are used
No magic strings/numbers - all strings are in
constants
ormessages
filesES queries are wrapped in a Query object rather than inlined in the code
Where possible our common library functions have been used (e.g. dates manipulated via
dates
)Cleaned up commented out code, etc
Urls are constructed with
url_for
not hard-codedTesting
Unit tests have been added/modified
Functional tests have been added/modified
Code has been run manually in development, and functional tests followed locally
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?
Documentation
FeatureMap annotations have been added
Documentation updates - if needed - have been identified and prepared for inclusion into main documentation (e.g. added and highlighted/commented as appropriate to this PR)
Core model documentation has been added to if needed: https://docs.google.com/spreadsheets/d/1lun2S9vwGbyfy3WjIjgXBm05D-3wWDZ4bp8xiIYfImM/edit
Events and consumers documentation has been added if needed: https://docs.google.com/spreadsheets/d/1oIeG5vg-blm2MZCE-7YhwulUlSz6TOUeY8jAftdP9JE/edit
The docs for this branch have been generated and pushed to the doc site (see docs/README.md for details)
Release Readiness
If needed, migration has been created and tested locally
Release sheet has been created, and completed as far as is possible https://docs.google.com/spreadsheets/d/1Bqx23J1MwXzjrmAygbqlU3YHxN1Wf7zkkRv14eTVLZQ/edit
There has been a recent merge up from
develop
(or other base branch). List the dates of the merges up from develop belowTesting
List the Functional Tests that must be run to confirm this feature
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