feat: Managed Events V2

[alishaz-polymath]

What does this PR do?

Continues the work done by @leog in #11958

Fixes # (issue)

Requirement/Documentation

• If there is a requirement document, please, share it here.
• If there is ab UI/UX design document, please, share it here.

Type of change

• [ ] Bug fix (non-breaking change which fixes an issue)
• [ ] Chore (refactoring code, technical debt, workflow improvements)
• [ ] New feature (non-breaking change which adds functionality)
• [ ] Breaking change (fix or feature that would cause existing functionality to not work as expected)
• [ ] This change requires a documentation update

How should this be tested?

• Are there environment variables that should be set?
• What are the minimal test data to have?
• What is expected (happy path) to have (input and output)?
• Any other important info that could help to test that PR

Mandatory Tasks

• [ ] Make sure you have self-reviewed the code. A decent size PR without self-review might be rejected.

Checklist

• I haven't read the contributing guide
• My code doesn't follow the style guidelines of this project
• I haven't commented my code, particularly in hard-to-understand areas
• I haven't checked if my PR needs changes to the documentation
• I haven't checked if my changes generate no new warnings
• I haven't added tests that prove my fix is effective or that my feature works
• I haven't checked if new and existing unit tests pass locally with my changes

[vercel[bot]]

The latest updates on your projects. Learn more about Vercel for Git ↗︎

Name	Status	Preview	Comments	Updated (UTC)
ai	✅ Ready (Inspect)	Visit Preview	💬 Add feedback	Mar 11, 2024 11:52pm
api	✅ Ready (Inspect)	Visit Preview	💬 Add feedback	Mar 11, 2024 11:52pm
dev	✅ Ready (Inspect)	Visit Preview	💬 Add feedback	Mar 11, 2024 11:52pm

5 Ignored Deployments

Name	Status	Preview	Comments	Updated (UTC)
cal	⬜️ Ignored (Inspect)	Visit Preview		Mar 11, 2024 11:52pm
cal-demo	⬜️ Ignored (Inspect)	Visit Preview		Mar 11, 2024 11:52pm
calcom-web-canary	⬜️ Ignored (Inspect)	Visit Preview		Mar 11, 2024 11:52pm
qa	⬜️ Ignored (Inspect)	Visit Preview		Mar 11, 2024 11:52pm
ui	⬜️ Ignored (Inspect)	Visit Preview		Mar 11, 2024 11:52pm

[github-actions[bot]]

Thank you for following the naming conventions! 🙏 Feel free to join our discord and post your PR link.

[github-actions[bot]]

📦 Next.js Bundle Analysis for @calcom/web

This analysis was generated by the Next.js Bundle Analysis action. 🤖

One Page Changed Size

The following page changed size from the code in this PR compared to its base branch:

Page	Size (compressed)	First Load	% of Budget (350 KB)
/event-types/[type]	435.42 KB	623.81 KB	178.23% (🟡 +0.17%)

Details

Only the gzipped size is provided here based on an expert tip.

First Load is the size of the global bundle plus the bundle for the individual page. If a user were to show up to your website and land on a given page, the first load size represents the amount of javascript that user would need to download. If next/link is used, subsequent page loads would only need to download that page's bundle (the number in the "Size" column), since the global bundle has already been downloaded.

Any third party scripts you have added directly to your app using the <script> tag are not accounted for in this analysis

The "Budget %" column shows what percentage of your performance budget the First Load total takes up. For example, if your budget was 100kb, and a given page's first load size was 10kb, it would be 10% of your budget. You can also see how much this has increased or decreased compared to the base branch of your PR. If this percentage has increased by 20% or more, there will be a red status indicator applied, indicating that special attention should be given to this. If you see "+/-

[deploysentinel[bot]]

No failed tests 🎉

[github-actions[bot]]

Hey there, there is a merge conflict, can you take a look?

[github-actions[bot]]

This PR is being marked as stale due to inactivity.

[github-actions[bot]]

This PR is being marked as stale due to inactivity.

[alishaz-polymath]

Nice work, looks pretty good already 👏🏻

Some things I found during testing:

* When locking/unlocking fields and switching tabs before saving the changes are lost

Thank you for this, will take a look 🙏

