papi-web-org / papi-web Goto Github PK
View Code? Open in Web Editor NEWPapi-web
Papi-web
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).
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.
One of two possible solutions:
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
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.
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.
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 is a long-term tracking issue for the papi rewrite, this one focusing on rewriting all the basic functionalities of papi, namely:
[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).
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:
results
screens (#35, merged)results
screen searchable for arbitersI 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.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).
This issue is a follow-up of the discussion from #21 .
menu_text
is required for the screen to be displayed as a menu item. This information is specified in ref section (40).menu
and menu_text
properties, %t, %f and %l tokens).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 issue is a TODO item: replace the ugly refresh code to use HTMX instead.
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)
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.
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.
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.
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:
Those features aside, this screen should probably be like any update screen.
A declarative, efficient, and flexible JavaScript library for building user interfaces.
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
An Open Source Machine Learning Framework for Everyone
The Web framework for perfectionists with deadlines.
A PHP framework for web artisans
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
Some thing interesting about web. New door for the world.
A server is a program made to process requests and deliver data to clients.
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
Some thing interesting about visualization, use data art
Some thing interesting about game, make everyone happy.
We are working to build community through open source technology. NB: members must have two-factor auth.
Open source projects and samples from Microsoft.
Google ❤️ Open Source for everyone.
Alibaba Open Source for everyone
Data-Driven Documents codes.
China tencent open source team.