This PR is handles the changes required to support envelopes. The new
envelope editor/signing page will be hidden during release.
The core changes here is to migrate the documents and templates model to
a centralized envelopes model.
Even though Documents and Templates are removed, from the user
perspective they will still exist as we remap envelopes to documents and
templates.
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.
## Description
Add a new document audit log to detect when the document is viewed. This
should only be visible in the document audit log page
Notes:
1. I wanted to reuse the `DOCUMENT_OPENED` event and add an additional
paramter to track sequential views, but it's not query-able
2. This will log "DOCUMENT_VIEWED" before "DOCUMENT_OPENED" but i don't
think it matters
Adds password reauthentication to our existing reauth providers,
additionally swaps from an exclusive provider to an inclusive type where
multiple methods can be selected to offer a this or that experience.
Adds document access tokens and QR code functionality to enable secure
document sharing via URLs. It includes a new document access page that
allows viewing and downloading documents through tokenized links.
Adds next recipient dictation functionality to document signing flow,
allowing assistants and signers to update the next recipient's
information during the signing process.
## Related Issue
N/A
## Changes Made
- Added form handling for next recipient dictation in signing dialogs
- Implemented UI for updating next recipient information
- Added e2e tests covering dictation scenarios:
- Regular signing with dictation enabled
- Assistant role with dictation
- Parallel signing flow
- Disabled dictation state
## Testing Performed
- Added comprehensive e2e tests covering:
- Sequential signing with dictation
- Assistant role dictation
- Parallel signing without dictation
- Form validation and state management
- Tested on Chrome and Firefox
- Verified recipient state updates in database
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.
Adds the ability to align text to the left, center or right for relevant
fields.
Previously text was always centered which can be less desirable.
See attached debug document which has left, center and right text
alignments set for fields.
<img width="614" alt="image"
src="https://github.com/user-attachments/assets/361a030e-813d-458b-9c7a-ff4c9fa5e33c"
/>
N/A
- Added text align option
- Update the insert in pdf method to support different alignments
- Added a debug mode to field insertion
- Ran manual tests using the debug mode
Adds a new `ownerDocumentCompleted` to the email settings that controls
whether a document will be sent to the owner upon completion.
This was previously the only email you couldn't disable and didn't
account for users integrating with just the API and Webhooks.
Also adds a flag to the public `sendDocument` endpoint which will adjust
this setting while sendint the document for users who aren't using
`emailSettings` on the `createDocument` endpoint.
## 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
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.
## 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
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
🙇
