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

Programming exercises: Fix an issue in which long manual feedback is not correctly displayed #9562

Merged
merged 29 commits into from
Nov 2, 2024

Conversation

az108
Copy link
Contributor

@az108 az108 commented Oct 22, 2024

Checklist

General

Server

  • Important: I implemented the changes with a very good performance and prevented too many (unnecessary) and too complex database calls.
  • I strictly followed the principle of data economy for all database calls.
  • I strictly followed the server coding and design guidelines.
  • I added multiple integration tests (Spring) related to the features (with a high test coverage).
  • I added pre-authorization annotations according to the guidelines and checked the course groups for all new REST Calls (security).
  • I documented the Java code using JavaDoc style.

Client

  • Important: I implemented the changes with a very good performance, prevented too many (unnecessary) REST calls and made sure the UI is responsive, even with large data (e.g. using paging).
  • I strictly followed the principle of data economy for all client-server REST calls.
  • I strictly followed the client coding and design guidelines.
  • Following the theming guidelines, I specified colors only in the theming variable files and checked that the changes look consistent in both the light and the dark theme.
  • I added multiple integration tests (Jest) related to the features (with a high test coverage), while following the test guidelines.
  • I added authorities to all new routes and checked the course groups for displaying navigation elements (links, buttons).
  • I documented the TypeScript code using JSDoc style.
  • I added multiple screenshots/screencasts of my UI changes.
  • I translated all newly inserted strings into English and German.

Changes affecting Programming Exercises

  • High priority: I tested all changes and their related features with all corresponding user types on a test server configured with the integrated lifecycle setup (LocalVC and LocalCI).
  • I tested all changes and their related features with all corresponding user types on a test server configured with Gitlab and Jenkins.

Motivation and Context

Fixes #9434
This is a fix which adresses following issue where long feedback was not beeing loaded properly from the server.
This is most probably either caused by the result beeing damaged or not saved properly or the feedback beeing overwritten. To tackle the second mentioned potential reason following was done (described in Description).

Additionally another bug was fixed where instructors were not able to edit long feedback in manual assessements.

Description

I refactored the method which handles saving the long feedback when its created and when a long feedback is edited then the whole feedback is loaded to avoid that instructors override the long feedback with the short feedback which is loaded per default. The BaseAPIHTTPService on the client side was adjusted to also accept text responses from the server, making the rest call look very easy to understandable.

Note: The saving of manual assesements for programming exercise needs further refactoring but this is not part of this PR!

Steps for Testing

Prerequisites:

  • 1 Instructor
  • 1 Student
  • 1 Programming Exercise
  1. Log in to Artemis as Instructor
  2. Create a Programming Exercise
  3. Log in as Student and participate in the Programming Exercise
  4. Log in as Instructor and set the Due Date to now and set Manual Assesement
  5. Navigate to the Programming Exercise and press the View button in the TutorActions tab
  6. Press the Assesement Dashboard button
  7. Assess the Student Sumbission by creating a new Feedback with over 1000 characters
  8. Save this and reload the page
  9. Verify that the feedback box now displays the whole long feedback and no shortend version
  10. Try to edit the long feedback and save again
  11. Verify that the long feedback was changed
  12. Do this for Modelling and Quiz and Text Exercises aswell

Testserver States

Note

These badges show the state of the test servers.
Green = Currently available, Red = Currently locked
Click on the badges to get to the test servers.







Review Progress

Performance Review

  • I (as a reviewer) confirm that the client changes (in particular related to REST calls and UI responsiveness) are implemented with a very good performance even for very large courses with more than 2000 students.
  • I (as a reviewer) confirm that the server changes (in particular related to database calls) are implemented with a very good performance even for very large courses with more than 2000 students.

Code Review

  • Code Review 1
  • Code Review 2

Manual Tests

  • Test 1
  • Test 2

Performance Tests

  • Test 1
  • Test 2

Screenshots

Before:
image
After:
image

Summary by CodeRabbit

Release Notes

  • New Features

    • Introduced handling for long feedback texts across various assessment services.
    • Added conditional rendering for feedback components based on the presence of valid assessment results.
    • Enhanced FeedbackService to fetch long feedback text dynamically.
    • Implemented new input properties for components to receive result identifiers, improving feedback detail processing.
  • Bug Fixes

    • Enhanced feedback management to prevent duplicates during assessments.
  • Documentation

    • Updated comments for clarity in the BaseApiHttpService.
  • Tests

    • Improved test coverage for FeedbackService with Angular's testing utilities and HTTP request mocking.

@az108 az108 added the bugfix label Oct 22, 2024
@az108 az108 self-assigned this Oct 22, 2024
@github-actions github-actions bot added server Pull requests that update Java code. (Added Automatically!) client Pull requests that update TypeScript code. (Added Automatically!) assessment Pull requests that affect the corresponding module labels Oct 22, 2024
@github-actions github-actions bot added programming Pull requests that affect the corresponding module text Pull requests that affect the corresponding module labels Oct 24, 2024
@az108 az108 marked this pull request as ready for review October 24, 2024 20:53
@az108 az108 requested a review from a team as a code owner October 24, 2024 20:53
Copy link

coderabbitai bot commented Oct 24, 2024

Walkthrough

The changes in this pull request primarily involve the addition of a new repository, LongFeedbackTextRepository, across multiple service classes, enhancing their ability to manage long feedback text. Key methods such as saveManualAssessment, deleteLongFeedback, and new methods like handleFeedbackPersistence have been introduced or modified to improve feedback handling during assessments. Additionally, various components have been updated to conditionally render feedback based on the presence of valid result identifiers, ensuring a more robust user interface.

Changes