* Any change in the parent resets everything from the children to the default values of the parent
  
  * Not sure about the actual field that is changed if it is unlocked ->  If an unlocked field is changed in the parent, should this change the value of all children?

I think it should. If the Admin/Parent event type field is changed, it should apply to the children, locked or unlocked. Although, I see the problem where the Admin wishes to change the default (for future users) but that might just be over-engineering 🤔

* When locking workflows and a user already has a personal workflow assigned (as it was unlocked before), it stays active. For all other field we change back to the default settings if locked, so I think we should also disable all personal workflows once locked

Ah, right. I had a similar issue with Private URL as well. I'll check if the fix is straightforward for this. I have currently locked private url, for example. If the fix seems like a more complex thing to fix, probably better to do a follow up and fix exactly this kind of issue in v2.1. I'll check and report back 🙏

Thank you for these shouts @CarinaWolli 👏

[CarinaWolli]

I think it should. If the Admin/Parent event type field is changed, it should apply to the children, locked or unlocked. Although, I see the problem where the Admin wishes to change the default (for future users) but that might just be over-engineering 🤔

I think the actual change is fine to be applied in all children. We can revisit if users run into problems or would expect different 👍

Any change in the parent resets everything from the children to the default values of the parent

This definitely shouldn't happen, only the field changed should be affected

[alishaz-polymath]

I think it should. If the Admin/Parent event type field is changed, it should apply to the children, locked or unlocked. Although, I see the problem where the Admin wishes to change the default (for future users) but that might just be over-engineering 🤔

I think the actual change is fine to be applied in all children. We can revisit if users run into problems or would expect different 👍

Any change in the parent resets everything from the children to the default values of the parent

This definitely shouldn't happen, only the field changed should be affected

Oh right, yeah this is what I meant. Any specific field change should update the value of that field in child event types

[alishaz-polymath]

I think it should. If the Admin/Parent event type field is changed, it should apply to the children, locked or unlocked. Although, I see the problem where the Admin wishes to change the default (for future users) but that might just be over-engineering 🤔

I think the actual change is fine to be applied in all children. We can revisit if users run into problems or would expect different 👍

Any change in the parent resets everything from the children to the default values of the parent

This definitely shouldn't happen, only the field changed should be affected

Oh right, yeah this is what I meant. Any specific field change should update the value of that field in child event types

I had a look @CarinaWolli and apparently we pass in all the fields when updating an event type, not just the one that was updated/modified. Unless we do that at event-type update call, we can't really identify which fields were updated and stop the reset of all managed events fields 🤔

[github-actions[bot]]

This PR is being marked as stale due to inactivity.

[leog]

@alishaz-polymath is there anything I can help with? Sorry I didn't catch this before.

[alishaz-polymath]

@alishaz-polymath is there anything I can help with? Sorry I didn't catch this before.

All good! Thank you for asking @leog 🙌

[alishaz-polymath]

Great PR @alishaz-polymath I've gone through and tested each fields except for "Apps" and "Workflows" since I think those would need a bit more time. I've left a few comments so far.

Blocking

* When an admin locks a previously unlocked field, I think we should push the parent field down to the children. Ex. if a child event type has a different title from the parent, if a field is going to be locked again there isn't a way to change the title of the child unless the field is unlocked, changed back, and then locked again

Asked @ciaranha for his inputs here ^, once we have finalized the ideal flow, I'll implement the changes

---

* I noticed when the parent makes changes and saves it's propagated to children event types even if that field is unlocked and there's a different value set from the parent

Asked @ciaranha for his inputs here ^, once we have finalized the ideal flow, I'll implement the changes

---

* When multiple durations are set, the toggle to lock/unlock the default value isn't changing

Resolved ✅

---

* Member's default location isn't being set in the field unless we choose something else

Resolved ✅

---

* When selecting offset start times, there's two toggles for lock/unlock but they're tied together. I noticed other options that are similar to this don't have the same toggles for the sub options. I think we should decide if we want to offer this level of granularity or not

This was unintended, fixed and Resolved ✅

---

* When toggling the "Enable Private URL", on and off we'll sometimes run into the prisma error `An operation failed because it depends on one or more records that were required but not found. No 'HashedLink' record was found for a nested delete on relation 'EventTypeToHashedLink'`. The second time I hit the save button it goes through.

