-
Notifications
You must be signed in to change notification settings - Fork 51
pkp/pkp-lib#11296, pkp/pkp-lib#11366, pkp/pkp-lib#11387 [Versioning] #621
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
base: main
Are you sure you want to change the base?
Conversation
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.
Hi Blessie,
looking great, first part of the feedback is done.
In addition to that I am now looking what we could do that form. Will post that separately, need to do some experimenting first.
src/components/Modal/DialogBody.vue
Outdated
@@ -62,3 +65,14 @@ function fireCallback(callback) { | |||
} | |||
} | |||
</script> | |||
|
|||
<style> | |||
/* Override style when form is opened in a dialog */ |
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.
I know that we still have similar patterns in the code base, but trying to move away from them and basically don't change styling of the component from the outside, and handle these scenarios via variants. Reason basically is that it makes difficult to change the underlying components - if there are these hidden dependencies from parent components.
Here I think biggest problem is additional padding on the sides. So maybe just full width variant would work ok?
src/composables/useModal.js
Outdated
* Close the currently open dialog modal | ||
* @param {boolean} [triggerLegacyCloseHandler=true] - Whether to trigger the legacy close handler | ||
*/ | ||
function closeDialog(triggerLegacyCloseHandler = true) { |
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.
Lets keep useModal friendly and remove that mysterious argument, I think its unnecessary. Its only important within modalStore to differentiate whether the close event is coming from the legacy handler (therefore no need to call him again) or not. And here we already know that its not coming from legacy handler
@@ -10,6 +10,7 @@ export const FileManagerConfigurations = { | |||
{ | |||
roles: [pkp.const.ROLE_ID_AUTHOR], | |||
actions: [ | |||
Actions.FILE_SEND_TO_EDITOR, |
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.
Do we have details whether for author this functionality needs to be bit different. Do we let Author create new version etc?
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.
Hi Jarda, this was confirmed that we should only allow "Send File to Text Editor" for users who can also access "Publish, Unpublish" or "Create New Version". So I updated this and applied accordingly.
*/ | ||
const selectedMenuState = computed(() => { | ||
const actionArgs = selectedMenuItem.value?.actionArgs || {}; | ||
|
||
// If menu is "dialog-only" action, don't update the actionArgs | ||
// to preserve the current primary/secondary menu items dislayed in the workflow content | ||
if (actionArgs.isDialogOnly) { |
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.
I was thinking whether this is good excuse to actually fix that stupid selectMenu
action, which does not exist. And thats is super confusing.. and would like to fix that.
What do you think about these changes #622
With that, basically if you add action without state, it would just get triggered, but it would not select that menu item. So you would not need to track the previousMenuState here.
@@ -68,7 +93,15 @@ export function useWorkflowMenu({ | |||
|
|||
// Update selectedMenuKey in url when menu selection changes | |||
watch(selectedMenuKey, (newSelectedMenuKey) => { | |||
queryParamsUrl.workflowMenuKey = newSelectedMenuKey; | |||
if (newSelectedMenuKey !== 'publication_create_new_version') { | |||
queryParamsUrl.workflowMenuKey = newSelectedMenuKey; |
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 I believe also could go away with the PR I suggested above.
}; | ||
}; | ||
|
||
const handleVersionSubmission = async (formData) => { |
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.
Nothing wrong with using arrow function, just to be bit more consistent with rest of the composables, where we use normal function
async function handleVersionSubmission(formData){...
0e41b34
to
cebf298
Compare
Hi @jardakotesovec , thank you for all your inputs! This is now ready for your review again. |
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.
Hi Blessie, thank you for updates. Couple minor items.
@@ -143,6 +145,8 @@ export default { | |||
return true; | |||
}, | |||
}, | |||
spacingVariant: String, |
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.
Can you add comment here to clarify the options, and when someone would use them?
Actually not sure about the footerSpacingVariant purpose?
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.
There's some styling that FormPage.vue adds to the bottom of the form, the footerSpacingVariant
will change that to match the styling with Dialog. But I removed this now and just kept the spacingVariant
prop to handle two computed classes for styling.
bodyProps: { | ||
mode: 'sendToTextEditor', | ||
displayDefaultFooter: false, | ||
onCloseFn: () => closeDialog(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.
I think the boolean argument is not needed anymore after removing it from closeDialog in useModal?
const {getLatestPublication} = useSubmission(); | ||
let publications = []; | ||
let latestPublication = null; | ||
const modeState = { |
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.
Here I would suggest some comments, so it easier to understand what the modes represents. That should make reading rest of the logic easier.
@@ -424,5 +447,7 @@ export function useForm(_form = {}, {customSubmit} = {}) { | |||
addGroup, | |||
addFieldText, | |||
addFieldSelect, | |||
getField, |
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.
All these functions make sense to not accept form argument. You can probably just move the getField inside the useForm so it does not need form as argument.
option.value === 'true' ? {...option, disabled: !allowMinor} : option, | ||
); | ||
|
||
setSelectOptions(versionIsMinorField, updatedOptions); |
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.
Sorry to obsess about this. But keep thinking about how to structure the useForm api to scale across different use cases. Here you are manipulating existing options array, already tackling internal field structure. So the setSelectOptions is not really abstracting much.
I am thinking about options we could go about this to set good example for future use cases..
Basically to solve the case the need of updating anything on the form field based on some scenario.
To avoid duplications with creating udpate* functions, like updateTextField in addition to addTextField. Maybe we could just tweak the add* functions so they replace field, if it already exist (that can be checked by the field name).
With that, you could follow the declarative approach as vue.js has, having function which gives you result based on the input state.
function getVersionIsMinorField({allowMinor, modelState, currentValue}) {
return {
label: t('publication.revisionSignificance.label'),
description: t('publication.revisionSignificance.description'),
options: [
{label: t('publication.revisionSignificance.major'), value: 'false'},
{
label: t('publication.revisionSignificance.minor'),
value: 'true',
disabled: !allowMinor,
},
],
size: 'large',
isRequired: modeState.isPublishMode,
value: currentValue === 'true' && !allowMinor ? 'false' : currentValue,
};
}
Which you could use for both initially adding the field and for updating it in updateMinorOptionAvailability
addFieldSelect('versionIsMinor', getVersionIsMinorField({...}))
What you think?
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.
Just to expand on that suggestion. We will be adding third parameter options
to the addField* functions. So we can specify where it should be added for example (we have similar capability in PHP, and it will be useful to plugins to be able to insert field to certain place). So maybe we can also have override:true
option there so be more explicit about intention to update existing field.
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.
Hi Jarda, this makes sense. I updated this and if you're happy with the changes on the addFieldSelect
, I can apply the same on the other addField functions.
@@ -66,11 +81,6 @@ export function useWorkflowMenu({ | |||
} | |||
}); | |||
|
|||
// Update selectedMenuKey in url when menu selection changes | |||
watch(selectedMenuKey, (newSelectedMenuKey) => { |
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.
Why this got removed? This it stops updating the currently selected menuKey in the url, which defeats the idea of being able to bookmark or share the url and open the workflow menu in given place
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.
The entire watch function was accidentally removed after I reverted my changes intended for the checking if newSelectedMenuKey === 'publication_create_new_version'
, which is now deleted. I brought this back now.
3b7562e
to
dd82bc1
Compare
…nges from side menu in submission workflow
… data is fetched
…in publication pages
…tPublication id when loading submission page
…s to useWorkflowDataSubmissionPublication api
…menu clicked is dialog only
…lication version
…orkflowVersionDialogBody.vue and define field values depending on form mode
…es not exist on any publications yet
…enu for publications
…enu for publcation versions
…ore publishing unassigned versions
…o handle styling for forms
…an access publish, unpublish or create new version
…footer container
…lication's Title & Abstract page
dd82bc1
to
988347b
Compare
…s and remove setSelectOptions method
…er for OMP and OPS
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.
Looking great.. only thing I think still would be worthwhile improving was more detailed explanation where the individual mode are used. So its easier to understand in what contexts its used. But thats just minor documenting thing.
I will improve useForm at some point for more fields and to handle override
in more general way. But for this PR this is ok.
I think great call on concentrating the logic for this to separate composable - I think that good use of composables.
No description provided.