Quick edit modal for content title and description

[AlexVelezLl]

Summary

Description of the change(s) you made

Add a quick edit modal to edit content nodes titles and descriptions.

Screenshots

Compartir.pantalla.-.2023-12-08.17_14_21.mp4

Reviewer guidance

How can a reviewer test these changes?

1. Go to update a channel content
2. Click on the edit button besides the menu button of a content node.

References

Closes #3413

Comments

Contributor's Checklist

PR process:

• If this is an important user-facing change, PR or related issue the CHANGELOG label been added to this PR. Note: items with this label will be added to the CHANGELOG at a later time
• If this includes an internal dependency change, a link to the diff is provided
• The docs label has been added if this introduces a change that needs to be updated in the user docs?
• If any Python requirements have changed, the updated requirements.txt files also included in this PR
• Opportunities for using Google Analytics here are noted
• Migrations are safe for a large db

Studio-specifc:

• All user-facing strings are translated properly
• The notranslate class been added to elements that shouldn't be translated by Google Chrome's automatic translation feature (e.g. icons, user-generated text)
• All UI components are LTR and RTL compliant
• Views are organized into pages, components, and layouts directories as described in the docs
• Users' storage used is recalculated properly on any changes to main tree files
• If there new ways this uses user data that needs to be factored into our Privacy Policy, it has been noted.

Testing:

• Code is clean and well-commented
• Contributor has fully tested the PR manually
• If there are any front-end changes, before/after screenshots are included
• Critical user journeys are covered by Gherkin stories
• Any new interactions have been added to the QA Sheet
• Critical and brittle code paths are covered by unit tests

---

Reviewer's Checklist

This section is for reviewers to fill out.

• Automated test coverage is satisfactory
• PR is fully functional
• PR has been tested for accessibility regressions
• External dependency files were updated if necessary (yarn and pip)
• Documentation is updated
• Contributor is in AUTHORS.md

[marcellamaki]

This looks so great @AlexVelezLl! Nice work. Clean code, tests 🎉 , and manual testing looks good.

I have one piece of non-blocking feedback (although admittedly I am leaving this as a comment, rather than approving, just for the sake of having a discussion) which I would like the opinion of @bjester and @MisRob on, as this is a bit older in our "studio patterns".

We have some shared validators (I think Misha was someone who did some of the work on putting them into one place -- contentcuration/contentcuration/frontend/shared/utils/validation.js) which we use in other places for form validation of various aspects of the content node data structure mostly.

@bjester and @MisRob - do you both think it would be valuable here to use those, for the sake of consistency? The title validation is functionally the same as what Alex has done...and perhaps he even referred to that to come up with the validation. Some of the validations are more complex, however, and in these cases it might be worth just importing and using the existing validators. And then, if we do that, for the sake of consistency, it might make sense to just use them throughout this project.

Alex, obviously none of this was specified in the issue, and we are just... figuring this out as we go. 😄 It has been a while since anyone has done any significant new front-end feature work in this part of Studio.

Anyone's thoughts welcome! (cc @akolson)

[MisRob]

I think it'd be useful to have validators organized at one place (a file or a directory) since there are many of them across the Studio at various places. The current pattern was a reaction to having many similar/same validators all over the place.

That said, I'm not sure if all existing validators will make sense for new work. For example here

studio/contentcuration/contentcuration/frontend/shared/utils/validation.js

Lines 170 to 176 in 525b7db

	// Validators
	// These functions return an array of validators (validator is
	// a function that returns `true` or an error code)
	// Designed to be compatible with Vuetify's inputs rules
	export function getTitleValidators() {
	return [value => Boolean(value && value.trim()) || ValidationErrors.TITLE_REQUIRED];
	}

you can see that the validator output is designed to work with Vuetify's inputs. In this PR though, we need a validator for our KDS component (which is good!).

If existing validators can't be used, I still see value having them organized in one file even though they're a bit different, perhaps even more so, because we can at least make sure that validation rules are consistent, whether used for Vuetify or KDS components.

[MisRob]

Relatedly, we also have error messages in that file

studio/contentcuration/contentcuration/frontend/shared/utils/validation.js

Line 130 in 525b7db

[ValidationErrors.TITLE_REQUIRED]: translator.$tr('fieldRequired'),

. I can see at least one of them duplicated here in EditTitleDescriptionModal.vue So that could be another reason to re-use the validation utils in one way or another.

[bjester]

Since this modal isn't specific to individual content nodes, or ContentNodeEditListItem component itself, it seems slightly better to have it implemented outside of this component. As a modal, there should only ever be one of them open at a time. Having it implemented singularly outside of ContentNodeEditListItem then better aligns its implementation with its behavior. You could have this component emit events upwards that can be handled where we render multiple of these as a group.

We have the same issue with ContentNodeContextMenu but we've seen how that can increase memory usage and have come to recognize that its a pattern we should correct.

[AlexVelezLl]

Hi @MisRob! I added a new method getInvalidText(validators, value) to make the rule validations and return the translated error to match the KTextBox interface, let me know if it makes sense 👐.

@bjester I pushed it up so that it is rendered two levels higher in the "CurrentTopicView" component, to have all the quick edit modals (also those for the bulk selection) in the same place.

[MisRob]

@AlexVelezLl

I added a new method getInvalidText(validators, value) to make the rule validations and return the translated error to match the KTextBox interface, let me know if it makes sense 👐.

Oh that's so elegant and will be handy for other validators too!

[bjester]

@bjester I pushed it up so that it is rendered two levels higher in the "CurrentTopicView" component, to have all the quick edit modals (also those for the bulk selection) in the same place.

Yes this seems better, especially as you build more of these bulk editing modals! Thanks @AlexVelezLl