## 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>
- Added functionality to decline team invitations
- Added email notifications for when team is deleted
- Added email notifications for team members joining and leaving
## 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
## 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
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>
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.
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.
## 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
