Feature/allow single submissions and path names

[euberdeveloper]

This pull request add minor updates described in the last comment of #1852. It fixed #1848 and #1849

[Kr0nox]

As mentioned on the last PR, since you are changing/adding features on how submissions can be given to Jplag, please add an e2e case for each of them.

Here are references on where they are implemented currently:
develop/report-viewer/tests/e2e/OpenComparisonTest.spec.ts
develop/.github/workflows/complete-e2e.yml

Please add one for every Problem solved by this PR

[euberdeveloper]

Ok, the tests I did so far weren't in the e2e, I'll add some

[euberdeveloper]

The functioning of the e2e tests seems to be more complicated than the normal Java tests.
If I've understook correctly, for each featur I should:

1. Add a zip dataset to .github/workflows/files
2. During the action, java -jar jplag.jar ${{ matrix.dataset.folder }} -l ${{ matrix.dataset.language }} -r ${{ matrix.dataset.name }}-report ${{ matrix.dataset.cliArgs }} will execute it
3. The report result will be added to an artifact
4. I should add here an object with the expected first two submission names that will be compared
5. The e2e tests of Vue will do the rest

Is it correct?

[sonarqubecloud]

Quality Gate passed for 'JPlag Plagiarism Detector'

Issues
0 New issues
0 Accepted issues

Measures
0 Security Hotspots
0.0% Coverage on New Code
0.0% Duplication on New Code

See analysis details on SonarCloud

[euberdeveloper]

In this check, the error is Set the SONAR_TOKEN env variable.. Is it something that should be done on your side? @Kr0nox @tsaglam

Otherwise all checks seem to have passed!

[tsaglam]

I finally found some time to take a look at the PR. Understanding what was part of this PR and what was not was a bit tricky due to the lack of a PR description.

If I understand correctly, this PR currently contains two changes:

• Fix an issue where single-submission root directory + single-submission old directory was not accepted
• Fix the issue with multiple root folders that have the same name by using the shortest uncommon path

We discussed these features internally. The first one is excellent; we would like to include it. We currently do not want to support the second one, as including super directories in the root names exposes them in the report zip. This means a user could expose information about their system via a report that might not be intended.

Sorry for giving you this feedback so late.

[euberdeveloper]

Ok, so should I divide the pull request in two pull requests?

[euberdeveloper]

Also for the second feature, we could make it that it stops until the current dir where it is executed JPlag CLI or something similar so that it doesn't give further than needed

[tsaglam]

Ok, so should I divide the pull request in two pull requests?

Yes, the first feature should be its own PR.

Also for the second feature, we could make it that it stops until the current dir where it is executed JPlag CLI or something similar so that it doesn't give further than needed

I will take that idea into our internal discussions.

[euberdeveloper]

Ok, then:

1. I will close this PR and make a new PR only with the accepted feature
2. I will open another PR with the unaccepted one, in which in case some changes could be proposed
   • e.g. stopping at cwd or something similar when proceeding to the parents
   • e.g. adding a flag "unsafe" or "reveal paths" and only if active the feature will act

I think with a specific flag to enable the feature the security issue is solved, because one that wants to use it must explicitly specify that the behaviour is wanted

[tsaglam]

Closed, as discussed above.