Currently there is only one class used to add test data; [`DataInitializer`](b9f7dd5a49/core/src/main/java/se/su/dsv/scipro/DataInitializer.java). That class is already very large and causes a lot of merge conflicts when multiple changes are in the pipeline as noted by #109.
This change makes it possible to have multiple classes adding test data so that each change adds its own class and thus there are no conflicts. It also has the benefit of making each class smaller and more self-contained for testing a specific feature.
Some additional infrastructure was added in the form of the `BaseData` and `Factory` (naming improvements notwithstanding) interfaces to help each class add its own test data and re-use common data.
Finally all test data related classes have been moved to their own module so they can be properly excluded when building for production but are included by default while developing.
Fixes#109
## Future work
* Add a mechanism to work with date and time.
Many processes (and therefore service method implementations) rely on the time between certain events. For example a final seminar must be scheduled a set amount of days in advance. In the ideal world, the test data is populated using these service methods to more accurately represent an achievable real world state. Therefore there must be a way to manipulate time when adding test data.
* Add more methods to the `Factory` interface as we discover more common steps that many populators must take.
* Add more base data available through the `BaseData` interface as we discover more common data that many populators need
Care must be taken that this data is final and useful in its base state since populators will rely on that state.
Co-authored-by: Nico Athanassiadis <nico@dsv.su.se>
Reviewed-on: #112
Reviewed-by: Nico Athanassiadis <nico@dsv.su.se>
Co-authored-by: Andreas Svanberg <andreass@dsv.su.se>
Co-committed-by: Andreas Svanberg <andreass@dsv.su.se>
Click link and see that system is working. Log in using the principal `admin@example.com`. Change something in the deployed system. Re-run the action. See that the database has reset.
**Major change** Added OAuth 2 login so no longer need modified web.xml with filter. Run `docker compose up` to start the local OAuth 2 authorization server to log in. Use the custom ticket form and enter the username you want to log in as in the "Principal" field.
Squashed all migrations since there are faulty ones that can't be applied to an empty database.
Reviewed-on: #15
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>
This is one requirement in bringing #15 to reality.
Currently the way to log in to SciPro is by having a locally modified `web.xml` that emulates being authenticated via single sign-on (SSO). This method can not work on an automatically deployed test server. It is also not possible to have real SSO configured for the test servers due to their dynamic nature and that they are given a new hostname each time. Our current SSO solution requires there to be certificate issued to specific hostnames. Even if it were possible to get SSO set up how would the username received from SSO match to test data? We would have to have real usernames in our test data which is not desirable.
To solve both of the problems described above - requiring a locally modified version of a git tracked file and needing an authentication mechanism that works for dynamic test servers - a change of the authentication mechanism from Tomcat controlled SSO to application controlled OAuth 2 is proposed. There is already an OAuth 2 authorization server running in production which itself is authenticates users via SSO that will be used in production and for the permanent test servers. In development and for the dynamic test servers a local authorization server running in Docker is provided.
For "regular" users there will be no noticeable change, they will be prompted to log in via SSO and then they get access to the system. For users with high developer access they will, on the permanent test servers, be prompted to "issue token". On that page they can use the top form to authenticate as themselves based on their SSO authentication, or use the bottom form to issue a completely custom authentication and log in as whatever username they deem necessary. The temporary test servers and during local development will work similarly with the only difference being that there is no SSO log in first and you will be prompted to issue a token immediately. The default authentication (top form) will be a local sys-admin level user.
## How to test
1. Start the local OAuth 2 authorization server with `docker compose up`
2. Start SciPro
3. Attempt to log in
Co-authored-by: Nico Athanassiadis <nico@dsv.su.se>
Reviewed-on: #27
Reviewed-by: Nico Athanassiadis <nico@dsv.su.se>
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>
