test-coverage
5 Commits
| Author | SHA1 | Message | Date | |
|---|---|---|---|---|
| 1554d4bc27 |
Enforce code formatting via Prettier (#44)
All checks were successful
Build and test / build-and-test (push) Successful in 11m55s
Fixes #43 by introducing [Prettier](https://prettier.io/). Prettier is an extremely opinionated formatter. It will reformat every single line according to its style. There are virtually no configuration options so there can be no discussion about formatting rules. There are two parameters that are configurable; indent length and line length. Indent length has been set to 4 because that's the Java standard. Line length defaults to 80 but has been increased to 100. The rational for this is that Prettier was created for JavaScript which is much less verbose than Java. Not only does every Java line start with 8 spaces of indentation vs. JavaScripts 0 or 2, it also has types wile JavaScript does not and uses `const` for variable declarations. Compare the two below examples as well as an actual example from the source code that is too long for the default 80 characters. I have no problem dropping down to the default 80 if that is preferred I just felt that with the average length of a line of Java code being pretty long, excessive wrapping would reduce readability. ```javascript const attributes = { ... }; ``` ```java Map<String, String> attributes = Map.of( ... ); ``` Or the following real code which is 97 characters long. ```java Set<ProjectParticipant> contributors = daisyAPI.getContributors(project.getIdentifier()); ``` Reviewed-on: #44 Reviewed-by: Tom Zhao <tom.zhao@dsv.su.se> Co-authored-by: Andreas Svanberg <andreass@dsv.su.se> Co-committed-by: Andreas Svanberg <andreass@dsv.su.se> |
|||
| a2330ce2d5 |
Squash and fix migrations so they run against an empty schema (#24)
All checks were successful
Build and test / build-and-test (push) Successful in 6m51s
This is one requirement in bringing #15 to reality. Currently there are some 450 migration scripts that have been added over the past 11 years. Unfortunately some of these migration scripts have some defects. Either from the fact that they are very old and from another database engine (MySQL vs currently MariaDB), make assumptions about the database name, or its contents. Due to these defects trying to bring an empty schema up-to-date by running all migrations will fail with [372]( |
|||
| ff4c5b58b4 |
Allow changes to the reflection to be made after it's been submitted (#13)
All checks were successful
Build and test / build-and-test (push) Successful in 7m5s
Replaces #12 Fixes card 3213 and 3412 There are minimum requirements for the reflection document submitted by authors at the end of the thesis process. Before now there was no way to handle the case when the reflection did not meet these minimum requirements. This change makes it possible in two ways; 1. The supervisor can request improvements to be made requiring the author to re-submit a new reflection inside SciPro 2. The supervisor can directly edit the reflection themselves if it has been submitted out-of-band or for any other reason Co-authored-by: Nico Athanassiadis <nico@dsv.su.se> Reviewed-on: #13 Reviewed-by: Nico Athanassiadis <nico@dsv.su.se> |
|||
| a9b8542576 |
Fix users getting stuck at a blank white page after logging in. (#16)
All checks were successful
Build and test / build-and-test (push) Successful in 6m41s
By default, Tomcat will use a cookie to track the session. However, if there is no cookie sent by the browser it will append the session id to the URL. The way it does this is by adding a ";jsessionid=..." to the end. This is not a problem in itself, but it can enable session hijacking if the URL is shared and ";" is a blocked character by the default Spring Security configuration (see StrictHttpFirewall).
So what happens is a user navigates to SciPro. No session cookie is sent since this is the first request. SciPro sees that the user is not authenticated and redirects the user to the login page. When SciPro checks for authentication it checks the session which will instruct Tomcat to create a session. Since Tomcat sees no cookie it will append the session id to the redirect URL to try and track the session. After the user has logged in they are redirected back to SciPro with the session id in the URL which is then blocked by Spring's StrictHttpFirewall.
To avoid this, we can set the tracking mode to *only* COOKIE.
An alternative solution is to tell Spring to allow ";" in the URL but there seems to be good reason as to why it is blocked, see the Javadoc linked below.
|
|||
| ccac2c1cf8 |
Enable creating an API using Spring Web (#5)
All checks were successful
Build and test / build-and-test (push) Successful in 6m54s
SciPro will have to provide information to the upcoming student portal. Wicket does not have the ability to serve JSON in the usual REST way and is only able to serve HTML. The most common way to write JSON over HTTP API:s in Java is using Spring Web, but currently SciPro uses Guice for dependency injection rather than Spring which makes adding Spring Web a bit more tricky. This pull request attempts to solve this by doing the following; * Replacing Guice with Spring * Adding a new API module that uses Spring Web * Turning the entire system into a standard Spring Boot web application The hope is that these changes will bring the following benefits; * Harmonize our web stack (Daisy uses Spring and the new lecture hall system is full Spring Boot) * Enable easy development of a traditional JSON over HTTP API * Ease future recruitment by using the most common Java web frameworks Reviewed-on: #5 Reviewed-by: niat8586 <nico@dsv.su.se> Co-authored-by: Andreas Svanberg <andreass@dsv.su.se> Co-committed-by: Andreas Svanberg <andreass@dsv.su.se> |
