Misc fixes

[joeauyeung]

What does this PR do?

Misc fixes

Fixes # (issue)

Environment: Staging(main branch) / Production

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?

• Test A
• Test B

Checklist

• I haven't read the contributing guide
• My code doesn't follow the style guidelines of this project
• I haven't performed a self-review of my own code and corrected any misspellings
• 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]

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

Name	Status	Preview	Updated
cal	❌ Failed (Inspect)		Dec 13, 2022 at 5:38PM (UTC)

[CarinaWolli]

We also need to consider team event types here. A user can activate workflows on team event types

[CarinaWolli]

Maybe this help. I think we do the same here: https://github.com/calcom/cal.com/blob/53d160e49539eaab5395a6fe51d1d7ec03c0c62e/packages/trpc/server/routers/viewer/workflows.tsx#L301

[joeauyeung]

That user should still be under the users field for team event types, right? Won't this consider that? If the user is not a part of that team event type, I don't think they should be able to edit workflows

[CarinaWolli]

Currently, any user of a team can set workflows active on a team event type. So we also would need to adapt that in the workflow editing page (multi-dropdown). But we can do that in a follow-up PR

[ciaranha]

@joeauyeung While I do think you're suggestion is very reasonable and makes sense, I think we need a proper top-down approach to permissions with users. ie we need roles of people who can edit (admins) and those that can't (members). Until we implement that, I don't think there's a benefit to having specific rules where people can edit some things but not others, as it will be difficult to track what people can and can't do for both our customers and us.

please re-review