File Change Summary
src/main/java/de/tum/cit/aet/artemis/assessment/service/AssessmentService.java Added LongFeedbackTextRepository as a dependency; modified constructor and saveManualAssessment method.
src/main/java/de/tum/cit/aet/artemis/assessment/service/ResultService.java Introduced deleteLongFeedback and handleFeedbackPersistence methods; refactored saveFeedbackWithHibernateWorkaround.
src/main/java/de/tum/cit/aet/artemis/programming/service/ProgrammingAssessmentService.java Added LongFeedbackTextRepository to constructor; updated saveAndSubmitManualAssessment method.
src/main/java/de/tum/cit/aet/artemis/text/service/TextAssessmentService.java Added LongFeedbackTextRepository to constructor.
src/main/webapp/app/assessment/unreferenced-feedback-detail/unreferenced-feedback-detail.component.ts Implemented OnInit interface; added resultId input and loadLongFeedback method.
src/main/webapp/app/course/learning-paths/services/base-api-http.service.ts Expanded responseType options in HTTP methods; modified response handling.
src/main/webapp/app/exercises/file-upload/assess/file-upload-assessment.component.html Conditional rendering for <jhi-unreferenced-feedback> based on result.id.
src/main/webapp/app/exercises/modeling/assess/modeling-assessment-editor/modeling-assessment-editor.component.html Conditional rendering for <jhi-unreferenced-feedback> based on result.id.
src/main/webapp/app/exercises/modeling/manage/example-modeling/example-modeling-submission.component.html Conditional rendering for <jhi-unreferenced-feedback> based on result.id.
src/main/webapp/app/exercises/programming/assess/code-editor-tutor-assessment-container.component.html Conditional rendering for <jhi-unreferenced-feedback> based on manualResult.id.
src/main/webapp/app/exercises/shared/feedback/feedback.service.ts Extended BaseApiHttpService and added getLongFeedbackText method.
src/main/webapp/app/exercises/shared/unreferenced-feedback/unreferenced-feedback.component.html Added [resultId] input to jhi-unreferenced-feedback-detail.
src/main/webapp/app/exercises/shared/unreferenced-feedback/unreferenced-feedback.component.ts Added resultId input property to UnreferencedFeedbackComponent.
src/main/webapp/app/exercises/text/assess/text-submission-assessment.component.html Conditional rendering for <jhi-unreferenced-feedback> based on result.id.
src/main/webapp/app/exercises/text/manage/example-text-submission/example-text-submission.component.html Conditional rendering for <jhi-unreferenced-feedback> based on result.id.
src/test/javascript/spec/component/assessment-shared/unreferenced-feedback-detail.component.spec.ts Added FeedbackService mock provider in tests.
src/test/javascript/spec/service/feedback/feedback-service.spec.ts Integrated Angular testing utilities; added tests for getLongFeedbackText.

Assessment against linked issues

Objective Addressed Explanation
Ensure all feedback is displayed correctly in the feedback view (9434)

Possibly related PRs

Suggested reviewers

  • JohannesStoehr
  • EneaGore
  • pzdr7
  • Malekos74
  • SimonEntholzer

Thank you for using CodeRabbit. We offer it for free to the OSS community and would appreciate your support in helping us grow. If you find it useful, would you consider giving us a shout-out on your favorite social media?

❤️ Share
🪧 Tips

Chat

There are 3 ways to chat with CodeRabbit:

  • Review comments: Directly reply to a review comment made by CodeRabbit. Example:
    • I pushed a fix in commit <commit_id>, please review it.
    • Generate unit testing code for this file.
    • Open a follow-up GitHub issue for this discussion.
  • Files and specific lines of code (under the "Files changed" tab): Tag @coderabbitai in a new review comment at the desired location with your query. Examples:
    • @coderabbitai generate unit testing code for this file.
    • @coderabbitai modularize this function.
  • PR comments: Tag @coderabbitai in a new PR comment to ask questions about the PR branch. For the best results, please provide a very specific query, as very limited context is provided in this mode. Examples:
    • @coderabbitai gather interesting stats about this repository and render them as a table. Additionally, render a pie chart showing the language distribution in the codebase.
    • @coderabbitai read src/utils.ts and generate unit testing code.
    • @coderabbitai read the files in the src/scheduler package and generate a class diagram using mermaid and a README in the markdown format.
    • @coderabbitai help me debug CodeRabbit configuration file.

Note: Be mindful of the bot's finite context window. It's strongly recommended to break down tasks such as reading entire modules into smaller chunks. For a focused discussion, use review comments to chat about specific files and their changes, instead of using the PR comments.

CodeRabbit Commands (Invoked using PR comments)

  • @coderabbitai pause to pause the reviews on a PR.
  • @coderabbitai resume to resume the paused reviews.
  • @coderabbitai review to trigger an incremental review. This is useful when automatic reviews are disabled for the repository.
  • @coderabbitai full review to do a full review from scratch and review all the files again.
  • @coderabbitai summary to regenerate the summary of the PR.
  • @coderabbitai resolve resolve all the CodeRabbit review comments.
  • @coderabbitai configuration to show the current CodeRabbit configuration for the repository.
  • @coderabbitai help to get help.

Other keywords and placeholders

  • Add @coderabbitai ignore anywhere in the PR description to prevent this PR from being reviewed.
  • Add @coderabbitai summary to generate the high-level summary at a specific location in the PR description.
  • Add @coderabbitai or @coderabbitai title anywhere in the PR title to generate the title automatically.

Documentation and Community

  • Visit our Documentation for detailed information on how to use CodeRabbit.
  • Join our Discord Community to get help, request features, and share feedback.
  • Follow us on X/Twitter for updates and announcements.

Copy link

@coderabbitai coderabbitai bot left a comment

Choose a reason for hiding this comment

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

Actionable comments posted: 12

🧹 Outside diff range and nitpick comments (11)
src/main/webapp/app/exercises/shared/feedback/feedback.service.ts (1)

20-23: Add documentation and improve error handling

While the implementation is functionally correct, consider these improvements:

  1. Add JSDoc documentation to describe the method's purpose, parameters, and return value
  2. Consider using URL encoding for the parameters
  3. Add error handling for failed requests

Here's a suggested improvement:

+    /**
+     * Retrieves the long feedback text for a specific result and feedback combination
+     * @param resultId - The ID of the result
+     * @param feedbackId - The ID of the feedback
+     * @returns Promise containing the long feedback text
+     * @throws Error if the request fails
+     */
     public async getLongFeedbackText(resultId: number, feedbackId: number): Promise<string> {
-        const url = `results/${resultId}/feedbacks/${feedbackId}/long-feedback`;
+        const url = `results/${encodeURIComponent(resultId)}/feedbacks/${encodeURIComponent(feedbackId)}/long-feedback`;
         return await this.get<string>(url, { responseType: 'text' });
     }
src/main/webapp/app/assessment/unreferenced-feedback-detail/unreferenced-feedback-detail.component.ts (1)

Line range hint 14-26: Consider implementing OnDestroy to prevent memory leaks.

The component has multiple event emitters but lacks proper cleanup. Consider implementing the OnDestroy interface to unsubscribe from observables.

Apply this diff:

