Closed JMitnik closed 1 month ago
**Stage 1: Backend** 1. Data modeling * DialogueSchedule * DataPeriod * EvaluationPeriod * Enable a boolean `informNextAvailability` * Customer:`enableDialogueSchedule` 2. Write a resolver to `create` a dialogue-schedule, and to `edit`. * Also, test the resolvers both. 3. Write a resovler to fetch the `dialogue schedule`. * Also, test the resolver both (and the edge case). 4. Write a resolver, `isOpen` on the `dialogue`, which uses the current `EvaluationPeriod` * How dos an EvaluationPeriod get made? I think we can derive it for now. * Example * Our Evaluation Period Schedule defines a `start` expression, like Monday 18th, and a `72 hours` delta. * For a dialogue, we always include the `EvaluationPeriodSchedule` of the dialogue. We calculate based on schedule whether it is *currently* open or not: does our current date-time fall in between the `start` and projected end date of `+72 hours`. 5. Go over all Workspace statistics, and derive the active `Data Period`. Use this derived Data Period if the `workspace` has enabled `enableDialogueSchedule`. **Stage 2: Now for the dialogue** 1. If the dialoguue has `isOpen` to be false, show a modal. * The modal should be friendly and simple, and let the person know that it is closed. 2. (Optional, Iteration 2) If `informNextAvailability` is true, we can add a countdown to the next date **Stage 3: Now for the crucial part of the dashboard.** 1. In the `Workspace` Dashboard, make sure that all resolvers from now on opt-in to the potential `data-period`. This likely means * The `start` and `end` date of the fields are now optional. * The connected `data period` are fetched in the service methods, and "resolved" to become `Period` classes, with an `activePeriod` as well, and an `calculatedStartDate` and `calculatedEndDate`. These can be used instead of the current `start` date and `end` date. 2. The current date picker is temporarily removed. 3. We add a `data period` picker, with an extra option to still go back to the previous data period. **Stage 4: Now to make it adjustable in the dashboard (Other PR).** 1. Add in the Teams overview a new button, `Schedule`, which opens a Modal. * This is a `ModalWizard` consisting of multiple steps (a Data Period and Evaluation Period). We need to build such a wizard which stores intermediate step results, and then reuses those results when accessing the steps back and forth.
This pull request is automatically being deployed by Amplify Hosting (learn more).
Access this pull request here: https://pr-484.d36c61y3h9mqcx.amplifyapp.com
This pull request is automatically being deployed by Amplify Hosting (learn more).
Access this pull request here: https://pr-484.d2j37lx5gsfgp1.amplifyapp.com
Great job dude! Love the speed. I will update this comment with my findings Feedback:
Closes HAAS-453
API
Introduces a few new things in the API which will help us maintain codeability. This is still WIP, but is already easing a lot of the struggles.
DialogueSchedule
. By giving it the same fields once, we can consistently now use this one class for outputting a schedule in Graphql, calculating certain ranges and using those in other downstream tasks, and serves as a neat container for our fields (rather than the various objects we query).toGraphQL
methods can be quite powerful. Right now, I use helper classes, as well as some nested helper classes, to potentially expose all relevant fields. Not just hte prisma fields, but also the derived fields that belong to that class. I think this will really help us manage all of the different graphql dependencies.The distinctions between
service
,prisma adapter
, andhelper
are useful to highlight. A service does the plumbing, really. It knows which database calls to make (using the prisma adapters), can create different instances of these helper classes, perhaps sometimes aggregate. It is responsible for making the helper classes talk to one another. But the real magic could well occur within these helper classes instead. That creates a nice distinction, where one does the pure querying, one does the interesting calculations and containerizing certain fields (helper classes), and one sits in between to help both achieve what they need.Also, of course, introduced a few new models.
save
, to do both the editing and creating. I'm sure it can be split or done neater, but this felt adequate.Dashboard
The dashboard has received two major upgrades.
dialogueSchedule
. If someone chooses to adjust the filter, they can, but we will soon remove these picks in favour of nicer oens.cron syntax
, with a particular range that is dictated by the amount of minutes one cna add on top of the "start time".Dialogue
The dialogue has been adjusted to show a simple Modal whenever a dialogue is blocked. Not best copywriting, but who's gonna sue.