I exported the .rpt and the properties file from BIRT report designer, zipped it, and then saved it in the TRIRIGA Document Manager under the respective object (in this case, triProject). I then modified and updated my query report as “External”, and then in the “Options” tab, pointed to the ZIP file from BIRT. However, when I run the report to view the BIRT report, I get a MID error. Meanwhile, the BIRT report works fine when I run it in BIRT report designer.
[Admin: This post is related to the 03.29.17 post about getting an error when evaluating script in TRIRIGA but not BIRT designer, and the 05.11.16 post about running a BIRT report ZIP. To see other related posts, use the BIRT tag.]
We are using TRIRIGA 3.5.2. We are currently experiencing an issue with lease document attachments. When one user uploads a document that has the same name to two different lease records, the document record is overwritten.
The issue stems from the fact that the upload functionality defaults the path to \ROOT\Object Attachments\[Employee Name]\triRealEstateContract\[File Name]. There is a folder ID parameter in the action URL, but it doesn’t seem to work. Is there a way for TRIRIGA to create a folder based on the current record ID instead of the BO name?
[Admin: To see other related posts, use the Document Manager tag.]
Moving forward, we resolved an issue where malicious files can be uploaded via document upload by bypassing the client side validation.
[Admin: This post is related to the 01.25.16 post and 07.18.15 post about restricting the upload of certain file types. To see other related posts, use the Vulnerability tag or CVE tag.]
A user is unable to create a document and gets the following error “User does not have permissions to create a document”. How do you resolve this error?
The proper security access has not been granted to the Document object. Login as an Admin user. Go to the Security Manager. Select the Document object. In the right-hand panel, look at the access level. Make sure that “Read, Update and Create” is selected.
[Admin: This post is related to the 05.10.17 post about the 3.5.2 Security Manager. To see other related posts, use the Security Manager tag.]
I would like to know if TRIRIGA can manage document expiration, such as building registrations, fire regulations, or other documents that are related to specific due dates. I saw the “Location” (Building, Land) object > Assessment tab, but it seems that the “Regulatory” object can only manage inspection and opportunities for the specific location. And it seems the Document Manager only acts as a “repository”. Do you have any information about document expiration?
TRIRIGA OOB has no concept of document expiration, but it could be developed and implemented very easily. You could create a scheduled event, based on an expiration date for each document. When that scheduled event is triggered, a workflow could move the document to an expired state and send a notification.
[Admin: To see other related posts, use the Notifications tag.]
After an upload of a document, we use a custom task to send the document to a FileNet instance for content searchability. From that point, we don’t need the document in the TRIRIGA database any longer.
Is there any simple way to delete the content associated to a document record? This ensures we have control over where documents and sensitive information are being stored, and to save database space. From reviewing the API, it looks like we might be able to achieve this in our custom task with .setContent(null or empty content). Is there a nicer approach?
[Admin: This post is related to the 12.02.16 post about integrating with a CMIS or ECM, and the 06.09.16 post about using an ECM instead of Document Manager.]
Between the TRIRIGA 3.3.2 and 3.5.2 releases, applets were removed, the Document Manager upload widget was updated, and new security constraints were put in place. As a result of these changes, any “External URL” navigation items that worked in 3.3.2.x to upload documents may no longer work…
After the change from the applet upload to the HTML5 upload, the widget can no longer be used directly in a portal section without a record context.