feat: Improve timetable source options #209
feat: Improve timetable source options #209sevorl wants to merge 1 commit intoJonasJoKuJonas:mainfrom
Conversation
…guration - Fix timetable query to respect school year boundaries - Add configurable timetable source options flow with separate sub-forms - Update integration to read timetable_source from options instead of data - Add proper validation for all timetable source types (Personal, Class, Teacher, Student) - Add translation keys for new options flow steps in all languages (en, de, nl) - Restructure options flow to use dedicated forms for each source type - Fix saving and validation issues in options configuration
|
@JonasJoKuJonas : Would you mind taking a look at this pull request? |
|
I originally decided against it because all the entities have fixed names. If the source is changed to a new class, the names are no longer correct. I currently have no way of testing you code because I'm finished with Abitur so to implement you changes I have to be sure you thought of edge case's and implement proper error handling. |
|
Hi @JonasJoKuJonas, The sensors don't get renamed automatically, so that existing automations etc. wont break.. They could be renamed manually of course |
| self.password = config.data["password"] | ||
| self.timetable_source = config.data["timetable_source"] | ||
| self.timetable_source_id = config.data["timetable_source_id"] | ||
| self.timetable_source = config.options.get("timetable_source", config.data.get("timetable_source")) |
There was a problem hiding this comment.
The data should always be read from options, never from ether options or config.
When creating a new entry, the data must be stored in options.
For existing entries, migrate the data using CONFIG_ENTRY_VERSION so that all information is consistently kept in options.
2 participants
It is now possible to change the time table source for an existing configuration.
It is not needed to delete the existing configuration and start from scratch