Hi Vernon,

I have to ask: is project access enabled? I don't know enough about project access to say if it is or not, given what you have explained. Someone recently had problems similar to yours, and the reason it didn't work was that project access was not enabled for the project in question.

If you login as IFSAPP and find one of those first documents, and generate access results, what does it say about USER2's access to that document?

Thanks!
 

The project access and the document access for documents to projects operate somewhat independently of one another.  You can’t control or later grant access for a user to documents just by adding them to a project.  If a user isn’t in a document access group, then the documents created before that user was added to the group are not visible because the document access doesn’t include that user at that point.  From the point the user was added to the group, then all new documents created from that point forward should include the user. 

You can further verify in your testing by adding USER2 to one of the older documents which aren’t visible (manually on the Document Revision access), then it should be visible.

We end up doing this a good bit for new starters that weren’t in a group and then need to look at older project documents, they have to be added to the documents manually (whether connected to a project or not) in order to see the documents.

@ShawnBerk 

You can’t control or later grant access for a user to documents just by adding them to a project.

The idea is that you should be able to do just that, by using object-controlled document access, and by connecting documents to projects with project access enabled.

If a user isn’t in a document access group, then the documents created before that user was added to the group are not visible because the document access doesn’t include that user at that point.  From the point the user was added to the group, then all new documents created from that point forward should include the user.

This is true for "normal" document access and you are describing how the access templates work there.

We end up doing this a good bit for new starters that weren’t in a group and then need to look at older project documents, they have to be added to the documents manually (whether connected to a project or not) in order to see the documents.

Then you are not using object-controlled document access together with projects in the best way. Or there is a bug in there…

How document access works, including how object-controlled document access works, is described here:

https://docs.ifs.com/ifsclouddocs/22r1/CreateAndMaintainDocument/AboutDocumentAccess.htm?StandAlone=true
The documentation is packed with information so reading slowly and carefully is recommended

If something in there is not correct, not clear, etc., we would love to hear about it.
 

@Mathias Dahl

Thanks for that link Mathias, I will review and dig into our setup.  My response is based on our experience for the last six years after having paid IFS training on DocMan, so it will be quite unfortunate if this could have been done better from the beginning.  Your explanation of how it ‘should’ work wasn’t ever mentioned.  In fact, we’ve written scripts that are executed daily to keep the access in line for new users. 

I will also go back and dig up the IFS case that we raised for a related access issue and see if the understanding then aligns with the documentation. Maybe we just never asked the right question to the right person.

Thanks for that link Mathias, I will review and dig into our setup.

Welcome. I hope you will learn something new from it. It sounds like you didn't know about that part of the documentation, which is a bit sad. We write it for people like you after all, and try our best to keep it updated. In general, you should have a look at all documentation we have under "Topics in IFS". Some of those documents are a gold mine of general information on certain concepts.

My response is based on our experience for the last six years after having paid IFS training on DocMan, so it will be quite unfortunate if this could have been done better from the beginning.

Yes. But perhaps I just misunderstood you earlier. We'll see soon I guess.

Your explanation of how it ‘should’ work wasn’t ever mentioned.  In fact, we’ve written scripts that are executed daily to keep the access in line for new users.

Depending on your approach to document access that might or might not be needed. When not using object-controlled access the main recommendation is to always use person groups, both in the document access templates and also when specific lines have been added to specific documents. That's a good baseline to avoid having to update documents when new people join.

What exactly are the scripts doing?

I will also go back and dig up the IFS case that we raised for a related access issue and see if the understanding then aligns with the documentation. Maybe we just never asked the right question to the right person.

Maybe, yes. Document access is something people ask about on regular intervals so I know we have challenges reaching out on how it works. And object-controlled access in particular seems hard to understand. I think it's quite easy but then again I'm responsible for designing it...

Since it seems this is the first time you see that documentation, please let us know what you think of it. As mentioned earlier, it's a bit dense, but it should explain everything there is to know about document access. I gave it a quick read through now and it did not seem overly hard to understand. But, again, I might not be the right person to be the judge of that...

Good luck with your learning!
 

What exactly are the scripts doing?

They are directly working around a change that was introduced with V9 that we considered a bug and were told would require a MOD to fix.  We didn’t bite on doing the MOD instead created an hourly script to keep documents visible to all users on the most prolific object - Customer Order.

Details on the problem and MOD proposal are in G1966162.

I have a slightly different issue. I created a project in TEST with Project Access on. I gave myself full access to the project as well as view, edit and admin document access to the project through my team member ship. I added 2 documents.

I added “Joe Schmoe” so that he would have access to the project but unchecked view, admin and edit access to documents through his membership of another Team. But Joe Schmoe still has access to the documents

My understanding is that the way this user has been set up ‘he’ should not be able to access the documents