-export class UnreferencedFeedbackDetailComponent implements OnInit {
+export class UnreferencedFeedbackDetailComponent implements OnInit, OnDestroy {
+    private destroy$ = new Subject<void>();
+
+    ngOnDestroy(): void {
+        this.destroy$.next();
+        this.destroy$.complete();
+        this.dialogErrorSource.complete();
+    }
src/test/javascript/spec/component/assessment-shared/unreferenced-feedback-detail.component.spec.ts (1)

Line range hint 48-95: Add test coverage for long feedback functionality.

The current test suite lacks coverage for the long feedback functionality introduced in this PR. Consider adding the following test cases:

  1. Loading long feedback
  2. Handling long feedback display
  3. Error cases for long feedback retrieval

Here's a suggested test implementation:

it('should load long feedback when available', async () => {
    const mockFeedbackService = TestBed.inject(FeedbackService);
    jest.spyOn(mockFeedbackService, 'getLongFeedbackText').mockResolvedValue('long feedback text');
    
    comp.feedback = {
        id: 1,
        hasLongFeedback: true,
        resultId: 123
    } as Feedback;
    
    await comp.loadLongFeedback();
    
    expect(mockFeedbackService.getLongFeedbackText).toHaveBeenCalledExactlyOnceWith(123, 1);
    expect(comp.feedback.detailText).toBe('long feedback text');
});

it('should handle errors when loading long feedback', async () => {
    const mockFeedbackService = TestBed.inject(FeedbackService);
    jest.spyOn(mockFeedbackService, 'getLongFeedbackText').mockRejectedValue(new Error('Failed to load'));
    
    comp.feedback = {
        id: 1,
        hasLongFeedback: true,
        resultId: 123
    } as Feedback;
    
    await comp.loadLongFeedback();
    
    expect(mockFeedbackService.getLongFeedbackText).toHaveBeenCalledExactlyOnceWith(123, 1);
    // Verify error handling behavior based on your implementation
});
src/main/webapp/app/exercises/shared/unreferenced-feedback/unreferenced-feedback.component.ts (3)

20-20: Add TypeScript documentation for the resultId input property.

Consider adding JSDoc documentation to explain the purpose and usage of this property, especially since it's crucial for long feedback handling.

+    /** The ID of the result associated with this feedback component. Used for loading long feedback text. */
     @Input() resultId: number;

Line range hint 11-13: Implement OnDestroy interface for proper cleanup.

To prevent potential memory leaks, implement the OnDestroy interface to clean up any subscriptions or event listeners that might be created by external components subscribing to the EventEmitter outputs.

-export class UnreferencedFeedbackComponent {
+export class UnreferencedFeedbackComponent implements OnDestroy {
+    ngOnDestroy() {
+        // Clean up any subscriptions or event listeners
+        this.feedbacksChange.complete();
+        this.onAcceptSuggestion.complete();
+        this.onDiscardSuggestion.complete();
+    }

Line range hint 48-63: Improve type safety and code style compliance.

A few style improvements to better align with the coding guidelines:

-    validateFeedback() {
+    validateFeedback(): void {
         if (!this.unreferencedFeedback || this.unreferencedFeedback.length === 0) {
             this.assessmentsAreValid = false;
             return;
         }
-        for (const feedback of this.unreferencedFeedback) {
+        for (const feedback of this.unreferencedFeedback) {
             if (feedback.credits == undefined || isNaN(feedback.credits)) {
                 this.assessmentsAreValid = false;
                 return;
             }
         }
         this.assessmentsAreValid = true;
     }
src/main/webapp/app/course/learning-paths/services/base-api-http.service.ts (1)

112-112: LGTM! Consider documenting responseType in JSDoc.

The responseType option has been consistently added across all HTTP methods, providing the necessary flexibility for handling both JSON and text responses while maintaining backward compatibility.

Consider adding the responseType parameter to each method's JSDoc, for example:

     * @param url The endpoint URL excluding the base server url (/api).
     * @param options The HTTP options to send with the request.
+    * @param options.responseType The response type to expect ('json' | 'text'). Defaults to 'json'.
     * @protected

Also applies to: 144-144, 174-174, 205-205, 236-236

src/main/java/de/tum/cit/aet/artemis/programming/service/ProgrammingAssessmentService.java (2)

94-97: Feedback handling changes look good, with minor optimization suggestions.

The changes effectively address the long feedback display issues. Consider these improvements:

  1. Add null check before accessing getFeedbacks()
  2. Avoid unnecessary ArrayList creation
-        resultService.deleteLongFeedback(newManualResult.getFeedbacks());
-        List<Feedback> feedbacks = new ArrayList<>(newManualResult.getFeedbacks());
+        var feedbacks = newManualResult.getFeedbacks();
+        if (feedbacks != null) {
+            resultService.deleteLongFeedback(feedbacks);
+            newManualResult.updateAllFeedbackItems(feedbacks, true);
+        }
-        newManualResult.updateAllFeedbackItems(feedbacks, true);

94-94: Fix typo in comment.

"Assesements" should be "Assessments"

-        // we do this to avoid problems of editing longFeedbackTexts in manual Assesements
+        // we do this to avoid problems of editing longFeedbackTexts in manual Assessments
src/main/java/de/tum/cit/aet/artemis/assessment/service/ResultService.java (2)

539-542: Avoid Unnecessary List Creation for Performance Improvement

In line 541, creating a new ArrayList from result.getFeedbacks() may be unnecessary if updateAllFeedbackItems can work directly with the existing list.

If updateAllFeedbackItems does not modify the list, consider passing result.getFeedbacks() directly to avoid the overhead of list duplication.

-List<Feedback> feedbacks = new ArrayList<>(result.getFeedbacks());
-result.updateAllFeedbackItems(feedbacks, true);
+result.updateAllFeedbackItems(result.getFeedbacks(), true);

Verify that this change does not affect the logic of updateAllFeedbackItems.


15-15: Avoid Unused Imports to Clean Up the Code

Line 15 introduces an unused import java.util.function.Function;. Unused imports can clutter the code and may lead to confusion.

Remove the unused import to adhere to clean code practices.

-import java.util.function.Function;

Ensure the code compiles successfully after removing the import.

📜 Review details

Configuration used: .coderabbit.yaml
Review profile: CHILL

📥 Commits

Files that changed from the base of the PR and between 61c92c6 and 683c120.

📒 Files selected for processing (17)
  • src/main/java/de/tum/cit/aet/artemis/assessment/service/AssessmentService.java (4 hunks)
  • src/main/java/de/tum/cit/aet/artemis/assessment/service/ResultService.java (3 hunks)
  • src/main/java/de/tum/cit/aet/artemis/programming/service/ProgrammingAssessmentService.java (4 hunks)
  • src/main/java/de/tum/cit/aet/artemis/text/service/TextAssessmentService.java (2 hunks)
  • src/main/webapp/app/assessment/unreferenced-feedback-detail/unreferenced-feedback-detail.component.ts (3 hunks)
  • src/main/webapp/app/course/learning-paths/services/base-api-http.service.ts (7 hunks)
  • src/main/webapp/app/exercises/file-upload/assess/file-upload-assessment.component.html (2 hunks)
  • src/main/webapp/app/exercises/modeling/assess/modeling-assessment-editor/modeling-assessment-editor.component.html (2 hunks)
  • src/main/webapp/app/exercises/modeling/manage/example-modeling/example-modeling-submission.component.html (1 hunks)
  • src/main/webapp/app/exercises/programming/assess/code-editor-tutor-assessment-container.component.html (1 hunks)
  • src/main/webapp/app/exercises/shared/feedback/feedback.service.ts (2 hunks)
  • src/main/webapp/app/exercises/shared/unreferenced-feedback/unreferenced-feedback.component.html (2 hunks)
  • src/main/webapp/app/exercises/shared/unreferenced-feedback/unreferenced-feedback.component.ts (1 hunks)
  • src/main/webapp/app/exercises/text/assess/text-submission-assessment.component.html (2 hunks)
  • src/main/webapp/app/exercises/text/manage/example-text-submission/example-text-submission.component.html (1 hunks)
  • src/test/javascript/spec/component/assessment-shared/unreferenced-feedback-detail.component.spec.ts (2 hunks)
  • src/test/javascript/spec/service/feedback/feedback-service.spec.ts (2 hunks)
🧰 Additional context used
📓 Path-based instructions (17)
src/main/java/de/tum/cit/aet/artemis/assessment/service/AssessmentService.java (1)

Pattern src/main/java/**/*.java: naming:CamelCase; principles:{single_responsibility,small_methods,no_duplication}; db:{perf_queries,datetime_not_timestamp}; rest:{stateless,singleton,delegate_logic,http_only,minimal_dtos}; dtos:{java_records,no_entities,min_data,single_resp}; di:constructor_injection; kiss:simple_code; file_handling:os_indep_paths; practices:{least_access,avoid_transactions,code_reuse,static_member_ref,prefer_primitives}; sql:{param_annotation,uppercase,avoid_subqueries};java:avoid_star_imports

src/main/java/de/tum/cit/aet/artemis/assessment/service/ResultService.java (1)

Pattern src/main/java/**/*.java: naming:CamelCase; principles:{single_responsibility,small_methods,no_duplication}; db:{perf_queries,datetime_not_timestamp}; rest:{stateless,singleton,delegate_logic,http_only,minimal_dtos}; dtos:{java_records,no_entities,min_data,single_resp}; di:constructor_injection; kiss:simple_code; file_handling:os_indep_paths; practices:{least_access,avoid_transactions,code_reuse,static_member_ref,prefer_primitives}; sql:{param_annotation,uppercase,avoid_subqueries};java:avoid_star_imports

src/main/java/de/tum/cit/aet/artemis/programming/service/ProgrammingAssessmentService.java (1)

Pattern src/main/java/**/*.java: naming:CamelCase; principles:{single_responsibility,small_methods,no_duplication}; db:{perf_queries,datetime_not_timestamp}; rest:{stateless,singleton,delegate_logic,http_only,minimal_dtos}; dtos:{java_records,no_entities,min_data,single_resp}; di:constructor_injection; kiss:simple_code; file_handling:os_indep_paths; practices:{least_access,avoid_transactions,code_reuse,static_member_ref,prefer_primitives}; sql:{param_annotation,uppercase,avoid_subqueries};java:avoid_star_imports

src/main/java/de/tum/cit/aet/artemis/text/service/TextAssessmentService.java (1)

Pattern src/main/java/**/*.java: naming:CamelCase; principles:{single_responsibility,small_methods,no_duplication}; db:{perf_queries,datetime_not_timestamp}; rest:{stateless,singleton,delegate_logic,http_only,minimal_dtos}; dtos:{java_records,no_entities,min_data,single_resp}; di:constructor_injection; kiss:simple_code; file_handling:os_indep_paths; practices:{least_access,avoid_transactions,code_reuse,static_member_ref,prefer_primitives}; sql:{param_annotation,uppercase,avoid_subqueries};java:avoid_star_imports

src/main/webapp/app/assessment/unreferenced-feedback-detail/unreferenced-feedback-detail.component.ts (1)

Pattern src/main/webapp/**/*.ts: angular_style:https://angular.io/guide/styleguide;methods_in_html:false;lazy_loading:true;code_reuse:true;tests:meaningful;types:PascalCase;enums:PascalCase;funcs:camelCase;props:camelCase;no_priv_prefix:true;strings:single_quotes;localize:true;btns:functionality;links:navigation;icons_text:newline;labels:associate;code_style:arrow_funcs,curly_braces,open_braces_same_line,indent_4;memory_leak_prevention:true;routes:naming_schema;chart_framework:ngx-charts;responsive_layout:true

src/main/webapp/app/course/learning-paths/services/base-api-http.service.ts (1)

Pattern src/main/webapp/**/*.ts: angular_style:https://angular.io/guide/styleguide;methods_in_html:false;lazy_loading:true;code_reuse:true;tests:meaningful;types:PascalCase;enums:PascalCase;funcs:camelCase;props:camelCase;no_priv_prefix:true;strings:single_quotes;localize:true;btns:functionality;links:navigation;icons_text:newline;labels:associate;code_style:arrow_funcs,curly_braces,open_braces_same_line,indent_4;memory_leak_prevention:true;routes:naming_schema;chart_framework:ngx-charts;responsive_layout:true

src/main/webapp/app/exercises/file-upload/assess/file-upload-assessment.component.html (1)

Pattern src/main/webapp/**/*.html: @if and @for are new and valid Angular syntax replacing *ngIf and *ngFor. They should always be used over the old style.

src/main/webapp/app/exercises/modeling/assess/modeling-assessment-editor/modeling-assessment-editor.component.html (1)

Pattern src/main/webapp/**/*.html: @if and @for are new and valid Angular syntax replacing *ngIf and *ngFor. They should always be used over the old style.

src/main/webapp/app/exercises/modeling/manage/example-modeling/example-modeling-submission.component.html (1)

Pattern src/main/webapp/**/*.html: @if and @for are new and valid Angular syntax replacing *ngIf and *ngFor. They should always be used over the old style.

src/main/webapp/app/exercises/programming/assess/code-editor-tutor-assessment-container.component.html (1)

Pattern src/main/webapp/**/*.html: @if and @for are new and valid Angular syntax replacing *ngIf and *ngFor. They should always be used over the old style.

src/main/webapp/app/exercises/shared/feedback/feedback.service.ts (1)

Pattern src/main/webapp/**/*.ts: angular_style:https://angular.io/guide/styleguide;methods_in_html:false;lazy_loading:true;code_reuse:true;tests:meaningful;types:PascalCase;enums:PascalCase;funcs:camelCase;props:camelCase;no_priv_prefix:true;strings:single_quotes;localize:true;btns:functionality;links:navigation;icons_text:newline;labels:associate;code_style:arrow_funcs,curly_braces,open_braces_same_line,indent_4;memory_leak_prevention:true;routes:naming_schema;chart_framework:ngx-charts;responsive_layout:true

src/main/webapp/app/exercises/shared/unreferenced-feedback/unreferenced-feedback.component.html (1)

Pattern src/main/webapp/**/*.html: @if and @for are new and valid Angular syntax replacing *ngIf and *ngFor. They should always be used over the old style.

src/main/webapp/app/exercises/shared/unreferenced-feedback/unreferenced-feedback.component.ts (1)

Pattern src/main/webapp/**/*.ts: angular_style:https://angular.io/guide/styleguide;methods_in_html:false;lazy_loading:true;code_reuse:true;tests:meaningful;types:PascalCase;enums:PascalCase;funcs:camelCase;props:camelCase;no_priv_prefix:true;strings:single_quotes;localize:true;btns:functionality;links:navigation;icons_text:newline;labels:associate;code_style:arrow_funcs,curly_braces,open_braces_same_line,indent_4;memory_leak_prevention:true;routes:naming_schema;chart_framework:ngx-charts;responsive_layout:true

src/main/webapp/app/exercises/text/assess/text-submission-assessment.component.html (1)

Pattern src/main/webapp/**/*.html: @if and @for are new and valid Angular syntax replacing *ngIf and *ngFor. They should always be used over the old style.

src/main/webapp/app/exercises/text/manage/example-text-submission/example-text-submission.component.html (1)

Pattern src/main/webapp/**/*.html: @if and @for are new and valid Angular syntax replacing *ngIf and *ngFor. They should always be used over the old style.

src/test/javascript/spec/component/assessment-shared/unreferenced-feedback-detail.component.spec.ts (1)

Pattern src/test/javascript/spec/**/*.ts: jest: true; mock: NgMocks; bad_practices: avoid_full_module_import; perf_improvements: mock_irrelevant_deps; service_testing: mock_http_for_logic; no_schema: avoid_NO_ERRORS_SCHEMA; expectation_specificity: true; solutions: {boolean: toBeTrue/False, reference: toBe, existence: toBeNull/NotNull, undefined: toBeUndefined, class_obj: toContainEntries/toEqual, spy_calls: {not_called: not.toHaveBeenCalled, once: toHaveBeenCalledOnce, with_value: toHaveBeenCalledWith|toHaveBeenCalledExactlyOnceWith}}

src/test/javascript/spec/service/feedback/feedback-service.spec.ts (1)

Pattern src/test/javascript/spec/**/*.ts: jest: true; mock: NgMocks; bad_practices: avoid_full_module_import; perf_improvements: mock_irrelevant_deps; service_testing: mock_http_for_logic; no_schema: avoid_NO_ERRORS_SCHEMA; expectation_specificity: true; solutions: {boolean: toBeTrue/False, reference: toBe, existence: toBeNull/NotNull, undefined: toBeUndefined, class_obj: toContainEntries/toEqual, spy_calls: {not_called: not.toHaveBeenCalled, once: toHaveBeenCalledOnce, with_value: toHaveBeenCalledWith|toHaveBeenCalledExactlyOnceWith}}

🔇 Additional comments (32)
src/main/webapp/app/exercises/shared/feedback/feedback.service.ts (2)

3-3: LGTM: Service extension properly implemented

The extension of BaseApiHttpService aligns with the PR objectives to improve HTTP handling for long feedback text responses.

Also applies to: 6-6


20-23: Verify integration with UnreferencedFeedbackDetailComponent

The service is used by UnreferencedFeedbackDetailComponent. Let's verify the integration is properly implemented.

✅ Verification successful

Let me gather more information about the actual integration by checking the implementation of UnreferencedFeedbackDetailComponent and FeedbackTextComponent.


Integration with UnreferencedFeedbackDetailComponent is properly implemented

The verification confirms:

  • UnreferencedFeedbackDetailComponent correctly uses getLongFeedbackText to fetch and update feedback details
  • The service is properly tested with correct endpoint and response handling
  • The integration follows the expected pattern where:
    • The service method is called with required parameters (resultId, feedbackId)
    • The response updates the feedback's detailText
    • Changes are propagated via the onFeedbackChange event emitter
🏁 Scripts executed

The following scripts were executed for the analysis:

Script:

#!/bin/bash
# Search for usage of getLongFeedbackText in components
ast-grep --pattern 'getLongFeedbackText($$$)'

# Search for FeedbackService injection in components
rg -l "FeedbackService" --type ts

Length of output: 816


Script:

#!/bin/bash
# Check implementation of UnreferencedFeedbackDetailComponent
rg -A 10 "getLongFeedbackText" src/main/webapp/app/assessment/unreferenced-feedback-detail/unreferenced-feedback-detail.component.ts

# Check implementation of FeedbackTextComponent
rg -A 10 "getLongFeedbackText" src/main/webapp/app/exercises/shared/feedback/text/feedback-text.component.ts

# Check the test implementation
rg -A 10 "getLongFeedbackText" src/test/javascript/spec/service/feedback/feedback-service.spec.ts

Length of output: 1135

src/test/javascript/spec/service/feedback/feedback-service.spec.ts (2)

1-3: LGTM! Proper setup of Angular testing utilities.

The imports and test setup follow Angular testing best practices by using TestBed and HttpTestingController.

Also applies to: 9-9


35-47: Verify test coverage for all feedback scenarios.

The test covers the basic functionality, but consider adding tests for:

  1. Very long feedback text (edge cases)
  2. Special characters in feedback
  3. Empty feedback handling
src/main/webapp/app/exercises/shared/unreferenced-feedback/unreferenced-feedback.component.html (3)

Line range hint 9-13: LGTM! Proper usage of new Angular syntax.

The conditional rendering using @if follows the new Angular syntax guidelines correctly.


Line range hint 30-43: LGTM! Consistent implementation across feedback types.

The feedback suggestions section maintains consistency with the unreferenced feedback section, properly implementing:

  • New Angular @for syntax
  • resultId binding
  • Track expression for performance optimization

Line range hint 14-29: LGTM! Proper implementation of feedback iteration.

The changes follow best practices:

  • Uses new @for syntax correctly
  • Includes track expression for performance
  • Adds resultId binding which aligns with the PR objective of fixing long feedback display

Let's verify the resultId property is properly defined in the component:

✅ Verification successful

The resultId property is properly defined and used correctly

The component class has the resultId property properly defined as an input property:

@Input() resultId: number;

This matches with the template usage and confirms the property is correctly implemented.

🏁 Scripts executed

The following scripts were executed for the analysis:

Script:

#!/bin/bash
# Description: Verify resultId property in the component class
ast-grep --pattern 'class UnreferencedFeedbackComponent {
  $$$
  resultId: $_ = $_
  $$$
}'

Length of output: 218


Script:

#!/bin/bash
# Let's try a different approach to find the component file and check resultId
fd "unreferenced-feedback.component.ts" --type f --exec cat {}

Length of output: 6057

src/main/webapp/app/assessment/unreferenced-feedback-detail/unreferenced-feedback-detail.component.ts (2)

1-13: LGTM! Imports and component metadata are well-organized.

The imports and component decorator follow Angular style guidelines correctly.


Line range hint 1-85: Verify the integration with manual assessment workflow.

The implementation looks solid for handling long feedback. Let's verify the integration with the manual assessment workflow.

✅ Verification successful

Let me generate additional verification scripts to check the integration with the manual assessment workflow more thoroughly.

This will help us verify:

  1. How the unreferenced-feedback component (parent) handles the resultId
  2. The proper integration between parent and child components
  3. The complete flow of the manual assessment workflow

Based on the verification results, I can now provide the final response:

Integration with manual assessment workflow is properly implemented

The implementation shows correct integration with the manual assessment workflow through:

  • Proper resultId propagation from parent UnreferencedFeedbackComponent to child UnreferencedFeedbackDetailComponent
  • Consistent usage across various assessment templates (text, modeling, file-upload exercises)
  • Correct handling of feedback changes and long feedback loading

The component is used consistently across the application with proper resultId binding, and the implementation aligns with the PR objectives for handling long feedback.

🏁 Scripts executed

The following scripts were executed for the analysis:

Script:

#!/bin/bash
# Description: Verify the component's integration in manual assessment templates
# and ensure proper binding of resultId.

echo "Checking manual assessment templates for component usage..."
rg -l "jhi-unreferenced-feedback-detail" --type html

echo "\nVerifying resultId binding in templates..."
rg "\[resultId\]" --type html -A 2 -B 2

Length of output: 8822


Script:

#!/bin/bash
# Check the unreferenced-feedback component implementation
echo "Checking unreferenced-feedback component implementation..."
cat src/main/webapp/app/exercises/shared/unreferenced-feedback/unreferenced-feedback.component.ts

echo "\nChecking unreferenced-feedback component template..."
cat src/main/webapp/app/exercises/shared/unreferenced-feedback/unreferenced-feedback.component.html

echo "\nChecking for resultId usage in the parent component..."
rg "resultId.*: number" --type typescript -A 2 -B 2 src/main/webapp/app/exercises/shared/unreferenced-feedback/unreferenced-feedback.component.ts

Length of output: 9024

src/test/javascript/spec/component/assessment-shared/unreferenced-feedback-detail.component.spec.ts (2)

18-18: LGTM: Import statement is correctly added.


40-40: Verify mock implementation for long feedback functionality.

While the MockProvider is correctly configured, given that this PR implements long feedback functionality, we should verify if specific methods need to be mocked in the FeedbackService.

Let's check what methods we might need to mock:

✅ Verification successful

Mock implementation is sufficient for the test cases

The current mock implementation using MockProvider(FeedbackService) is adequate because:

  • The component only uses getLongFeedbackText method from FeedbackService
  • The test cases focus on feedback type changes, SGI updates, and deletion events
  • None of the test cases explicitly verify the long feedback loading functionality, which is acceptable as it's an implementation detail
🏁 Scripts executed

The following scripts were executed for the analysis:

Script:

#!/bin/bash
# Search for FeedbackService method calls in the component
ast-grep --pattern 'FeedbackService.$_($$$)'

# Search for long feedback related methods in FeedbackService
rg -t typescript "long.*feedback" --glob "feedback.service.ts"

Length of output: 268


Script:

#!/bin/bash
# Search for FeedbackService method calls in the test file
rg -A 3 "feedbackService" src/test/javascript/spec/component/assessment-shared/unreferenced-feedback-detail.component.spec.ts

# Search for FeedbackService implementation
fd "feedback.service.ts" --exec cat {}

Length of output: 1309


Script:

#!/bin/bash
# Search for component implementation to see how the service is used
fd "unreferenced-feedback-detail.component.ts" --exec cat {}

# Search for test cases in the spec file
cat src/test/javascript/spec/component/assessment-shared/unreferenced-feedback-detail.component.spec.ts

Length of output: 8398

src/main/java/de/tum/cit/aet/artemis/text/service/TextAssessmentService.java (3)

19-19: LGTM: Clean import addition.

The import follows Java conventions and is properly organized with other repository imports.


45-47: LGTM: Clean constructor dependency injection.

The constructor changes properly integrate the new repository:

  • Follows constructor injection pattern
  • Maintains consistent parameter ordering
  • Correctly propagates dependency to superclass

Line range hint 63-94: Verify integration with long feedback handling.

While the constructor changes support long feedback handling, the prepareSubmissionForAssessment method might need enhancement to properly handle long feedback loading, especially when loading existing results.

Let's verify the feedback loading implementation in related services:

src/main/webapp/app/exercises/file-upload/assess/file-upload-assessment.component.html (2)

52-60: LGTM! Proper null checking and new input property added.

The changes correctly implement:

  • Conditional rendering based on result existence
  • New resultId input property for feedback persistence
  • Modern Angular @if syntax as per guidelines

102-110: LGTM! Consistent implementation in assessment template.

The implementation matches the main layout, ensuring consistent behavior across both locations.

Let's verify that this pattern is consistently applied across other assessment components:

✅ Verification successful

Consistent implementation pattern confirmed across assessment components

The implementation is indeed consistent across all assessment components in the codebase. All instances of jhi-unreferenced-feedback follow the same pattern:

  • Conditional rendering with @if (result && result.id)
  • Common props: feedbacks, readOnly, highlightDifferences, resultId
  • Consistent feedback change handling
🏁 Scripts executed

The following scripts were executed for the analysis:

Script:

#!/bin/bash
# Description: Check for consistent implementation of unreferenced-feedback component
# across assessment templates

# Test: Look for similar patterns in other assessment components
rg -l "jhi-unreferenced-feedback" "src/main/webapp/app/exercises" | \
  xargs rg -A 5 "@if.*result.*id.*jhi-unreferenced-feedback"

Length of output: 124


Script:

#!/bin/bash
# Let's try a different approach to find unreferenced-feedback usage patterns
# First, find all files containing the component
rg -l "jhi-unreferenced-feedback" "src/main/webapp/app/exercises"

# Then let's examine the context around each usage
echo "=== Detailed usage patterns ==="
rg -B 2 -A 5 "jhi-unreferenced-feedback" "src/main/webapp/app/exercises"

Length of output: 15096

src/main/webapp/app/exercises/shared/unreferenced-feedback/unreferenced-feedback.component.ts (1)

Line range hint 5-13: Component structure follows Angular best practices.

The component is well-structured with proper separation of concerns, clear event handling, and focused methods.

src/main/webapp/app/exercises/programming/assess/code-editor-tutor-assessment-container.component.html (2)

Line range hint 1-1: Great job using the new Angular control flow syntax!

The template consistently uses the new @if syntax instead of the older *ngIf, which aligns with the current coding guidelines.

Also applies to: 4-4, 13-13, 18-18, 67-67, 134-134, 141-141, 166-166


141-152: Feedback component changes look good and align with PR objectives.

The conditional rendering of jhi-unreferenced-feedback now properly checks for both manualResult and manualResult.id, ensuring the component only renders when there's a valid result. The addition of [resultId]="manualResult.id" enables proper loading of long feedback text.

This change directly addresses the issue of long feedback not being displayed by:

  1. Ensuring the feedback component only renders with a valid result ID
  2. Providing the result ID needed to fetch the complete feedback text
src/main/webapp/app/course/learning-paths/services/base-api-http.service.ts (2)

13-13: LGTM! Documentation improvement.

The rewording makes the documentation more consistent with typical JSDoc style.


55-55: LGTM! Enhanced response handling.

The changes improve the service's ability to handle text responses while simplifying the response handling logic. This aligns well with the PR's objective of fixing long feedback display issues.

Let's verify that all services extending BaseApiHttpService handle the response type changes correctly:

Also applies to: 60-63, 66-66

✅ Verification successful

Response type changes are correctly handled across the codebase

The verification confirms that:

  • All services extending BaseApiHttpService handle the response type changes correctly
  • The responseType: 'text' is used appropriately in FeedbackService.getLongFeedbackText() which is the primary use case for this change
  • Other services extending BaseApiHttpService (LearningPathApiService, FeedbackAnalysisService, CourseCompetencyApiService) use the default 'json' response type, which is compatible with the changes

The changes to the base service are safe and well-integrated across the codebase.

🏁 Scripts executed

The following scripts were executed for the analysis:

Script:

#!/bin/bash
# Search for classes extending BaseApiHttpService to ensure they handle both response types
ast-grep --pattern 'class $_ extends BaseApiHttpService {
  $$$
}'

# Search for explicit responseType usage to ensure compatibility
rg "responseType: ['|\"]text['|\"]" 

Length of output: 24234

src/main/webapp/app/exercises/modeling/assess/modeling-assessment-editor/modeling-assessment-editor.component.html (2)

67-78: Well-structured implementation with proper conditional rendering!

The changes follow best practices by:

  • Using the new @if syntax as per guidelines
  • Adding proper null checks for result and result.id
  • Including the resultId input property for better feedback handling

67-78: Verify handling of long feedback in UnreferencedFeedbackComponent.

While the template changes look good, let's verify the actual handling of long feedback in the component.

Also applies to: 150-158

✅ Verification successful

Let me generate additional scripts to check the UnreferencedFeedbackComponent implementation specifically:

This will help us verify how the component actually handles feedback display and if there are any length-related constraints.


Let me check one more aspect - the feedback collapse component since it appears to handle the actual feedback display:

This will help us understand how feedback text is actually handled and if there are any length limitations in place.


Long feedback is properly handled with collapsible display

The codebase has robust handling for long feedback through the FeedbackCollapseComponent which:

  • Automatically collapses feedback longer than 300 characters
  • Provides expand/collapse functionality for viewing full content
  • Handles multi-line feedback appropriately

The changes in the template are safe and work well with the existing feedback display system.

🏁 Scripts executed

The following scripts were executed for the analysis:

Script:

#!/bin/bash
# Description: Check UnreferencedFeedbackComponent implementation for long feedback handling

# Look for the component implementation
echo "Searching for UnreferencedFeedbackComponent implementation..."
rg -l "UnreferencedFeedbackComponent" --type ts

# Check for any length limitations or truncation in the component
echo "Checking for potential text truncation..."
rg -i "truncate|maxLength|substring|slice" --type ts

Length of output: 51452


Script:

#!/bin/bash
# Check UnreferencedFeedbackComponent implementation and its feedback handling
echo "Checking UnreferencedFeedbackComponent implementation..."
rg -A 10 "export class UnreferencedFeedbackComponent" --type ts

echo "Checking feedback-related templates and components..."
rg -A 5 "class=\"feedback" src/main/webapp/app/exercises/shared/unreferenced-feedback/unreferenced-feedback.component.html || true

Length of output: 1847


Script:

#!/bin/bash
# Check feedback collapse component implementation
echo "Checking FeedbackCollapseComponent implementation..."
rg -A 15 "export class FeedbackCollapseComponent" --type ts

echo "Checking feedback collapse template..."
rg -A 10 "feedback-collapse" --type html

# Check for any feedback display constants
echo "Checking for feedback-related constants..."
rg "FEEDBACK_.*_LIMIT|FEEDBACK_.*_LENGTH" --type ts

Length of output: 6732

src/main/webapp/app/exercises/text/manage/example-text-submission/example-text-submission.component.html (1)

162-170: LGTM! The changes align with PR objectives and coding guidelines.

The conditional rendering of <jhi-unreferenced-feedback> with result.id check helps prevent potential issues with undefined feedback references, which aligns with fixing the long feedback display issues. The code also correctly uses the new @if syntax as per guidelines.

Let's verify the component's usage across other assessment templates:

✅ Verification successful

Consistent usage of jhi-unreferenced-feedback with proper result.id checks verified across all templates

The verification shows that all assessment templates consistently implement the same pattern:

  • All instances of <jhi-unreferenced-feedback> are wrapped in @if (result && result.id) checks
  • This pattern is uniformly applied across different exercise types (text, programming, modeling, file-upload)
  • The component usage follows the same structure with similar input bindings
🏁 Scripts executed

The following scripts were executed for the analysis:

Script:

#!/bin/bash
# Description: Check for consistent usage of jhi-unreferenced-feedback across assessment templates
# Expected: Similar conditional rendering with result.id check

# Search for jhi-unreferenced-feedback usage in assessment templates
rg -g '*.html' -B 2 -A 2 '<jhi-unreferenced-feedback'

Length of output: 8110

src/main/java/de/tum/cit/aet/artemis/programming/service/ProgrammingAssessmentService.java (3)

6-6: LGTM: Import changes are clean and follow guidelines.

The new imports are properly organized and avoid wildcards as per coding guidelines.

Also applies to: 20-20


53-56: LGTM: Constructor changes follow dependency injection best practices.

The constructor properly implements constructor injection and correctly delegates to the superclass.


94-97: Verify complete feedback persistence flow.

Let's ensure the feedback persistence changes are properly integrated across the system.

✅ Verification successful

Based on the shell script results, I can now generate the final response as there is sufficient evidence to verify the feedback persistence flow.

Feedback persistence flow is properly integrated

The changes are correctly integrated within the system's feedback persistence flow:

  • deleteLongFeedback is consistently used across services before updating feedback items
  • updateAllFeedbackItems is properly implemented in Result domain and used by all assessment services
  • Test coverage confirms proper handling of long feedback texts and manual assessments
🏁 Scripts executed

The following scripts were executed for the analysis:

Script:

#!/bin/bash
# Description: Verify the complete feedback persistence flow

# Check for other services using LongFeedbackTextRepository
echo "Checking for other services using LongFeedbackTextRepository..."
rg "LongFeedbackTextRepository" --type java

# Check for related feedback persistence methods
echo "Checking for related feedback persistence methods..."
rg "deleteLongFeedback|updateAllFeedbackItems" --type java -A 5

# Look for potential feedback-related tests
echo "Checking for related test coverage..."
fd -e java -e kt --full-path ".*[Tt]est.*" | xargs rg "LongFeedbackText|ManualAssessment"

Length of output: 19395

src/main/webapp/app/exercises/modeling/manage/example-modeling/example-modeling-submission.component.html (2)

Line range hint 1-1: LGTM: Consistent usage of new Angular control flow syntax.

The template correctly uses the new @if and @for syntax throughout, following the coding guidelines to prefer these over the older *ngIf and *ngFor directives.

Also applies to: 37-37, 42-42, 51-51, 67-67, 77-77, 89-89, 102-102, 111-111, 134-134, 141-141, 149-149, 156-156, 166-166, 186-186, 194-194


186-194: LGTM: Improved feedback component rendering logic.

The changes enhance the feedback display by:

  1. Adding proper validation to ensure the component only renders with a valid result ID
  2. Providing the result ID to the feedback component for proper association

This aligns well with the PR's objective of fixing long feedback display issues.

src/main/java/de/tum/cit/aet/artemis/assessment/service/AssessmentService.java (2)

20-20: LGTM: Dependency injection follows best practices.

The addition of LongFeedbackTextRepository follows the constructor injection pattern and maintains immutability with the final modifier.

Also applies to: 71-72, 76-76, 90-90


290-292: Consider adding error handling and transaction management.

While the deletion of long feedback before saving prevents duplicate entries, there are a few concerns:

  1. The operation lacks explicit error handling for the deleteLongFeedback call
  2. Multiple database operations (delete + save) should be wrapped in a transaction to maintain data consistency

Let's verify the transaction management in the codebase:

Consider these improvements:

  1. Add error handling for the deleteLongFeedback operation
  2. Ensure proper transaction boundaries, either through:
    • Adding @Transactional annotation to the method
    • Explicitly handling transactions in the service layer
src/main/java/de/tum/cit/aet/artemis/assessment/service/ResultService.java (1)

633-653: Use Batch Deletion for Efficiency in deleteLongFeedback

To improve performance when deleting multiple LongFeedbackText entities, consider using batch deletion provided by the repository.

[performance]

Modify the method to collect all IDs and perform a bulk delete:

List<Long> feedbackIds = feedbackList.stream()
    .filter(feedback -> feedback.getHasLongFeedbackText() && feedback.getId() != null)
    .map(Feedback::getId)
    .toList();

longFeedbackTextRepository.deleteByFeedbackIds(feedbackIds);

Ensure that deleteByFeedbackIds is implemented in LongFeedbackTextRepository using a suitable query for batch deletion.

@az108 az108 temporarily deployed to artemis-test5.artemis.cit.tum.de October 24, 2024 21:02 — with GitHub Actions Inactive
Copy link
Contributor

@JohannesStoehr JohannesStoehr left a comment

Choose a reason for hiding this comment

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

Code

Copy link
Contributor

@florian-glombik florian-glombik left a comment

Choose a reason for hiding this comment

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

Re-approve code after merging develop

Copy link

@sachmii sachmii left a comment

Choose a reason for hiding this comment

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

Re-approve

Copy link

@Malekos74 Malekos74 left a comment

Choose a reason for hiding this comment

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

Merge conflict reapprove

Copy link
Contributor

@dmytropolityka dmytropolityka left a comment

Choose a reason for hiding this comment

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

code

Copy link

@SindiBuklaji SindiBuklaji left a comment

Choose a reason for hiding this comment

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

Tested on TS5. Works as described 👍

@az108 az108 added this to the 7.6.5 milestone Nov 1, 2024
@krusche krusche changed the title Programming exercises: Fix Long Manual Feedback not beeing displayed Programming exercises: Fix an issue in which long manual feedback is not correctly displayed Nov 2, 2024
@krusche krusche merged commit ae9299d into develop Nov 2, 2024
50 of 62 checks passed
@krusche krusche deleted the bugfix/long-feedback-not-beeing-displayed branch November 2, 2024 06:44
@coderabbitai coderabbitai bot mentioned this pull request Nov 27, 2024
25 tasks
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
assessment Pull requests that affect the corresponding module bugfix client Pull requests that update TypeScript code. (Added Automatically!) programming Pull requests that affect the corresponding module ready to merge server Pull requests that update Java code. (Added Automatically!) tests text Pull requests that affect the corresponding module
Projects
Archived in project
Status: Done
Development

Successfully merging this pull request may close these issues.

General manual feedback not fully shown in feedback view