During our field rework that makes fields appear
more accurately between signing and the completed pdf we swapped to
using text fields. Unfortunately as part of that we dropped using the
Noto font for the text field causing ANSI encoding issues when
encountering certain characters.
This change restores the font and handles a nasty issue we had with our
form flattening reverting our selected font.
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.
## Description
I added the option of downloading a document without the signing
certificate for teams. They can disable/enable the option in the
preferences tab.
The signing certificate can still be downloaded separately from the
`logs` page.
## Description
Currently certificate translations on production sometimes does not show
the required language.
This could not be replicated when creating certificates on staging
(Browserless.io) and local development (Chromium), which means this fix
ultimately cannot be tested unless on live.
This is an attempt to fix it by isolating the certificate generation
into it's own context, and applying a cookie to define the required
language.
This fix is based on the assumption that there is some sort of error
which pushes the certificate to be generated on the client side, which
ultimately will render in English due to constraints on nextjs.
## Changes Made
- Apply language into cookie instead purely dynamically on SSR
- Minor unrelated fixes
## Testing Performed
Tested to ensure certificates could still be generated
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 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
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
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
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.
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.
