Thursday, 23 May 2013

PDF Settings and Recreation of old PDFs

There is one thing that needs to be discussed here. We have option to allow admin to set PDF settings for document or a group. So now whenever a PDF is generated, those settings are used.

If we change the settings, they will be used in pdf generation next time. So old documents has PDFs with the old settings as PDFs were created before settings were changed.

So,  do we need to recreate the PDFs of old documents if PDF settings are changed? Two things that we need to decide between:

  1. If we are re-creating PDFs, we will have to generate PDFs for all documents to which this settings apply, so more processing (someone unnecessary also)
  2. If not, then we won't see pdfs with new settings until a new version is checked in or a new document is added.

Monday, 29 April 2013

Restricting the depth of the Document Group hierarchy

While working on UI, we realized, we need to have some control on the depth of the document group hierarchy to make UI and UX better. We have found out that depth of 2 , i.e. 2 sub groups, is sufficient and in most use case, they are more than enough.

We just wanted to take your opinion about this. What do you think about this?

Tuesday, 16 April 2013

Front Page Requirements

Front page requirements:

The data requirements for the  front page of the SOP is a combination of organization information to identify the document, Document information, and potentially a watermark. Please see examples of SOP's sent to Kishan

Organization Information:
Organization Name:
Organization Address:
Organization Logo:

Document Group: (Version 2)
Document Group Name
Document Group Logo
Document Group Front Page Template

Document Information Required:
Document Title:
Document No:
Version No:
Date Approved (Effective Date):
Document Owner:
Document Approver: (Note, there may be multiple approvers). Is it possible to put name and signatures of the approvers?
Copy Expiry Date

Version 1: The user can select from a small list of pre-defined fron page templates. The company name and logo will appear on the front page, as per the template definition. The document information will also be formatted according to the template definition.

Version 2: The concept of document groups having the ability to select a template and logo for all document s within that group is that some companies have subdivisions with different names etc. Therfore, while they may want to keep a single document tree, they may want subgroups of that tree to have different names and logo's on the front page of the SOP to identify that division etc.
An extreme example would be General Electric...    They have hundreds of companies within the organization, each with their own name, logo etc.

Thoughts, comments, criticisms welcome :)


Monday, 15 April 2013

Watermarks in PDFs

Are we going to have watermarks in the PDF that was generated by DocControl? 

Thursday, 28 March 2013

Length of Front Header Page

The length of front header page, added in PDF of the document, is just a one page or it can vary depending upon the content. I mean, if we have long list of approvers and all cannot be accommodated in single page, what should happen? 

Tuesday, 26 March 2013

Thoughts for Version 2 or 3 or 4...: Google Doc integration

Any thoughts on the level of difficulty in adding a Google drive feature-set to a future version of DocControl. Note, this also may work with DropBox......

(1): DocControl Login authentication via Google.

(2) A "Publish to DocControl" widget on Google drive.
1-click send a file of any type to DocControl:
Standard document types would be sent to DocContol in their native format.
Native Google documents would need to be converted to PDF prior to sending. The original Google doc would stay on the drive.  This would create a PDF snapshot that could go through the approval process.  Just like  the upload button in DocControl.

(3): For companies using Google Drive, you could also  publish the approved PDF Controlled Documents in Google drive, under the same folder structure as in DocControl, with appropriate view permissions. Users could then view the approved PDF documents in Google Drive using permissions defined in DocControl.

Does anyone else have ideas for a future version!!!!!!!!!!!!!!!!!!!!!!!!!

Monday, 25 March 2013

Doubts - Re Matt/Kishan/Nrip 's Discussion on PDFs

1. What details will be there in the header page of PDF that was published?
2. What kind of flexibility is to be given to the user for this header page?
3. What is the formatting going to be like?
4. If we are using fixed formatting for the header and if rest of the pages has different formatting, fonts etc, what should happen?
5. What going to be in footer?
6. What are the options available in footer for user?

Wednesday, 6 March 2013

Approval Deadline

Who will decide the approval deadline? Are deadlines also applicable for retirement requests?

Tuesday, 5 March 2013

Competitor Features

  • Exchange comments and notes with people you share files with.
  • Use a web browser for uploading and downloading files.
  • Encryption is used to transfer all files.
  • Track complete history of file versions and who accessed them.
  • Customize the file sharing experience to be consistent with your business style such as logos, colors, etc.

Customer Feedback , Knowledgebase and Trouble Trackers

Lets put down the scope of what we want ...

Then look at our Options?

Monday, 4 March 2013

Actions to be Audited

Here is the list of actions that should be audited, in my opinion. Please suggest the missing actions that should also be audited.


Document Downloaded for viewing
Document Created
Document Checkout
Document Checkin
User Group Created
Members Added in User Group
Access Group Created
Members Added in Access Group
Approver Group Created
Members Added in Approver Group
Document Group Created
Members Added in Document Groups
User Added
Document Owners added
Sign up
User verified
Document Approved
Document Retirement Requested
Access Permission Given to Document Group
Access Permission Given to Document

Failed Logins

Friday, 1 March 2013

Allowed file types

We have option to allow certain extensions to be added only. Consider a scenario, we have added a .log file as document and those files are being accepted. Now the policy changes and .log files are not allowed to be uploaded. What should happen if user checks out old document and try to check in the file? Should it be accepted?

What happens when a document retires?

Retired documents are equal to  deleted documents? Or they can be viewed?

Who has the ability to request the retirement for a document? Are approvers of documents same as the approvers for retirement?

Deadline for Approving

What is it exactly? What happens if deadline is not met?

What is chain of custody?

In MRD,  1.1.1 Solution Overview section contains a feature called chain of custody in Security  and Compliance Management  . What is that?

Wednesday, 27 February 2013

Approval Permission vs Access Permission

If someone is added as an approver to a particular document/document group and he doesn;t have even the read access, what should happen in this case?

Tuesday, 26 February 2013

Approvers for a Document with multiple parents?

If a document is not specifically assigned any approvers' list, approvers for that documents should be those which are assigned for the document's parent. If a document has multiple parents, who will approve the document? Approvers of all parent groups?

Sunday, 24 February 2013

How does versioning of Document work?

In DMS, how does versioning work? Does user gives the versions, system generates the version or both?

Should we take version number from user and generate a revision number and also store it?

I am confused how versioning will work? Please enlighten me on versioning of a Document.

Thursday, 21 February 2013

Access Permission conflicts on UI level

There is a possibility of access permission conflict on UI. In current UI, when user views all document, he will see all the groups and documents that are the part of root document group (i.e. on top level in hierarchy).  Documents that the part of only some group will only be visible under only those groups. If a person does not have read permission to those groups, he won't be able to see that document because there is no path for the use that lead to the document.

For example, as shown in above image, there is a doc which is only inside the Steering Wheel. User has permission to read/write that document. But he doesn't have permission to read Steering Wheel Document Group. So if he want to read the document inside it, he must be able to go to Steering Wheel and get a link to see document. But he can't as he won't be able to see Steering Wheel in first place!

So, such implementation will cause issues for such scenario.

There are two possible solutions that I can think of,

1. User will be able to read a document group (but see his file only) even if he doesn't have permission, if he has access to one or more document groups or documents inside that document group. But this thing will cause another visibility issue. Suppose if a document is part of several document groups. User have access to some groups only, then he will also see the other document groups (with just his file) for which he doesn't have access to. So, he will be actually see the name of document group which he is not suppose to know in some case. Again, a solution for that can be, if a document is part of at least one group that he can read, he won't be able to see other groups. This approach looks ideal but again, computation overhead and complexity for system will increase causing slower performance if number of document/user/access groups/members and documents increase and relation between them become complex.

2. A much more simpler approach to this issue may be, in root document group (i.e. page after clicking View All Documents link), as we are listing all document groups, we also list all the documents so that there is no issue for visible path to access the file. There is always a link to document if user has access to it. This approach has very less overheads compared to first approach.

So what approach do you think is good to adopt?

Thursday, 14 February 2013

If a Doc is to be approved by a group of users and half of them approve it while the remaining half
don’t so what will be the final decision?

If I am a Doc Owner who has the rights to set the Access Rights for my Doc? The Owner himself or
 the Admin?