## Description
PDFs can have pages that are rotated, which are correctly rendered in
the frontend. However, when we load the PDF in the backend, the rotation
is applied which causes issues when we want to insert fields.
To account for this, we swap the width and height for pages that are
rotated by 90/270 degrees. This is so we can calculate the virtual
position the field was placed if it was correctly oriented in the
frontend.
Then when we insert the fields, we apply a transformation to the
position of the field so it is rotated correctly.
**Test document with 0/90/180/270 rotated pages**
[rotated_test.pdf](https://github.com/user-attachments/files/15798138/rotated_test.pdf)
chore: sunset early adopters
<!-- This is an auto-generated comment: release notes by coderabbit.ai
-->
## Summary by CodeRabbit
- **New Features**
- Introduced a new `Carousel` component with video autoplay
functionality.
- Added a `Thumb` component for carousel navigation.
- Introduced a new `Enterprise` component detailing enterprise licensing
and compliance.
- **Updates**
- Updated the `Hero` component to replace the `Widget` with the new
`Carousel`.
- Revised the `PricingTable` component to reflect new pricing plans and
details.
- Changed tooltip text in the marketing app for better clarity.
- Updated button texts and links in the `Callout` component to promote
the "Free Plan".
- **Content**
- Published a blog post announcing the end of the Early Adopters Plan
and introducing new pricing plans.
- **Dependencies**
- Added Embla Carousel dependencies for enhanced carousel functionality.
<!-- end of auto-generated comment: release notes by coderabbit.ai -->
Modifies the generated filename for the downloaded PDF by appending
"_signed" to the base title.
## Changes Made
- Update the filename in the downloadFile function call to append
"_signed" to the baseTitle variable.
## Testing Performed
Tested the `downloadPDF` function locally to ensure that the downloaded
PDF file has the correct filename with "_signed" appended.
## Description
Update the direct template signing process and emails to correctly
reflect the role of the recipient who actioned the direct template.
<!-- This is an auto-generated comment: release notes by coderabbit.ai
-->
## Summary by CodeRabbit
- **New Features**
- Dynamic updating of title and description based on recipient role in
the document signing process.
- Enhanced email templates to include recipient roles, providing more
context in email notifications.
- **Improvements**
- More descriptive actions in email templates based on recipient roles,
improving clarity for recipients.
<!-- end of auto-generated comment: release notes by coderabbit.ai -->
## Description
Direct templates links is a feature that provides template owners the
ability to allow users to create documents based of their templates.
## General outline
This works by allowing the template owner to configure a "direct
recipient" in the template.
When a user opens the direct link to the template, it will create a flow
where they sign the fields configured by the template owner for the
direct recipient. After these fields are signed the following will
occur:
- A document will be created where the owner is the template owner
- The direct recipient fields will be signed
- The document will be sent to any other recipients configured in the
template
- If there are none the document will be immediately completed
## Notes
There's a custom prisma migration to migrate all documents to have
'DOCUMENT' as the source, then sets the column to required.
---------
Co-authored-by: Lucas Smith <me@lucasjamessmith.me>
## Description
This PR adds generic OIDC as an authentication provider. This allows
personal users and companies potentially to define whatever IdP they
want as long as it supports the OIDC well known format. (Azure, Zitadel,
Authentik, KeyCloak, Google, etc. all support it)
## Related Issue
Fixes#1090
## Changes Made
- Adds OIDC buttons to the signin and registration pages
- Adds appropriate environment variables
- Adds migration to add OIDC to the `IdentityProvider` Enum
## Testing Performed
#### Zitadel
- Created application in Zitadel as an web app, with Client auth
- Enabled `User Info inside ID Token` in Token settings
- Copied client id and client secret to the new .ENV variables
- Copied the well-known URL from the URLs section to .ENV
- Created new account with OIDC provider button
- Verified email manually
- Signed into account with OIDC provider
- Logged out
- Signed into accounting again with OIDC provider
#### Authentik
- Created application in Authentik
- Copied client id and client secret to the new .ENV variables
- Copied the well-known URL from the URLs section to .ENV
- Created new account with OIDC provider button
- Verified email manually
- Signed into account with OIDC provider
- Logged out
- Signed into accounting again with OIDC provider
#### Azure AD
- Created application in Azure AD using OAuth2
- Copied client id and client secret to the new .ENV variables
- Copied the well-known URL from the URLs section to .ENV
- Created new account with OIDC provider button
- Verified email manually
- Signed into account with OIDC provider
- Logged out
- Signed into accounting again with OIDC provider
Adds fields to the Account model to support various pieces
of data returned by OIDC providers such as AzureAD and GitLab.
Additionally passes through the email verification status and handles
retrieving the email for providers such as AzureAD who use a different
claim instead.
Reverts the change to find-documents to use Kysely. I'd like to gain
confidence by using it in smaller pieces before commiting to doing
what is one of our most complicated queries in Documenso.
Introduces the ability to not send an email when sending
(publishing) a document using the API.
Additionally returns the signing link for each recipient
when working with recipient API endpoints and returns
the document object including recipients when sending
documents via API.
