Is your feature request related to a problem? Please describe.
There is no solution for deployment of this tool.

Describe the solution you'd like
Adding a deploy script (e.g. Deployer) that allows user to specify their hostname and everything else gets handled automagically.

Describe alternatives you've considered
-/-

Additional context
It seems that Deployer needs to be added as phar because of an inconsistency with composer dependencies.

There seems to be an issue with the ItemCount of the Imports and the amount of Allocations that the platform is showing to the users in the frontend. To be able to further analyze this issue there is a need for a new Filter that is only listing all Allocations from one given Import.

The project needs some console commands for the future:

• Install/ Init command
• Add User command that allows to instantly promote to admin.
• Add Areas command
• Add Hospital command
• Clear Imports command (remove files related to Import)
• Re-Import command (delete corresponding Allocations and process them again)
• Watchdog command (process all Allocations as a batch, search for and fix errors)

Is your feature request related to a problem? Please describe.
It has been announced that the indication codes of IVENA are going to change to reach an interoperability between the different instances of the system. Therefore it is neccessary to find a solution for this.

Describe the solution you'd like
One possible solution would be to add a ValueObject to the database that could handle the change in the future?

Describe alternatives you've considered
Add a script that automatically transforms the current indication codes to the new ones, as soon as they have been released. But this change would be needed in the Import too.

Additional context
A solution would even be needed if this change is not going to happen because currentle the data from other states has incompatible indication codes to the ones from Hessen.

Describe the bug
When filtering allocations by import the filter gets lost as soon as any other filters of the page are applied (e.g. sorting, or any other filter from the AllocationFilterSet).

To Reproduce

1. Go to any 'Import'
2. Click on 'Filter by this Import'
3. On the filtered Page click on any other 'Filter' and apply it.
4. See that the import filter is now missing.

Expected behavior
The import filter should be preserved.

Is your feature request related to a problem? Please describe.
A special Page including the help/FAQ section is currently missing and therefore should be added.

Describe the solution you'd like
There should be another "special" page that presents it's content (maybe just some headings like the h2) as accordion with anchors that provide some kind of help.

Describe alternatives you've considered
However this page is designed it will be necessary to include a "On this page" section with a scrollspy for the overview.

Users who do not have the Role Role_User can not access the Allocation Index view because of the following error:

Uncaught PHP Exception Doctrine\ORM\Query\QueryException: "[Semantical Error] line 0, col 89 near 'hospital WHERE': Error: 'hospital' is already defined." at /app/vendor/doctrine/orm/lib/Doctrine/ORM/Query/QueryException.php line 47

There has been a new release of deployer, see: https://github.com/deployphp/deployer/releases

$ /var/www/html/cois/node_modules/.bin/encore dev
Running webpack ...

node:internal/crypto/hash:67
  this[kHandle] = new _Hash(algorithm, xofLen);
                  ^

Error: error:0308010C:digital envelope routines::unsupported
    at new Hash (node:internal/crypto/hash:67:19)
    at Object.createHash (node:crypto:130:10)
    at BulkUpdateDecorator.hashFactory (/var/www/html/cois/node_modules/webpack/lib/util/createHash.js:145:18)
    at BulkUpdateDecorator.update (/var/www/html/cois/node_modules/webpack/lib/util/createHash.js:46:50)
    at OriginalSource.updateHash (/var/www/html/cois/node_modules/webpack/node_modules/webpack-sources/lib/OriginalSource.js:104:8)
    at NormalModule._initBuildHash (/var/www/html/cois/node_modules/webpack/lib/NormalModule.js:870:17)
    at handleParseResult (/var/www/html/cois/node_modules/webpack/lib/NormalModule.js:936:10)
    at /var/www/html/cois/node_modules/webpack/lib/NormalModule.js:1028:4
    at processResult (/var/www/html/cois/node_modules/webpack/lib/NormalModule.js:745:11)
    at /var/www/html/cois/node_modules/webpack/lib/NormalModule.js:809:5 {
  opensslErrorStack: [ 'error:03000086:digital envelope routines::initialization error' ],
  library: 'digital envelope routines',
  reason: 'unsupported',
  code: 'ERR_OSSL_EVP_UNSUPPORTED'
}