I couldn't re-create this at all on my end, so perhaps I'd need more information on how to recreate this.

---

Non-blocking

* I noticed that for the single line text fields, when toggling the switch it focuses on the text field. I think we can make this looked more polished if we had these separated

Not entirely sure I follow here, when I click on the toggle, it doesn't switch focus to the text fields for me. Tested on Title

---

* Likewise I'm not a huge fan of the changing sizes of the field lock toggle. Could it be a set width?

I agree, Done & Resolved ✅

---

* Should we also lock/unlock the number of seats offered?

I think that's overkill tbh. Just the parent field being locked/unlocked should be enough IMO.

[joeauyeung]

@alishaz-polymath added some clarifying points

• When toggling the "Enable Private URL", on and off we'll sometimes run into the prisma error An operation failed because it depends on one or more records that were required but not found. No 'HashedLink' record was found for a nested delete on relation 'EventTypeToHashedLink'. The second time I hit the save button it goes through.

  • This might be related to propagating changes from the parent down to the child. Since the private URL is regenerated when the option is toggled, when the parent toggles the option the child private URL becomes broken. Which is causing the URL to become invalid or causes the DB issue above

• ~~I noticed that for the single line text fields, when toggling the switch it focuses on the text field. I think we can make this looked more polished if we had these separated~~

  • ~~In that GIF when we click the toggle, the field turns white and we can start typing. For other fields we don't do that so I think we should keep it consistent~~
  • Talked with @alishaz-polymath and it seems to be different browser behaviours. Good to ignore for now

[CarinaWolli]

Is this ready for review again or still something missing?

[alishaz-polymath]

Is this ready for review again or still something missing?

Just waiting for the checks to pass 😅

[alishaz-polymath]

Retested my review comments

Passing

* When an admin locks a previously unlocked field, I think we should push the parent field down to the children ✅

Blocking

* Still getting errors around the private URL field. When the field is unlocked and the child has the option enabled. When toggling the option on the parent I think it's trying to generate new URLs for the children. If it's using Prisma's `createMany` I would look at the `skipDuplicates` option.
  ![CleanShot 2024-03-08 at 11 39 31@2x](https://private-user-images.githubusercontent.com/65426560/311301161-633ed23d-69d5-4eec-8193-66cbe6c26e75.png?jwt=eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJpc3MiOiJnaXRodWIuY29tIiwiYXVkIjoicmF3LmdpdGh1YnVzZXJjb250ZW50LmNvbSIsImtleSI6ImtleTUiLCJleHAiOjE3MDk5MTY5NzEsIm5iZiI6MTcwOTkxNjY3MSwicGF0aCI6Ii82NTQyNjU2MC8zMTEzMDExNjEtNjMzZWQyM2QtNjlkNS00ZWVjLTgxOTMtNjZjYmU2YzI2ZTc1LnBuZz9YLUFtei1BbGdvcml0aG09QVdTNC1ITUFDLVNIQTI1NiZYLUFtei1DcmVkZW50aWFsPUFLSUFWQ09EWUxTQTUzUFFLNFpBJTJGMjAyNDAzMDglMkZ1cy1lYXN0LTElMkZzMyUyRmF3czRfcmVxdWVzdCZYLUFtei1EYXRlPTIwMjQwMzA4VDE2NTExMVomWC1BbXotRXhwaXJlcz0zMDAmWC1BbXotU2lnbmF0dXJlPThkM2E3ZmM5ZGY4NzVkMzk5NGZlNWY1NjM5Y2RlM2ExZGNjZjA4NzU3YzJiNTE3YjE4YjljN2ZhMWE2NDhmNmYmWC1BbXotU2lnbmVkSGVhZGVycz1ob3N0JmFjdG9yX2lkPTAma2V5X2lkPTAmcmVwb19pZD0wIn0.mpdCEGiSVq_obYqQtPp8-3Wt8Ib24wt6-GgskYoRJ1w)

Just managed to re-create the issue. Working on a fix 🙏

[alishaz-polymath]

Since this is Core, let's wait for Foundations team to give a green signal before we merge this 🙏