Maintaining Oppia's Core Data with Frontend Validation Checks

NOTE: No more available checks in this issue.

All Validation Check Issues:

• #13449
• #13603
• [you are here] #13764
• #13820
• #13821
• #13822

Introduction

Background

Oppia’s data storage is frequently updated to have the most recent features. To ensure a smooth user and developer experience, we need to have checks in place which ensure the integrity of the data currently being stored, as well as the integrity of future data.

These checks should exist in both the frontend and the backend. Oppia’s users interact with Oppia’s data in the GUI (frontend), so we need frontend validation checks that stop the user from inputting or doing anything in the GUI that should not be allowed. In the case where the user does manage to do something bad, the inputs get routed to our Python backend, and that’s where we need backend validation checks. These backend validation checks stop the inputs from reaching Oppia’s data storage.

This starter task focuses on the frontend half of the validation checks.

Getting Started

Note: This issue requires you to spend time understanding how information is passed from HTML to Angular, if you are not familiar yet. Do not take on tasks in this issue unless you have time to learn that!

Review the instructions below on how to add a frontend validation check. Then leave a message on the issue thread asking to be assigned to a validation check. We’ll assign you to the check by adding your username next to the item. If you have any questions, send a message on the issue thread, and we’ll help you out!

How to Add Frontend Validation Checks for Core Models

Steps

1. First, launch Oppia on localhost.
2. Given the data model for your validation check (indicated by the 🏷️), navigate to the corresponding page in the GUI and familiarize yourself with the user workflow. A good way to understand the context of the data model or page is to search the codebase for class <tag>( where <tag> is replaced by the text after the 🏷️. This will show the data that is ultimately passed to the backend storage.
3. Find the Angular Typescript (.ts) files for the data model. They will likely be inside of core/templates/components or core/templates/domain. An easy way to find the file to edit is by copying and pasting specific text from the GUI (if there is any and if it is related to your validation check). HINT: If a field is topic_url_title in the Python code, then it will very likely be called topicUrlTitle in the Angular code.
4. Find the HTML (.html) files for the corresponding data model. They will likely be inside of core/templates/pages.
5. Figure out how data is routed from the GUI (HTML) to the middle-layer (Angular TypeScript), and make sure that no invalid inputs can get past the middle-layer! You might need to edit both the HTML and TypeScript files.
6. Test the changes by clicking on your interaction in the exploration editor, and try to submit bad inputs!
7. If applicable, add / modify a unit test (in the *.spec.ts file) to test the code you’ve added.

Guidelines on User-Facing Messages

We want to provide the user with a smooth experience, especially when an input is invalid. Make sure the user either:

• Is not allowed to type the invalid input, and there is a small subtext that states the validation underneath the input at all times
• Can type the invalid input but is not allowed to click the save button, and there is red subtext that states the validation underneath the input when the save button is disabled

Validation Checks

Available Checks

None

Claimed Checks

• (on hold) Skill misconception notes, misconception feedback, and skill content worked-examples question and answer should all be valid HTML strings with at most 1000 characters. 🏷️ Misconception 🏷️ WorkedExample @ashish-patwal #14247
• (on hold) Find appropriate HTML length limits for the HTML length checks that this issue adds. @EricZLou

Completed Checks

• Exploration title should have max length of 36. 🏷️ Exploration @EricZLou #13777
• Skill misconceptions should have unique names. 🏷️ Skill @EricZLou #13816
• State content should be a valid HTML string with at most 10,000 characters. 🏷️ State @lkbhitesh07 #13918
• Thumbnail filename should be a string that does not start with a dot, does not contain / or consecutive dots, and has an SVG extension. 🏷️ Story, Subtopic, Topic @siddharthmehta02 #13807
• Exploration tags should be a list of at most 10 non-empty strings without duplicates, where each tag has max length of 30. 🏷️ Exploration @EricZLou #14119
• Outcome feedback, default outcome feedback, hint content, and solution explanation should be valid HTML strings with at most 200 characters. 🏷️ Outcome 🏷️ DefaultOutcome 🏷️ Hint 🏷️ Solution @soumyo123-prog #14035
• Topic page_title_fragment_for_web should be non-empty, with min-length 5 and max-length 50. 🏷️ Topic @nadintamer #14264
• Story notes should have at most 5000 characters. 🏷️ Story @lkbhitesh07 #14159
• Skill rubric explanations should be a list of at most 10 strings of 300 characters each, and there should be at least one explanation for the Medium rubric level. 🏷️ Rubric @lkbhitesh07 #14159
• For curated lessons (lessons within topics), outcome refresher_exploration_id should be None. 🏷️ Outcome @lkbhitesh07 #14908
• Topic practice_tab_is_displayed is true only when there are at least 10 practice questions in the topic. 🏷️ Topic @EricZLou #14799

[EricZLou]

@ashish-patwal hmmm I see – does your terminal give any more descriptive errors other than PIPE error? In the meantime, since you have confirmed that your tests are all passing locally, you can use git push --no-verify to get around Oppia’s git hook. Let me know if that works.

[ashish-patwal]

hey @EricZLou , i am trying to push my changes to my fork , but after passing lint checks and frontend validation checks , it is not not actually pushing the code . I tried to locate my pushed branch in my fork but it’s not there . here’s an ss :

Also you can at the right bottom bar that the git push command is exiting with some PIPE error .