We ran into problems upgrading from Apps 8 to Apps 9. From our thinking, "view" access on a document class should include *every* document in that class.

We programmed a work-around that runs every hour. Under every Document Revision, Access tab, Definition tab, we populate records with all the necessary groups and their corresponding access rights.

You won’t need to give them DocMan Admin, they should be able to see the document when these steps are done:

1. Permissions for Doc Man itself and the associated screens - assume this is already done if they can see their own docs
2. User added to a Person Group that is granted access to the particular Document Class via the Approval Template (usually you wouldn’t want to do this user by user and document by document)

You can check for a given Document Revision to see if the user is granted access through either the Person Group or their own admin access if they created the document.

@ShawnBerk Thank you for your reply this really helps.
I noticed that only access is granted to the documents which created after template creation gets permission.

I think we need to give access manually to already created document revisions. Do you know whether there is an IFS functionality to do this?

@harshamc00 

Yes, that is correct, if the document revisions were created prior to the user being added into a particular person group or the group given access to the document class, they won’t have the access line added that the new user needs.

I’ve had to fix many of these manually for certain users, but I tend to do it on an adhoc basis.  But if you need to wholesale update a document class, you’ll want to do it via a migration job or through a script.  This is along the lines of what Kevin @durette was referring to above.  

There is no out of the box solution from IFS that I know of, but haven’t played with this in V10 at all to see if there is a retroactive update function.  Maybe one of the IFS Employees will chime in.

As you found out, the access template only works for new documents. Existing ones will not get their access changed. It is a good idea to use person groups in the access templates instead of specific persons since then you can add and remove people to and from the groups as needed.

True, using the groups is the best plan when you know that group needs access, then it is person independent.  But that doesn’t fix the problem of later updating an access template with an additional person group, there will still be the legacy documents that aren’t visible to the newly added group.  So it is really the same issue in that instance or at least the need to fix is the same.  

Yes, “after the fact”, nothing will help more than to manually modify the access definition in each existing document. So, you need to think already when you define the access templates, and only use groups, rarely persons. We once had a small project to build a function that would “push” an access template to existing documents, but other priorities got into the way…

This is a very poor/dissapointing answer.  IFS shouldn’t expect IT admin to manually add a record to the “Access Definition” on every single EXISTING document whenever a new Group ID or User ID is associated to a “Access Template” - why isn’t there a background job that runs nightly to take care of this?