Problème remonté par l'arbitre principal du Championnat scolaire des écoles 2024 à Vezin.

Lors de l'export depuis ChessEvent via papi-web, les joueurs qui n'avaient pas été pointés n'ont pas été marqués comme forfait général.

During the setup of a tournament, I realized that it would be cool to limit the tournaments used for the screens of type results, which is not something currently possible.

We'll see more about that later.

EDIT: task list:

• Allow restriction of tournaments in the configuration of results screens (#35, merged)
• Allow configuration of results display time
• Make results screen searchable for arbiters
• Allow deletion of results for arbiters

This is a tracking issue for the replacement of the JET database as a storage medium.

Current plans are to use SQLite databases for local storage (see the documentation about it).
An instance running on a remote server could use some other database, like Postgres (with adaptation of the storage types for best performance/safety).

Concerns about the storage of personal data (GDPR) need to be addressed, and cannot be completely avoided.

During the setup for an event with several tournaments which don't have the same start times or cadence, I realized that only one timer is available.

Current solution

One of two possible solutions:

1. Spin up two different servers with different ports, and set up two events with a distinct timer.
2. Use one timer and add events for each (which can interfere with each other).

Proposed solution

Allow the use of distinct timers in an event (undecided syntax)
If several timers are configured, use show_timer = <timer_id> and disallow show_timer = on in screens and tournaments

I propose making each class responsible for the parsing of itself, in its own little world.

One example for the Tournament class:

class Tournament:
	# Current class definition
	@classmethod
	def from_dict(cls, d: dict):
		# here d is extracted from Event.reader
		# basically (selectively) copy-paste the code of __build_tournament()
		# One caveat is that we need to somehow get the warnings and errors in the correct place
		return cls(...)

This would allow us to test those parts in isolation more easily, e.g. by slicing parts of the file and seeing if it still parses how we want it to

This is a tracking issue for the use of bbpPairings as the core pairing engine, instead of using papi.

This issue requires the use of a user interface (see #16).

Once done, this allows one to directly retrieve the pairings from the output, rather than reconstruct the tables from the papi database.

In Python, the usual way to handle errors is "EAFP" (It's easier to ask for forgiveness than permission).
This is especially true for interfacing with the operating system, etc.

The point is that the current version of the code uses a lot of code like this:

section = 'XXX'
if not self.has_section(section):
	# log no section error
else:
	key = 'YYY'
	if not self.has_option(section, key):
		# log no key error
	else:
		var = self.get(section, key)
		# do something with var

This could probably be changed to the following pattern:

try:
	section = self['XXX'] # config_reader['XXX']
	try:
		var = section['YYY']
		# do something with var
	except (KeyError, TypeError): # TypeError can happen if 'XXX' is a key and we expected a section
		# log no key error
except KeyError:
	#log no section error

I don't feel comfortable trying to understand the legacy API that is currently used, so this might be worthwhile (we should not get this to the main branch before equivalence of behaviour is established first, of course)

This is a tracking issue for the creation of a new user interface (local GUI).

The design has yet to be decided.

There are several GUI libraries in Python that can help us with that (licence noted in brackets, list not exhaustive).

1. PySimpleGUI (LGPLv3+)
2. easyGUI (BSD)

This issue is a follow-up of the discussion from #21 .

• Menus section (34) should specify that menu_text is required for the screen to be displayed as a menu item. This information is specified in ref section (40).
• Template & families section (33) should be inverted with menus section (34), since templating can be an harder concept to understand and this section rely heavily on stuff from menus section (menu and menu_text properties, %t, %f and %l tokens).
  Examples in menus section could be simplified to not contain templates nor families.
• Rotators section (35) should emphase better that families property can take a list of families.

I propose allowing expert users to use a format they could be more comfortable with.

The main trouble I have with INI files is the lack of a formal speciication, and as such, I recommend using a format with a formal specification, such as YAML or TOML, both of which have either a well-known library or an stdlib module associated with its parsing.

This would imply writing and maintaining two different parsers, as well as the documentation for both or more formats (if we so decide, although most likely only the physical structure of the configuration file would change), so the workload would probably increase.

This is definitely not a priority for now, but could help with flexibility.

Arbiters should be able to access this screen from any update screen, probably with an authentication method (band-aid solution for now: define a password in the event file, and encrypt it in memory, disable this type of screen if no password defined).

The main features of this screen should be:

1. For any pairing, if a result has been given, allow the arbiter to change the result with any possible result.
2. Allow the arbiter to input non-player-facing results, namely forfeits (at some point in the future: non-standard results)
3. A way to safely get back to the previous update screen once done (the arbiter needs to authenticate again to get to this screen).

Those features aside, this screen should probably be like any update screen.

With respect to reports by a user, it seems as though Django is too slow for a quick startup.
I recommend considering a micro-framework like Flask, as it should start quicker (although we need to measure before we get the conclusion)

This issue is a TODO item: replace the ugly refresh code to use HTMX instead.

[FR]
Cette issue est ouverte pour permettre de centraliser les rapports de bug générique à des fins de documentation, qu'ils soient directement envoyés par les utilisateurs ici, soit envoyés par mail à un développeur.
Les rapports doivent contenir au moins le fichier log du serveur, avec préférentiellement la configuration de l'événement anonymisée (en particulier en enlevant les mots de passe et/ou identifiants).

[EN]
This issue has been opened to centralize generic bug reports for documentation purposes, whether they are sent here directly by users, or sent by email to a developer.
Reports must contain at a minimum the log file written by the server, and preferably the anonymized event configuration (in particular, logins and passwords have to be removed).

I tried to run export.py to generate a build of the application from my source repo, it went well, but I noticed a few issues with what has been generated:

- [] Build is put in the parent folder of the folder from when the script is run, it was confusing for me since usually, as an user, you expect output to be generated inside of the current location. EXPORT_DIR could be changed to address this issue.

• bin folder is generated as a file instead of a folder, making the server.bat script not working. Check attachments for more details.
  It could be related to my configuration so I would put it here: Windows 10.

Also, I think it could be nice to have some kind of simple technical README, for new people who want to contribute to the project (it would make their integration simpler, and maybe motivate more people to join).

• Add (technical) README describing required stack to start the project, how to build the executable and maybe more.

This is a long-term tracking issue for the papi rewrite, this one focusing on rewriting all the basic functionalities of papi, namely:

1. Tie-breaks;
2. FIDE title norms computation and certificates (arbiter norm certificates?);
3. Interim rating computation;
4. TRF generation (and parsing?) (#20)

I've just arbited a small tournament for under 18s and tried out the new check-in feature for the first time. While it worked functionally, it's actually quite awkward to use in practice.

For context, I'm using an iPad to allow players to check-in and enter results. While entering results presents no issues for the player, checking in requires being very accurate when taping the checkboxes next to the names. On many occasions the players accidentally checked in the player above or below them, reducing my confidence in the accuracy of the pointage. Even when it worked, it ofter took several attempts to click the right place.

I'd like to see the interface improved to follow the pattern of the results input : allow players to click anywhere on their name row, then pop up a box, with their name, to confirm or cancel the pointage.