Any ideas?

paul

I think I’m back to realizing that what we need to happen, what logically seems valid but doesn’t work this way in V9 Doc Man is pretty related to this post.

Our exact issue is that we have hundreds of users with access to the customer order object, we have 1 user per order (order entry person) that attaches the documents related to that order.  That user is never looking at the document revision, is not controlling the access level to the document revision, nor is aware of how it is that everyone gets access to the document.  They merely know they attached the customer PO to the customer order and everyone in sales, finance, service, and manufacturing should be able to see that document.  We expect all users that have access to the customer order should have view access to the documents connected to the customer order (assuming the correct document class), why wouldn’t they?  If the permissions grant access to the object, the person group the user is in grants access to the class, and the object itself is set to grant access to the document class, then logically, the user should also get access to those documents in that class that are attached to that object.

We’ve ended up creating a DOCUMENT_VIEWER person group that everyone who can have view access to documents gets assigned to (one script is to make sure the new users are added to this group).

This person group is then connected to the few document classes that when used should have global visibility.  This part works as expected with no script to clean up.

However, when a user that is in a more limited person group than the global one initially creates the document as part of another object (opportunity for example) and then the same document is later connected to the customer order, only the user that made the connection has access to the document and all of the other users in the customer order side group can’t see it because the object doesn’t grant at least the view access that is expected as part of the object.

The other script comes along, looks for these lines that have been inserted by the object, but create no actual access line, and inserts a dummy line with view access since the object doesn’t.

Here is an example:

Now that I’ve read through the documentation, I don’t think that setting things up any differently would actually fix this issue, thus the script is still a requirement.  I did learn one thing that I didn’t realize played into the access control and that is that Preliminary and Released can be handled differently on the visibility.  For these quick document attachments of a pdf or email that is never going to be revision controlled, never going to change, never going to be touched on the document revision, the document remains in a Preliminary status.  Way too many additional steps to release for zero gain, we just want a quick connection to an object with visibility to the document, no need to control it.

I’m beginning to understand that our use case goes a good bit against the access design for DocMan even though I consider our use prolific.  90% of the documents get attached, never released, never updated, only viewed by a half dozen other users over the lifetime of the document.  The other 10% where there is a degree of control and restriction, we don’t have issues with the access really.

I also learned how to specifically exclude users to certain documents with the understanding that Person wins over Object and Group, so that might come in handy.

All in all, a useful read, but not a change to our solution nor would a different explanation at training changed the outcome either.

@paulreed 

What are his access levels through the document management person groups?

If you go through the document revision > access tab, is he connected via another group or directly via his person?

@ShawnBerk “Joe” only has access through his team. So i created another subproject called Documents and added a document and excluded “Joe” from the subproject. He does not get access to the subproject and therefore does not see the document attached that level. Not really a good solution.

So my next solution was to was to go to Document Management basic data and create a new document class 999 and then go Access Template and attach a Group ID that Joe was not a member of.

I then attached a document to the project using the new Document Class. When i logged in as “Joe”, he sees a document has been attached but “View” is greyed out. But he can detach it and stranger still he can attach a document with class 999 AND view it

@paulreed 

Yep….I get all your issues.

The problem with document classes, even if you don’t put the user in the group, but they manage to find the document class, they can still attach/create documents with that class and gain access to at least that one, even if wrong.  We had to implement a Custom Logical Unit to prevent attaching documents to the wrong class to objects not allowed, but that was more to ensure reliably connecting to the right class, rather than excluding certain users from the class.

Using knowledge I just gained, what if you add ‘Joe’ to the document class, but with zero access, can you exclude him then?

@ShawnBerk that was an interesting idea but had no effect. Then it dawned on me that I had been creating documents using the attachment bar at the bottom of the screen rather that attaching documents on the Project Document tab and using Create Documents wizard. The wizard has a check box “Restricted”. If I checked the box then the Document Access I had set up was invoked and “Joe” does not see the new created document in either the Document tab or through the attachment task bar. With a little more testing I think it is working as designed and have learned some more about Document Management in the the process. Thx 

More things I learned today:

Restricted Access

If other persons should not be aware that a document exists in the system, it can be protected via the Restricted Access option. If this option is enabled, it will hide the document from everyone who does not have at least View Access to that particular document revision.

This property is set in the document title. Any user with administrator access to any document revision of a given document title should be able to change the Restricted Access option.

Firstly, you are talking about object-controlled document access here as well, right? A user should not never be allowed to grant himself access to a document by connecting it to an object that is enabled for object-controlled document access. There are protections against that built-in. It’s very important that this works. If a user is not one of the admins of a document, and if they connect a document for which he did not have access to an object that is allowed to control the document access, then the “object access line” for that document should have “empty” access (not View, not Edit, not Admin). Is this not how it works for you, or did I misunderstand?

