JMitnik / haas

haas
0 stars 0 forks source link

Dialogue Schedule #484

Closed JMitnik closed 1 month ago

JMitnik commented 2 years ago

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.

The distinctions between service, prisma adapter, and helper 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.

Dashboard

The dashboard has received two major upgrades.

CleanShot 2022-10-13 at 06 37 00@2x
  1. The Automations Overview now has an added section, for specific Automations (in this case, our Schedule). The copywriting is not yet super, but the basic setup is there. The first highlighted Automation is the schedule, and it will open a modal where you can setup the Data Period and Evaluation Period (as well as edit them, toggle them, etc). This is an early stab at the multi-step wizard; it's missing a pager, and it could be a little bit more elegant, but I like it so far.
  2. Each frontend date-picker now is overriden by the global dialogueSchedule. If someone chooses to adjust the filter, they can, but we will soon remove these picks in favour of nicer oens.
  3. I chose to represent the Data and Evaluation period as a 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.

linear[bot] commented 2 years ago
HAAS-453 Dialogue Closure

**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.

aws-amplify-eu-central-1[bot] commented 2 years ago

This pull request is automatically being deployed by Amplify Hosting (learn more).

Access this pull request here: https://pr-484.d36c61y3h9mqcx.amplifyapp.com

aws-amplify-eu-central-1[bot] commented 2 years ago

This pull request is automatically being deployed by Amplify Hosting (learn more).

Access this pull request here: https://pr-484.d2j37lx5gsfgp1.amplifyapp.com

Cold-A-Muse commented 2 years ago

Great job dude! Love the speed. I will update this comment with my findings Feedback: