dashboard issueshttps://gitlab.servus.at/aura/dashboard/-/issues2024-03-18T12:20:09+01:00https://gitlab.servus.at/aura/dashboard/-/issues/282Read radio station settings from Steering API and store/cache locally2024-03-18T12:20:09+01:00David TrattnigRead radio station settings from Steering API and store/cache locallyParent: aura#242+
---
## Dependency
- aura#221+Parent: aura#242+
---
## Dependency
- aura#221+1.0-alpha5Konrad MohrfeldtKonrad Mohrfeldthttps://gitlab.servus.at/aura/dashboard/-/issues/263Remove global state of "current show", which is updated when clicking calenda...2024-02-23T16:55:29+01:00David TrattnigRemove global state of "current show", which is updated when clicking calendar timeslotsParent: https://gitlab.servus.at/aura/dashboard/-/issues/268+
---
Currently selecting timeslots in the calendar, automatically a global state is updated with the show of the calendar item.
Generally, there should be no global state sto...Parent: https://gitlab.servus.at/aura/dashboard/-/issues/268+
---
Currently selecting timeslots in the calendar, automatically a global state is updated with the show of the calendar item.
Generally, there should be no global state storing the current show, as this leads to confusing UX. As it increases complexity of the code, it also was the cause of various bugs in the past.
- Instead, the current show should be identified by the URL
- Sidebar Navigation: The current show and its child items should only be available when the user is in the show area. When the user is browsing the calendar area, nothing in the show area is expanded
- Navigating between calendar and show, should be performed via URLs. Compare: https://gitlab.servus.at/aura/dashboard/-/issues/262 and https://gitlab.servus.at/aura/dashboard/-/issues/243
- Optional: The selected timeslot state can be represented in the URL1.0-alpha7Konrad MohrfeldtKonrad Mohrfeldthttps://gitlab.servus.at/aura/dashboard/-/issues/247Implement basic permissions2024-03-27T11:31:23+01:00Konrad MohrfeldtImplement basic permissionsParent: aura#156+
---
Implement permissions as discussed in aura/aura#156.
### Dependency
- steering#177+Parent: aura#156+
---
Implement permissions as discussed in aura/aura#156.
### Dependency
- steering#177+1.0-alpha4 — Raving Raccoon 🤪🦝Konrad MohrfeldtKonrad Mohrfeldthttps://gitlab.servus.at/aura/dashboard/-/issues/236[STORY] as a ProKo, I want to be able to change the end-date of a schedule, s...2024-02-16T19:27:06+01:00Margarethe Maierhofer-Lischka[STORY] as a ProKo, I want to be able to change the end-date of a schedule, so I can better plan the programme in advanceParent: https://gitlab.servus.at/aura/aura/-/issues/255+
---
When creating a new schedule for a show, the end-date for this schedule can be entered. This means that after that date, no further timeslots will be generated for the program...Parent: https://gitlab.servus.at/aura/aura/-/issues/255+
---
When creating a new schedule for a show, the end-date for this schedule can be entered. This means that after that date, no further timeslots will be generated for the program. This end-date is shown as "last emission" / "Letzte Austrahlung" on the ShowInfo page. When a radiomaker decides to end his show in some other moment in the future, a ProKo should be able to change this end-date. Just deleting future timeslots from the calendar does not change the end-date of the schedule.
## Proposed solutions
To realize this feature, two things are proposed:
- The option to edit the end-date of a schedule could be integrated in the emission manager dialog that pops up when selecting a show in the calendar view.
- ~~the term "Letzte Ausstrahlung" should be changed to "Enddatum der Sendereihe" / "Show terminates at", to give more clarity.~~1.0-alpha7Konrad MohrfeldtKonrad Mohrfeldthttps://gitlab.servus.at/aura/dashboard/-/issues/228Display details of failed uploads, including the log file2024-03-21T18:17:08+01:00David TrattnigDisplay details of failed uploads, including the log fileParent: dashboard#150+
---
### Old Media Management
The old Dashboard media management provides a history of uploads with all the details if and why it failed.
![image](/uploads/8aef697fbbf0d849e8c5b07866d04849/image.png)
![image](/...Parent: dashboard#150+
---
### Old Media Management
The old Dashboard media management provides a history of uploads with all the details if and why it failed.
![image](/uploads/8aef697fbbf0d849e8c5b07866d04849/image.png)
![image](/uploads/c8f5ef4c4bb615e9cedd0a3cf3f7ba17/image.png)
### New Uploader
The new uploader in contrast is very simplified:
![image](/uploads/133be8d947fcf8e95ae6113a0875b9bc/image.png)
While this is good for easy UX, in order to investigate problems we also need some improved capabilities for the new uploader. Failed upload attempts should also be available at a later time.
Also compare dashboard#104+.
### Cases where UI does not display any error state
When there's a general server error (500), Dashboard currently not indicate an issue. In these scenario below upload nor adding any other input source indicates an error, while it's not working:
![image](/uploads/16f19b5e5491b0cc8ccb6affcd8b5f16/image.png){width=45%}
But the logs show this:
![image](/uploads/a6ec99d7e8012047b3d1dbff5d9502d2/image.png){width=45%}1.0-alpha6Konrad MohrfeldtKonrad Mohrfeldthttps://gitlab.servus.at/aura/dashboard/-/issues/219[STORY] As a ProKo I want a simple way to create and manage hosts, in order t...2023-11-09T12:02:46+01:00David Trattnig[STORY] As a ProKo I want a simple way to create and manage hosts, in order to keep show and episode information up-to-dateParent: https://gitlab.servus.at/aura/aura/-/issues/41+
---
ProKos and show owners should be able to:
- Create the most simple version of a host on a show and episode level. The minimal details to be entered are `name`. ProKos are able ...Parent: https://gitlab.servus.at/aura/aura/-/issues/41+
---
ProKos and show owners should be able to:
- Create the most simple version of a host on a show and episode level. The minimal details to be entered are `name`. ProKos are able to do that for all shows. Show Owners (users) are able to create hosts only for their show.
ProKos should be able to:
- Assuming all required users are already created by the radio IT, ProKos need a way to attach a host profile to some user
- Hosts with actual user accounts attached, should have some sort of visual indiciation (icon?), that they are not only for displaying in the front-end, but actually have some real account, they can login with.
- Ability for Programme Coordinators to manage details of all hosts including upload of profile images. **tbc:** Is there a need to introduce a separate top level section, listing and filtering all users+hosts?1.0-alpha5Konrad MohrfeldtKonrad Mohrfeldthttps://gitlab.servus.at/aura/dashboard/-/issues/127[EPIC] Refactor stores and migrate to Pinia2024-03-27T02:30:05+01:00Konrad Mohrfeldt[EPIC] Refactor stores and migrate to Pinia[Pinia](https://pinia.vuejs.org/) is the recommended central state management solution for Vue3. Apart from that the current store implementations have a few problems, namely:
* some separation-of-concerns-violations, i.e. `alert` calls...[Pinia](https://pinia.vuejs.org/) is the recommended central state management solution for Vue3. Apart from that the current store implementations have a few problems, namely:
* some separation-of-concerns-violations, i.e. `alert` calls that interact with the user instead of setting error states
* inability to react to error states (exceptions are swallowed and turned into `alert`s)
* code duplication (i.e. setting authentication headers)
## Basis for follow-up tasks
Once transitioned we might also
* get rid of the `axios` dependency which most certainly can be replaced with the browser-native `fetch`: https://gitlab.servus.at/aura/dashboard/-/issues/279+
* be able to reduce the overall code size through generic implementations for CRUD operations: `TODO: check where we can do generic implementations. Create tickets.`
* improve DX by using TypeScript: https://gitlab.servus.at/aura/dashboard/-/issues/278+
## Subtasks
* [x] migrate auth store
* [x] migrate files store
* [x] migrate playlists store
* [x] migrate notes store
* [x] migrate schedules store
* [x] migration timeslots store
* [x] migrate shows store
* [x] migrate meta stores (including types, funding-categories, categories, topics, music-focus, languages, and hosts)
* #135+
* `TODO: identify other open sub-tasks, if any.`1.0-alpha4 — Raving Raccoon 🤪🦝Konrad MohrfeldtKonrad Mohrfeldthttps://gitlab.servus.at/aura/dashboard/-/issues/107Image Cropper for Avatars, Show and Episode Images2024-03-18T13:15:58+01:00David TrattnigImage Cropper for Avatars, Show and Episode ImagesParent: aura#214+
---
Integrate an Image Cropper component and store images in [different resolutions in Steering](https://gitlab.servus.at/aura/aura/-/issues/114).
We want to define an aspect ratio depending on the image type. This co...Parent: aura#214+
---
Integrate an Image Cropper component and store images in [different resolutions in Steering](https://gitlab.servus.at/aura/aura/-/issues/114).
We want to define an aspect ratio depending on the image type. This configuration should be radio specific. For example at o94 we have avatars as 1:1 and show/episodes pictures as 16:9.
Evaluate which VueJS Cropper is matching our requirements.
## Dependency
aura#221+1.0-alpha5Konrad MohrfeldtKonrad Mohrfeldt