Also, there is an optional functionality where you can stop users from creating documents from certain classes. By default everyone can create a new document of a certain class. But you can override this by providing a list of persons or person groups that can do it instead.

Found the case. Here is the description:

Symptom:
   One user creates a document revision and the object connection - all works fine.  If one user creates the revision but another creates the object connection, the access for the object isn't set correctly.
Consequence/Value:
   Some users cannot access documents attached to the Customer Order when their access right is inherited only from the object connection.

Funny, that is what I mentioned in my recent reply: a user who is not an admin of a document should not be able to grant access to other users by connecting the document to an object that can control the document access. It’s one of the most important rules, if not THE most important ones, in the object-controlled document access concept. If you think about it for a while, I think you will come to the same conclusion. Think about it: what if I can grant myself access, or grant someone else access, just by connecting a document (which I don’t “own”, or have any access on) to an object. It would be a big security hole.

You can see that as a limitation of that concept, of course, but it’s one put in there to protect the against illegal access to documents.

PS. It might not be practical if this needs to happen a lot, but it’s not hard for any of the admins of a document to change the maximum access level granted from the customer order. Is this what the script is doing?

@ShawnBerk 

However, when a user that is in a more limited person group than the global one initially creates the document as part of another object (opportunity for example) and then the same document is later connected to the customer order, only the user that made the connection has access to the document

There is no such rule that explicitly only grants access to the person who connects a document to an object.

When a document is connected to an object that has been enabled for controlling document access, a check is made: is the user who does the connection one of the admins of the document? If they are, then the "default object access level" is applied to the object-access line that is added under Access when the connection is made. If they are not an admin, then the access levels will be set to "empty". Again, this is to protect abusing the object-controlled document access concept.

...and all of the other users in the customer order side group can’t see it because the object doesn’t grant at least the view access that is expected as part of the object.

The object probably grants the necessary access, but the document "vetos" it, using the access on the "object line" under the Access tab on the document. One of the admins of the document must set the access to at least View for others to be allowed to view it (if the customer order access rules allow it).

I did learn one thing that I didn’t realize played into the access control and that is that Preliminary and Released can be handled differently on the visibility.

Are you referring to this section:

Access is defined per document revision for persons, groups and objects and each access line can be enabled and disabled when necessary. The ability to disable access lines is convenient during the development of the document, before it is released. In this way, the access template can include persons that has no access during the preliminary stage, by having the Enabled option cleared. When the document is later released the disabled access lines can be enabled, opening up the access to a wider audience.

That "feature" is something you use "manually". When a document is released we present the option to enable access lines that were initially disabled. You can toggle access lines on or off at any time, but we provide that option as a convenience feature while releasing, because it is a natural point in time to make the access to a document to a wider audience (when it was preliminary you might want to keep the access to a smaller group of people.)

For these quick document attachments of a pdf or email that is never going to be revision controlled, never going to change, never going to be touched on the document revision, the document remains in a Preliminary status.  Way too many additional steps to release for zero gain, we just want a quick connection to an object with visibility to the document, no need to control it.

I understand. I want to mention the "quick release" feature though, in case you do want to release more documents. That does not force the user to do much work at all.

I’m beginning to understand that our use case goes a good bit against the access design for DocMan even though I consider our use prolific.  90% of the documents get attached, never released, never updated, only viewed by a half dozen other users over the lifetime of the document.  The other 10% where there is a degree of control and restriction, we don’t have issues with the access really.

Docman needs to support a wide variety of use cases, from simple meeting notes with no need for access or status control to important legal or HR documents where access and control is very important. Because of the latter use cases, it might sometimes be harder than necessary to handle the former. But we have tried to add options to make easy cases easy, so to speak. For example, you can set Person ID to "*" in the access template for a document class and have "everyone" get the access level set on that line. You would do that for documents that require "no access". So it's basically a balance between having a really tight security and at the same time allow for an "easy" setup. As you can understand, if there is a conflict when designing some new feature, security always wins...

All in all, a useful read, but not a change to our solution nor would a different explanation at training changed the outcome either.

Comforting perhaps then, considering you spent time and money on that workshop back in the day? :-) 

Lastly, about this:

We expect all users that have access to the customer order should have view access to the documents connected to the customer order (assuming the correct document class), why wouldn’t they?  If the permissions grant access to the object, the person group the user is in grants access to the class, and the object itself is set to grant access to the document class, then logically, the user should also get access to those documents in that class that are attached to that object.

I think the above is the core of the problem, for you. Let me try to express it in my own words and see if you agree that I understood it correctly:

Your point is that, even if it's not one of the document admins that connects a document to a customer order, the "object access line" should get the default access levels are per our basic data because that document class access template already states that "everyone" (if that is the case) should get access to new documents in that class. Am I right?

