
A client requested it, and it makes sense showing the full count.
This is how it was before.

<!-- This is an auto-generated comment: release notes by coderabbit.ai
-->
## Summary by CodeRabbit
- **New Features**
- Updated document status tab counts to display actual numbers without
capping at 99 or using '+' symbols.
- **Bug Fixes**
- Improved clarity and accuracy of document status counts in the user
interface.
<!-- end of auto-generated comment: release notes by coderabbit.ai -->
<!-- This is an auto-generated comment: release notes by coderabbit.ai
-->
## Summary by CodeRabbit
- **New Features**
- Introduced a new blog post titled "Go Fork Yourself," discussing the
philosophy of open-source software and the significance of forking
within the OSS community, along with real-world examples and an
invitation for reader engagement.
<!-- end of auto-generated comment: release notes by coderabbit.ai -->
Before

After

<!-- This is an auto-generated comment: release notes by coderabbit.ai
-->
## Summary by CodeRabbit
- **New Features**
- Introduced a new font style for signature fields, enhancing visual
distinction.
- Increased text size for signature fields to improve prominence.
- **Bug Fixes**
- Adjusted the text size for signature display on larger screens for
better visual hierarchy.
<!-- end of auto-generated comment: release notes by coderabbit.ai -->
## Description
It used the wrong property for finding the document's dateFormat in the
`DATE_FORMATS` array.
<!-- This is an auto-generated comment: release notes by coderabbit.ai
-->
## Summary by CodeRabbit
- **New Features**
- Improved date format selection in the settings form to ensure accurate
formatting based on value.
- Default timezone now automatically set to the user's local timezone
for better user experience.
- **Bug Fixes**
- Corrected initialization of the timezone field to enhance form
accuracy.
<!-- end of auto-generated comment: release notes by coderabbit.ai -->
prisma customer story on blog
<!-- This is an auto-generated comment: release notes by coderabbit.ai
-->
## Summary by CodeRabbit
- **New Features**
- Introduced a customer story blog post detailing why Prisma chose
Documenso for their signing needs, highlighting four key reasons.
- Added author information and metadata for enhanced content engagement.
- Included links to additional resources and social media for reader
interaction.
<!-- end of auto-generated comment: release notes by coderabbit.ai -->
## Description
Currently the language cookie is set to session, so restarting browser
will reset it.
This sets the expiry for two years.
<!-- This is an auto-generated comment: release notes by coderabbit.ai
-->
## Summary by CodeRabbit
- **New Features**
- Enhanced language preference functionality with extended cookie
lifespan for improved user experience.
- **Bug Fixes**
- Resolved issues related to cookie expiration for language settings.
<!-- end of auto-generated comment: release notes by coderabbit.ai -->
## Description
Adds the ability for the document owner to edit recipients and their
fields after the document has been sent.
A recipient can only be updated or deleted if:
- The recipient has not inserted any fields
- Has not completed the document
<!-- This is an auto-generated comment: release notes by coderabbit.ai
-->
## Summary by CodeRabbit
## Release Notes
- **New Features**
- Added new localization messages to clarify user actions regarding
document signing.
- Enhanced French translations for improved user interaction.
- **Improvements**
- Updated localization strings in German and English for clearer
feedback on signer and recipient statuses.
- Improved overall structure of localization files for better
maintainability.
- **Dependency Updates**
- Upgraded `next-axiom` and `remeda` libraries to their latest versions,
potentially enhancing performance and stability.
<!-- end of auto-generated comment: release notes by coderabbit.ai -->
---------
Co-authored-by: Mythie <me@lucasjamessmith.me>
## Description
Add initial French translations
<!-- This is an auto-generated comment: release notes by coderabbit.ai
-->
## Summary by CodeRabbit
- **New Features**
- Added support for the French language, enhancing accessibility for
French-speaking users.
- Introduced localized French messages for various application
functionalities, improving user experience.
- **Bug Fixes**
- Minor formatting updates in French translation files to remove
extraneous newline characters.
- **Chores**
- Updated line references in French translation files to maintain
alignment with code changes.
<!-- end of auto-generated comment: release notes by coderabbit.ai -->
---------
Co-authored-by: Lucas Smith <me@lucasjamessmith.me>
Co-authored-by: Crowdin Bot <support+bot@crowdin.com>
Co-authored-by: github-actions <github-actions@documenso.com>
## Description
Currently invalid or missing `accept-language` headers will cause issues
rendering Plural components since we do not validate them.
This adds a check to try filter out invalid locales.
<!-- This is an auto-generated comment: release notes by coderabbit.ai
-->
## Summary by CodeRabbit
- **New Features**
- Enhanced locale filtering process to ensure only valid locales are
processed.
- **Bug Fixes**
- Improved data integrity by preventing invalid locales from affecting
application functionality.
<!-- end of auto-generated comment: release notes by coderabbit.ai -->
Currently this won't always display super well since
our insertion solution isn't amazing but our current
minimum bounds within the UI are a bit large and can be
smaller.
This change makes it smaller and uses container queries to
support dynamically displaying labels based on the container
size.
Adds the ability to specify an optional signing order for documents.
When specified a document will be considered sequential with recipients
only being allowed to sign in the order that they were specified in.
## Description
Web changes:
- Enabled i18n for web
- Add option to change language in command menu
- Add option to change language in menu-switcher
Web and marketing changes:
- Stop setting 'en' preference into cookie if the user's language is not
supported
- Dropped middleware changes
- Rotated cookie from 'i18n' to 'language'
<!-- This is an auto-generated comment: release notes by coderabbit.ai
-->
## Summary by CodeRabbit
- **New Features**
- Introduced a language switcher in the footer for improved language
selection.
- Added dynamic language change functionality in the command menu.
- Implemented a dropdown menu item for quick access to the language
switcher.
- **Bug Fixes**
- Resolved issues related to language change notifications and state
management.
- **Translations**
- Added new translation entries for improved language support, including
"Search languages..." in English and German.
- Updated existing translations to enhance clarity and accuracy.
- **Chores**
- Simplified internationalization handling in middleware.
<!-- end of auto-generated comment: release notes by coderabbit.ai -->
---------
Co-authored-by: github-actions <github-actions@documenso.com>
Templates can be created and sent with advanced fields that have empty
values. That will cause an error when the user tries to sign the
document.
For example, you can create a template with a checkbox field and save
it. Then, you can click the "Use template" button and send the document
by clicking "Send document." However, this shouldn't be possible if the
advanced field doesn't have any values.
Add the authOptions property to the document and
recipient related API endpoints.
These were previously missing so the only way API
users could set the authOptions was via templates
and using the generateTemplate endpoint.
## Description
Seems like I was overconfident in #1323 and I did not test properly.
Currently, the advanced settings for a field in a **template** is not
pre-filled with the current fieldMeta, although it is correctly
pre-filled in a **draft document** (That's probably where I messed up my
testing).
In this PR, I propose to directly use the fieldMeta provided by the
field prop in `FieldAdvancedSettings`, instead of multiplying tRPCs to
request the fieldMeta while we already have it.
I apologize for the wasted time in reviewing my previous PR which was
only correcting the display of the field label in the template view.
## Testing Performed
- This time, I correctly checked that the advanced settings for a field
is correctly pre-filled both in a document draft and in a template.
- `npm run build` builds correctly.
When the Select field has a default value, it automatically signs with
it. If you change it, you need to refresh the page to re-sign again with
that value. This PR improves the UX by making the default value
"selectable" in the dropdown menu.
<!-- This is an auto-generated comment: release notes by coderabbit.ai
-->
## Summary by CodeRabbit
- **New Features**
- Updated the `DropdownField` component to simplify the handling of
default values, ensuring the dropdown starts without a pre-selected
option.
- Improved the clarity of the placeholder text in the dropdown,
enhancing user experience.
<!-- end of auto-generated comment: release notes by coderabbit.ai -->
---
name: Pull Request
about: Submit changes to the project for review and inclusion
---
## Description
<!--- Describe the changes introduced by this pull request. -->
<!--- Explain what problem it solves or what feature/fix it adds. -->
## Related Issue
<!--- If this pull request is related to a specific issue, reference it
here using #issue_number. -->
<!--- For example, "Fixes #123" or "Addresses #456". -->
## Changes Made
<!--- Provide a summary of the changes made in this pull request. -->
<!--- Include any relevant technical details or architecture changes.
-->
- Change 1
- Change 2
- ...
## Testing Performed
<!--- Describe the testing that you have performed to validate these
changes. -->
<!--- Include information about test cases, testing environments, and
results. -->
- Tested feature X in scenario Y.
- Ran unit tests for component Z.
- Tested on browsers A, B, and C.
- ...
## Checklist
<!--- Please check the boxes that apply to this pull request. -->
<!--- You can add or remove items as needed. -->
- [ ] I have tested these changes locally and they work as expected.
- [ ] I have added/updated tests that prove the effectiveness of these
changes.
- [ ] I have updated the documentation to reflect these changes, if
applicable.
- [ ] I have followed the project's coding style guidelines.
- [ ] I have addressed the code review feedback from the previous
submission, if applicable.
## Additional Notes
<!--- Provide any additional context or notes for the reviewers. -->
<!--- This might include details about design decisions, potential
concerns, or anything else relevant. -->
<!-- This is an auto-generated comment: release notes by coderabbit.ai
-->
## Summary by CodeRabbit
- **New Features**
- Introduced a new `CallToAction` component to enhance user engagement
in the self-hosting documentation.
- Added interactive call-to-action elements in the self-hosting
documentation pages to guide users towards specific actions.
- **Documentation**
- Updated self-hosting documentation to include the new call-to-action
feature, improving usability and interactivity.
<!-- end of auto-generated comment: release notes by coderabbit.ai -->
## Description
Refactor the current date formatting system to utilize Lingui.
## Changes Made
- Remove redundant `LocaleData` component with Lingui dates
## Important notes
For the internal pages for certificates, default to en-US to format any
dates.
<!-- This is an auto-generated comment: release notes by coderabbit.ai
-->
## Summary by CodeRabbit
- **New Features**
- Enhanced internationalization support across various components by
utilizing the `i18n` object for date formatting.
- Streamlined locale management by removing cookie-based language
handling and adopting a more centralized approach.
- **Bug Fixes**
- Improved date formatting consistency by replacing the `LocaleDate`
component with direct calls to `i18n.date()` in multiple components.
- **Documentation**
- Updated localization strings in the `web.po` files to reflect recent
changes in the source code structure.
- **Chores**
- Minor formatting adjustments and code organization improvements across
various files to enhance readability and maintainability.
<!-- end of auto-generated comment: release notes by coderabbit.ai -->
---------
Co-authored-by: github-actions <github-actions@documenso.com>
<!-- This is an auto-generated comment: release notes by coderabbit.ai
-->
## Summary by CodeRabbit
- **Chores**
- Updated the metadata revision dates in multiple German translation
files for consistency.
- Added extraneous blank lines in multiple translation files for cleaner
formatting.
<!-- end of auto-generated comment: release notes by coderabbit.ai -->
Co-authored-by: Crowdin Bot <support+bot@crowdin.com>
Fixes#1318 and allows to submit a partial `fieldMeta` when updating a
field instead of replacing the current `fieldMeta`, to be consistent
with other endpoints.
Fixes#1259. I literally just used the exact same line of code than from
the document page so it is consistent.
The bug is extremely frustrating because if you make change to the
fields meta on the template and refresh the page, you can't see field
meta (label, default value, required), and neither do your co-workers.
Of course, I tested the change and it now displays correctly the
existing field meta on the template page.
## Description
<!--- Describe the changes introduced by this pull request. -->
In this PR, I've fixed a small grammar error.
## Related Issue
Fixes: #1315
## Changes Made
It replaces `"wont"` with `"won't"` and `"Only your signing experience
is"` with `"Only your signing experience will be"`
## Checklist
- [x] I have tested these changes locally and they work as expected.
- [x] I have added/updated tests that prove the effectiveness of these
changes.
- [x] I have updated the documentation to reflect these changes, if
applicable.
- [x] I have followed the project's coding style guidelines.
- [x] I have addressed the code review feedback from the previous
submission, if applicable.
<!-- This is an auto-generated comment: release notes by coderabbit.ai
-->
## Summary by CodeRabbit
- **Bug Fixes**
- Updated text in the Document Share Button for enhanced clarity and
grammatical accuracy.
<!-- end of auto-generated comment: release notes by coderabbit.ai -->
---------
Co-authored-by: ajeet <109718740+ajeetcode@users.noreply.github.com>
Previously we would delete all invites and confirmation tokens upon
completing the action that they represent.
This change instead adds a flag on each token indicating whether it has
been completed so we can action a
completed token differently in the UI to reduce confusion for users.
This had been brought up a number of times where confirmation emails,
team member invites and other items
may have been actioned and forgotten about causing an error toast/page
upon subsequent revisit.
Previously dialogs would be closed upon refocusing the browser tab due to router refetches occuring which would cause data-table columns to re-render. This is now resolved by extracting the column definitions outside of the returning render and into a memo hook.
## Description
Configure the advanced field via API.
## Checklist
<!--- Please check the boxes that apply to this pull request. -->
<!--- You can add or remove items as needed. -->
- [x] I have tested these changes locally and they work as expected.
- [ ] I have added/updated tests that prove the effectiveness of these
changes.
- [x] I have updated the documentation to reflect these changes, if
applicable.
- [x] I have followed the project's coding style guidelines.
- [ ] I have addressed the code review feedback from the previous
submission, if applicable.
<!-- This is an auto-generated comment: release notes by coderabbit.ai
-->
## Summary by CodeRabbit
- **New Features**
- Enhanced API functionality to support field metadata during field
creation.
- Introduced validation checks for field metadata to ensure necessary
information is provided for advanced field types.
- **Bug Fixes**
- Improved error handling during field creation to return properly
formatted error responses.
- **Documentation**
- Updated API schemas to include field metadata, enhancing data
validation and response structures.
<!-- end of auto-generated comment: release notes by coderabbit.ai -->
When signing a document the final signer is often
greeted with a super long completing spinner since
we are synchronously signing the document and sending
emails to all recipients. This is frustrating and
has caused issues for customers and self-hosters.
Moving sealing to a background job resolves this
and improves the overall snappiness of the app while
also supporting retrying the sealing if it were to
fail in the future.
This has the implication of a document no longer
immediately being in a "completed" state once all
signers have signed. To assist with this we now
refetch the page every 5 seconds upon signing
completion until the document status as shifted to
completed.
Previously, it wasn't possible to download an audit log of a document
uploaded by another user because the function used the ID of the user
making the request to retrieve the document. However, the document
uploaded by another user has that user's ID, not the ID of the user
making the request.
Adds support for an `externalId` query param to be passed when linking a
user to a direct template. This external id will then be stored on the
document upon signing completion.
Since we allow checkboxes and radio fields without a label (which we use for the value) we
had an issue where multiple checkboxes with no value would exist and items would not end
up checked on the resulting document.
This change fixes that by adding a placeholder value for these empty checkboxes and labels.
This change will allow for user registration when users are federated
through oidc provider even if the general signup is disabled
additionally the users email address can now be automatically set as
trusted. This will force corporate users to signin using SSO instead of
creating manual accounts.
Updates the current regex based approach for validating redirect urls to
instead use the native URL constructor which is available in browsers and
Node.js and handles several valid cases that were previously not working.
fair use policy and support page
<!-- This is an auto-generated comment: release notes by coderabbit.ai
-->
## Summary by CodeRabbit
- **New Features**
- Added a "Support" documentation page outlining various support options
for users, including Community, Paid Account, and Enterprise support.
- Introduced a "Fair Use Policy" documentation page, providing
guidelines and reassurance regarding usage of the service.
- Enhanced the account creation documentation with additional
information about the Fair Use Policy.
- **Improvements**
- Updated the documentation structure with new sections for easier
navigation, including "Support" and "Fair Use Policy."
<!-- end of auto-generated comment: release notes by coderabbit.ai -->
chore: translation typo
<!-- This is an auto-generated comment: release notes by coderabbit.ai
-->
## Summary by CodeRabbit
- **New Features**
- Enhanced the `Header` component for improved internationalization by
enabling translation of the "Documentation" text.
- **Documentation**
- Added comments in translation files to link translation entries to the
`Header` component, improving maintainability and traceability for
future updates.
<!-- end of auto-generated comment: release notes by coderabbit.ai -->
<!-- This is an auto-generated comment: release notes by coderabbit.ai
-->
## Summary by CodeRabbit
- **New Features**
- Enhanced clarity and accuracy of translation strings for the German
and Romanian languages, including the Enterprise License description.
- **Bug Fixes**
- Corrected translation errors in both German and Romanian, ensuring
proper grammar and terminology.
- **Chores**
- Updated revision dates across multiple translation files to reflect
the latest changes for better tracking.
<!-- end of auto-generated comment: release notes by coderabbit.ai -->
---------
Co-authored-by: Crowdin Bot <support+bot@crowdin.com>
Co-authored-by: github-actions <github-actions@documenso.com>
## Description
This PR introduces an initial i18n implementation using
[Lingui](https://lingui.dev).
We plan to combine it with Crowdin which will provide AI translations
when PRs are merged into main.
We plan to rollout i18n to only marketing for now, and will review how
everything goes before continuing to introduce it into the main
application.
## Reasoning
Why not use i18n-next or other alternatives?
To hopefully provide the best DX we chose Lingui because it allows us to
simply wrap text that we want to translate in tags, instead of forcing
users to do things such as:
- Update the text to `t('some-text')`
- Extract it to the file
- The text becomes a bit unreadable unless done correctly
Yes, plugins such as i18n-ally and Sherlock exist to simplify these
chores, but these require the user to be correctly setup in vscode, and
it also does not seem to provide the required configurations for our
multi app and multi UI package setup.
## Super simple demo
```html
// Before
<p>Text to update</p>
// After
<p>
<Trans>Text to update</Trans>
</p>
```
## Related Issue
Relates to #885 but is only for marketing for now.
Another branch is slowly being prepared for the changes required for the
web application while we wait to see how this goes for marketing.
## Changes Made
Our configuration does not follow the general standard since we have
translations that cross:
- Web app
- Marketing app
- Constants package
- UI package
This means we want to separate translations into:
1. Marketing - Only translations extracted from `apps/marketing`
2. Web - Only translations extracted from `apps/web`
3. Common - Translations from `packages/constants` and `packages/ui`
Then we bundle, compile and minify the translations for production as
follows:
1. Marketing = Marketing + Common
2. Web = Web + Common
This allows us to only load the required translations when running each
application.
Overall general changes:
- Add i18n to marketing
- Add core i18n setup to web
- Add pre-commit hook and GH action to extract any new <Trans> tags into
the translation files
<!-- This is an auto-generated comment: release notes by coderabbit.ai
-->
## Summary by CodeRabbit
- **New Features**
- Added Romanian localization for marketing messages to improve
accessibility for Romanian-speaking users.
- Introduced German and English translation modules and PO files to
enhance the application's internationalization capabilities.
- Integrated internationalization support in the RootLayout component
for dynamic language settings based on server-side configurations.
- Enhanced the Enterprise component with translation support to adapt to
user language preferences.
- Added a `<meta>` tag to prevent Google from translating the page
content, supporting internationalization efforts.
- **Bug Fixes**
- Resolved minor issues related to the structure and accessibility of
translation files.
- **Chores**
- Updated project dependencies to support the new localization features
and ensure stability.
<!-- end of auto-generated comment: release notes by coderabbit.ai -->
---------
Co-authored-by: Lucas Smith <me@lucasjamessmith.me>
Co-authored-by: Crowdin Bot <support+bot@crowdin.com>
Co-authored-by: github-actions <github-actions@documenso.com>
---
name: Pull Request
about: Submit changes to the project for review and inclusion
---
## Description
Corrects grammar on `/pricing` page of main website.
## Related Issue
N/A
## Changes Made
Added the word "for" (grammar)
Pluralized "offer" to "offers" (grammar)
## Testing Performed
No testing should be required for this change.
## Checklist
- [x] I have tested these changes locally and they work as expected.
- [x] I have added/updated tests that prove the effectiveness of these
changes.
- [x] I have updated the documentation to reflect these changes, if
applicable.
- [x] I have followed the project's coding style guidelines.
- [x] I have addressed the code review feedback from the previous
submission, if applicable.
## Additional Notes
<!-- This is an auto-generated comment: release notes by coderabbit.ai
-->
## Summary by CodeRabbit
- **Bug Fixes**
- Improved grammatical accuracy in the Enterprise component, enhancing
readability and professionalism.
<!-- end of auto-generated comment: release notes by coderabbit.ai -->
- Added functionality to decline team invitations
- Added email notifications for when team is deleted
- Added email notifications for team members joining and leaving
---
name: Pull Request
about: Submit changes to the project for review and inclusion
---
## Description
<!--- Describe the changes introduced by this pull request. -->
<!--- Explain what problem it solves or what feature/fix it adds. -->
## Related Issue
<!--- If this pull request is related to a specific issue, reference it
here using #issue_number. -->
<!--- For example, "Fixes #123" or "Addresses #456". -->
## Changes Made
<!--- Provide a summary of the changes made in this pull request. -->
<!--- Include any relevant technical details or architecture changes.
-->
- Change 1
- Change 2
- ...
## Testing Performed
<!--- Describe the testing that you have performed to validate these
changes. -->
<!--- Include information about test cases, testing environments, and
results. -->
- Tested feature X in scenario Y.
- Ran unit tests for component Z.
- Tested on browsers A, B, and C.
- ...
## Checklist
<!--- Please check the boxes that apply to this pull request. -->
<!--- You can add or remove items as needed. -->
- [ ] I have tested these changes locally and they work as expected.
- [ ] I have added/updated tests that prove the effectiveness of these
changes.
- [ ] I have updated the documentation to reflect these changes, if
applicable.
- [ ] I have followed the project's coding style guidelines.
- [ ] I have addressed the code review feedback from the previous
submission, if applicable.
## Additional Notes
<!--- Provide any additional context or notes for the reviewers. -->
<!--- This might include details about design decisions, potential
concerns, or anything else relevant. -->
<!-- This is an auto-generated comment: release notes by coderabbit.ai
-->
## Summary by CodeRabbit
- **New Features**
- Added "Documentation" and "Support" links to the footer for enhanced
resource accessibility.
- Updated the "Changelog" link position for improved navigation.
- **Bug Fixes**
- Replaced dynamic URL handling with a direct link to API documentation
for clarity and consistency.
<!-- end of auto-generated comment: release notes by coderabbit.ai -->
## Description
<!--- Describe the changes introduced by this pull request. -->
<!--- Explain what problem it solves or what feature/fix it adds. -->
## Related Issue
<!--- If this pull request is related to a specific issue, reference it
here using #issue_number. -->
<!--- For example, "Fixes #123" or "Addresses #456". -->
## Changes Made
<!--- Provide a summary of the changes made in this pull request. -->
<!--- Include any relevant technical details or architecture changes.
-->
- Change 1
- Change 2
- ...
## Testing Performed
<!--- Describe the testing that you have performed to validate these
changes. -->
<!--- Include information about test cases, testing environments, and
results. -->
- Tested feature X in scenario Y.
- Ran unit tests for component Z.
- Tested on browsers A, B, and C.
- ...
## Checklist
<!--- Please check the boxes that apply to this pull request. -->
<!--- You can add or remove items as needed. -->
- [ ] I have tested these changes locally and they work as expected.
- [ ] I have added/updated tests that prove the effectiveness of these
changes.
- [ ] I have updated the documentation to reflect these changes, if
applicable.
- [ ] I have followed the project's coding style guidelines.
- [ ] I have addressed the code review feedback from the previous
submission, if applicable.
## Additional Notes
<!--- Provide any additional context or notes for the reviewers. -->
<!--- This might include details about design decisions, potential
concerns, or anything else relevant. -->
<!-- This is an auto-generated comment: release notes by coderabbit.ai
-->
## Summary by CodeRabbit
- **Documentation**
- Enhanced project README for clarity and improved environment variables
section.
- Added comprehensive developer and user documentation, including guides
on local development, public API, self-hosting, and compliance
standards.
- Introduced specific guides for contributing, creating API keys, using
webhooks, and setting up security measures.
- Detailed documentation on various fields available for document
signing to improve user understanding.
- Added metadata structuring to improve navigation within the
documentation site.
- **Chores**
- Updated `.gitignore` to better handle project files.
- **New Features**
- Introduced detailed metadata and documentation for various Documenso
functionalities, including signing documents, user profiles, and
compliance levels.
- Added functionality for Direct Link Signing, enabling easy sharing for
document signing.
<!-- end of auto-generated comment: release notes by coderabbit.ai -->
---------
Co-authored-by: Timur Ercan <timur.ercan31@gmail.com>
Co-authored-by: Lucas Smith <me@lucasjamessmith.me>
Co-authored-by: David Nguyen <davidngu28@gmail.com>
## Description
Adds the external ID column to documents and templates with an option to
configure it in the API or UI.
External ID's can be used to link a document or template to an external
system and identify them via webhooks, etc.
Introduces the ability to use anonymous SMTP authentication where no username or password is provided.
Also introduces a new flag to disable TLS avoiding cases also where STARTTLS is used despite `secure` being
set to `false`
Introduces customization options for the document completion email
template to allow for custom email bodies and subjects for documents
created from direct templates.
## Testing Performed
- Verified correct rendering of custom email subject and body for direct
template documents
- Verified the all other completed email types are sent correctly
chore Top 3 Signing Efficiency Hacks for Freelancers
<!-- This is an auto-generated comment: release notes by coderabbit.ai
-->
## Summary by CodeRabbit
- **New Features**
- Introduced a blog post titled "Top 3 Signing Efficiency Hacks for
Freelancers" with tips on streamlining contract signing using Documenso.
<!-- end of auto-generated comment: release notes by coderabbit.ai -->
changelog for v 1.5.6
<!-- This is an auto-generated comment: release notes by coderabbit.ai
-->
## Summary by CodeRabbit
- **New Features**
- Display document creation time in the documents view.
- Introduced direct template links for easier access.
- Added support for OpenID Connect (OIDC) for improved authentication
options.
- **Enhancements**
- Transitioned to a new rust-based library for signing documents,
enhancing performance and security.
<!-- end of auto-generated comment: release notes by coderabbit.ai -->
announcing profiles blogpost
<!-- This is an auto-generated comment: release notes by coderabbit.ai
-->
## Summary by CodeRabbit
- **New Features**
- Introduced "Documenso Profiles" that allow users to share digital
signature templates publicly.
- Recipients can sign documents directly via public links, streamlining
the signing process.
<!-- end of auto-generated comment: release notes by coderabbit.ai -->
How to Sign an NDA online (fast) blog article
<!-- This is an auto-generated comment: release notes by coderabbit.ai
-->
## Summary by CodeRabbit
- **New Features**
- Published a new blog post on signing NDAs faster with Documenso,
highlighting the use of direct links, templates, and basic signing for
efficiency.
<!-- end of auto-generated comment: release notes by coderabbit.ai -->
## Description
**Pending testing on preview**
Enable yearly team pricing during checkout.
## Changes Made
- Enable selecting yearly team pricing during checkout
- Update pricing on marketing to $480 for yearly team plan
## Testing Performed
- Stripe simulations
Pending manual testing
<!-- This is an auto-generated comment: release notes by coderabbit.ai
-->
## Summary by CodeRabbit
- **New Features**
- Updated the savings message in the pricing table to reflect new
savings amounts.
- Adjusted yearly pricing from $500 to $480.
- Modified user addition costs based on subscription periods.
- **Improvements**
- Simplified button text in the Create Team Checkout Dialog to
consistently display "Checkout".
<!-- end of auto-generated comment: release notes by coderabbit.ai -->
## Description
When using account required auth for a given document this change now
shows the sign up or sign in button depending on if an account actually
exists within
Documenso.
This change should reduce friction and confusion when a recipient has
been invited to a document.
## Related Issue
<!--- If this pull request is related to a specific issue, reference it
here using #issue_number. -->
<!--- For example, "Fixes #123" or "Addresses #456". -->
## Changes Made
- Updated the ssr for the signing page to fetch whether a user account
exists when document auth is required
- Pass the user exists flag to the document auth required page
## Testing Performed
- Created and sent a document to a user with an account and one without an account in both a logged in and logged out state and confirmed that the dialogs are displayed as expected.

<!-- This is an auto-generated comment: release notes by coderabbit.ai
-->
## Summary by CodeRabbit
- **New Features**
- Introduced user statistics display including metrics on document
creation and signing in the admin dashboard.
- Added a bar chart visualizing monthly growth data of users with
documents.
- **Enhancements**
- Updated dashboard stats page to provide more detailed user-related
metrics and charts.
- Added new CSS variable `--gold` for consistent theming across light
and dark modes.
<!-- end of auto-generated comment: release notes by coderabbit.ai -->
## Description
Show a dialog when the document has signers with no signature fields
placed.
## Changes Made
Created a new dialog that'll be triggered when the document owner tries
to send a document to the signers without placing signature fields. The
document owners can't proceed to the next step unless they add signature
fields.
## Checklist
- [x] I have tested these changes locally and they work as expected.
- [ ] I have added/updated tests that prove the effectiveness of these
changes.
- [ ] I have updated the documentation to reflect these changes, if
applicable.
- [x] I have followed the project's coding style guidelines.
- [ ] I have addressed the code review feedback from the previous
submission, if applicable.
https://github.com/documenso/documenso/assets/25515812/f1b5c34e-2ce0-40e3-804c-f05d23045710
<!-- This is an auto-generated comment: release notes by coderabbit.ai
-->
## Summary by CodeRabbit
- **New Features**
- Introduced "Direct Links" for async signing, allowing users to create
documents from templates using public links.
- Added `MissingSignatureFieldDialog` component to ensure users don't
miss adding signature fields.
- **Enhancements**
- Updated blog content to provide guidance on contract management and
announce new pricing plans.
- **Bug Fixes**
- Improved async signing process for better efficiency and control.
- **Refactor**
- Improved internal code structure and import order for stripe-related
functionality.
- **Tests**
- Enhanced e2e tests to verify signature presence before document
creation and updated test flows for document approval.
<!-- end of auto-generated comment: release notes by coderabbit.ai -->
---------
Co-authored-by: David Nguyen <davidngu28@gmail.com>
## Description
This pull request introduces the functionality to display pending fields
on the document page view. This enhancement allows users to see which
fields are pending and need to be completed.

## Changes Made
- Added `getPendingFieldsForDocument` function in
`packages/lib/server-only/field/get-pending-fields-for-document.ts` to
fetch pending fields for a document.
- Created a new component `DocumentPendingFields` in
`document-pending-fields.tsx` to display the pending fields with options
to hide individual fields.
## Testing Performed
- Tested the new feature by creating documents with pending fields and
verifying their display on the document page view.
- Verified that the pending fields are correctly hidden when the "Hide
field" button is clicked.
- Ran unit tests for the new functionality and existing components to
ensure no regressions.
## Checklist
- [x] I have tested these changes locally and they work as expected.
- [x] I have added/updated tests that prove the effectiveness of these
changes.
- [x] I have updated the documentation to reflect these changes, if
applicable.
- [x] I have followed the project's coding style guidelines.
- [ ] I have addressed the code review feedback from the previous
submission, if applicable.
## Additional Notes
No additional notes.
<!-- This is an auto-generated comment: release notes by coderabbit.ai
-->
## Summary by CodeRabbit
- **New Features**
- Introduced logic for handling pending and completed document fields
based on signing status.
- **Refactor**
- Replaced `getCompletedFieldsForDocument` with `getFieldsForDocument`.
- Updated `DocumentReadOnlyFields` component to `DocumentPendingFields`.
- **Bug Fixes**
- Improved field retrieval accuracy and display based on recipient
signing status.
- **Style**
- Enhanced UI elements with new icons and button adjustments for better
user interaction.
<!-- end of auto-generated comment: release notes by coderabbit.ai -->
---------
Co-authored-by: David Nguyen <davidngu28@gmail.com>
## Description
Currently a work in progress but this adds background tasks to Documenso
for handling tasks that take a little longer and aren't part of the
overall critical path.
## Related Issue
N/A
## Changes Made
Added a pluggable jobs provider supporting both a local provider and a
Trigger.dev provider.
## Testing Performed
- Verified job level retries work
- Verified task level retries work without incrementing job retries


**This will still have a lot of rough edges but is a perfect MVP for
local _durable_ compute which may accept more providers later on**
<!-- This is an auto-generated comment: release notes by coderabbit.ai
-->
## Summary by CodeRabbit
- **New Features**
- Added background job management functionalities to handle email
sending and job processing.
- Introduced support for triggering and managing jobs using various
providers.
- **Chores**
- Updated environment configuration files to support new job management
features.
- Added and updated scripts and dependencies for job management and CLI
commands.
- **Refactor**
- Refactored email sending functionalities to utilize the new job queue
mechanism.
- **Documentation**
- Updated documentation to reflect the new environment variables and
configurations related to background jobs.
- **Configuration**
- Updated Docker configurations to support new services for job
management.
- Updated VSCode settings for improved development experience with new
dependencies and formatting rules.
- **Database**
- Added new database schemas and migrations to support background job
management and tracking.
<!-- end of auto-generated comment: release notes by coderabbit.ai -->
documenso for freelancer contracts article
<!-- This is an auto-generated comment: release notes by coderabbit.ai
-->
## Summary by CodeRabbit
- **New Features**
- Published a new blog post: "How Documenso Enhances Contract Management
for Freelancers, Helping Them Close More Clients Efficiently." This post
offers insights into contract management and the benefits of digital
signatures using Documenso.
- **Documentation**
- Updated a hyperlink in the conclusion section of the blog post titled
"How Documenso Helps Freelancers Close More Clients Efficiently" to
direct users to a new URL related to signing freelance contracts with
Documenso.
<!-- end of auto-generated comment: release notes by coderabbit.ai -->
added changelog page to marketing site
<!-- This is an auto-generated comment: release notes by coderabbit.ai
-->
## Summary by CodeRabbit
- **New Features**
- Introduced a changelog page to detail recent updates and features.
- Added a link to the changelog in the website footer for easy access.
<!-- end of auto-generated comment: release notes by coderabbit.ai -->
When using account required auth for a given document
this change now shows the sign up or sign in button
depending on if an account actually exists within
Documenso.
This change should reduce friction and confusion when a
recipient has been invited to a document.
direct links account blogarticle
<!-- This is an auto-generated comment: release notes by coderabbit.ai
-->
## Summary by CodeRabbit
- **New Features**
- Introduced Direct Links for templates, allowing asynchronous document
signing via unique shareable links for easy access.
<!-- end of auto-generated comment: release notes by coderabbit.ai -->
"How Documenso Helps Freelancers Close More Clients Efficiently" blog
article
<!-- This is an auto-generated comment: release notes by coderabbit.ai
-->
## Summary by CodeRabbit
- **Documentation**
- Added a new blog post titled "How Documenso Helps Freelancers Close
More Clients Efficiently," discussing the benefits of using Documenso to
streamline the proposal process with digital signatures for enhanced
speed and security in closing deals.
<!-- end of auto-generated comment: release notes by coderabbit.ai -->
## Description
Adjusts the styling to improve the layout and appearance of the carousel
controls and thumbnails on smaller screens.
## Changes Made
- Updated the carousel control styling to be more responsive.
- Adjusted the font size and padding of the slide component for better
display on mobile screens.
## Screenshot

## Checklist
- [x] I have tested these changes locally and they work as expected.
- [ ] I have added/updated tests that prove the effectiveness of these
changes.
- [ ] I have updated the documentation to reflect these changes, if
applicable.
- [x] I have followed the project's coding style guidelines.
- [ ] I have addressed the code review feedback from the previous
submission, if applicable.
<!-- This is an auto-generated comment: release notes by coderabbit.ai
-->
<!-- end of auto-generated comment: release notes by coderabbit.ai -->
## 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.
A series of changes to improve sealing robustness avoiding errors that
have appeared during monitoring.
Additionally handles the recently published CVE affecting the
`pdfjs-dist` library.
Bumps ReactPDF and pdfjs-dist to avoid the CVE that allows
for code execution in pdf's. This change doesn't specifically
upgrade to the latest pdfjs-dist due to issues with top level
await, instead disabling the evaluation of javascript within
the PDF.
Use Noto Sans to gracefully handle inserting custom text
on PDF's. Previously we were using Helvetica which is a
standard PDF font but that would fail for any character
that couldn't be encoded in WinANSI.
Noto Sans was chosen as it has support for a large number
of languages and glyphs with challenges now being adding
support for CJK glyphs.
Previously we used the form flattening method from PDF-Lib
but unfortunately when it encountered orphaned form items
or other PDF oddities it would throw an error.
Because of this certain documents would fail to seal and
be stuck in a pending state with no recourse available.
This change rewrites the form flattening handler to be
more lenient when coming across the unknown opting to skip
items it can't handle rather than abort.
---
name: Pull Request
about: Submit changes to the project for review and inclusion
---
## Description
Display time in 12h format in the documents table.
<!--- Describe the changes introduced by this pull request. -->
<!--- Explain what problem it solves or what feature/fix it adds. -->
## Related Issue
<!--- If this pull request is related to a specific issue, reference it
here using #issue_number. -->
<!--- For example, "Fixes #123" or "Addresses #456". -->
Fixes#1077
## Changes Made
<!--- Provide a summary of the changes made in this pull request. -->
<!--- Include any relevant technical details or architecture changes.
-->
- Use DateTime.DATETIME_SHORT
- ...
## Testing Performed
<!--- Describe the testing that you have performed to validate these
changes. -->
<!--- Include information about test cases, testing environments, and
results. -->
- Tested time in different timezone.
- Ran tests in web and mobile browser
1. Login
2. Add a document
3. Verify that you see date and time in 12h format as per your locale.
## Checklist
<!--- Please check the boxes that apply to this pull request. -->
<!--- You can add or remove items as needed. -->
- [x] I have tested these changes locally and they work as expected.
- [x] I have added/updated tests that prove the effectiveness of these
changes.
- [x] I have updated the documentation to reflect these changes, if
applicable.
- [x] I have followed the project's coding style guidelines.
- [x] I have addressed the code review feedback from the previous
submission, if applicable.
## Additional Notes
<img width="1512" alt="Screenshot 2024-04-29 at 04 21 53"
src="https://github.com/documenso/documenso/assets/29673073/778155d4-a920-40bd-acdc-7451c9c5d4b7">
<img width="300" alt="Screenshot 2024-04-29 at 04 22 18"
src="https://github.com/documenso/documenso/assets/29673073/3471de0f-f426-4ea1-be1e-220462aff9e4">
## Description
General enhancements for templates.
## Changes Made
Added the following changes to the template flow:
- Allow adding document meta settings
- Allow adding email settings
- Allow adding document access & action authentication
- Allow adding recipient action authentication
- Save the state between template steps similar to how it works for
documents
Other changes:
- Extract common fields between document and template flows
- Remove the title field from "Use template" since we now have it as
part of the template flow
- Add new API endpoint for generating templates
## Testing Performed
Added E2E tests for templates and creating documents from templates
**Description:**
This PR updates and adds a new action to assign `status: assigned` label
---------
Signed-off-by: Adithya Krishna <aadithya794@gmail.com>
## Description
Update the template flow to allow for entering recipient placeholder
emails and names
## Changes Made
- General refactoring
- Added advanced recipient settings for future usage
## Description
Currently if you complete a pending encrypted document, it will prevent
the document from being sealed due to the systems inability to decrypt
it.
This PR disables uploading any documents that cannot be loaded as a
temporary measure.
**Note**
This is a client side only check
## Changes Made
- Disable uploading documents that cannot be parsed
- Refactor putFile to putDocumentFile
- Add a flag as a backup incase something goes wrong
## Description
Currently users who sign in via Google SSO do not get assigned a Stripe
customer account.
This enforces the Stripe customer requirement on sign in.
There might be a better place to put this so it's open to any
suggestions.
## Description
Improves the sealing process by being strict on how long certificate
generation can take, opting to fail generation and continue sealing.
Also changes the ordering of sealing so an error in the process won't
also cause a document to be "COMPLETED" since it hasn't been
cryptographically sealed yet.
The downside to this change is that documents that fail during sealing
will require manual intervention as a signer or owner won't be able to
*complete* the document.
## Testing Performed
- Modified code to force specific failure modes to occur and verified
that documents were either gracefully sealed without a certificate or
not sealed and not completed.
Improves the sealing process by being strict on how
long certificate generation can take, opting to fail
generation and continue sealing.
Also changes the ordering of sealing so an error in the
process won't also cause a document to be "COMPLETED"
since it hasn't been cryptographically sealed yet.
The downside to this change is that documents that fail
during sealing will require manual intervention as a signer
or owner won't be able to *complete* the document.
## Description
Currently deleting a pending document where you are a recipient off will
delete the document, but will also throw an error.
This is due to the recipient being updated after the document deleted,
which is only supposed to happen for completed documents.
## Description
Automatically marks the document as completed if all the recipients are
CC.
## Changes Made
Added an if statement in the last form step (`onAddSubjectFormSubmit`)
that checks if all the recipients are CC. If so, the document status is
updated to `COMPLETED`.
## Testing Performed
Tested the changes and they work as expected.
## Checklist
<!--- Please check the boxes that apply to this pull request. -->
<!--- You can add or remove items as needed. -->
- [x] I have tested these changes locally and they work as expected.
- [ ] I have added/updated tests that prove the effectiveness of these
changes.
- [ ] I have updated the documentation to reflect these changes, if
applicable.
- [x] I have followed the project's coding style guidelines.
- [ ] I have addressed the code review feedback from the previous
submission, if applicable.
<!-- This is an auto-generated comment: release notes by coderabbit.ai
-->
## Summary by CodeRabbit
- **New Features**
- Enhanced document sending logic to update document status based on
recipient roles.
- **Bug Fixes**
- Removed redundant form submission handling in the document editing
feature.
<!-- end of auto-generated comment: release notes by coderabbit.ai -->
## Description
Feature flags are broken on SSR due to this error
```
TypeError: fetch failed
at Object.fetch (node:internal/deps/undici/undici:11731:11)
at process.processTicksAndRejections (node:internal/process/task_queues:95:5) {
cause: RequestContentLengthMismatchError: Request body length does not match content-length header
at write (node:internal/deps/undici/undici:8590:41)
at _resume (node:internal/deps/undici/undici:8563:33)
at resume (node:internal/deps/undici/undici:8459:7)
at [dispatch] (node:internal/deps/undici/undici:7704:11)
at Client.Intercept (node:internal/deps/undici/undici:7377:20)
at Client.dispatch (node:internal/deps/undici/undici:6023:44)
at [dispatch] (node:internal/deps/undici/undici:6254:32)
at Pool.dispatch (node:internal/deps/undici/undici:6023:44)
at [dispatch] (node:internal/deps/undici/undici:9343:27)
at Agent.Intercept (node:internal/deps/undici/undici:7377:20) {
code: 'UND_ERR_REQ_CONTENT_LENGTH_MISMATCH'
}
}
```
I've removed content-length header since it isn't mandatory to my
knowledge for get requests.
## Changes
- Add fallback local flags when individual flag request fails
- Add error logging
- Remove `content-length` from headers being passed to Posthog
## Description
Upgrade playwright once again and use CDP for remote connections to
avoid version lock-in with `playwright.connect`
Resolves the issue where all CI is failing currently due to downgrading
playwright.
## Description
Currently if you create a team webhook, you can see it in your personal
webhooks.
However, interacting with them will throw errors because there is server
side logic preventing any interaction with them since they are outside
of the correct context.
So the solution is to either:
- Allow the user to edit the team webhooks that they created on their
personal webhooks page
- Hide team webhooks for personal webhooks pages
This PR goes with the second option, but is open to suggestions.
## Description
Added the ability for recipients to see fields from other recipients who
have completed the document when they are signing the document
Added the ability for the document owner to see fields from recipients
who have completed the field on the document page view (only visible
when the document is pending)
## 🚨🚨 Migrations🚨🚨
- Drop all `Fields` that do not have a `Recipient` set (not sure how it
was possible in the first place)
- Remove optional `Recipient` field on `Field` which doesn't make sense
<!-- This is an auto-generated comment: release notes by coderabbit.ai
-->
## Summary by CodeRabbit
## Summary by CodeRabbit
- **New Features**
- Enhanced document viewing by adding read-only fields based on document
status.
- Improved signing page by fetching and displaying completed fields for
tokens.
- Updated avatar component to show recipient status with tooltips for
better user interaction.
- **Bug Fixes**
- Made `recipientId` a required field in the database to ensure data
consistency.
- **Refactor**
- Optimized popover functionality in UI components for better
performance and user experience.
- **Documentation**
- Added detailed component and function descriptions for new features in
the system.
<!-- end of auto-generated comment: release notes by coderabbit.ai -->
## Description
Disable the document certificate download button when the document is
not complete
## Changes Made
- Disable UI button
- Disable TRPC API endpoint
## Testing Performed
Tested locally for pending, draft and completed documents
**Description:**
This PR adds a check for filename title and if the title ends with
`.pdf` then the extension isnt added or else its added
<!-- This is an auto-generated comment: release notes by coderabbit.ai
-->
## Summary by CodeRabbit
- **Bug Fixes**
- Enhanced email attachment handling to ensure PDF files are correctly
identified with a ".pdf" extension.
<!-- end of auto-generated comment: release notes by coderabbit.ai -->
## Description
Allow users to download a completed document via API.
## Testing Performed
Tested the code locally by trying to download both draft and completed
docs. Works as expected.
## Checklist
- [x] I have tested these changes locally and they work as expected.
- [ ] I have added/updated tests that prove the effectiveness of these
changes.
- [ ] I have updated the documentation to reflect these changes, if
applicable.
- [x] I have followed the project's coding style guidelines.
- [ ] I have addressed the code review feedback from the previous
submission, if applicable.
<!-- This is an auto-generated comment: release notes by coderabbit.ai
-->
## Summary by CodeRabbit
- **New Features**
- Implemented functionality to download signed documents directly from
the app.
<!-- end of auto-generated comment: release notes by coderabbit.ai -->
## Description
Updated the email content based on whether the document owner is a
recipient or not.
If the document owner is a recipient (self-signer):
* the email subject will be `Please view/sign/approve your document`
* the email header will be `Please view/sign/approve your document
"<your-doc-title>"`
* the email content will be `You have initiated the document
"<your-doc-title>" that requires you to view/sign/approve it.`
Otherwise:
* the email subject will be `Please view/sign/approve this document`
* the email header will be `<doc-owner> has invited you to
view/sign/approve "<doc-title>"`
* the email content will be `<doc-owner> has invited you to
view/sign/approve the document "<doc-title>".`
## Related Issue
Related to #1091
## Testing Performed
Tested the feature with a different number of recipients (including and
excluding the document owner - self-signer). Tested both the sending and
resending functionality.
## Checklist
- [x] I have tested these changes locally and they work as expected.
- [ ] I have added/updated tests that prove the effectiveness of these
changes.
- [ ] I have updated the documentation to reflect these changes, if
applicable.
- [x] I have followed the project's coding style guidelines.
- [ ] I have addressed the code review feedback from the previous
submission, if applicable.
## UI Screenshots




<!-- This is an auto-generated comment: release notes by coderabbit.ai
-->
## Summary by CodeRabbit
## Summary by CodeRabbit
- **New Features**
- Enhanced the document invitation components to support scenarios where
the recipient is also the sender, providing customized email content and
subject lines.
- Introduced new properties in email templates to improve clarity and
relevance based on the user's role in the document signing process.
- **Refactor**
- Updated components to use a more flexible `headerContent` property for
displaying invitation headers, replacing previous individual inviter
details.
<!-- end of auto-generated comment: release notes by coderabbit.ai -->
## Description
Currently users can sign and complete draft documents, which will result
in a completed document in an invalid state.
## Changes Made
- Prevent recipients from inserting or uninserting fields for draft
documents
- Prevent recipients from completing draft documents
- Remove ability to copy signing tokens unless document is pending
<!-- This is an auto-generated comment: release notes by coderabbit.ai
-->
## Summary by CodeRabbit
- **New Features**
- Enhanced document status visibility and control across various
components in the application. Users can now see and interact with
document statuses more dynamically in views like `DocumentPageView`,
`DocumentEditPageView`, and `DocumentsDataTable`.
- Improved document signing process with updated status checks, ensuring
actions like signing, completing, and removing fields are only available
under appropriate document statuses.
- **Bug Fixes**
- Adjusted document status validation logic in server-side operations to
prevent actions on incorrectly stated documents, enhancing the overall
security and functionality of document processing.
<!-- end of auto-generated comment: release notes by coderabbit.ai -->
## Description
Add additional information for each role to help document owners
understand what each role involves.
## Changes Made



## Testing Performed
Tested the changes locally.
## Checklist
<!--- Please check the boxes that apply to this pull request. -->
<!--- You can add or remove items as needed. -->
- [x] I have tested these changes locally and they work as expected.
- [ ] I have added/updated tests that prove the effectiveness of these
changes.
- [ ] I have updated the documentation to reflect these changes, if
applicable.
- [x] I have followed the project's coding style guidelines.
- [ ] I have addressed the code review feedback from the previous
submission, if applicable.
<!-- This is an auto-generated comment: release notes by coderabbit.ai
-->
## Summary by CodeRabbit
- **New Features**
- Updated recipient role terminology and added tooltips in the
`AddSignersFormPartial` component:
- "Signer" changed to "Needs to sign" with tooltip
- "Receives copy" changed to "Needs to approve" with tooltip
- "Approver" changed to "Needs to view" with tooltip
- "Viewer" changed to "Receives copy" with tooltip
- Enhanced select dropdown options with icons and tooltips for different
recipient roles in the `AddTemplatePlaceholderRecipients` component.
<!-- end of auto-generated comment: release notes by coderabbit.ai -->
---------
Co-authored-by: Timur Ercan <timur.ercan31@gmail.com>
## Description
Fix the issue where duplicate templates can be created
## Changes Made
- Prevent duplicate templates by correctly disabling elements
- Clear the PDF when the form is reset
- General UI changes to new template dialog for consistency
- Add description for new template dialog
- Add close button for new template dialog
## Testing Performed
Manual testing
## Checklist
- [X] I have tested these changes locally and they work as expected.
- [X] I have followed the project's coding style guidelines.
<!-- This is an auto-generated comment: release notes by coderabbit.ai
-->
## Summary by CodeRabbit
- **New Features**
- Introduced new components in the template creation dialog for better
usability: `DialogClose`, `DialogDescription`, and `DialogFooter`.
- Enhanced file upload handling and display.
- Added a cancel button and a create template button to the dialog
footer for improved navigation.
- **Refactor**
- Updated the dialog content and form layout for a more intuitive user
experience.
- Refactored form structure and labels for clarity.
- **Removed Features**
- Removed the `Label` component from the dialog.
<!-- end of auto-generated comment: release notes by coderabbit.ai -->
## Description
Currently, when the command menu is opened using the Command+K hotkey,
two modals are getting rendered.
This is because the modals are mounted in two components: header and
desktop-nav. Upon triggering the hotkey, both modals are rendered.
## Related Issue
#1032
## Changes Made
The changes I made are in the desktop nav component. If the desktop nav
receives the command menu state value and the state setter function, it
will trigger only that. If not, it will trigger the state setter that is
defined in the desktop nav. This way, we are preventing the modal from
mounting two times.
## Testing Performed
- Tested behaviour of command menu in the portal
- Tested on browsers chrome, arc, safari, chrome, firefox
## Checklist
- [x] I have tested these changes locally and they work as expected.
- [ ] I have added/updated tests that prove the effectiveness of these
changes.
- [ ] I have updated the documentation to reflect these changes, if
applicable.
- [x] I have followed the project's coding style guidelines.
- [ ] I have addressed the code review feedback from the previous
submission, if applicable.
<!-- This is an auto-generated comment: release notes by coderabbit.ai
-->
## Summary by CodeRabbit
- **New Features**
- Enhanced the navigation experience by integrating command menu state
management directly within the `DesktopNav` component, allowing for
smoother interactions and control.
- **Refactor**
- Simplified the handling of the command menu by removing the
`CommandMenu` component and managing its functionality within
`DesktopNav`.
<!-- end of auto-generated comment: release notes by coderabbit.ai -->
---------
Co-authored-by: David Nguyen <davidngu28@gmail.com>
## Description
This PR introduces the ability to add oneself as a signer by simply
clicking a button, rather than filling the details manually.
### "Add Myself" in the document creation flow
https://github.com/documenso/documenso/assets/25515812/0de762e3-563a-491f-a742-9078bf1d627d
### "Add Myself" in the document template creation flow
https://github.com/documenso/documenso/assets/25515812/775bae01-3f5a-4b24-abbf-a47b14ec594a
## Related Issue
Addresses
[#113](https://github.com/documenso/backlog-internal/issues/113)
## Changes Made
Added a new button that grabs the details of the logged-in user and
fills the fields *(email, name, and role)* automatically when clicked.
## Testing Performed
Tested the changes locally through the UI.
## Checklist
- [x] I have tested these changes locally and they work as expected.
- [ ] I have added/updated tests that prove the effectiveness of these
changes.
- [ ] I have updated the documentation to reflect these changes, if
applicable.
- [x] I have followed the project's coding style guidelines.
- [ ] I have addressed the code review feedback from the previous
submission, if applicable.
<!-- This is an auto-generated comment: release notes by coderabbit.ai
-->
## Summary by CodeRabbit
- **New Features**
- Introduced the ability for users to add themselves as signers within
documents seamlessly.
- **Enhancements**
- Improved form handling logic to accommodate new self-signer
functionality.
- Enhanced user interface elements to support the addition of self as a
signer, including a new "Add myself" button and disabling input fields
during the process.
<!-- end of auto-generated comment: release notes by coderabbit.ai -->
**Description:**
- Updated mobile header with respect to latest designs
<!-- This is an auto-generated comment: release notes by coderabbit.ai
-->
## Summary by CodeRabbit
- **New Features**
- Added a new `showText` property to the `MenuSwitcher` component to
control text visibility.
- Added a `textSectionClassName` property to the `AvatarWithText`
component for conditional text section styling.
- Updated the `CommandDialog` and `DialogContent` components with new
positioning and styling properties.
- **Style Updates**
- Adjusted text size responsiveness in the `Hero` component for various
screen sizes.
- Modified text truncation and input styling in the `Widget` component.
- Changed the width of the `SheetContent` element in `MobileNavigation`
and adjusted footer layout.
- **Documentation**
- Added instructions for certificate placement in `SIGNING.md`.
- **Refactor**
- Standardized type imports across various components and utilities for
improved type checking.
<!-- end of auto-generated comment: release notes by coderabbit.ai -->
---------
Signed-off-by: Adithya Krishna <adithya@documenso.com>
Signed-off-by: Adithya Krishna <aadithya794@gmail.com>
Co-authored-by: David Nguyen <davidngu28@gmail.com>
The searchDocuments function is used for the shortcuts commands, afaik.
The function returns the documents that match the user query (if any),
alongside all their recipients.
The reason for that is so it can build the path for the document. E.g.
if you're the document owner, the document path will be
`..../documents/{id}`. But if you're a signer for example, the document
path (link) will be `..../sign/{token}`.
So instead of doing that on the frontend, I moved it to the backend.
At least that's what I understood. If I'm wrong, please correct me.
<!-- This is an auto-generated comment: release notes by coderabbit.ai
-->
## Summary by CodeRabbit
- **New Features**
- Enhanced the `CommandMenu` component to simplify search result
generation and improve document link management based on user roles.
- **Refactor**
- Updated document search logic to include recipient token masking and
refined document mapping.
- **Style**
- Minor formatting improvement in document routing code.
<!-- end of auto-generated comment: release notes by coderabbit.ai -->
<!-- This is an auto-generated comment: release notes by coderabbit.ai
-->
## Summary by CodeRabbit
- **Refactor**
- Enhanced the API specification generation process to include operation
IDs, security schemes, and security definitions more efficiently.
<!-- end of auto-generated comment: release notes by coderabbit.ai -->
---------
Co-authored-by: Lucas Smith <me@lucasjamessmith.me>


<!-- This is an auto-generated comment: release notes by coderabbit.ai
-->
## Summary by CodeRabbit
- **New Features**
- Introduced a "Claim Account" feature allowing new users to sign up by
providing their name, email, and password.
- Enhanced user experience for both logged-in and non-logged-in users
with improved UI/UX and additional functionality.
- **Enhancements**
- Implemented form validation and error handling for a smoother sign-up
process.
- Integrated analytics to track user actions during account claiming.
<!-- end of auto-generated comment: release notes by coderabbit.ai -->
---------
Co-authored-by: Lucas Smith <me@lucasjamessmith.me>
Co-authored-by: David Nguyen <davidngu28@gmail.com>
---
name: Pull Request
about: Submit changes to the project for review and inclusion
---
## Description
Should fix the rerendering of the status widget
## Related Issue
<!--- If this pull request is related to a specific issue, reference it
here using #issue_number. -->
<!--- For example, "Fixes #123" or "Addresses #456". -->
## Changes Made
<!--- Provide a summary of the changes made in this pull request. -->
<!--- Include any relevant technical details or architecture changes.
-->
- Change 1
- Change 2
- ...
## Testing Performed
<!--- Describe the testing that you have performed to validate these
changes. -->
<!--- Include information about test cases, testing environments, and
results. -->
- Tested feature X in scenario Y.
- Ran unit tests for component Z.
- Tested on browsers A, B, and C.
- ...
## Checklist
<!--- Please check the boxes that apply to this pull request. -->
<!--- You can add or remove items as needed. -->
- [ ] I have tested these changes locally and they work as expected.
- [ ] I have added/updated tests that prove the effectiveness of these
changes.
- [ ] I have updated the documentation to reflect these changes, if
applicable.
- [ ] I have followed the project's coding style guidelines.
- [ ] I have addressed the code review feedback from the previous
submission, if applicable.
## Additional Notes
<!--- Provide any additional context or notes for the reviewers. -->
<!--- This might include details about design decisions, potential
concerns, or anything else relevant. -->
## Description
When document audit logs were first introduced, we by default set the
`fieldSecurity` to `NONE`
Now that document auth has been added, this is causing issues since we
do not use `NONE` to define field that has no migrations required, but
rather have the `fieldSecurity` field itself be undefined.
To keeps things consistent, this migration replaces `NONE` with
undefined.
There are a few ways to approach this:
- Run a prisma migration on the JSON
- Modify the data before we pass the data to the schema in
`parseDocumentAuditLogData`
- Use `NONE` instead of undefined
If anyone thinks there's a better way to do this, please drop a comment
🙇
## Description
General UI updates
## Changes Made
- Add consistent spacing between document edit/view/log pages
- Add document status to document audit log page
- Update document loading page to reserve space for the document status
below the title
- Update the document audit log page to show full dates in the correct
locale
## Description
Adds the ability to prefill native PDF form fields via the API using
either normal documents or templates.
Since we won't always know when a document is uploaded and has forms we
opt to do this on creation for templates and on sending the document to
recipients in all cases. This means that for a created document it can
look a little funky since the form fields are missing the data until the
document is sent.
This should be improved in a later change but since we've scoped this to
an API only workflow for now we are less concerned with the visual
issues.
## Related Issue
N/A
## Changes Made
- Added the `formValues` field the document model
- Added a new method for finding and filling form fields based on a `key
| value` pair
- Updated the API input shapes to take the new field.
## Testing Performed
- Have created and tested a document using the API both for creation and
usage with a template.
- Have verified that the fields display as expected either during
creation or sending depending on the document type.
## Description
Fetch the updated version of the document after sealing it and return
it. Previously, the `document.documentData.data` wasn't up to date. Now
it is.
## Related Issue
Fixes#1088.
## Testing Performed
* Added console.logs in the code to make sure it returns the proper data
* Set up a webhook and tested that the webhook receives the updated data
## Checklist
<!--- Please check the boxes that apply to this pull request. -->
<!--- You can add or remove items as needed. -->
- [x] I have tested these changes locally and they work as expected.
- [ ] I have added/updated tests that prove the effectiveness of these
changes.
- [ ] I have updated the documentation to reflect these changes, if
applicable.
- [x] I have followed the project's coding style guidelines.
- [ ] I have addressed the code review feedback from the previous
submission, if applicable.
## Changes Made
- Refactor/optimise tests
- Reduce flakiness
- Add parallel tests (if there's enough CPU capacity)
- Removed explicit worker count when running parallel tests. Defaults to
50% of CPU capacity.
Might want to consider sharding the test across runners in the future as
our tests grows.
## Description
Fixed issue where accounts that were initially created via
email/password, then linked to an SSO account, can bypass the 2FA during
login if they use their email password.
## Testing Performed
Tested locally, and 2FA is now required for linked SSO accounts
## Description
Add the following document action auth options:
- 2FA
- Passkey
If the user does not have the required auth setup, we onboard them
directly.
## Changes made
Note: Added secondaryId to the VerificationToken schema
## Testing Performed
Tested locally, pending preview tests
## Checklist
- [X] I have tested these changes locally and they work as expected.
- [X] I have added/updated tests that prove the effectiveness of these
changes.
- [X] I have followed the project's coding style guidelines.
<!-- This is an auto-generated comment: release notes by coderabbit.ai
-->
## Summary by CodeRabbit
- **New Features**
- Introduced components for 2FA, account, and passkey authentication
during document signing.
- Added "Require passkey" option to document settings and signer
authentication settings.
- Enhanced form submission and loading states for improved user
experience.
- **Refactor**
- Optimized authentication components to efficiently support multiple
authentication methods.
- **Chores**
- Updated and renamed functions and components for clarity and
consistency across the authentication system.
- Refined sorting options and database schema to support new
authentication features.
- **Bug Fixes**
- Adjusted SignInForm to verify browser support for WebAuthn before
proceeding.
<!-- end of auto-generated comment: release notes by coderabbit.ai -->
Added a dialog button at the bottom of the admin/documents/[id] page
with confirmation popup.
Confirmation popup have validation for reason to input.
On confirmation document is deleted, and an email is triggred to the
owner of document with the reason stated.
Let me know if there is any more requirement or correction is needed in
this pr. :) #1020
## Description
Currently opening modals, clicking select boxes or using anything from
radix that overlays the screen in some way will shift the screen.
This can be easily noticeable when changing the document "Period"
selector on the /documents page.
## Changes Made
Undo the gutter change for now. Can find a proper solution another time.
https://github.com/documenso/documenso/assets/20962767/5bcae576-2944-4ae5-a2c3-0589e7f61bdb
This change flattens and normalizes annotation and widget layers within
the PDF document removing items that can be accidentally modified after
signing which would void the signature attached to the document.
Initially this change was just to assign to an ArcoForm object in the
document catalog if it existed but quickly turned into the above.
When annotations aren't flattened Adobe PDF will say that the signature
needs to be validated and upon doing so will become invalid due to the
annotation layers being touched.
To resolve this I set out to flatten and remove the annotations by
pulling out their normal appearances if they are present, converting
them into xobjects and then drawing those using the drawObject operator.
This resolves a critical issue the users experienced during the signing
flow when they had marked up a document using annotations in pdf
editors.
## Description
Currently if you try to load the document edit page when fields need to
be rendered, you will not be able to see the fields until you proceed to
the next step.
This is because the fields require the document PDF to be loaded prior
to rendering them.
This PR resolves that issue by only rendering the fields after the PDF
is loaded.
## Changes Made
- Add a state to track whether the PDF is loaded
- Render the fields only after the PDF is loaded
## Testing Performed
Tested document flow manually and the fields are rendered correctly on
load.
## Checklist
- [X] I have tested these changes locally and they work as expected.
- [X] I have updated the documentation to reflect these changes, if
applicable.
## Description
**Fixes issues with mismatching state between document steps.**
For example, editing a recipient and proceeding to the next step may not
display the updated recipient. And going back will display the old
recipient instead of the updated values.
**This PR also improves mutation and query speeds by adding logic to
bypass query invalidation.**
```ts
export const trpc = createTRPCReact<AppRouter>({
unstable_overrides: {
useMutation: {
async onSuccess(opts) {
await opts.originalFn();
// This forces mutations to wait for all the queries on the page to reload, and in
// this case one of the queries is `searchDocument` for the command overlay, which
// on average takes ~500ms. This means that every single mutation must wait for this.
await opts.queryClient.invalidateQueries();
},
},
},
});
```
I've added workarounds to allow us to bypass things such as batching and
invalidating queries. But I think we should instead remove this and
update all the mutations where a query is required for a more optimised
system.
## Example benchmarks
Using stg-app vs this preview there's an average 50% speed increase
across mutations.
**Set signer step:**
Average old speed: ~1100ms
Average new speed: ~550ms
**Set recipient step:**
Average old speed: ~1200ms
Average new speed: ~600ms
**Set fields step:**
Average old speed: ~1200ms
Average new speed: ~600ms
## Related Issue
This will resolve#470
## Changes Made
- Added ability to skip batch queries
- Added a state to store the required document data.
- Refetch the data between steps if/when required
- Optimise mutations and queries
## Checklist
- [X] I have tested these changes locally and they work as expected.
- [X] I have followed the project's coding style guidelines.
---------
Co-authored-by: Lucas Smith <me@lucasjamessmith.me>
## Description
Add support to login with passkeys.
Passkeys can be added via the user security settings page.
Note: Currently left out adding the type of authentication method for
the 'user security audit logs' because we're using the `signIn`
next-auth event which doesn't appear to provide the context. Will look
into it at another time.
## Changes Made
- Add passkeys to login
- Add passkeys feature flag
- Add page to manage passkeys
- Add audit logs relating to passkeys
- Updated prisma schema to support passkeys & anonymous verification
tokens
## Testing Performed
To be done.
MacOS:
- Safari ✅
- Chrome ✅
- Firefox ✅
Windows:
- Chrome [Untested]
- Firefox [Untested]
Linux:
- Chrome [Untested]
- Firefox [Untested]
iOS:
- Safari ✅
## Checklist
<!--- Please check the boxes that apply to this pull request. -->
<!--- You can add or remove items as needed. -->
- [X] I have tested these changes locally and they work as expected.
<!-- This is an auto-generated comment: release notes by coderabbit.ai
-->
## Summary by CodeRabbit
- **New Features**
- Introduced Passkey authentication, including creation, sign-in, and
management of passkeys.
- Added a Passkeys section in Security Settings for managing user
passkeys.
- Implemented UI updates for Passkey authentication, including a new
dialog for creating passkeys and a data table for managing them.
- Enhanced security settings with server-side feature flags to
conditionally display new security features.
- **Bug Fixes**
- Improved UI consistency in the Settings Security Activity Page.
- Updated button styling in the 2FA Recovery Codes component for better
visibility.
- **Refactor**
- Streamlined authentication options to include WebAuthn credentials
provider.
- **Chores**
- Updated database schema to support passkeys and related functionality.
- Added new audit log types for passkey-related activities.
- Enhanced server-only authentication utilities for passkey registration
and management.
<!-- end of auto-generated comment: release notes by coderabbit.ai -->
## Details
Currently there's no way to have a proper PR template selector. Since we
rarely use the E2E template, I've opted to move the generic PR template
to be the default template.
## Description
Update the add signer form to disable the signers when required.
I assume the actual issue is that `{...field}` was spreading a disabled
prop which was overriding our one.
## Changes Made
- Use fieldset to disable inputs
- Manually disable select since fieldset doesn't work for that select
for some reason
Right now, the eslint command runs separately for each staged file. This
PR aims to change that by running just one eslint command for all the
files that have been changed.
## Description
Updates the `on-create.sh` script to use our `dx` command resolving
issues where it couldn't find the docker compose file due to changes
that have happened since publishing the Documenso docker image.
## Related Issue
Resolves#1026
## Test Details
N/A
## Checklist
- [x] I have written the new test and ensured it works as intended.
- [x] I have added necessary documentation to explain the purpose of the
test.
- [x] I have followed the project's testing guidelines and coding style.
- [x] I have addressed any review feedback from previous submissions, if
applicable.
## Additional Notes
N/A
## Description
Updates the docker documentation and compose files to include key file
related configuration for self hosters. This was missed as the key file
environment variables weren't documented in the `.env.example` file
which was used for creating the docker documentation.
## Related Issue
#1012
## Changes Made
- Updated the docker configuration to include key file environment
variables
- Updated the .env.example to include key file env vars
- Updated the compose images to use volumes for key files
## Testing Performed
- I have used the containers with the updated values and confirmed that
they work as expected
## Checklist
- [x] I have tested these changes locally and they work as expected.
- [x] I have added/updated tests that prove the effectiveness of these
changes.
- [x] I have updated the documentation to reflect these changes, if
applicable.
- [x] I have followed the project's coding style guidelines.
- [x] I have addressed the code review feedback from the previous
submission, if applicable.
## Additional Notes
N/A
## Description
This pull request addresses the issue where users on touchscreen devices
couldn't properly see the Recipients list. I have implemented a two-easy
solution to address this problem, offering a seamless user experience
across device types:
1. Popover for Touchscreen: For touchscreen devices, I have added a
popover that displays the Recipients list when users tap on the avatars.
2. Tooltip for Larger Screens: On larger screens (desktops and laptops),
I have added a tooltip that appears when users hover over the avatars.
## Changes
1. Added `Popover` for smaller devices and keep the `Tooltip` for larger
devices.
2. Renamed the component `stack-avatars-wtih-tooltip` to
`stack-avatars-wtih-ui` because now it contains both Tooltip and
Popover.
3. Used the `useWindowSize` hook to conditionally render the `Tooltip`
and `Popover`
4. To avoid repeating the same code, I've created a new component named
`stack-avatars-components.tsx` to show the recipient's details. This
component uses both Popover and Tooltip.
## PR Preview
https://github.com/documenso/documenso/assets/87828904/2dc9b056-b4bd-43dd-b427-a0e803dee55a
## Issue
Closes#756
When prisma:migrate-dev needs to reset the database it will run the seed script to repopulate data. Now that we've added the seed script to our root setup command we will want to avoid this behaviour since we will end up double seeding the database which currently can cause issues.
## Description
Fixes the issue with Vercel preview deployments failing.
It appears that the old `PGHOST` environment variable injected by neon
was:
`ep-snowy-snowflake-a2vc5pa2.eu-central-1.aws.neon.tech`
It is now:
`ep-snowy-snowflake-a2vc5pa2.eu-central-1-pooler.aws.neon.tech`
Notice the `-pooler` being attached automatically to the `PGHOST`.
## References
> The following changes were made to the [Neon Vercel
Integration](https://vercel.com/integrations/neon):
>
>To ensure that users accessing a Neon database from a serverless
environment have enough connections, the DATABASE_URL and PGHOST
environment variables added to a Vercel project by the Neon integration
are now set to a pooled Neon connection string by default. Pooled
connections support up to 10,000 simultaneous connections. Previously,
these variables were set to an unpooled connection string supporting
fewer concurrent connections.
https://neon.tech/docs/changeloghttps://neon.tech/docs/guides/vercel#manage-vercel-environment-variables
Remove `bcrypt` in favor of `@node-rs/bcrypt` which includes precompiled
binaries for many platforms reducing the number of tasks to run post
`npm install`.
Resolves#986
Tidy the docker setup and include a Github Action
for publishing docker containers to DockerHub and
Github Container Registry.
Also add a small README file with docker hosting instructions.
Tidy the docker setup and include a Github Action
for publishing docker containers to DockerHub and
Github Container Registry.
Also add a small README file with docker hosting instructions.
Return the recipient as an array to match the other formats for Zapier.
Otherwise, Zaps with the "DOCUMENT_OPENED" hooks won't work.
All the other webhooks return the "Recipient" field as an array.
---
name: Pull Request
about: Submit changes to the project for review and inclusion
---
## Description
<!--- Describe the changes introduced by this pull request. -->
<!--- Explain what problem it solves or what feature/fix it adds. -->
## Related Issue
<!--- If this pull request is related to a specific issue, reference it
here using #issue_number. -->
<!--- For example, "Fixes #123" or "Addresses #456". -->
## Changes Made
<!--- Provide a summary of the changes made in this pull request. -->
<!--- Include any relevant technical details or architecture changes.
-->
- Change 1
- Change 2
- ...
## Testing Performed
<!--- Describe the testing that you have performed to validate these
changes. -->
<!--- Include information about test cases, testing environments, and
results. -->
- Tested feature X in scenario Y.
- Ran unit tests for component Z.
- Tested on browsers A, B, and C.
- ...
## Checklist
<!--- Please check the boxes that apply to this pull request. -->
<!--- You can add or remove items as needed. -->
- [ ] I have tested these changes locally and they work as expected.
- [ ] I have added/updated tests that prove the effectiveness of these
changes.
- [ ] I have updated the documentation to reflect these changes, if
applicable.
- [ ] I have followed the project's coding style guidelines.
- [ ] I have addressed the code review feedback from the previous
submission, if applicable.
## Additional Notes
<!--- Provide any additional context or notes for the reviewers. -->
<!--- This might include details about design decisions, potential
concerns, or anything else relevant. -->
This PR adds the public-facing API.

The public API will allow users to interact with Documenso
programmatically. At the moment, there are 5 available endpoints:
1. `GET /documents`
- get all documents of the user making the API call
- it accepts 2 URL query parameters - `page` and `perPage`, but they are
not mandatory
2. `GET /documents/:id`
- get a specific document of the user making the API call
- it requires 1 URL parameter, which represents the ID of the document
that needs to be retrieved
3. `DELETE /documents/:id`
- delete a specific document of the user making the API call
- it requires 1 URL parameter, which represents the ID of the document
that needs to be deleted
4. `POST /documents`
- making a POST request to this endpoint will return an S3 pre-signed
URL where you can upload the document
- it requires you to pass the file name and the file content type
5. `PATCH /documents/:id/send-for-signing`
- send a document for signing
- it allows you to pass the following:
- signer email *(required)*
- signer name *(optional)*
- field type (signature, email, name, etc.) *(required)*
- page number where to insert the field *(required)*
- page X *(required)*
- page Y *(required)*
- page width *(required)*
- page height *(required)*
- email subject *(optional)*
- email body *(optional)*
The users are authenticated through API tokens. The users can create one
or more tokens in their account settings, and each token will be
available for 1 year _(duration open to suggestions/changes)_.
Each time the user makes a request, the app checks if the token exists
and if it's valid. The app will return `401` *(unauthorized)* and the
appropriate error message if either is false. If both are true AND the
user uses the correct HTTP verb and passes the required URL parameters
and body, the API call will be successful.
Code overview:
- `@documenso/packages/lib/trpc/api-contract` - this folder contains the
`contract` and `schema` files. The `contract.ts` file describes the
structure of the API, the format of the requests and responses, and how
to authenticate your API calls, among others. The `schema.ts` file
contains the Zod schemas used in the API contract.
- `@documenso/packages/trpc/server/api-token-router` - this folder
contains the `router.rs` and `schema.ts` files. Here are the tRPC
procedures used on the frontend. That is, the user's settings page,
where the user can list/create/delete API tokens.
- `@documenso/packages/trpc/tsconfig.json` - I added `"strict": true`
because that's what's suggested in the `ts-rest` documentation.
*([source](https://ts-rest.com/docs/quickstart#create-a-contract))*
- `[...ts-rest].tsx` - This file contains the implementation of the API.
You can see the logic behind each route.
- the rest of the code represents the code for the API tokens page in
the user's settings.
<!-- This is an auto-generated comment: release notes by coderabbit.ai
-->
## Summary by CodeRabbit
- **New Features**
- Added two-factor authentication form handling in profile settings.
- Introduced account deletion functionality, including Stripe customer
data removal.
- Updated UI components and styles for improved user interaction, such
as enhanced visual feedback for destructive actions.
- **Refactor**
- Improved code quality by updating import statements for type-only
imports.
- **Chores**
- Restructured the `forwardPorts` array in dev container configuration
for clarity.
- Removed a trailing comma in the `vscode` extensions list to adhere to
JSON format rules.
- **Documentation**
- Added comments to clarify the handling of undefined values in
two-factor authentication verification.
- **Database**
- Implemented a SQL migration script for creating a default deleted user
in the system.
<!-- end of auto-generated comment: release notes by coderabbit.ai -->
## Description
This feature allows us to have a dedicated page to view details for a
document.
The current `/documents/[id]` page has been moved to
`/documents/[id]/edit`.
The new `/documents/[id]` page will now display general information on
the document itself.
This will allow us to provide more details relating to a document in the
future, such as version history.
## Examples
These may be outdated as deployment failed
Login via example@documenso.com
Draft document no recipients:
https://stg-7hpkvyc5i-documenso.vercel.app/documents/446
Draft document with recipients:
https://stg-7hpkvyc5i-documenso.vercel.app/documents/440
Pending document:
https://stg-7hpkvyc5i-documenso.vercel.app/documents/447
Completed document:
https://stg-7hpkvyc5i-documenso.vercel.app/documents/448
Pending teams document:
https://stg-7hpkvyc5i-documenso.vercel.app/t/hello/documents/449/
## Checklist
<!--- Please check the boxes that apply to this pull request. -->
<!--- You can add or remove items as needed. -->
- [ ] I have tested these changes locally and they work as expected.
- [ ] I have added/updated tests that prove the effectiveness of these
changes.
- [X] I have followed the project's coding style guidelines.
## Additional Notes
When a user "sends" a document (DRAFT -> PENDING), should we redirect
them to the document/id page, or keep it how it currently is and have it
redirect to `/documents` page?
Disables the generation of the blog and content pages using
generateStaticPaths to deal with a regression with routing
introduced with next-runtime-env.
## Description
Add support for enterprise billing plans.
Enterprise billing plans by default get access to everything early
adopters do:
- Unlimited teams
- Unlimited documents
They will also get additional features in the future.
## Notes
Pending webhook updates to support enterprise onboarding.
Rolled back env changes `NEXT_PUBLIC_PROJECT` since it doesn't seem to
work.
improved document-dropzone ui for small vertical screens (screens less
than 800px vertically)
Although it can still become congested on really small vertical screens,
but possibility is really low.
fixes: #840
Adding a security.txt file enables security researchers to quickly and
easily see where they can submit security issues and know that they are
being taken serious. From the proposal website:
> "When security risks in web services are discovered by independent
security researchers who understand the severity of the risk, they often
lack the channels to disclose them properly. As a result, security
issues may be left unreported. security.txt defines a standard to help
organizations define the process for security researchers to disclose
security vulnerabilities securely.”
See also https://securitytxt.org
## Description
Currently we're not restricting team transfer and email verification
tokens from flowing into the frontend.
This changes restricts it to only return the required information
instead of the whole data object.
## Description
Currently the document redirect URL feature is preventing documents from
being created unless a redirect URL is provided.
During the document edit flow, the redirect URL is hidden in an advanced
tab with the value of an empty string, which will always fail the
current Zod validation since `optional` requires undefined to pass.
There are multiple ways to fix this, but I think this is the easiest
method where we can assume an empty string is valid.
## Description
Fixed issue where setting a recipient role as CC will prevent any
further changes as it is considered as "sent" and "signed".
## Other changes
- Prevent editing document after completed
- Removed CC and Viewers from the field recipient list since they will
never be filled
- Minor UI issues
## Checklist
- [X] I have tested these changes locally and they work as expected.
- [X] I have added/updated tests that prove the effectiveness of these
changes.
- [X] I have followed the project's coding style guidelines.
## Description
Add the ability to feature flag the teams feature via UI.
Also added minor UI changes
## Checklist
- [X] I have tested these changes locally and they work as expected.
- [X] I have added/updated tests that prove the effectiveness of these
changes.
- [X] I have followed the project's coding style guidelines.
## Description
Fixed issue where you are prevented from removing fields for a recipient
that has multiple fields.
Example:
Recipient has 3 fields, you remove 1 and proceed to next step. In the
next step the field reappears as it was not deleted.
## Checklist
- [X] I have tested these changes locally and they work as expected.
- [X] I have added/updated tests that prove the effectiveness of these
changes.
- [X] I have followed the project's coding style guidelines.
## Description
Add support for teams which will allow users to collaborate on
documents.
Teams features allows users to:
- Create, manage and transfer teams
- Manage team members
- Manage team emails
- Manage a shared team inbox and documents
These changes do NOT include the following, which are planned for a
future release:
- Team templates
- Team API
- Search menu integration
## Testing Performed
- Added E2E tests for general team management
- Added E2E tests to validate document counts
## Checklist
- [X] I have tested these changes locally and they work as expected.
- [X] I have added/updated tests that prove the effectiveness of these
changes.
- [ ] I have updated the documentation to reflect these changes, if
applicable.
- [X] I have followed the project's coding style guidelines.
## Description
**Fixed document limitation bypassing issues through templates.**
Previously, users could bypass document restrictions by utilizing
templates even after reaching their limitations. This fix ensures that
templates will no longer function as a workaround when users reach their
document limits.
## Changes
1. imported `useLimits` hook on `data-table-templates.tsx`
2. Disabled the 'Use Template' button when the user reaches their limit.
3. Added an Alert Component on top of the templates page to notify users
that they can't use templates anymore because they have reached their
limit.
4. Used `getServerLimits` hook on `template-router` to a condition on
the server.
## Example

## Issue
Closes#883
## Description
Adds the ability to see the events relating to the account.
Event data includes:
- Device
- IP Address
- Time
- Action
Actions are:
- Profile update
- Account linked to SSO (Example user signs in with Google after
creating a email/password account)
- Enable 2FA
- Disable 2FA
- Reset password
- Update password
- Sign out
- Sign in
- Sign in fail
- Sign in 2FA fail
## Changes
- Added audit logs
- Updated 2FA dialogs to have consistent footers
- Update `/settings/security/page` layout
## Testing Performed
Tested events:

More tested events:

## Checklist
- [X] I have tested these changes locally and they work as expected.
- [X] I have followed the project's coding style guidelines.
## Additional Notes
- Not sure if we really want to record the sign out event or not
- Might want to design breadcrumbs for nested setting pages
## Description
Currently the count for the documents table tabs do not display the
correct values when the period filter is applied.
## Changes Made
- Updated `getStats` to support filtering on period
## Testing Performed
- Tested to see if the documents tab count were being filtered based on
the period
## Checklist
- [X] I have tested these changes locally and they work as expected.
- [X] I have followed the project's coding style guidelines.
## Description
This pull request solves the problem where the avatar component within
the document list has the same z-index value as the header component,
causing the avatar to be above the header. When two elements have the
same z-index value, the last one takes priority!
## Related Issue
Fixes#870
## Changes Made
1. Increases the value of the header's `z-index` by `10` (the current
value is `50`
## Description
Currently we are required to ensure PII data is not passed around in
search parameters and in the open for GDPR reasons.
Allowing us to encrypt and decrypt values with expiry dates will allow
us to ensure this doesn't happen.
## Changes Made
- Added TPRC router for encryption method
## Testing Performed
- Tested encrypting and decrypting data with and without `expiredAt`
- Tested via directly accessing API and also via trpc in react
components
- Tested parsing en email search param in a page and decrypting it
successfully
## Checklist
- [X] I have tested these changes locally and they work as expected.
- [X] I have followed the project's coding style guidelines.
When you're in the `/documents` page in the dashboard, if you hover over
a draft and a completed document, you'll see different URLs.
At the moment, the shortcut tries to go to the following URL for a
completed document `/documents/{doc-id}`.
However, that's the wrong URL, since the URL for a completed doc is
`/sign/{token}` when the user is the recipient, not the one that sent
the document for signing.
If it's the document owner & the document is completed, the URL is fine
as `/documents/{doc-id}`.
---------
Co-authored-by: Lucas Smith <me@lucasjamessmith.me>
Fixed the deleting signature block issue on touchscreens, for some
reason the `onClick` event isn't working on the touchscreens that's why
I've added `onTouchEnd` event to delete the signature block when the
user clicks on it.
Extracts the API implementation to a package so we can
potentially reuse it across different applications in the
event that we move off using a Next.js API route.
Additionally tidies up the tokens page and form to be more simplified.
## Description
Currently there are various z-index values that are causing:
- Toasts to be placed behind dialog blur background
- Menu being cropped off by header
## Changes Made
- Revert `z-[1000]` back to `z-50` for the header (not exactly sure why
it was bumped)
- Refactor z-indexes over 9000 to start from 1000
- Ensure z-index of toast is higher than dialog
This PR makes a small but useful tweak to the `DeleteDocumentDialog`.
Now, the input field gets cleared whenever the dialog is opened. Here’s
what’s changed:
1. **Clear Field After Deleting**: After you delete something and open
the dialog again, it won’t show the old, deleted text anymore. It’s
clean and ready for the next delete.
2. **Type Again to Confirm**: If you type something but close the dialog
without deleting, you’ll have to type it again next time. This way, it
makes sure the user really mean to delete something and didn't do it by
mistake.
Demo Link:
See the old vs. new in action here:
https://www.loom.com/share/80eca0d3b1994f7cbcab6f222db2dbfe?sid=ebc6135c-345e-4640-b395-daff190a96e7
It’s a small change, but it makes the delete process safer and smoother.
## Description
Previously we assumed that there can only be 1 subscription per user.
However, that will soon no longer the case with the introduction of the
Teams subscription.
This PR will apply the required migrations to support multiple
subscriptions.
## Changes Made
- Updated the Prisma schema to allow for multiple `Subscriptions` per
`User`
- Added a Stripe `customerId` field to the `User` model
- Updated relevant billing sections to support multiple subscriptions
## Testing Performed
- Tested running the Prisma migration on a demo database created on the
main branch
Will require a lot of additional testing.
## Checklist
- [ ] I have tested these changes locally and they work as expected.
- [ ] I have added/updated tests that prove the effectiveness of these
changes.
- [X] I have followed the project's coding style guidelines.
## Additional Notes
Added the following custom SQL statement to the migration:
> DELETE FROM "Subscription" WHERE "planId" IS NULL OR "priceId" IS
NULL;
Prior to deployment this will require changes to Stripe products:
- Adding `type` meta attribute
---------
Co-authored-by: Lucas Smith <me@lucasjamessmith.me>
Currently customers with inactive/expired plans will be shown the
BillingPlans component but upon hitting the subscribe button they will
be redirected to their portal where they are unable to complete a
checkout.
To resolve this we check for expiration of their subscription and use a
normal stripe checkout instead.
* feat: add link to homepage on the complete sign page for logged in users
* feat: added ChevronLeft icon to the link
* feat: remove icon from the link
Change "Open" links to "Open Startup" to reduce confusion about how to open the web app.
Additionally add the OSS Friends link to the footer since it was dropped during some changes.
Implementation of a universal upload allowing for multiple storage backends
starting with `database` and `s3`.
Allows clients to put and retrieve files from either client or server using
a blend of client and server actions.
* feat: update document table layout
- Removed dashboard page
- Removed redundant ID column
- Moved date to first column
- Added estimated locales for SSR dates
- Fixed z-index when dragging pre-existing fields
- Refactored document flow
- Added button spinner
- Added animation for document flow slider
- Updated drag and drop fields
- Updated document flow so it adjusts to the height of the PDF
- Updated claim plan dialog
This change actually makes the authoring flow work for
the most part by tying in emailing and more.
We have also done a number of quality of life updates to
simplify the codebase overall making it easier to continue
work on the refresh.
Improve the stripe webhook endpoint by checking for
subscriptions prior to performing an update to handle
cases where accounts have no created subscription.
This can happen in sitations such as when a checkout_session has been created but the payment fails.
description:Create a bug report to help us improve
body:
- type:markdown
attributes:
value:Thank you for reporting an issue.
Please fill in as much of the form below as you're able to.
- type:textarea
attributes:
label:Issue Description
description:Please provide a clear and concise description of the problem.
- type:textarea
attributes:
label:Steps to Reproduce
description:Please provide step-by-step instructions to reproduce the issue. Include code snippets, error messages, and any other relevant information.
- type:textarea
attributes:
label:Expected Behavior
description:Describe what you expected to happen.
- type:textarea
attributes:
label:Current Behavior
description:Describe what is currently happening.
- type:textarea
attributes:
label:Screenshots (optional)
description:If applicable, add screenshots to help explain the issue.
- type:input
attributes:
label:Operating System [e.g., Windows 10]
- type:input
attributes:
label:Browser [e.g., Chrome, Firefox]
- type:input
attributes:
label:Version [e.g., 2.0.1]
- type:checkboxes
attributes:
label:Please check the boxes that apply to this issue report.
options:
- label:I have searched the existing issues to make sure this is not a duplicate.
- label:I have provided steps to reproduce the issue.
- label:I have included relevant environment information.
- label:I have included any relevant screenshots.
- label:I understand that this is a voluntary contribution and that there is no guarantee of resolution.
- label:I want to work on creating a PR for this issue if approved
description:Suggest a new idea or enhancement for this project
body:
- type:markdown
attributes:
value:Please provide a clear and concise title for your feature request
- type:textarea
attributes:
label:Feature Description
description:Describe the feature you are requesting in detail. Explain what problem it solves or what value it adds to the project.
- type:textarea
attributes:
label:Use Case
description:Provide a scenario or use case where this feature would be beneficial. Explain how users would interact with this feature and why it's important.
- type:textarea
attributes:
label:Proposed Solution
description:If you have an idea of how this feature could be implemented, describe it here. Include any technical details, UI/UX considerations, or design suggestions.
- type:textarea
attributes:
label:Alternatives (optional)
description:Are there any alternative ways to achieve the same goal? Describe other approaches that could be considered if this feature is not implemented.
- type:textarea
attributes:
label:Additional Context
description:Add any additional context or information that might be relevant to the feature request.
- type:checkboxes
attributes:
label:Please check the boxes that apply to this feature request.
options:
- label:I have searched the existing feature requests to make sure this is not a duplicate.
- label:I have provided a detailed description of the requested feature.
- label:I have explained the use case or scenario for this feature.
- label:I have included any relevant technical details or design suggestions.
- label:I understand that this is a suggestion and that there is no guarantee of implementation.
- label:I want to work on creating a PR for this issue if approved
console.log(`Issue Count For ${username}: ${issueCount}`);
if (issueCount > 3) {
let issueCountMessage = `### 🚨 Documenso Police 🚨`;
issueCountMessage += `\n@${username} has ${issueCount} open issues assigned already. Consider whether this issue should be assigned to them or left open for another contributor.`;
Hey There! and thank you for opening this pull request! 📝👋🏼
We require pull request titles to follow the [Conventional Commits Spec](https://www.conventionalcommits.org/en/v1.0.0/) and it looks like your proposed title needs to be adjusted.
@ -5,23 +5,39 @@ If you plan to contribute to Documenso, please take a moment to feel awesome ✨
## Before getting started
- Before jumping into a PR be sure to search [existing PRs](https://github.com/documenso/documenso/pulls) or [issues](https://github.com/documenso/documenso/issues) for an open or closed item that relates to your submission.
- Select and issue from [here](https://github.com/documenso/documenso/issues) or create a new one
- Consider the results from the discussion in the issue
- Select an issue from [here](https://github.com/documenso/documenso/issues) or create a new one
- Consider the results from the discussion on the issue
- Accept the [Contributor License Agreement](https://documen.so/cla) to ensure we can accept your contributions.
## Taking issues
Before taking an issue, ensure that:
- The issue has been assigned the public label
- The issue is clearly defined and understood
- No one has been assigned to the issue
- No one has expressed intention to work on it
You can then:
1. Comment on the issue with your intention to work on it
2. Begin work on the issue
Always feel free to ask questions or seek clarification on the issue.
## Developing
The development branch is <code>main</code>. All pull request should be made against this branch. If you need help getting started, [join us on Discord](https://documen.so/discord).
The development branch is <code>main</code>. All pull requests should be made against this branch. If you need help getting started, [join us on Discord](https://documen.so/discord).
1. [Fork](https://help.github.com/articles/fork-a-repo/) this repository to your
own GitHub account and then
[clone](https://help.github.com/articles/cloning-a-repository/) it to your local device.
2. Create a new branch:
- Create a new branch (include the issue id and somthing readable):
- Create a new branch (include the issue id and something readable):
Signing documents is a fundamental building block of private, economic, and government interactions. Access to easy and secure signing to participate in society should therefore be a fundamental right for everyone. The technology to enable this should be accessible and widespread.
We know that open source is the key to solving this need once and for all to benefit all humankind. Using open source kickstarts innovation by putting the open sharing of ideas and solutions first. With Documenso, we will create an open and globally accessible signing platform to empower users, customers, and developers to fulfill their needs. Documenso is built by and for the global community, listening and implementing what is needed. Being transparent with the code and the processes that use it brings trust and security to the platform.
We build Documenso for longevity and scale by embracing the capital efficiency and inclusiveness of the Commercial Open Source (COSS) movement. We are building a global commodity for the world.
> This project is currently under community review and will publish it's first production release soon™.
## About Documenso
## About this project
Signing documents digitally should be fast and easy and should be the best practice for every document signed worldwide. This is technically quite easy today, but it also introduces a new party to every signature: The signing tool providers. While this is not a problem in itself, it should make us think about how we want these providers of trust to work. Documenso aims to be the world's most trusted document-signing tool. This trust is built by empowering you to self-host Documenso and review how it works under the hood.
Signing documents digitally is fast, easy and should be best practice for every document signed worldwide. This is technically quite easy today, but it also introduces a new party to every signature: The signing tool providers. While this is not a problem in itself, it should make us think about how we want these providers of trust to work. Documenso aims to be the world's most trusted document signing tool. This trust is built by empowering you to self-host Documenso and review how it works under the hood. Join us in creating the next generation of open trust infrastructure.
Join us in creating the next generation of open trust infrastructure.
The current project goal is to <b>[release a production ready version](https://github.com/documenso/documenso/milestone/1)</b> for self-hosting as soon as possible. If you want to help making that happen you can:
We're currently working on a redesign of the application, including a revamp of the codebase, so Documenso can be more intuitive to use and robust to develop upon.
- Check out the first source code release in this repository and test it
- Tell us what you think in the current [Discussions](https://github.com/documenso/documenso/discussions)
- Join the [Slack Channel](https://documen.so/slack) for any questions and getting to know to other community members
- ⭐ the repository to help us raise awareness
- Spread the word on Twitter, that Documenso is working towards a more open signing tool
- Fix or create [issues](https://github.com/documenso/documenso/issues), that are needed for the first production release
- Check out the first source code release in this repository and test it.
- Tell us what you think in the [Discussions](https://github.com/documenso/documenso/discussions).
- Join the [Discord server](https://documen.so/discord) for any questions and getting to know to other community members.
- ⭐ the repository to help us raise awareness.
- Spread the word on Twitter that Documenso is working towards a more open signing tool.
- Fix or create [issues](https://github.com/documenso/documenso/issues), that are needed for the first production release.
## Contributing
- To contribute please see our [contribution guide](https://github.com/documenso/documenso/blob/main/CONTRIBUTING.md).
- To contribute, please see our [contribution guide](https://github.com/documenso/documenso/blob/main/CONTRIBUTING.md).
# Tech
## Contact us
Documenso is built using awesome open source tech including:
Contact us if you are interested in our Enterprise plan for large organizations that need extra flexibility and control.
- [React-PDF for viewing PDFs](https://github.com/wojtekmaj/react-pdf)
- [PDF-Lib for PDF manipulation](https://github.com/Hopding/pdf-lib)
- [Zod for schema declaration and validation](https://zod.dev/)
- [Lucide React for icons in React app](https://lucide.dev/)
- [Framer Motion for motion library](https://www.framer.com/motion/)
- [Radix UI for component library](https://www.radix-ui.com/)
- Check out `/package.json` and `/apps/web/package.json` for more
- Support for [opensignpdf (requires Java on server)](https://github.com/open-pdf-sign) is currently planned.
<ahref="https://cal.com/timurercan/enterprise-customers?utm_source=banner&utm_campaign=oss"><imgalt="Book us with Cal.com"src="https://cal.com/book-with-cal-dark.svg"/></a>
- [PostgreSQL (local or remote)](https://www.postgresql.org/download/)
<!-- - Support for [opensignpdf (requires Java on server)](https://github.com/open-pdf-sign) is currently planned. -->
## Developer Quickstart
## Local Development
### Requirements
To run Documenso locally, you will need
- Node.js (v18 or above)
- Postgres SQL Database
- Docker (optional)
### Developer Quickstart
> **Note**: This is a quickstart for developers. It assumes that you have both [docker](https://docs.docker.com/get-docker/) and [docker-compose](https://docs.docker.com/compose/) installed on your machine.
Want to get up and running quickly? Follow these steps:
- [Clone the repository](https://help.github.com/articles/cloning-a-repository/) it to your local device.
1. [Fork this repository](https://docs.github.com/en/pull-requests/collaborating-with-pull-requests/working-with-forks/about-forks) to your GitHub account.
```sh
git clone https://github.com/documenso/documenso
```
After forking the repository, clone it to your local device by using the following command:
- Set up your `.env` file using the recommendations in the `.env.example` file.
- Run `npm run dx` in the root directory
- This will spin up a postgres database and inbucket mail server in docker containers.
That's it! You should now be able to access the app at http://localhost:3000
2. Set up your `.env` file using the recommendations in the `.env.example` file. Alternatively, just run `cp .env.example .env` to get started with our handpicked defaults.
Incoming mail will be available at http://localhost:9000
3. Run `npm run dx` in the root directory
Your database will also be available on port `54320`. You can connect to it using your favorite database client.
- This will spin up a postgres database and inbucket mailserver in a docker container.
4. Run `npm run dev` in the root directory
5. Want it even faster? Just use
```sh
npm run d
```
#### Access Points for Your Application
1.**App** - http://localhost:3000
2.**Incoming Mail Access** - http://localhost:9000
3.**Database Connection Details**
- **Port**: 54320
- **Connection**: Use your favorite database client to connect using the provided port.
Follow these steps to setup documenso on you local machine:
### Manual Setup
- [Clone the repository](https://help.github.com/articles/cloning-a-repository/) it to your local device.
```sh
git clone https://github.com/documenso/documenso
```
- Run <code>npm i</code> in root directory
- Rename <code>.env.example</code> to <code>.env</code>
- Set DATABASE_URL value in .env file
- You can use the provided test database url (may be wiped at any point)
- Or setup a local postgres sql instance (recommended)
- Create the database scheme by running <code>db-migrate:dev</code>
- Setup your mail provider
- Set <code>SENDGRID_API_KEY</code> value in .env file
- You need a SendGrid account, which you can create [here](https://signup.sendgrid.com/).
- Documenso uses [Nodemailer](https://nodemailer.com/about/) so you can easily use your own SMTP server by setting the <code>SMTP\_\* variables</code> in your .env
- Run <code>npm run dev</code> root directory to start
- Register a new user at http://localhost:3000/signup
Follow these steps to setup Documenso on your local machine:
1. [Fork this repository](https://docs.github.com/en/pull-requests/collaborating-with-pull-requests/working-with-forks/about-forks) to your GitHub account.
After forking the repository, clone it to your local device by using the following command:
3. Create your `.env` from the `.env.example`. You can use `cp .env.example .env` to get started with our handpicked defaults.
4. Set the following environment variables:
- NEXTAUTH_URL
- NEXTAUTH_SECRET
- NEXT_PUBLIC_WEBAPP_URL
- NEXT_PUBLIC_MARKETING_URL
- NEXT_PRIVATE_DATABASE_URL
- NEXT_PRIVATE_DIRECT_DATABASE_URL
- NEXT_PRIVATE_SMTP_FROM_NAME
- NEXT_PRIVATE_SMTP_FROM_ADDRESS
5. Create the database schema by running `npm run prisma:migrate-dev`
6. Run `npm run dev` in the root directory to start
7. Register a new user at http://localhost:3000/signup
---
- Optional: Seed the database using <code>npm run db-seed</code> to create a test user and document
- Optional: Upload and sign <code>apps/web/resources/example.pdf</code> manually to test your setup
- Optional: Seed the database using `npm run prisma:seed -w @documenso/prisma` to create a test user and document.
- Optional: Create your own signing certificate.
- To generate your own using these steps and a Linux Terminal or Windows Subsystem for Linux (WSL), see **[Create your own signing certificate](./SIGNING.md)**.
- Optional: Create your own signing certificate
- A demo certificate is provided in `/app/web/resources/certificate.p12`
- To generate your own using these steps and a Linux Terminal or Windows Subsystem for Linux (WSL) see **[Create your own signing certificate](#creating-your-own-signing-certificate)**.
### Run in Gitpod
## Updating
- Click below to launch a ready-to-use Gitpod workspace in your browser.
- If you pull the newest version from main, using <code>git pull</code>, it may be necessary to regenerate your database client
- You can do this by running the generate command in `/packages/prisma`:
```sh
npx prisma generate
```
- This is not necessary on first clone.
[](https://gitpod.io/#https://github.com/documenso/documenso)
# Creating your own signing certificate
### Run in DevContainer
For the digital signature of your documents you need a signing certificate in .p12 format (public and private key). You can buy one (not recommended for dev) or use the steps to create a self-signed one:
We support DevContainers for VSCode. [Click here to get started.](https://vscode.dev/redirect?url=vscode://ms-vscode-remote.remote-containers/cloneInVolume?url=https://github.com/documenso/documenso)
1. Generate a private key using the OpenSSL command. You can run the following command to generate a 2048-bit RSA key:\
<code>openssl genrsa -out private.key 2048</code>
### Video walkthrough
2. Generate a self-signed certificate using the private key. You can run the following command to generate a self-signed certificate:\
This will prompt you to enter some information, such as the Common Name (CN) for the certificate. Make sure you enter the correct information. The -days parameter sets the number of days for which the certificate is valid.
3. Combine the private key and the self-signed certificate to create the p12 certificate. You can run the following command to do this: \
4. You will be prompted to enter a password for the p12 file. Choose a strong password and remember it, as you will need it to use the certificate (**can be empty for dev certificates**)
5. Place the certificate <code>/apps/web/resources/certificate.p12</code>
If you're a visual learner and prefer to watch a video walkthrough of setting up Documenso locally, check out this video:
# Docker
[](https://youtu.be/Y0ppIQrEnZs)
> We are still working on the publishing of docker images, in the meantime you can follow the steps below to create a production ready docker image.
## Docker
Want to create a production ready docker image? Follow these steps:
We provide a Docker container for Documenso, which is published on both DockerHub and GitHub Container Registry.
- Run `./docker/build.sh` in the root directory.
- Publish the image to your docker registry of choice.
You can pull the Docker image from either of these registries and run it with your preferred container hosting provider.
- Docker support
- One-Click-Deploy on Render.com Deploy
Please note that you will need to provide environment variables for connecting to the database, mailserver, and so forth.
# Troubleshooting
For detailed instructions on how to configure and run the Docker container, please refer to the [Docker README](./docker/README.md) in the `docker` directory.
## Support IPv6
## Self Hosting
In case you are deploying to a cluster that uses only IPv6. You can use a custom command to pass a parameter to the NextJS start command
We support a variety of deployment methods, and are actively working on adding more. Stay tuned for updates!
> Please note that the below deployment methods are for v0.9, we will update these to v1.0 once it has been released.
Then, inside the `documenso` folder, copy the example env file:
```
cp .env.example .env
```
The following environment variables must be set:
-`NEXTAUTH_URL`
-`NEXTAUTH_SECRET`
-`NEXT_PUBLIC_WEBAPP_URL`
-`NEXT_PUBLIC_MARKETING_URL`
-`NEXT_PRIVATE_DATABASE_URL`
-`NEXT_PRIVATE_DIRECT_DATABASE_URL`
-`NEXT_PRIVATE_SMTP_FROM_NAME`
-`NEXT_PRIVATE_SMTP_FROM_ADDRESS`
> If you are using a reverse proxy in front of Documenso, don't forget to provide the public URL for both `NEXTAUTH_URL` and `NEXT_PUBLIC_WEBAPP_URL` variables!
Now you can install the dependencies and build it:
```
npm i
npm run build:web
npm run prisma:migrate-deploy
```
Finally, you can start it with:
```
cd apps/web
npm run start
```
This will start the server on `localhost:3000`. For now, any reverse proxy can then do the frontend and SSL termination.
> If you want to run with another port than 3000, you can start the application with `next -p <ANY PORT>` from the `apps/web` folder.
### Run as a service
You can use a systemd service file to run the app. Here is a simple example of the service running on port 3500 (using 3000 by default):
```bash
[Unit]
Description=documenso
After=network.target
[Service]
Environment=PATH=/path/to/your/node/binaries
Type=simple
User=www-data
WorkingDirectory=/var/www/documenso/apps/web
ExecStart=/usr/bin/next start -p 3500
TimeoutSec=15
Restart=always
[Install]
WantedBy=multi-user.target
```
### Railway
[](https://railway.app/template/bG6D4p)
### Render
[](https://render.com/deploy?repo=https://github.com/documenso/documenso)
### Koyeb
[](https://app.koyeb.com/deploy?type=git&repository=github.com/documenso/documenso&branch=main&name=documenso-app&builder=dockerfile&dockerfile=/docker/Dockerfile)
## Elestio
[](https://elest.io/open-source/documenso)
## Troubleshooting
### I'm not receiving any emails when using the developer quickstart.
When using the developer quickstart, an [Inbucket](https://inbucket.org/) server will be spun up in a docker container that will store all outgoing emails locally for you to view.
The Web UI can be found at http://localhost:9000, while the SMTP port will be on localhost:2500.
### Support IPv6
If you are deploying to a cluster that uses only IPv6, You can use a custom command to pass a parameter to the Next.js start command
For local docker run
@ -227,5 +339,25 @@ containers:
- start
- --
- -H
- "::"
- '::'
```
### I can't see environment variables in my package scripts.
Wrap your package script with the `with:env` script like such:
```
npm run with:env -- npm run myscript
```
The same can be done when using `npx` for one of the bin scripts:
```
npm run with:env -- npx myscript
```
This will load environment variables from your `.env` and `.env.local` files.
For the digital signature of your documents you need a signing certificate in .p12 format (public and private key). You can buy one (not recommended for dev) or use the steps to create a self-signed one:
1. Generate a private key using the OpenSSL command. You can run the following command to generate a 2048-bit RSA key:
`openssl genrsa -out private.key 2048`
2. Generate a self-signed certificate using the private key. You can run the following command to generate a self-signed certificate:
This will prompt you to enter some information, such as the Common Name (CN) for the certificate. Make sure you enter the correct information. The -days parameter sets the number of days for which the certificate is valid.
3. Combine the private key and the self-signed certificate to create the p12 certificate. You can run the following command to do this:
4. You will be prompted to enter a password for the p12 file. Choose a strong password and remember it, as you will need it to use the certificate (**can be empty for dev certificates**)
5. Place the certificate `/apps/web/resources/certificate.p12` (If the path does not exist, it needs to be created)
## Docker
> We are still working on the publishing of docker images, in the meantime you can follow the steps below to create a production ready docker image.
Want to create a production ready docker image? Follow these steps:
- cd into `docker` directory
- Make `build.sh` executable by running `chmod +x build.sh`
- Run `./build.sh` to start building the docker image.
- Publish the image to your docker registry of choice (or) If you prefer running the image from local, run the below command
-`-p` - Passes down which ports to use. First half is the host port, Second half is the app port. You can change the first half anything you want and reverse proxy to that port.
-`-v` - Volume let's you persist the data
-`--name` - Name of the container
-`documenso:latest` - Image you have built
## Deployment
We support a variety of deployment methods, and are actively working on adding more. Stay tuned for updates!
## Railway
[](https://railway.app/template/DjrRRX)
## Render
[](https://render.com/deploy?repo=https://github.com/documenso/documenso)
This is a [Next.js](https://nextjs.org/) project bootstrapped with [`create-next-app`](https://github.com/vercel/next.js/tree/canary/packages/create-next-app).
## Getting Started
First, run the development server:
```bash
npm run dev
# or
yarn dev
# or
pnpm dev
# or
bun dev
```
Open [http://localhost:3002](http://localhost:3002) with your browser to see the result.
You can start editing the page by modifying `app/page.tsx`. The page auto-updates as you edit the file.
This project uses [`next/font`](https://nextjs.org/docs/basic-features/font-optimization) to automatically optimize and load Inter, a custom Google Font.
## Learn More
To learn more about Next.js, take a look at the following resources:
- [Next.js Documentation](https://nextjs.org/docs) - learn about Next.js features and API.
- [Learn Next.js](https://nextjs.org/learn) - an interactive Next.js tutorial.
You can check out [the Next.js GitHub repository](https://github.com/vercel/next.js/) - your feedback and contributions are welcome!
## Deploy on Vercel
The easiest way to deploy your Next.js app is to use the [Vercel Platform](https://vercel.com/new?utm_medium=default-template&filter=next.js&utm_source=create-next-app&utm_campaign=create-next-app-readme) from the creators of Next.js.
Check out our [Next.js deployment documentation](https://nextjs.org/docs/deployment) for more details.
description: Learn how to contribute translations to Documenso and become part of our community.
---
import { Callout, Steps } from 'nextra/components';
# Contributing Translations
We are always open for help with translations! Currently we utilise AI to generate the initial translations for new languages, which are then improved over time by our awesome community.
If you are looking for development notes on translations, you can find them [here](/developers/local-development/translations).
<Callout type="info">
Contributions are made through GitHub Pull Requests, so you will need a GitHub account to
contribute.
</Callout>
## Overview
We store our translations in PO files, which are located in our GitHub repository [here](https://github.com/documenso/documenso/tree/main/packages/lib/translations).
The translation files are organized into folders represented by their respective language codes (`en` for English, `de` for German, etc). Each language folder contains three PO files:
1. `web.po`: Translations for the web application
2. `marketing.po`: Translations for the marketing application
3. `common.po`: Shared translations between web and marketing
Each PO file contains translations which look like this:
msgid "Want to send slick signing links like this one? <0>Check out Documenso.</0>"
msgstr "Möchten Sie auffällige Signatur-Links wie diesen senden? <0>Überprüfen Sie Documenso.</0>"
```
- `msgid`: The original text in English (never edit this manually)
- `msgstr`: The translated text in the target language
<Callout type="warning">
Notice the `<0>` tags? These represent HTML elements and must remain in both the `msgid` and `msgstr`. Make sure to translate the content between these tags while keeping the tags intact.
</Callout>
## How to Contribute
### Updating Existing Translations
1. Fork the repository.
2. Navigate to the appropriate language folder.
3. Open the PO file you want to update (web.po, marketing.po, or common.po).
4. Make your changes, ensuring you follow the PO file format.
5. Commit your changes with a message such as `chore: update German translations`
6. Create a Pull Request.
### Adding a New Language
If you want to add translations for a language that doesn't exist yet:
1. Create an issue in our GitHub repository requesting the addition of the new language.
2. Wait for our team to review and approve the request.
3. Once approved, we will set up the necessary files and kickstart the translations with AI to provide initial coverage.
## Need Help?
<Callout type="info">
If you have any questions, hop into our [Discord](https://documen.so/discord) and ask us directly!
</Callout>
Thank you for helping make Documenso more accessible to users around the world!
description: Learn how to contribute to Documenso and become part of our community.
---
import { Callout, Steps } from 'nextra/components';
# Contributing to Documenso
If you plan to contribute to Documenso, please take a moment to feel awesome. People like you are what open source is about. Any contributions, no matter how big or small, are highly appreciated.
This guide will help you get started with contributing to Documenso.
## Before Getting Started
<Steps>
### Check the Existing Issues and Pull Requests
Search the existing [issues](https://github.com/documenso/documenso/issues) to see if someone else reported the same issue. Or, check the [existing PRs](https://github.com/documenso/documenso/pulls) to see if someone else is already working on the same thing.
### Creating a New Issue
If there is no issue or PR for the problem you are facing, feel free to create a new issue. Make sure to provide as much detail as possible, including the steps to reproduce the issue.
### Picking an Existing Issue
If you pick an existing issue, take into consideration the discussion on the issue.
### Contributor License Agreement
Accept the [Contributor License Agreement](https://documen.so/cla) to ensure we can accept your contributions.
</Steps>
## Taking Issues
Before taking an issue, ensure that:
- The issue has been assigned the public label.
- The issue is clearly defined and understood.
- No one has been assigned to the issue.
- No one has expressed the intention to work on it.
After that:
1. Comment on the issue with your intention to work on it.
2. Start working on the issue.
Feel free to ask for help, clarification or guidance if needed. We are here to help you.
## Developing
The development branch is `main`, and all pull requests should be made against this branch. Here's how you can get started with developing:
<Steps>
### Set Up Documenso Locally
To set up your local environment, check out the [local development](/developers/local-development) guide.
### Pick a Task
Find an issue to work on or create a new one.
> Before working on an issue, ensure that no one else is working on it. If no one is assigned to the issue, you can pick it up by leaving a comment and asking to assign it to you.
Before creating a new issue, check the existing issues to see if someone else has already reported it.
### Create a New Branch
After you're assigned an issue, you can start working on it. Create a new branch for your feature or bug fix.
When creating a branch, make sure that the branch name:
- starts with the correct prefix: `feat/` for new features, `fix/` for bug fixes, etc.
- includes the issue ID you are working on (if applicable).
In the pull request description, include `references #yyyy` or `fixes #yyyy` to link it to the issue you are working on.
### Implement Your Changes
Start working on the issue you picked up and implement the changes. Make sure to test your changes locally and ensure that they work as expected.
### Open a Pull Request
After implementing your changes, open a pull request against the `main` branch.
</Steps>
<Callout type="info">
If you need help getting started, [join us on Discord](https://documen.so/discord).
</Callout>
## Building
Before pushing code or creating pull requests, please ensure you can successfully create a successful production build. You can build the project by running the following command in your terminal:
```bash
npm run build
```
Once the project builds successfully, you can push your code changes or create a pull request.
<Callout type="info">
Remember to run tests and perform any necessary checks before finalizing your changes. As a
result, we can collaborate more effectively and maintain a high standard of code quality in our
description: Learn how to use embedding to bring signing to your own website or application
---
# Embedding
Our embedding feature lets you integrate our document signing experience into your own application or website. Whether you're building with React, Preact, Vue, Svelte, Solid, or using generalized web components, this guide will help you get started with embedding Documenso.
## Availability
Embedding is currently available for all users on a **Teams Plan** and above, as well as **Early Adopter's** within a team (Early Adopters can create a team for free).
In the future, we will roll out a **Platform Plan** that will offer additional enhancements for embedding, including the option to remove Documenso branding for a more customized experience.
## How Embedding Works
Embedding with Documenso allows you to handle document signing in two main ways:
1. **Using Direct Templates**: Using direct templates you can have an evergreen template that upon completion will create a new document within Documenso.
2. **Using a Signing Token**: A more advanced option for those running rich integrations with Documenso already. Given a recipients signing token you can embed the signing experience in your application rather than direct the recipient to Documenso.
_For most use-cases we recommend using direct templates, however if you have a need for a more advanced integration, we are happy to help you get started._
## Supported Frameworks
We support embedding across a range of popular JavaScript frameworks, including:
Additionally, we provide **web components** for more generalized use. However, please note that web components are still in their early stages and haven't been extensively tested.
## Embedding with Direct Templates
#### Instructions
To get started with embedding using a Direct Template we will need the URL segment which is also referred to as the token for the template.
You can find your URL/Token by performing the following steps:
1. **Navigate to your team's templates within Documenso**

2. **Click on the direct link template you want to embed**
This will copy the URL to your clipboard, e.g. `https://stg-app.documenso.com/d/-WoSwWVT-fYOERS2MI37k`
**For the above url the token is `-WoSwWVT-fYOERS2MI37k`**
3. Provide the token to the `EmbedDirectTemplate` component in your frameworks SDK
```jsx
import { EmbedDirectTemplate } from '@documenso/embed-react';
const MyEmbeddingComponent = () => {
const token = 'YOUR_TOKEN_HERE'; // Replace with the actual token
return <EmbedDirectTemplate token={token} />;
};
```
---
**Converting a regular template to a direct link template**
If you don't currently have any direct link templates you can easily create one by selecting the "Direct Link" option within the actions dropdown on the templates table.
This will show a dialog which will ask you to configure which recipient should be used as the direct link signer.

---
## Embedding with Signing Tokens
To embed the signing process for an ordinary document, you’ll need a **document signing token** for the recipient. This token provides the necessary access to load the document and facilitate the signing process securely.
#### Instructions
1. Retrieve the signing token for the recipient document you want to embed
This will typically be done using an API integration where signing tokens are provided as part of the response when creating a document. Alternatively you can manually get a signing link by clicking hovering over a recipients avatar and clicking their email on a document that you own.
With the signing url on our clipboard we can extract the token the same way we did for the direct link template.
So `https://stg-app.documenso.com/sign/lm7Tp2_yhvFfzdeJQzYQF` will become `lm7Tp2_yhvFfzdeJQzYQF`
2. Provide the token to the `EmbedSignDocument` component in your frameworks SDK
```jsx
import { EmbedSignDocument } from '@documenso/embed-react';
const MyEmbeddingComponent = () => {
const token = 'YOUR_TOKEN_HERE'; // Replace with the actual token
return <EmbedSignDocument token={token} />;
};
```
---
## Using Embedding in Your Application
Once you've obtained the appropriate tokens, you can integrate the signing experience into your application. For framework-specific instructions, please refer to the guides provided in our documentation for:
- [React](/developers/embedding/react)
- [Preact](/developers/embedding/preact)
- [Vue](/developers/embedding/vue)
- [Svelte](/developers/embedding/svelte)
- [Solid](/developers/embedding/solid)
If you're using **web components**, the integration process is slightly different. Keep in mind that web components are currently less tested but can still provide flexibility for general use cases.
## Stay Tuned for the Platform Plan
While embedding is already a powerful tool, we're working on a **Platform Plan** that will introduce even more functionality. This plan will offer:
- Additional customization options
- The ability to remove Documenso branding
- Additional controls for the signing experience
More details will be shared as we approach the release.
description: Learn how to use our embedding SDK within your Preact application.
---
# Preact Integration
Our Preact SDK provides a simple way to embed a signing experience within your Preact application. It supports both direct link templates and signing tokens.
## Installation
To install the SDK, run the following command:
```bash
npm install @documenso/embed-preact
```
## Usage
To embed a signing experience, you'll need to provide the token for the document you want to embed. This can be done in a few different ways, depending on your use case.
### Direct Link Template
If you have a direct link template, you can simply provide the token for the template to the `EmbedDirectTemplate` component.
```jsx
import { EmbedDirectTemplate } from '@documenso/embed-preact';
const MyEmbeddingComponent = () => {
const token = 'YOUR_TOKEN_HERE'; // Replace with the actual token
description: Learn how to use our embedding SDK within your React application.
---
# React Integration
Our React SDK provides a simple way to embed a signing experience within your React application. It supports both direct link templates and signing tokens.
## Installation
To install the SDK, run the following command:
```bash
npm install @documenso/embed-react
```
## Usage
To embed a signing experience, you'll need to provide the token for the document you want to embed. This can be done in a few different ways, depending on your use case.
### Direct Link Template
If you have a direct link template, you can simply provide the token for the template to the `EmbedDirectTemplate` component.
```jsx
import { EmbedDirectTemplate } from '@documenso/embed-react';
const MyEmbeddingComponent = () => {
const token = 'YOUR_TOKEN_HERE'; // Replace with the actual token
description: Learn how to use our embedding SDK within your Solid.js application.
---
# Solid.js Integration
Our Solid.js SDK provides a simple way to embed a signing experience within your Solid.js application. It supports both direct link templates and signing tokens.
## Installation
To install the SDK, run the following command:
```bash
npm install @documenso/embed-solid
```
## Usage
To embed a signing experience, you'll need to provide the token for the document you want to embed. This can be done in a few different ways, depending on your use case.
### Direct Link Template
If you have a direct link template, you can simply provide the token for the template to the `EmbedDirectTemplate` component.
```jsx
import { EmbedDirectTemplate } from '@documenso/embed-solid';
const MyEmbeddingComponent = () => {
const token = 'YOUR_TOKEN_HERE'; // Replace with the actual token
description: Learn how to use our embedding SDK within your Svelte application.
---
# Svelte Integration
Our Svelte SDK provides a simple way to embed a signing experience within your Svelte application. It supports both direct link templates and signing tokens.
## Installation
To install the SDK, run the following command:
```bash
npm install @documenso/embed-svelte
```
## Usage
To embed a signing experience, you'll need to provide the token for the document you want to embed. This can be done in a few different ways, depending on your use case.
### Direct Link Template
If you have a direct link template, you can simply provide the token for the template to the `EmbedDirectTemplate` component.
```html
<script lang="ts">
import { EmbedDirectTemplate } from '@documenso/embed-svelte';
const token = 'YOUR_TOKEN_HERE'; // Replace with the actual token
description: Learn how to use our embedding SDK within your Vue application.
---
# Vue Integration
Our Vue SDK provides a simple way to embed a signing experience within your Vue application. It supports both direct link templates and signing tokens.
## Installation
To install the SDK, run the following command:
```bash
npm install @documenso/embed-vue
```
## Usage
To embed a signing experience, you'll need to provide the token for the document you want to embed. This can be done in a few different ways, depending on your use case.
### Direct Link Template
If you have a direct link template, you can simply provide the token for the template to the `EmbedDirectTemplate` component.
```html
<script setup lang="ts">
import { EmbedDirectTemplate } from '@documenso/embed-vue';
const token = ref('YOUR_TOKEN_HERE'); // Replace with the actual token
description: Learn how to set up Documenso for local development.
---
# Local development
There are multiple ways of setting up Documenso for local development. At the moment of writing this documentation, there are 3 ways of running Documenso locally:
- [Using the developer quickstart with Docker](/developers/local-development/quickstart)
- [Manually setting up the development environment](/developers/local-development/manual)
description: Manually set up Documenso on your machine for local development.
---
import { Callout, Steps } from 'nextra/components';
# Manual Setup
Follow these steps to set up Documenso on your local machine:
<Steps>
### Fork Documenso
Fork the [Documenso repository](https://docs.github.com/en/pull-requests/collaborating-with-pull-requests/working-with-forks/about-forks) to your GitHub account.
### Clone Repository
After forking the repository, clone it to your local device by using the following command:
description: Quickly set up Documenso on your machine for local development with Docker and Docker Compose.
---
import { Callout, Steps } from 'nextra/components';
# Developer Quickstart
<Callout type="info">
**Note**: This guide assumes that you have both [docker](https://docs.docker.com/get-docker/) and
[docker-compose](https://docs.docker.com/compose/) installed on your machine.
</Callout>
Want to get up and running quickly? Follow these steps:
<Steps>
### Fork Documenso
Fork the [Documenso repository](https://docs.github.com/en/pull-requests/collaborating-with-pull-requests/working-with-forks/about-forks) to your GitHub account.
### Clone Repository
After forking the repository, clone it to your local device by using the following command:
You will be prompted to enter some information, such as the certificate's Common Name (CN). Ensure that you provide the correct details. The `—days` parameter specifies the certificate's validity period.
### Create `p12` Certificate
Combine the private key and the self-signed certificate to create a `.p12` certificate. Use the following command:
If you get the error "Error: Failed to get private key bags", add the `-legacy` flag to the command `openssl pkcs12 -export -out certificate.p12 -inkey private.key -in certificate.crt -legacy`.
</Callout>
### `p12` Certificate Password
When you create the `.p12` certificate, you will be prompted to enter a password. Enter a strong password and keep it secure. Remember this password, as it will be required when using the certificate.
Note that for local development, the password can be left empty.
### Add Certificate to the Project
Finally, add the certificate to the project. Place the `certificate.p12` file in the `/apps/web/resources` directory. If the directory doesn't exist, create it.
The final file path should be `/apps/web/resources/certificate.p12`.
- [OpenAI](https://openai.com/) - Provides AI translations
Additional reading can be found in the [Lingui documentation](https://lingui.dev/introduction).
## Requirements
You **must** insert **`setupI18nSSR()`** when creating any of the following files:
- Server layout.tsx
- Server page.tsx
- Server loading.tsx
Server meaning it does not have `'use client'` in it.
```tsx
import { setupI18nSSR } from '@documenso/lib/client-only/providers/i18n.server';
export default function SomePage() {
setupI18nSSR(); // Required if there are translations within the page, or nested in components.
// Rest of code...
}
```
Additional information can be found [here.](https://lingui.dev/tutorials/react-rsc#pages-layouts-and-lingui)
## Quick guide
If you require more in-depth information, please see the [Lingui documentation](https://lingui.dev/introduction).
### HTML
Wrap all text to translate in **`<Trans></Trans>`** tags exported from **@lingui/macro** (not @lingui/react).
```html
<h1>
<Trans>Title</Trans>
</h1>
```
For text that is broken into elements, but represent a whole sentence, you must wrap it in a Trans tag so ensure the full message is extracted correctly.
```html
<h1>
<Trans>
This is one
<span className="text-foreground/60">full</span>
<a href="https://documenso.com">sentence</a>
</Trans>
</h1>
```
### Constants outside of react components
```tsx
import { Trans, msg } from '@lingui/macro';
import { useLingui } from '@lingui/react';
// Wrap text in msg`text to translate` when it's in a constant here, or another file/package.
export const CONSTANT_WITH_MSG = {
foo: msg`Hello`,
bar: msg`World`,
};
export const SomeComponent = () => {
const { _ } = useLingui();
return (
<div>
{/* This will render the correct translated text. */}
<p>{_(CONSTANT_WITH_MSG.foo)}</p>
</div>
);
};
```
### Plurals
Lingui provides a Plural component to make it easy. See full documentation [here.](https://lingui.dev/ref/macro#plural-1)
description: Learn how to create a Documenso API key and authenticate your API requests.
---
# API Authentication
Documenso uses API keys for authentication. An API key is a unique token that is generated for each client. The client must provide the key whenever it makes an API call. This way, Documenso can identify the clients making the requests and authorize their access to the API.
## Creating an API Key
To create an API key, navigate to the user settings page. Click on your avatar in the top right corner of the dashboard and select "**[User settings](https://app.documenso.com/settings)**" from the dropdown menu.

Once you're on the user settings page, navigate to the "**[API Tokens](https://app.documenso.com/settings/tokens)**" tab. The "API Token" page lists your existing keys and enables you to create new ones.

To create a new API key, you must:
- Choose a name (e.g. "zapier-key")
- We recommend using a descriptive name that helps you quickly identify the key and its purpose.
- Choose an expiration date
- You can set the key never to expire or choose when to become invalid: 7 days, 1 month, 3 months, 6 months, or 1 year.
After providing the required information, click the "Create token" button to generate the API key.

Once you've created the token, Documenso will display the key on the screen. Make sure to copy the key and store it securely. You won't be able to see the key again once you refresh/leave the page.
## Using the API Key
You must include the API key in the `Authorization` request header to authenticate your API requests. The format is `Authorization: api_xxxxxxxxxxxxxxxx`.
Here's a sample response from the API based on the above cURL request:
```json
{
"documents": [
{
"id": 11,
"userId": 2,
"teamId": null,
"title": "documenso",
"status": "PENDING",
"documentDataId": "ab2ecm1npk11rt5sp398waf7h",
"createdAt": "2024-04-25T11:05:18.420Z",
"updatedAt": "2024-04-25T11:05:36.328Z",
"completedAt": null
}
],
"totalPages": 1
}
```

The API key has access to your account and all its resources. Please keep it secure and do not share it with others. If you suspect your key has been compromised, you can revoke it from the "API Tokens" page in your user settings.
description: Learn how to interact with your documents programmatically using the Documenso public API.
---
# Public API
Documenso provides a public REST API enabling you to interact with your documents programmatically. The API exposes various HTTP endpoints that allow you to perform operations such as:
- retrieving, uploading, deleting, and sending documents for signing
- creating, updating, and deleting recipients
- creating, updating, and deleting document fields
The documentation walks you through creating API keys and using them to authenticate your API requests. You'll also learn about the available endpoints, request and response formats, and how to use the API.
## Swagger Documentation
The [Swagger documentation](https://app.documenso.com/api/v1/openapi) also provides information about the API endpoints, request parameters, response formats, and authentication methods.
## Availability
The API is available to individual users and teams.
description: Versioning information for the Documenso public API.
---
import { Callout } from 'nextra/components';
# API Versioning
Documenso uses API versioning to manage changes to the public API. This allows us to introduce new features, fix bugs, and make other changes without breaking existing integrations.
<Callout type="info">The current version of the API is `v1`.</Callout>
The API version is specified in the URL. For example, the base URL for the `v1` API is `https://app.documenso.com/api/v1`.
We may make changes to the API without incrementing the version number. We will always try to avoid breaking changes, but in some cases, it may be necessary to make changes that are not backward compatible. In these cases, we will increment the version number and provide information about the changes in the release notes.
Also, we may deprecate certain features or endpoints in the API. When we deprecate a feature or endpoint, we will provide information about the deprecation in the release notes and give a timeline for when the feature or endpoint will be removed.
Navigate to the `documenso` folder and create a `.env` file from the example `.env.example` file:
```bash
cp .env.example .env
```
Open the `.env` file and fill in the following variables:
```bash
- NEXTAUTH_URL
- NEXTAUTH_SECRET
- NEXT_PUBLIC_WEBAPP_URL
- NEXT_PUBLIC_MARKETING_URL
- NEXT_PRIVATE_DATABASE_URL
- NEXT_PRIVATE_DIRECT_DATABASE_URL
- NEXT_PRIVATE_SMTP_FROM_NAME
- NEXT_PRIVATE_SMTP_FROM_ADDRESS
```
<Callout type="info">
If you use a reverse proxy in front of Documenso, don't forget to provide the public URL for both
the `NEXTAUTH_URL` and `NEXT_PUBLIC_WEBAPP_URL` variables!
</Callout>
### Install the Dependencies
Install the project dependencies as follows:
```bash
npm i
npm run build:web
npm run prisma:migrate-deploy
```
### Start the Application
Finally, start the application:
```bash
npm run start
```
This will start the server on `localhost:3000`. Any reverse proxy can handle the front end and SSL termination.
<Callout type="info">
If you want to run with another port than `3000`, you can start the application with `next -p <ANY PORT>` from the `apps/web` folder.
</Callout>
</Steps>
## Docker
The following guide will walk you through setting up Documenso using Docker. You can choose between a Docker Compose production setup or a standalone container.
We provide a Docker container for Documenso, published on both DockerHub and GitHub Container Registry.
You can pull the Docker image from either of these registries and run it with your preferred container hosting provider.
Please note that you must provide environment variables for connecting to the database, mail server, and other services.
### Option 1: Production Docker Compose Setup
This setup includes a PostgreSQL database and the Documenso application. You will need to provide your own SMTP details using environment variables.
<Steps>
### Download the Docker Compose File
Download the Docker Compose file from the Documenso repository - [compose.yml](https://raw.githubusercontent.com/documenso/documenso/release/docker/production/compose.yml).
### Navigate to the `compose.yml` File
Once downloaded, navigate to the directory containing the `compose.yml` file.
### Set Up Environment Variables
Create a `.env` file in the same directory as the `compose.yml` file.
Then add your SMTP details as well as the following environment variables:
The `cert.p12` file is required to sign and encrypt documents, so you must provide your key file. Update the volume binding in the `compose.yml` file to point to your key file:
After updating the volume binding, save the `compose.yml` file and run the following command to start the containers:
```bash
docker-compose --env-file ./.env -d up
```
The command will start the PostgreSQL database and the Documenso application containers.
### Access the Application
Access the Documenso application by visiting `http://localhost:3000` in your web browser.
</Steps>
### Option 2: Standalone Docker Container
If you prefer to host the Documenso application on a specific container provider, use the pre-built Docker image from DockerHub or GitHub's Package Registry. You will need to provide your own database and SMTP host.
<Steps>
### Pull the Docker Image
Pull the Documenso Docker image from DockerHub:
```bash
docker pull documenso/documenso
```
Or, pull the image from GitHub Container Registry:
```bash
docker pull ghcr.io/documenso/documenso
```
### Run the Docker Container
Run the Docker container with the required environment variables:
You can access the Documenso application by visiting the URL you provided for the `NEXT_PUBLIC_WEBAPP_URL` environment variable in your web browser.
</Steps>
### Advanced Configuration
The environment variables listed above are a subset of those available for configuring Documenso. The table below provides a complete list of environment variables and their descriptions.
| `PORT` | The port on which the Documenso application runs. It defaults to `3000`. |
| `NEXTAUTH_URL` | The URL for the NextAuth.js authentication service. |
| `NEXTAUTH_SECRET` | The secret key used by NextAuth.js for encryption and signing. |
| `NEXT_PRIVATE_ENCRYPTION_KEY` | The primary encryption key for symmetric encryption and decryption (at least 32 characters). |
| `NEXT_PRIVATE_ENCRYPTION_SECONDARY_KEY` | The secondary encryption key for symmetric encryption and decryption (at least 32 characters). |
| `NEXT_PRIVATE_GOOGLE_CLIENT_ID` | The Google client ID for Google authentication (optional). |
| `NEXT_PRIVATE_GOOGLE_CLIENT_SECRET` | The Google client secret for Google authentication (optional). |
| `NEXT_PUBLIC_WEBAPP_URL` | The URL for the web application. |
| `NEXT_PRIVATE_DATABASE_URL` | The URL for the primary database connection (with connection pooling). |
| `NEXT_PRIVATE_DIRECT_DATABASE_URL` | The URL for the direct database connection (without connection pooling). |
| `NEXT_PRIVATE_SIGNING_TRANSPORT` | The signing transport to use. Available options: local (default) |
| `NEXT_PRIVATE_SIGNING_PASSPHRASE` | The passphrase for the key file. |
| `NEXT_PRIVATE_SIGNING_LOCAL_FILE_CONTENTS` | The base64-encoded contents of the key file will be used instead of the file path. |
| `NEXT_PRIVATE_SIGNING_LOCAL_FILE_PATH` | The path to the key file, default `/opt/documenso/cert.p12`. |
| `NEXT_PUBLIC_UPLOAD_TRANSPORT` | The transport for file uploads (database or s3). |
| `NEXT_PRIVATE_UPLOAD_ENDPOINT` | The endpoint for the S3 storage transport (for third-party S3-compatible providers). |
| `NEXT_PRIVATE_UPLOAD_FORCE_PATH_STYLE` | Whether to force path-style URLs for the S3 storage transport. |
| `NEXT_PRIVATE_UPLOAD_REGION` | The region for the S3 storage transport (defaults to us-east-1). |
| `NEXT_PRIVATE_UPLOAD_BUCKET` | The bucket to use for the S3 storage transport. |
| `NEXT_PRIVATE_UPLOAD_ACCESS_KEY_ID` | The access key ID for the S3 storage transport. |
| `NEXT_PRIVATE_UPLOAD_SECRET_ACCESS_KEY` | The secret access key for the S3 storage transport. |
| `NEXT_PRIVATE_SMTP_TRANSPORT` | The transport to send emails (smtp-auth, smtp-api, resend, or mailchannels). |
| `NEXT_PRIVATE_SMTP_HOST` | The host for the SMTP server for SMTP transports. |
| `NEXT_PRIVATE_SMTP_PORT` | The port for the SMTP server for SMTP transports. |
| `NEXT_PRIVATE_SMTP_USERNAME` | The username for the SMTP server for the `smtp-auth` transport. |
| `NEXT_PRIVATE_SMTP_PASSWORD` | The password for the SMTP server for the `smtp-auth` transport. |
| `NEXT_PRIVATE_SMTP_APIKEY_USER` | The API key user for the SMTP server for the `smtp-api` transport. |
| `NEXT_PRIVATE_SMTP_APIKEY` | The API key for the SMTP server for the `smtp-api` transport. |
| `NEXT_PRIVATE_SMTP_SECURE` | Whether to force the use of TLS for the SMTP server for SMTP transports. |
| `NEXT_PRIVATE_SMTP_FROM_ADDRESS` | The email address for the "from" address. |
| `NEXT_PRIVATE_SMTP_FROM_NAME` | The sender name for the "from" address. |
| `NEXT_PRIVATE_RESEND_API_KEY` | The API key for Resend.com for the `resend` transport. |
| `NEXT_PRIVATE_MAILCHANNELS_API_KEY` | The optional API key for MailChannels (if using a proxy) for the `mailchannels` transport. |
| `NEXT_PRIVATE_MAILCHANNELS_ENDPOINT` | The optional endpoint for the MailChannels API (if using a proxy) for the `mailchannels` transport. |
| `NEXT_PRIVATE_MAILCHANNELS_DKIM_DOMAIN` | The domain for DKIM signing with MailChannels for the `mailchannels` transport. |
| `NEXT_PRIVATE_MAILCHANNELS_DKIM_SELECTOR` | The selector for DKIM signing with MailChannels for the `mailchannels` transport. |
| `NEXT_PRIVATE_MAILCHANNELS_DKIM_PRIVATE_KEY` | The private key for DKIM signing with MailChannels for the `mailchannels` transport. |
| `NEXT_PUBLIC_DOCUMENT_SIZE_UPLOAD_LIMIT` | The maximum document upload limit displayed to the user (in MB). |
| `NEXT_PUBLIC_POSTHOG_KEY` | The optional PostHog key for analytics and feature flags. |
| `NEXT_PUBLIC_DISABLE_SIGNUP` | Whether to disable user signups through the /signup page. |
## Run as a Service
You can run the application using a `systemd.service` file. Here is a simple example of the service running on port `3500` (using `3000` by default):
```bash
[Unit]
Description=documenso
After=network.target
[Service]
Environment=PATH=/path/to/your/node/binaries
Type=simple
User=www-data
WorkingDirectory=/var/www/documenso/apps/web
ExecStart=/usr/bin/next start -p 3500
TimeoutSec=15
Restart=always
[Install]
WantedBy=multi-user.target
```
We offer several alternative deployment methods for Documenso if you need more options.
## Railway
[](https://railway.app/template/bG6D4p)
## Render
[](https://render.com/deploy?repo=https://github.com/documenso/documenso)
## Koyeb
[](https://app.koyeb.com/deploy?type=git&repository=github.com/documenso/documenso&branch=main&name=documenso-app&builder=dockerfile&dockerfile=/docker/Dockerfile)
description: A step-by-step guide to setting up and hosting your own Documenso instance.
---
import { CallToAction } from '@documenso/ui/components/call-to-action';
# Getting Started with Self-Hosting
This is a step-by-step guide to setting up and hosting your own Documenso instance. Before getting started, [select the right license for you](/users/licenses).
description: Learn how to set up OAuth providers for your own instance of Documenso.
---
## Google OAuth (Gmail)
To use Google OAuth, you will need to create a Google Cloud Platform project and enable the Google Identity and Access Management (IAM) API. You will also need to create a new OAuth client ID and download the client secret.
### Create and configure a new OAuth client ID
1. Go to the [Google Cloud Platform Console](https://console.cloud.google.com/)
2. From the projects list, select a project or create a new one
3. If the APIs & services page isn't already open, open the console left side menu and select APIs & services
4. On the left, click Credentials
5. Click New Credentials, then select OAuth client ID
6. When prompted to select an application type, select Web application
7. Enter a name for your client ID, and click Create
8. Click the download button to download the client secret
9. Set the authorized javascript origins to `https://<documenso-domain>`
10. Set the authorized redirect URIs to `https://<documenso-domain>/api/auth/callback/google`
11. In the Documenso environment variables, set the following:
description: Learn how to generate or buy a signing certificate for your Documenso instance.
---
import { Callout, Steps } from 'nextra/components';
# Generate or Buy
Self-hosting your Documenso instance requires your own certificate to sign documents. [This article](https://documenso.com/blog/building-documenso-pt1) explains why.
When it comes to certificates, you have two options:
- generate your certificate
- buy one from the Certificate Authority (CA)
<Callout type="info" emoji="ℹ️">
A self-signed certificate should suffice if your industry has no special signing regulation. For
example, Deel.com makes hundreds of millions in revenue based on a platform without any signing
certificate, making your self-signed instance technically more secure. Of course, this is not
legal advice.
</Callout>
## Generating A Certificate
If you don't have special requirements for the signature of your signed documents, you can use a self-generated (self-signed) certificate.
The main drawback is that mainstream PDF readers like Adobe won't recognize the signature as a trusted source or show a green checkmark. The certificate will still include your company/personal data to prove your Documenso instance signed the document. It also guarantees that the document wasn't altered after signing.
You can generate your signing certificate by following [this guide](/developers/local-development/signing-certificate).
## Buying a Certificate
If you want more "officially backed" _(for lack of a better word)_ signatures, you will need to buy a certificate from a CA (Certificate Authority). If you want a green checkmark in Adobe PDF, you will need a vendor trusted by Adobe. Check out all Adobe vendors with a green checkmark for the signature on the [Adobe Trust List](https://helpx.adobe.com/acrobat/kb/approved-trust-list1.html).
If you are based in Europe, it might make sense to go with a European one, though there is no hard requirement. While the pricing can vary from vendor to vendor, the certificate's properties don't. The usual case would be a corporate certificate detailing the company's name to which it was issued.
### Technical Process
Receiving your signing certificate is similar to receiving an SSL certificate. Since you need the actual certificate as part of the Documenso config, you must generate a secret private key and a CSR (Certificate Signing Request).
<Steps>
### Generate a private key
Generate a private key (on a secure machine or in an HSM, depending on your security needs and the provider's requirements).
### Create a CSR
Have the Certificate Authority sign the Certificate Signing Request.
### Configure Documenso to use the certificate
Configure your instance to use the new certificate by configuring the following environment variables in your `.env` file:
| `NEXT_PRIVATE_SIGNING_TRANSPORT` | The transport used for document signing. Available options: local (default), gcloud-hsm |
| `NEXT_PRIVATE_SIGNING_PASSPHRASE` | The passphrase for the local file-based signing transport. This field is optional. |
| `NEXT_PRIVATE_SIGNING_LOCAL_FILE_PATH` | The local file path to the .p12 file to use for the local signing transport. This field is optional. |
| `NEXT_PRIVATE_SIGNING_LOCAL_FILE_CONTENTS` | The base64-encoded contents of the .p12 file to use for the local signing transport. This field is optional. |
| `NEXT_PRIVATE_SIGNING_GCLOUD_HSM_KEY_PATH` | The Google Cloud HSM key path for the gcloud-hsm signing transport. This field is optional. |
| `NEXT_PRIVATE_SIGNING_GCLOUD_HSM _PUBLIC_CRT_FILE_PATH` | The path to the Google Cloud HSM public certificate file to use for the gcloud-hsm signing transport. This field is optional. |
| `NEXT_PRIVATE_SIGNING_GCLOUD_HSM _PUBLIC_CRT_FILE_CONTENTS` | The base64-encoded contents of the Google Cloud HSM public certificate file for the gcloud-hsm signing transport. This field is optional. |
| `NEXT_PRIVATE_SIGNING_GCLOUD_ APPLICATION_CREDENTIALS_CONTENTS` | The Google Cloud Credentials file path for the gcloud-hsm signing transport. This field is optional. |
description: Learn how to use webhooks to receive real-time notifications about your documents.
---
# Webhooks
Webhooks are HTTP callbacks triggered by specific events. When the user subscribes to a specific event, and that event occurs, the webhook makes an HTTP request to the URL provided by the user. The request can be a simple notification or carry a payload with more information about the event.
Some of the common use cases for webhooks include:
1. **Real-time Data Syncing**: Webhooks provide a way to keep data in sync across different platforms. For example, you can keep your system up-to-date with your Documenso documents by subscribing to events like document creation or signing.
2. **Automating Workflows**: They can trigger automated workflows that start when an event occurs. For example, the webhook could trigger an email when a document is signed.
3. **Integrating Third-Party Services**: Webhooks can be used to integrate Documenso with third-party services. For example, you could use a webhook to send data to a CRM system when a document is signed.
Documenso supports Webhooks and allows you to subscribe to the following events:
- `document.created`
- `document.sent`
- `document.opened`
- `document.signed`
- `document.completed`
## Create a webhook subscription
You can create a webhook subscription from the user settings page. Click on your avatar in the top right corner of the dashboard and select "**[User settings](https://app.documenso.com/settings)**" from the dropdown menu.

Then, navigate to the "**[Webhooks](https://app.documenso.com/settings/webhooks)**" tab, where you can see a list of your existing webhooks and create new ones.

Clicking on the "**Create Webhook**" button opens a modal to create a new webhook subscription.
To create a new webhook subscription, you need to provide the following information:
- Enter the webhook URL that will receive the event payload.
- Select the event(s) you want to subscribe to: `document.created`, `document.sent`, `document.opened`, `document.signed`, `document.completed`.
- Optionally, you can provide a secret key that will be used to sign the payload. This key will be included in the `X-Documenso-Secret` header of the request.

After you have filled in the required information, click on the "**Create Webhook**" button to save your subscription.
The screenshot below illustrates a newly created webhook subscription.

You can edit or delete your webhook subscriptions by clicking the "**Edit**" or "**Delete**" buttons next to the webhook.
## Webhook fields
The payload sent to the webhook URL contains the following fields:
| `payload.Recipient[].role` | string | The role of the recipient. |
| `payload.Recipient[].readStatus` | string | The read status of the document by the recipient. |
| `payload.Recipient[].signingStatus` | string | The signing status of the recipient. |
| `payload.Recipient[].sendStatus` | string | The send status of the document to the recipient. |
| `createdAt` | datetime | The creation date and time of the webhook event. |
| `webhookEndpoint` | string | The endpoint URL where the webhook is sent. |
## Webhook event payload example
When an event that you have subscribed to occurs, Documenso will send a POST request to the specified webhook URL with a payload containing information about the event.
## Example payloads
Below are examples of the payloads that are sent for each of the supported events. The payloads are sent as JSON data in the body of the POST request.
description: Documenso aims to be the world's most trusted document-signing tool. Join us in creating the next generation of open trust infrastructure.
---
import Image from 'next/image';
import Link from 'next/link';
import backgroundPattern from '@documenso/assets/images/background-pattern.png';
import cardBeautifulFigure from '@documenso/assets/images/card-beautiful-figure.png';
import cardConnectionsFigure from '@documenso/assets/images/card-connections-figure.png';
import cardPaidFigure from '@documenso/assets/images/card-paid-figure.png';
import cardSharingFigure from '@documenso/assets/images/card-sharing-figure.png';
import { cn } from '@documenso/ui/lib/utils';
import { Card, CardContent, CardTitle } from '@documenso/ui/primitives/card';
<span className="text-muted-foreground mx-auto mt-4 max-w-2xl text-center leading-normal tracking-tight">Documenso aims to be the world's most trusted document-signing tool. Join us in creating the next generation of open trust infrastructure.</span>
This page outlines our adherence to key regulations across various jurisdictions, including:
- U.S. ESIGN Act
- Uniform Electronic Transactions Act (UETA)
- European Union's eIDAS regulation
- Switzerland's ZertES
Whether you require simple electronic signatures or advanced cryptographic sealing, Documenso guarantees that all documents are securely sealed and compliant with the highest standards. Explore our compliance details below to understand how we maintain the integrity and enforceability of your electronic transactions.
<Callout emoji="🔏">
Documenso seals all signed documents cryptographically, regardless of signature level, to prevent
any alterations after signing.
</Callout>
## 🇺🇸 ESIGN (Electronic Signatures in Global and National Commerce) Act
<Callout type="info" emoji="✅">
Status: Compliant
</Callout>
The Electronic Signatures in Global and National Commerce Act (ESIGN Act) is a U.S. federal law that
ensures the legal validity and enforceability of electronic signatures and records in commerce.
### Main Requirements
- [x] Intent to Sign: "Parties must demonstrate their intent to sign [..]"
- [x] Consent: "The ESIGN Act requires that all parties involved in a transaction consent to the use of electronic signatures and records [..]"
- [x] Consumer Disclosures: Before obtaining their consent, financial institutions must provide the consumer a clear and conspicuous statement informing the consumer [..]
- [x] Record Retention: Electronic Records must be maintained for later access by signers.
- [x] Security: The ESIGN Act does not mandate specific security measures, but it does require that parties take reasonable steps to ensure the security and integrity of electronic signatures and records. This may include implementing encryption, access controls, and authentication measures.
## UETA (Uniform Electronic Transactions Act)
<Callout type="info" emoji="✅">
Status: Compliant
</Callout>
The Uniform Electronic Transactions Act is a law that provides a legal framework for the use of electronic
signatures and records in electronic transactions, ensuring they have the same validity and enforceability
The HIPAA (Health Insurance Portability and Accountability Act) is a U.S. law designed to protect patient health information's privacy and security and improve the healthcare system's efficiency and effectiveness.
description: Create a shareable link for document signing.
---
import { Callout, Steps } from 'nextra/components';
# Direct Link Signing
Direct Link Signing allows you to create a shareable link for document signing, where recipients can fill in their information and sign directly. Once the recipients sign the document, they will get it in their email. Also, if they have an account, the document gets saved in their account.
<Steps>
### Select a Document
Identify the template you want to share and make signable with a direct link. Then click on the 3 dots on the right side of the template and select "Direct link".

### Enable Direct Links
Once you click on "Direct link", you will be greeted with a modal where you can learn how direct links work. After reading the information, click "Enable direct link" to proceed.

### Select the Recipient
The next step is to select the recipient for the direct link. You can select an existing recipient or click the "Create one automatically" button to create a new direct link recipient.

### Send the Link
After selecting the recipient, you will get a direct link to share with the recipient. The format of the link is as follows:
description: Learn how to control the visibility of your team documents.
---
# Team's Document Visibility
By default, all documents created in a team are visible to all team members. However, you can control the visibility of your documents by changing the document's visibility settings.
To set the visibility of a document, click on the **Document visibility** dropdown in the document's settings panel.

The document visibility can be set to one of the following options:
- **Everyone** - The document is visible to all team members.
- **Managers and above** - The document is visible to people with the role of Manager or above.
- **Admin only** - The document is only visible to the team's admins.
description: Learn about our fair use policy, which enables us to have unlimited plans.
---
import { Callout } from 'nextra/components';
# Fair Use Policy
### Why
We offer our plans without any limits on volume because we want our users and customers to make the most of their accounts. Estimating volume is incredibly hard, especially for shorter intervals like a quarter. We are not interested in selling volume packages our customers end up not using. This is why the individual plan and the team plan do not include a limit on signing or API volume. If you are a customer of these [plans](https://documen.so/pricing), we ask you to abide by this fair use policy:
### Spirit of the Plan
> Use the limitless accounts as much as you like (they are meant to offer a lot) while respecting the spirit and intended scope of the account.
<Callout type="info">
What happens if I violate this policy? We will ask you to upgrade to a fitting plan or custom
pricing. We won’t block your account without reaching out. [Message
us](mailto:support@documenso.com) for questions. It's probably fine, though.
</Callout>
### DO
- Sign as many documents with the individual plan for your single business or organization you are part of
- Use the API and Zapier to automate all your signing to sign as much as possible
- Experiment with the plans and integrations, testing what you want to build: When in doubt, do it. Especially if you are just starting.
### DON'T
- Use the individual account's API to power a platform
- Run a huge company, signing thousands of documents per day on a two-user team plan using the API
- Let this policy make you overthink. If you are a paying customer, we want you to win, and it's probably fine
description: Learn how to create an account on Documenso.
---
import { Callout, Steps } from 'nextra/components';
# Create Your Account
<Steps>
### Pick a Plan
The first step to start using Documenso is to pick a plan and create an account. At the moment of writing this guide, we have 3 plans available: Free, Individual, and Teams.
Explore each plan's features and choose the one that best suits your needs. The [pricing page](https://documen.so/pricing) has more information about the plans.
<Callout>All plans are subject to our [Fair Use Policy](/users/fair-use).</Callout>
### Create an account
If you are unsure which plan to choose, you can start with the free plan and upgrade later.
To create a free account, navigate to the [registration page](https://documen.so/free) and fill in the required information.
### Optional: Claim a Premium Username
You can claim a premium username by upgrading to a paid plan. After upgrading to a paid plan, you can update your [public profile](https://app.documenso.com/settings/public-profile).
### Optional: Create a Team
If you are working with others, you can create a team and invite your team members to collaborate on your documents. More information about teams is available in the [Teams section](/users/get-started/teams).
description: Learn how to secure your Documenso account with Two-Factor Authentication (2FA) and Passkeys.
---
import { Callout, Steps } from 'nextra/components';
# Account Security
Documenso offers several security features to help you protect your account and documents. This guide will walk you through the steps to set up Two-Factor Authentication (2FA) and Passkeys for your account.
Two-factor authentication (2FA) and Passkeys are used for high-security and high-compliance signatures.
## Enable Two-Factor Authentication (2FA)
<Steps>
### Navigate to Security Settings
Navigate to your account's [security settings](https://app.documenso.com/settings/security). Here, you can manage your password and other security settings.

### Enable 2FA
Click the "Enable 2FA" button to start setting up Two-Factor Authentication. You will be presented with a QR code that you can scan with your 2FA app or a code that you can manually enter.

### Scan the QR Code
Use your 2FA app (e.g. Google Authenticator, Microsoft Authenticator) to scan the QR code. This will link your account to the 2FA app and generate a code that you can use to log in.
### Enter the 2FA Generated Code
After scanning the QR code, you will be prompted to enter the code generated by your 2FA app. After entering the code, click the "Enable 2FA" button to complete the process.
### 2FA Enabled
You have successfully enabled Two-Factor Authentication (2FA) for your account. To log in, you must enter the code generated by your 2FA app.
<Callout>
Logging in with Google will not require a 2FA code. As an authentication provider, your Google
account is considered secure. e.g. configuring 2FA for your Google account.
</Callout>
<Callout>
Logging in using a passkey will also not require a 2FA code since passkeys are considered 2FA by
design. The passkey itself is the first factor, and access to the device that holds it is
considered the second factor.
</Callout>
### Extra: Save the Backup Codes
Be sure to download and safely store the 2FA backup codes in case you lose access to your 2FA app. You can use these codes to log in to your account.
</Steps>
## Add Passkeys
A passkey is like a secret password stored locally on your device. You can log in from the device it was created on but not from another device.
<Steps>
### Navigate to Security Settings
Navigate to the [security settings](https://app.documenso.com/settings/security) in your account.
### Manage Passkeys
Click the "Manage passkeys" button to start setting up a passkey. You will be taken to a new page where you can manage your passkeys or add a new one.

### Add a New Passkey
To add a new passkey, click the "Add passkey" button. This opens a modal window where you can choose a passkey name.

After entering the passkey name, click the "Continue" button to proceed.
What happens next depends on the passkey provider you have configured. If you have a passkey provider installed in your browser, you will be prompted to add the passkey there. If not, you will be prompted to add the passkey to your browser's passkey manager.
Whatever option you choose, follow the on-screen instructions to add the passkey. Once the passkey is added, you can use it to log in to your account.
### Manage Passkeys
You can manage your passkeys from the passkeys page. You can see the list of passkeys you have added and remove them if needed.
Each team is a separate entity with its members, documents, and templates. You can create as many teams as you like but remember that each team is billed separately.
<Callout type="info">You can transfer the ownership of the team at any time.</Callout>
### Name and URL
Clicking the "+" button will open a modal where you must pick your team's name and URL. The URL is the team's identifier and will link to the team's page and settings. An example URL would be:
```bash
https://app.documenso.com/t/<your-team-name>
```

You can select a different name and URL for your team, but we recommend using the same or similar name.
### Invite Team Members
After creating the team, you can invite team members by navigating to the "Members" tab in the team settings and clicking the "Invite member" button.
To access the team settings, click on the team's name in the account dropdown and select the appropriate team. Lastly, click again on the avatar and then "Team Settings".
Once you click on the "Invite member" button, you will be prompted to enter the email address of the person you want to invite. You can also select the role of the person you are inviting.

You can also bulk-invite members by uploading a CSV file with the email addresses and roles of the people you want to invite.
The table below shows how the CSV file should be structured:
| Email address | Role |
| -------------------------- | ------- |
| team-admin@documenso.com | Admin |
| team-manager@documenso.com | Manager |
| team-member@documenso.com | Member |
<Callout type="info">
The basic team plan includes 5 members. You can invite as many members as you like by upgrading
your team's seats on the team's billing page.
</Callout>
#### Roles
You can assign different permissions to team members based on their roles. The roles available are:
You can add a team email to make signing and sending documents easier. Adding a team email allows you to:
- See a signing request sent to this email (Team Inbox)
- See all documents sent on behalf of the team
### (Optional) Transfer Team Ownership
You can transfer the team's ownership at any time. To do this, navigate to the "General" tab in the team settings and click the "Transfer team" button.
description: Get started with Documenso by creating an account, configuring your account security, collaborating with others via Teams, and using the basic features of Documenso.
---
# First Steps
This is a step-by-step guide to getting started with Documenso. You'll learn how to create a new account, configure your account security, collaborate with others via Teams, and use the features of Documenso.
The purpose of the Community Edition is to allow anyone to run their signing infrastructure. You can take Documenso as is and run it yourself with barely any restrictions. We aim to keep self-hosting a realistic option and not force the product to become cloud-only.
## License
Documenso and the Community Edition are licensed under [AGPL3](https://github.com/documenso/documenso/blob/main/LICENSE). Below, you can find an overview of the significant licensing terms. The most important thing that you must remember is that if you use the community edition, you must keep it open source:
> Permissions of this most robust copyleft license are conditioned on making available the complete source code of licensed works and modifications, which include larger works using a licensed work under the same license. Copyright and license notices must be preserved. Contributors provide an express grant of patent rights. When a modified version is used to provide a service over a network, the complete source code of the modified version must be made available.
### Permissions
- Modification - You can fork and modify the community edition.
- Distribution - You are free to redistribute the community edition.
- Patent use - See license for details.
- Private use - You can use the Community Edition privately.
<Callout type="info">
You can use Documenso commercially by hosting the community edition or otherwise (as long as you
keep the code open-source).
</Callout>
### Limitations
- **Liability & Warranty** - While we aim to build a best-in-class product, the community edition comes without an official warranty or liability.
- **EE Folder** - Features in the EE folder are not licensed under AGPL3 and cannot be used without an enterprise license. You can find a list of enterprise-licensed features [here](https://github.com/documenso/documenso/blob/main/packages/ee/FEATURES).
- **Official Support** - The Community Edition is not eligible for official customer support. While you can request community support through our Discord Community, it's not guaranteed that you will receive help. The Documenso team might also be happy to help, but be advised that this is strictly voluntary.
### Conditions
ℹ️ License and copyright notice
ℹ️ State changes
ℹ️ Disclose source
ℹ️ Network use is distribution
<Callout type="warning">
It's important to remember that you must keep the AGPL3 license for your modified or non-modified
version of Documenso. If you need clarification on whether this represents a problem or not for
you, reach out to us on [Discord](documen.so/discord).
The Documenso Enterprise Edition is our license for self-hosters that need the full range of support and compliance. Everything in the EE folder and all features listed [here](https://github.com/documenso/documenso/blob/main/packages/ee/FEATURES) can be used after acquiring a paid license.
The choice between the two editions is entirely yours, depending on your specific needs. If you require official support and enterprise-level compliance, the Enterprise Edition is likely the best fit. However, if you find that the Community Edition, with its almost unrestricted features and use cases (including commercial use), meets all your requirements, we encourage you to start with it. Remember, you can always upgrade later.
description: Learn how to set up your public profile on Documenso.
---
import { Callout, Steps } from 'nextra/components';
# User Profile
Documenso allows you to create a public profile to share your templates for anyone to sign. This is useful for distributing and collecting signatures for commonly used documents, making it more efficient for both the document creator and the signers.
<Callout type="info">A free Documenso account gives you 5 free signatures per month.</Callout>
<Steps>
### Navigate to Your Profile Settings
Click on your profile picture in the top right corner and select "User settings". Then, navigate to the "Public Profile" tab to configure your profile.
This is the URL that people will use to access your profile. We recommend choosing something easy to remember and share.
The structure of the URL is as follows:
```bash
https://app.documenso.com/p/<username>
```
Setting the public profile URL is mandatory to publish your profile.
### (Optional) Add a Bio Description
If you want to add a description to your profile, you can do so here. This is a good place to introduce yourself and explain what kind of documents you have available for signing.
### (Optional) Add a Profile Picture
Uploading a profile picture is optional, but we recommend it to make your profile more recognizable.
### Private/Public Profile
You can choose to make your profile public or private. Only you can access it if you make it private. If you make it public, anyone with the link can access it.
To make your profile public, toggle the switch to the right ("Show") at the top right-hand side of the page.
### (Optional) Link Templates
Linking templates to your profile is optional, but it's what makes your profile helpful. Linking templates allow people to sign documents directly from your profile. As a result, we recommend linking at least one template you want to share with others.
Learn more about [templates](/users/templates).
### Publish your Profile
After configuring your profile, click the "Update" button at the bottom of the page to publish it. Once you have published your profile, you can share the link with others if you made it public.

The image above shows an example of a public profile on Documenso.
### Share the Link
Add the link to your other social profiles and share it on social media so people know they can quickly sign your documents from there.
<Callout>Tag @documenso on X to get a retweet and an endorsement from us.</Callout>
description: Learn about the different fields you can add to your documents in Documenso.
---
# Document Fields
Learn about the different fields you can add to your documents in Documenso and how to make the most of them.
## Signature Field
The signature field collects the signer's signature. It's required for each recipient with the "Signer" role.
### Document Editor View
The field doesn't have any additional settings. You just need to place it on the document where you want the signer to sign.

### Document Signing View
The recipient will see the signature field when they open the document to sign.
The recipient must click on the signature field to open the signing view, where they can sign using their mouse, touchpad, or touchscreen.

The image below shows the signature field signed by the recipient.

After signing, the recipient can click the "Complete" button to complete the signing process.
## Email Field
The email field is used to collect the signer's email address.
### Document Editor View
The field doesn't have any additional settings. You just need to place it on the document where you want the signer to sign.

### Document Signing View
When the recipient opens the document to sign, they will see the email field.
The recipient must click on the email field to automatically sign the field with the email associated with their account.

The image below shows the email field signed by the recipient.

After entering their email address, the recipient can click the "Complete" button to complete the signing process.
## Name Field
The name field is used to collect the signer's name.
### Document Editor View
The field doesn't have any additional settings. You just need to place it on the document where you want the signer to sign.

### Document Signing View
When the recipient opens the document to sign, they will see the name field.
The recipient must click on the name field, which will automatically sign the field with the name associated with their account.

The image below shows the name field signed by the recipient.

After entering their name, the recipient can click the "Complete" button to complete the signing process.
## Date Field
The date field is used to collect the date of the signature.
### Document Editor View
The field doesn't have any additional settings. You just need to place it on the document where you want the signer to sign.

### Document Signing View
When the recipient opens the document to sign, they will see the date field.
The recipient must click on the date field to automatically sign the field with the current date and time.

The image below shows the date field signed by the recipient.

After entering the date, the recipient can click the "Complete" button to complete the signing process.
## Text Field
The text field is used to collect text input from the signer.
### Document Editor View
Place the text field on the document where you want the signer to enter text. The text field comes with additional settings that can be configured.

To open the settings, click on the text field and then on the "Sliders" icon. That opens the settings panel on the right side of the screen.

The text field settings include:
- **Label** - The label displayed in the field.
- **Placeholder** - The placeholder text displayed in the field.
- **Text** - The default text displayed in the field.
- **Character limit** - The maximum number of characters allowed in the field.
- **Required** - Whether the field is required or not.
- **Read only** - Whether the field is read-only or not.
It also comes with a couple of rules:
- The field can't be required and read-only at the same time.
- A read-only field can't have an empty text field. It must have a default text value.
- The signer must fill out a required field.
- The text field characters count can't exceed the character limit.
- The signer can't modify a read-only field.
- The field auto-signs if there is a default text value.
Let's look at the following example.

The field is configured as follows:
- Label: "Address"
- Placeholder: "Your office address"
- Default Text: "Signing Street 1, 241245"
- Character Limit: 35
- Required: False
- Read Only: False
Since the field has a label set, the label is displayed instead of the default text field value - "Add text".
### Document Signing View
What the recipient sees when they open the document to sign depends on the settings configured by the sender.
In this case, the recipient sees the text field signed with the default value.

The recipient can modify the text field value since the field is not read-only. To change the value, the recipient must click the field to un-sign it.
Once it's unsigned, the field uses the label set by the sender.

To sign the field with a different value, the recipient needs to click on the field and enter the new value.

Since the text field has a character limit, the recipient must enter a value that doesn't exceed the limit. Otherwise, an error message will appear, and the field will not be signed.
The image below illustrates the text field signed with a new value.

After signing the field, the recipient can click the "Complete" button to complete the signing process.
## Number Field
The number field is used for collecting a number input from the signer.
### Document Editor View
Place the number field on the document where you want the signer to enter a number. The number field comes with additional settings that can be configured.

To open the settings, click on the number field and then on the "Sliders" icon. That opens the settings panel on the right side of the screen.

The number field settings include:
- **Label** - The label displayed is the field.
- **Placeholder** - The placeholder text displayed in the field.
- **Value** - The default number displayed in the field.
- **Number format** - The format of the number.
- **Required** - Whether the field is required or not.
- **Read only** - Whether the field is read-only or not.
- **Validation** - The validation rules for the field.
It also comes with a couple of rules:
- The value must be a number.
- The field can't be required and read-only at the same time.
- A read-only field can't have an empty number field. It must have a default number value.
- The signer must fill out a required field.
- If the default number and a max value are set, the default number must be less than the max value.
- If the default number and a min value are set, the default number must be greater than the min value.
- The value must match the number format if a number format is set.
In this example, the number field is configured as follows:
- Label: "Quantity"
- Placeholder: "Enter the preferred quantity"
- Default Value: 12
- Number Format: "123,456,789.00"
- Required: False
- Read Only: False
- Validation:
- Min value: 5, Max value: 50

Since the field has a label set, the label is displayed instead of the default number field value - "Add number".
### Document Signing View
What the recipient sees when they open the document to sign depends on the settings configured by the sender.
The recipient sees the number field signed with the default value in this case.

Since the number field is not read-only, the recipient can modify its value. To change the value, the recipient must click the field to un-sign it.
Once it's unsigned, the field uses the label set by the sender.

To sign the field with a different value, the recipient needs to click on the field and enter the new value.

Since the number field has a validation rule set, the recipient must enter a value that meets the rules. In this example, the value needs to be between 5 and 50. Otherwise, an error message will appear, and the field will not be signed.
The image below illustrates the text field signed with a new value.

After signing the field, the recipient can click the "Complete" button to complete the signing process.
## Radio Field
The radio field is used to collect a single choice from the signer.
### Document Editor View
Place the radio field on the document where you want the signer to select a choice. The radio field comes with additional settings that can be configured.

To open the settings, click on the radio field and then on the "Sliders" icon. That opens the settings panel on the right side of the screen.

The radio field settings include:
- **Required** - Whether the field is required or not.
- **Read only** - Whether the field is read-only or not.
- **Values** - The list of choices for the field.
It also comes with a couple of rules:
- The field can't be required and read-only at the same time.
- A read-only field can't have an empty radio field. It must have at least one option.
- The signer must fill out a required field.
- The field auto-signs if there is a default value.
- The signer can't sign with a value not in the options list.
- The signer can't modify the field if it's read-only.
- It should contain at least one option.
- The field can't have more than one option selected.
In this example, the radio field is configured as follows:
- Required: False
- Read Only: False
- Options:
- Option 1
- Option 2
- Empty value
- Empty value
- Option 3

Since the field contains radio options, it displays them instead of the default radio field value, "Radio".
### Document Signing View
What the recipient sees when they open the document to sign depends on the settings configured by the sender.
In this case, the recipient sees the radio field unsigned because the sender didn't select a value.

The recipient can select one of the options by clicking on the radio button next to the option.

After signing the field, the recipient can click the "Complete" button to complete the signing process.
## Checkbox Field
The checkbox field is used to collect multiple choices from the signer.
### Document Editor View
Place the checkbox field on the document where you want the signer to select choices. The checkbox field comes with additional settings that can be configured.

To open the settings, click on the checkbox field and then on the "Sliders" icon. That opens the settings panel on the right side of the screen.

The checkbox field settings include the following:
- **Validation** - The validation rules for the field.
- **Rule** - The rule specifies "At least", "At most", and "Exactly".
- **Number** - The number of choices that must be selected.
- **Required** - Whether the field is required or not.
- **Read only** - Whether the field is read-only or not.
- **Options** - The list of choices for the field.
It also comes with a couple of rules:
- The field can't be required and read-only at the same time.
- A read-only field can't have an empty checkbox field. It must have at least one checked option.
- The signer must fill out a required field.
- The field auto-signs if there is a default value.
- The signer can't sign with a value not in the options list.
- The signer can't modify the field if it's read-only.
- It should contain at least one option.
In this example, the checkbox field is configured as follows:
- No validation rules
- Required: True
- Read Only: False
- Options:
- Option 1
- Empty value (checked)
- Option 2
- Option 3 (checked)
- Empty value

Since the field contains checkbox options, it displays them instead of the default checkbox field value, "Checkbox".
### Document Signing View
What the recipient sees when they open the document to sign depends on the settings configured by the sender.
In this case, the recipient sees the checkbox field signed with the values selected by the sender.

Since the field is required, the recipient can either sign with the values selected by the sender or modify the values.
The values can be modified in 2 ways:
- Click on the options you want to select or deselect.
- Hover over the field and click the "X" button to clear all the selected values.
The image below illustrates the checkbox field with the values cleared by the recipient. Since the field is required, it has a red border instead of the yellow one (non-required fields).

Then, the recipient can select values other than the ones chosen by the sender.

After signing the field, the recipient can click the "Complete" button to complete the signing process.
## Dropdown/Select Field
The dropdown/select field collects a single choice from a list of options.
### Document Editor View
Place the dropdown/select field on the document where you want the signer to select a choice. The dropdown/select field comes with additional settings that can be configured.

To open the settings, click on the dropdown/select field and then on the "Sliders" icon. That opens the settings panel on the right side of the screen.

The dropdown/select field settings include:
- **Required** - Whether the field is required or not.
- **Read only** - Whether the field is read-only or not.
- **Options** - The list of choices for the field.
- **Default** value - The default value selected in the field.
It also comes with a couple of rules:
- The field can't be required and read-only at the same time.
- A read-only field can't have an empty select field. It must have a default value.
- The signer must fill out a required field.
- The default value must be one of the options.
- The field auto-signs if there is a default value.
- The field can't be signed with a value not in the options list.
- The signer can't modify the field if it's read-only.
- It should contain at least one option.
In this example, the dropdown/select field is configured as follows:
- Required: False
- Read Only: False
- Default Value: None
- Options:
- Document
- Template
- Other
### Document Signing View
What the recipient sees when they open the document to sign depends on the settings configured by the sender.
In this case, the recipient sees the dropdown/select field with the default label, "-- Select ---" since the sender has not set a default value.

The recipient can modify the dropdown/select field value since the field is not read-only. To change the value, the recipient must click on the field for the dropdown list to appear.

The recipient can select one of the options from the list. The image below illustrates the dropdown/select field signed with a new value.

After signing the field, the recipient can click the "Complete" button to complete the signing process.
description: The guide gives a detailed description of all options available when sending out a document for signing.
---
import { Callout, Steps } from 'nextra/components';
# Send Documents for Signing
This guide will walk you through the process of sending a document out for signing. You will learn how to upload a document, add recipients, place signature fields, and send the document for signing.
<Steps>
### Login Into Your Account
The guide assumes you have a Documenso account. If you don't, you can create a free account [here](https://documen.so/free-docs).
### Upload Document
Navigate to the [Documenso dashboard](https://app.documenso.com/documents) and click on the "Add a document" button. Select the document you want to upload and wait for the upload to complete.
After the upload is complete, you will be redirected to the document's page. You can configure the document's settings and add recipients and fields here.
Click on the "Advanced options" button to access additional settings for the document. You can set an external ID, date format, time zone, and the redirect URL.

The external ID allows you to set a custom ID for the document that can be used to identify the document in your external system(s).
The date format and time zone settings allow you to customize how the date and time are displayed in the document.
The redirect URL allows you to specify a URL where the signer will be redirected after signing the document.
### (Optional) Document Access
Documenso enables you to set up access control for your documents. You can require authentication for viewing the document.
The available options are:
- **Require account** - The recipient must be signed in to view the document.
- **None** - The document can be accessed directly by the URL sent to the recipient.

<Callout type="info">
The "Document Access" feature is only available for Enterprise accounts.
</Callout>
### (Optional) Recipient Authentication
The "Recipient Authentication" feature allows you to specify the authentication method required for recipients to sign the signature field.
The available options are:
- **Require passkey** - The recipient must have an account and passkey configured via their settings.
- **Require 2FA** - The recipient must have an account and 2FA enabled via their settings.
- **None** - No authentication required.

This can be overridden by setting the authentication requirements directly for each recipient in the next step.
<Callout type="info">
The "Recipient Authentication" feature is only available for Enterprise accounts.
</Callout>
### Recipients
Click the "+ Add Signer" button to add a new recipient. You can configure the recipient's email address, name, role, and authentication method on this page.
You can choose any option from the ["Recipient Authentication"](#optional-recipient-authentication) section, or you can set it to "Inherit authentication method" to use the global action signing authentication method configured in the "General Settings" step.

You can also set the recipient's role, which determines their actions and permissions in the document.
| Signer | Needs to sign signatures fields assigned to them. | Yes | Yes |
| Approver | Needs to approve the document as a whole. Signature optional. | Yes | Optional |
| Viewer | Needs to confirm they viewed the document. | Yes | No |
| BCC | Receives a copy of the signed document after completion. No action is required. | No | No |
### Fields
Documenso supports 9 different field types that can be added to the document. Each field type collects various information from the recipients when they sign the document.

The available field types are:
- **Signature** - Collects the signer's signature
- **Email** - Collects the signer's email address
- **Name** - Collects the signer's name
- **Date** - Collects the date of the signature
- **Text** - Collects text input from the signer
- **Number** - Collects a number input from the signer
- **Radio** - Collects a single choice from the signer
- **Checkbox** - Collects multiple choices from the signer
- **Dropdown/Select** - Collects a single choice from a list of choices
All fields can be placed anywhere on the document and resized as needed.
<Callout type="info">
Learn more about the available field types and how to use them on the [Fields
page](signing-documents/fields).
</Callout>
#### Signature Required
Signer Roles require at least 1 signature field. You will get an error message if you try to send a document without a signature field.

### Email Settings
Before sending the document, you can configure the email settings and customize the subject line, message, and sender name.

If you leave the email subject and message empty, Documenso will use the default email template.
### Sending the Document
After configuring the document, click the "Send" button to send the document to the recipients. The recipients will receive an email with a link to sign the document.

#### Signing Link
If you need to copy the signing link for each recipient, you can do so by clicking on the recipient whose link you want to copy. The signing link is copied automatically to your clipboard.

Some files were not shown because too many files have changed in this diff
Show More
Reference in New Issue
Block a user
Blocking a user prevents them from interacting with repositories, such as opening or commenting on pull requests or issues. Learn more about blocking a user.