Audited every className token in the repo by compiling them against the shared
tailwind config and diffing generated selectors. The following dead tokens were
replaced with the intended, existing ones:
- text-sbase -> text-base (document invite email button, botched sm->base edit)
- text-primary-forground -> text-foreground (admin license card; the literal
spelling fix would render 10% lightness text on the dark card, the inherited
foreground colour is the intended look)
- tracking-tigh -> tracking-tight (signing waiting page heading)
- font-sm -> text-sm (4 delete-confirmation dialogs)
- dark:text-muted-background -> dark:text-muted (field drag ghost in 4 flows;
restores the dark mode readability fix intended by #1242)
- placeholder:text-foreground-muted -> placeholder:text-muted-foreground
(command palette input)
- text-medium -> font-medium (org create dialog free plan, matches paid plans)
- text-md -> text-base (envelope drop zone hint)
- justify-left -> justify-start (member invite remove button, no visual change)
- removed stray "gradie" fragment and text-dark (no dark colour exists)
No visual change except where the dead class silently disabled intended
styling (email button size, drag ghost dark mode text, dialog confirm text
size).
Generate certificates and audit logs using Konva instead of browserless.
This should:
- Reduce the changes of generations failing
- Improve sealing speed
Upgrade the `@react-email/render` package to handle
suspense during renders.
We could have just swapped to `renderAsync` for the 0.0.x
version of the package but it's better to upgrade as part
of this change.
CI has been run locally and emails have been verified to
work and render as expected in our local mail trap.
Improve the email sent to invite a user to approve/sign/assist/view a
document.
The current links "Reject Document" / "Sign Document" confuse some users
as they think the document will be rejected/signed just by clicking on
these buttons.
This change makes it more clear that they will have a chance to view the
document before they can reject/sign.
Allow organisations to manage an SSO OIDC compliant portal. This method
is intended to streamline the onboarding process and paves the way to
allow organisations to manage their members in a more strict way.
Improves the existing document rejection process by actually marking a
document as completed cancelling further actions.
## Related Issue
N/A
## Changes Made
- Added a new rejection status for documents
- Updated a million areas that check for document completion
- Updated email sending, so rejection is confirmed for the rejecting
recipient while other recipients are notified that the document is now
cancelled.
## Testing Performed
- Ran the testing suite to ensure there are no regressions.
- Performed manual testing of current core flows.
Introduces the ability for users with the **Assistant** role to prefill
fields on behalf of other signers. Assistants can fill in various field
types such as text, checkboxes, dates, and more, streamlining the
document preparation process before it reaches the final signers.
Implements a bulk send feature allowing users to upload a CSV file to
create multiple documents from a template. Includes CSV template
generation, background processing, and email notifications.
## Description
Adds support for rejecting a given document informing the document
owner.
Flows for resolving a rejection don't currently exist so it's up to the
document owner to reach out to the recipient and work out a way to move
forward via a new document or offline agreement.
## Related Issue
## Changes Made
- Added new rejection properties to the recipient schema
- Added API endpoints to support rejection
- Added email templates for notifying the document owner and recipient
- Added a dialog on the signing page to start the rejection flow.
## Testing Performed
- Manually tested the flow end to end
- Automated tests are planned
## Description
This PR introduces global settings for teams. At the moment, it allows
team admins to configure the following:
* The default visibility of the documents uploaded to the team account
* Whether to include the document owner (sender) details when sending
emails to the recipients.
### Include Sender Details
If the Sender Details setting is enabled, the emails sent by the team
will include the sender's name:
> "Example User" on behalf of "Example Team" has invited you to sign
"document.pdf"
Otherwise, the email will say:
> "Example Team" has invited you to sign "document.pdf"
### Default Document Visibility
This new option allows users to set the default visibility for the
documents uploaded to the team account. It can have the following
values:
* Everyone
* Manager and above
* Admins only
If the default document visibility isn't set, the document will be set
to the role of the user who created the document:
* If a user with the "User" role creates a document, the document's
visibility is set to "Everyone".
* Manager role -> "Manager and above"
* Admin role -> "Admins only"
Otherwise, if there is a default document visibility value, it uses that
value.
#### Gotcha
To avoid issues, the `document owner` and the `recipient` can access the
document irrespective of their role. For example:
* If a team member with the role "Member" uploads a document and the
default document visibility is "Admins", only the document owner and
admins can access the document.
* Similar to the other scenarios.
* If an admin uploads a document and the default document visibility is
"Admins", the recipient can access the document.
* The admins have access to all the documents.
* Managers have access to documents with the visibility set to
"Everyone" and "Manager and above"
* Members have access only to the documents with the visibility set to
"Everyone".
## Testing Performed
Tested it locally.
## Description
Support setting a document language that will control the language used
for sending emails to recipients. Additional work has been done to
convert all emails to using our i18n implementation so we can later add
controls for sending other kinds of emails in a users target language.
## Related Issue
N/A
## Changes Made
- Added `<Trans>` and `msg` macros to emails
- Introduced a new `renderEmailWithI18N` utility in the lib package
- Updated all emails to use the `<Tailwind>` component at the top level
due to rendering constraints
- Updated the `i18n.server.tsx` file to not use a top level await
## Testing Performed
- Configured document language and verified emails were sent in the
expected language
- Created a document from a template and verified that the templates
language was transferred to the document
## 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>
- Added functionality to decline team invitations
- Added email notifications for when team is deleted
- Added email notifications for team members joining and leaving
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