We did not think about that scenario and now that I do it looks logical at first. The problem is that the document class access template is something different than the object-controlled document access setup. The latter becomes one line on the Access tab on a document whereas the former is a possibly large list of access lines that should be applied to new documents. As it stands, I don't think we can marry these two concepts better right now. If you can think of a concrete change that would allow things to work more like you want it to, and without risking security, we can always consider it. We want a flexible and powerful document access concept after all.

I just realized something: what if the document class access template made a certain group of people admins on some of the classes that are usually connected to customer orders? Then, if any person of that group connects such a document to a customer order, the default object-controlled document access levels would be applied. It might not work for you but I'm throwing out the idea for you to think about.

 It might not be practical if this needs to happen a lot, but it’s not hard for any of the admins of a document to change the maximum access level granted from the customer order. Is this what the script is doing?

It actually is hard for the document admin to change the access level, actually impossible in our scenario, and it happens hundreds of thousands of times in our use case.  The majority of the documents attached that end up on the customer order are attached by field sales engineers who don’t use V9 APPs, but rather use V8 SAM (yes, still), consequently, they have never seen the document revision, nor do they have access to it because it is in APPs, not SAM.  They by nature are making the initial connection, but will almost never be the user later granting access to the other users by connecting to a global object.  We needed the object to do that work.  The entire time we were in V8, that is how it worked and worked fine for us.  Then when V9 came along (we moved APPs up, but not SAM), that loophole was closed, which is why we went with the script to add back just the minimum view access from the object standpoint to retain the visibility to the rest of the organization.

This entire landscape changes for us in Cloud, so I’ll have to rethink everything in this regard it seems.

For example, you can set Person ID to "*" in the access template for a document class and have "everyone" get the access level set on that line.

I will keep this in mind as an alternative to rebuilding the script in Cloud, it may suffice for our open case scenario for certain document classes.

That "feature" is something you use "manually". When a document is released we present the option to enable access lines that were initially disabled.

OK, now I realize what you were meaning, OK, so not something we were missing out, we use this feature for the revision controlled documents on the wizard dialog.  

Your point is that, even if it's not one of the document admins that connects a document to a customer order, the "object access line" should get the default access levels are per our basic data because that document class access template already states that "everyone" (if that is the case) should get access to new documents in that class. Am I right?

Yes, this is right, and I bet if you think about the poor position we’re starting from with the hybrid CRM/APPs setup, I’m sure it is not a scenario that would be considered.  Nor am I saying it really should be.  Likewise, I’ll not be as frustrated with what doesn’t work for us now that I better understand the design intent.  I just have to find a way to work within the confines it presents (which we do right now), but as I said, I’ll want to take the opportunity to redo it in Cloud.

Appreciate the significant discussion Mathias.

@Mathias Dahl 

@ShawnBerk 

The entire time we were in V8, that is how it worked and worked fine for us.  Then when V9 came along (we moved APPs up, but not SAM), that loophole was closed

I wonder what loop hole that might be. The current access concept, including object-controlled document access, has been the same since Apps 8. We might have fixed bugs, of course, and possibly one of those affected you. Do you know what it was or was it what you already mentioned you reported via that case? If the latter, then that behavior should have been there from Apps 8 even.

@ShawnBerk 

Yes, this is right, and I bet if you think about the poor position we’re starting from with the hybrid CRM/APPs setup, I’m sure it is not a scenario that would be considered.  Nor am I saying it really should be.  Likewise, I’ll not be as frustrated with what doesn’t work for us now that I better understand the design intent.  I just have to find a way to work within the confines it presents (which we do right now), but as I said, I’ll want to take the opportunity to redo it in Cloud.

It doesn't need to be a bad thing to have a few scripts or background jobs or whatever that runs now and then, to tweak the system to work exactly like you want it to. You're only doing automatically what you could have done manually. So no harm. It would be good of course if the existing business logic supported what you wanted to do/your way of working, but at some point we have to accept that it's not always the case.

From some of what you have written I have been thinking to myself: why not just add a line with Person ID = * in most of your document access templates, with View access. Or do you have documents that are "secret" to some users of customer orders and not others?

@ShawnBerk 

This entire landscape changes for us in Cloud, so I’ll have to rethink everything in this regard it seems.

IFS Cloud is for sure a big change to many upgrading customers. But you can sleep better knowing that the access concept in Docman is the same  

From some of what you have written I have been thinking to myself: why not just add a line with Person ID = * in most of your document access templates, with View access. Or do you have documents that are "secret" to some users of customer orders and not others?

This is the first change I’m going to make for the open document classes to remove the need for the script.  The closed or restricted document classes then I wouldn’t include this line on the access template.