Node.js v17.0.1
error Command failed with exit code 1.
info Visit https://yarnpkg.com/en/docs/cli/run for documentation about this command.
Script yarn encore dev handling the setup-frontend event returned with error code 1
Script @setup-frontend was called via setup

Any Ideas how i can fix that?

Is your feature request related to a problem? Please describe.
The current implementation of the Pages and the whole Website stuff is kind of messy, so this really should be changed!

Describe the solution you'd like
First there should be a real "HomepageController" that connects the different parts (e.g. the upcoming blog, the pages, etc.) with the help of Netgen layouts to be more flexible. Also the special Pages should be moved to separate controllers to apply special templates to them too (e.g. link to the user profiles of the board members on the terms, or include the cookie consent in a better way). And last but not least a special FAQ/ Help page should be considered.

ToDo List

• Add HomePage Controller to link up the different parts
• Move special Pages to own Controllers (Terms, Imprint, Privacy& Contact)
• #1346
• Move the visibility of a Page to a new field on the entity to separate it form the special pages.
• Add custom Pages to the "main menu" in the top or to a "sidebar menu" on all pages? Don't know what's better...
• #725

The Allocation list/ table needs filters that allow users to "play around" with the data.

Allow to filter Allocations by:

• Supply/ Dispatch Area
• Hospital
• CreatedAt date
• SK/ RMI
• Properties
• Age
• Gender

Additionally there is a need to:

• Sort allocations by all the filtered fields (excluding properties)

Github Actions are going to deprecate the current way we cache the dependencies from composer and yarn, so we need to update to v3 of the cache action.

See: https://github.blog/changelog/2022-10-11-github-actions-deprecating-save-state-and-set-output-commands/ and https://github.com/actions/cache/blob/main/examples.md#php---composer

Is your feature request related to a problem? Please describe.
As more and more data gets imported into the current alpha-test environment there has been a huge negative impact on the overall performance of the platform. This in part is a problem of the design of the Allocation entity, which is to huge and includes to many fields that should better be entities on their own e.g. the indication codes.

Describe the solution you'd like
Move fields that should better be an entity on their own to new entities and link them to the Allocation entitiy. Other then that it seems reasonable to create a AllocationListQuery that returns an AllocationListDto only including fields nescessary of the list view of the allocations.

Describe alternatives you've considered
I guess there is none...

Additional context
Entities that should exist on their own might be:

• Indication (code)
• Occasion
• Assignment
• Speciality / Speciality Detail
• Infections

Is your feature request related to a problem? Please describe.
Currently there is a huge inconsistency regarding changes in the application, because only some of the entities track who changed what. This should be improved for the future!

Describe the solution you'd like
The application needs at least an Audit log for the doctrine DBAL that can be accessed by the administrators in the backend. This feature could also be used to generate something like "recent actions" for users in their profile.

Describe alternatives you've considered
There are no alternatives.

Additional context
This is only used for documentation of the changes it's not the idea to switch to some kind of Event Sourcing.

There should be translations of everything available as the title of this issue says.

• Translations via Twig/ Symfony
• Translations for Vue.js with vue-i18n

Basically just what the caption says, the platform needs a GDPR cookie popup. Probably the best way would be to use one of the bundles available for this task.

Is your feature request related to a problem? Please describe.
Currently the allocations are missing any information on the dispatch area that was the origin on the allocation. But this could be an important information for any hospitals that are reciving (large numbers of) patients from other dispatch areas.

Describe the solution you'd like
Add a new field that is collecting the corresponding dispatch areas that were the origin ot the allocation.

Describe alternatives you've considered
Also one could add a new table that only collects this information for any given allocation.

Additional context
See above.

Describe the bug
When downloading the exported allocations from the database the file seems to be broken in Excel. Numbers is perfectly able to read the file and match captions and rows. But in Excel every row is just written in one column which makes it unusable.

To Reproduce
Steps to reproduce the behavior:

1. Go to 'Export'
2. Select Data and Click on 'Download'
3. Open .csv file with Excel
4. See error (whole rows are written in one column)

