Mod. NJEMS Enhancement - Add Check Out/In Functionality to CF PDFs to Preserve Original and Edited Versions
Description
No description
Problem Statement
Currently, locked PDF files (e.g., a Land Use permit) in Central File can be opened and edited using Adobe, but the edited file does not get uploaded to Central File. Instead, the original file on DEP Image gets overwritten. Ideally, the process should work like CF LetterBuilder (LB) documents, where the system requires users to check a PDF document out the system before they can make edits.
Project Justification
None
Estimated Transactions
N/A
Target Rollout Date
None
Target Rollout Date Reason
None
Attachments
Upload attachments
Drop your files to upload
(Max file size: 1.00 GiB)
Uploading...
(Template) Current File Name (1 / 7)
123KB / 2.1MB
(Template) File Name
123KB / 2.1MB
Upload completed. Click here to reload the page.
Activity
Show:
Create issue
Idea
Add watchers
Details
Sponsoring Leadership Area
Div. of Information Technology
Sponsoring Leadership Area's Priority
None
Program Area Lead(s)
None
DOIT technical lead(s)
Mike McCormack
All Involved Leadership Areas
Div. of Information TechnologyWatershed and Land Management
Created: 5 February 2025, 15:19
Updated:
22 May 2026, 15:16
@John.gehr - CGI proposes a solution that leverages the same functionality as LetterBuilder. For PDF’s that are generated as locked, we can simply ensure that staff who need to serve as signatories have rights to unlock the PDF document in order to apply a signature (if you recall, whether a newly created PDF is locked depends on the process by which it was created, and often the creation steps have hard-coded the locked state so that we currently do not have a single reference data field that controls it). I can add a separate ticket in CGI Jira based on your proposal for an additional column on LB to pdf ref data, to seek to address the PDFs generated that way. We’d need to consider potential conflicts with dsmtb_doc_template.locked_only_flag. The proposal:
Specifically, for a PDF document, the following steps could occur:
If necessary, end user would need to manually unlock a locked document
During check out for a PDF document, that PDF document will be downloaded to the browser
User can make whatever edits to that PDF document (add watermarks, sign document, etc…)
During check in for the PDF document, popup launches similar to Word document checkin
User can “undo” checkout without uploading new version of PDF, or
User can upload a new version of PDF and click OK to overwrite existing file with uploaded file
If necessary, end user would need to manually lock document
Would this approach be satisfactory?
@John.gehr Confirming that Mike McCormack has been in touch to convey that this change would follow after critical PEGA rollout fixes and will explore options that work around the PEGA browser-enforced changes from the legacy features.
@Knute Jensen Just adding this comment, about what a potential solution looks like and to keep the updates coming.
Solution:
A column could be added to MTB_AUTO_LETTERBUILDER_TO_PDF - "AUTO LOCK PDF" that controls the automatic locking and unlocking of PDF documents. All existing PDFs would be locked by default, thus ensuring that existing functionality across all programs remains the same. WLM and all other programs would then have manual control over what PDF documents, when generated, are lock and unlocked by default.
Then recreate the same Check-In Document screen that exists for Letterbuilder WORD documents, with the ability to upload over the existing PDF. Users can then lock the document manually. This would solve WLMs workflow issue.