Expected behavior
Excel should separate the data into the different rows.

There should be links to connect all entities for a better user experience.

• Add a User profile page
• Add links from Imports to Users and Hospitals
• Add links from Allocations to Imports, Users and Hospitals
• Add links from Hospitals to Users

Is your feature request related to a problem? Please describe.
Currently the users can only view and filter the Allocations which is just a tiny bit of data. It should be moved to a new "Data" section that also contains Hospitals, Areas, Indication Codes, Infections, etc. with their respective informations. This would make much more sense...

Describe the solution you'd like
A new section of the application is to be created with a sidebar (on the left?) that lists all the different data types that are available. At first this would just be the Hospitals, Areas and Allocations. As more and more parts of the Allocations get moved into their own objects (see #1057) they also get added here. All of this features should be moved to a general implementation of a special DataTable with the usual filters (see what currently can be done with Allocations).

To-Do List:

• Create new "Data" section
• Move Hospitals to new "Data" section
• Move Areas to "Data" section (see old admin backend)
• Move Allocations to "Data" section
• Add new ValueObjects as they are created...

Is your feature request related to a problem? Please describe.
This Tool should really be added to monitor the complexity and other potential problems with mess around the code.

Due to several reasons there is also a need for static pages for Content like an imprint or a faq. It would possibly be enough to use Markdown for the markup.

Related to the static Pages there should be a Link to the terms of usage that every User needs to accept.

Describe the bug
Since the #1055 the code coverage cannot be submitted anymore. The log includes the following error message:

Submitting to https://coveralls.io/api/v1/jobs
Client error occurred. status: 405 Method Not Allowed

<title>405 Not Allowed</title>

405 Not Allowed

---

nginx elapsed time: 0.876 sec memory: 8.00 MB Error: Process completed with exit code 1.

Expected behavior
Code Coverage gets submitted to Coveralls

There needs to be the possibility to export some (or all?) data from the system.

• Add a export feature for the Allocations that allows users to get data matching to the via api available filters, but maybe there should be "easier" filters for the start like a "Export by month" or a "Export by Supply/ Dispatch Area" feature for the start.
• Exports should be performed to CSV (and in the future Excel)
• All exports are getting stored in the /var/storage directory for a later download request with the same parameters and get pruned when new data is uploaded.

The current way of error handling while populating entities in ImportWriters is insufficient.

This should be the new way:

1. Rows get validated by each ImportWriter before attempting to write
2. Entities get populated by the ImportWriter
3. Entities get passed to the next ImportWriter and finally to the entity manager.

If any error is happening the import gets a new property counting the skipped rows and if these surpass a certain limit the import gets an "incomplete" or even the "failed" status. All of these errors are saved into the database including the Exception and the actual row as json to be reviewed in the frontend.

Is your feature request related to a problem? Please describe.
The current solution for the Import is really complex and more complex than it needs to be with the ImportService, the ImportWriters and the ImportReaders... This needs to be more easy and understandable for potential users and participants.

Describe the solution you'd like
At first there should be a ImportFactory that orchestrates how the Import is going to happen, at the moment a single AllocationImportFactory is enough. This factory manages the workflow via middlewares that the Factory controls and that accepts settings from the Factory.

The first middleware fetches the data and stores it as iterable associative array. It then passes the data along and the following middlewares create an entity, manipulate& validate it and finally sends the entity to the EntityManager to be flushed as batch. Errors that occur during this process result in a SkippedRow that gets also saved in the database for later review.

Required steps

1. Fetch data from CSV
2. Create Entity (Allocation or something else like MANV?) and add basic data like times& hospital
3. FieldParser for boolean parameters
4. Connect ValueObjects (needs one Middleware per ValueObject)
5. Pass Entity to EntityManager and flush every X row

Somehow I've missed to add translations to the new Filters. 😭

Now the following things have to be done:

• Add general Translations for Filters (e.g. "All Xyz")
• Re-Name the "Filter Hospitals" button for Allocations in Front- und Backend.

There are several dependencies in composer and yarn that are no longer used and be removed.

Examples:

• ChartJs

There should be a "public" homepage to welcome users who are not logged in to explain what this site is all about and where they can get into touch with us. Also the dashboard needs to be improved:

• The statistics need to be more detailed, with Users, Hospitals, Imports und Allocations related to the hospital of the current user (if user is related to a hospital) and their proportion of all data.
• The changelog should be moved to a separate section that keeps track of all users who already saw the changes. Or maybe some kind of small blog?
• Add a public homepage

The current solution is bad because the messages are explicit in the code and some of symfonys Translators features are not used like dynamic replacements or plurals.

Is your feature request related to a problem? Please describe.
As the project as it self needs more publicity it seems neccssary to have a own blog implementation to post stuff right "on site".

Describe the solution you'd like
Creating a Blog section that includes Posts, Categories, Tags and Comments (including admin review) and a RSS feed for the entires. Also there should be a twig partial that can be included in netgen layouts to be displayed on the Homepage.

Additional context

• Add BlogController to display a list of all Posts (with endless scrolling) and filtering by Categories or Tags
• Add PostController to display a single Post with corresponding Comments
• Allow Admins to review Comments to prevent spam (once a user gets approved every new comment is allowed)
• Add FeedController to create a RSS feed of the Posts

To provide more useful statistics the frontend should provide the possibility to filter the data.

The following basic filters should be available:

• Filter by Hospital (as usual only the ones a user is assigned to or owner of)
• Filter by Time: Year, Quarter, Month

Is your feature request related to a problem? Please describe.
Currently the secondary indications (and their codes) seem to get imported into the database, but there are no filters to search allocations with a specific secondary indication.

Describe the solution you'd like
Add a filter for secondary indications (and possibile one "without secondary indication") and check that the secondary indication is correctly recorded.

Describe alternatives you've considered
-/-

Additional context
No additional context.

The current way how the Paginator calculates the Pages has one fatal flaw:

If the the ::Per_Page attribute is 20 and the item count is 50 it calculates only 2 instead of 3 pages.

Therefore there needs to be a new edgecase in the calculation that includes cases where the ItemCount is exactly half of the ::Per_Page attribute and an even number.

To have a "cleaner" and more informative dashboard there needs to be some kind of "heatmap" for the Imports/Allocations so that Users an see if there are any missing days/weeks/months in their data.

Like the descriptions says... There should be a basic "benchmarking" that allows to aggregate the data from hospitals with matching characteristics depending on geological location, location type and size and provide some basic statistics.

For the future the project really needs a proper CI pipeline that does some static checks, executes all the tests and creates the docs.

This is kind of important because the current implementation is only a really really really basic one that doesn't cover a lot of possible edge cases.

This issue includes both the actual code documentation on the one hand and some (at least) basic docs for our Github page for users how to use the platform - including a kind of FAQ in the frontend.

ToDo:

• Add some decent amount of code documentation
• Add a (extensible?) FAQ to the frontend
• Add basic docs for the Github page of this project.

Add a first basic "analysis" to the exports with the corresponding data export for the trends during COVID-19

• Add a basic abstract "Analysis" class with a related factory for future.
• Add filters and processors to the analysis that allow for filtering by indications and aggregate data by years, months, weeks and weekdays.
• Add the creation of a "dump" that passes all the data into a CSV file for further analysis with Excel or other software.

The current way how the FilterService works is quite ineffective and should be changed to a Factory.

• Create the FilterFactory
• Provide Entities to the Filters and only execute them if supports() returns true.
• De-clutter Filters, e.g. move complete Forms to special FilterSets
• Add validation to Filters via Symfonys Validator
• Provide a more useful frontend for Filters

The following issues in compoer.json need a cleanup:

• Remove easy-coding-standard as its no loger used (incl. ecs.php config)
• Refactor scripts: Join checks to one command and improve installation by adding setup-related stuff etc. to auto-scripts.

There are currently only a few tests that cover only a friction of the code which needs to be improved drastically before the project could progress any further.

Unit tests

• Application Handlers
• Application Traits
• DataTransfer Objects
• Domain Commands
• Domain Entities
• Domain Events
• Factories
• Queries
• Services

Integration tests

• Controllers (Frontend)
• Controllers (Backend)