Default object access levels and Restricted access

Hi, thanks for posting here.

In a sense, you can forget about Default Object Access Levels when trying to understand how the document access works. It’s secondary and only a help selecting the right access definition check boxes for object-based document access.

What you must understand is how the document access rules work, what options we have to give a user access to a document.

I would rather not want to repeat here what the documentation already says about this, but briefly the options are: person-, group- and object-based access.

There is also a priority between those three “ways” to give a user access, person-base having the highest priority, overriding group- and object-based access. And then, of course, we have the “Docman Administrator” system privilege that gives a user super powers.

Now, about the Default Object Access Levels basic data… It controls what check boxes should be selected under Access / Definition in Document Revision, for “object access lines”, when the line is created (which is when you connect the document to an object, or enable the object to be able to control the access.) 

It’s simply a way to not have to set those check boxes manually, as an admin of a document. That is all it does, provides the default state of those check boxes, when a document is connected to an object that is enabled for controlling the document access. The basic data itself does NOT control the access directly. The state of the check boxes is part of the access control however.

Object controlled document access is what can grant a user access that they did not already get from a person- or group-based access line, via an object connection. For this to work, the object must have business logic to “calculate” the document access.

All of the above is independent of the Restricted Access functionality. Restricted Access means ONE thing only: if it is enabled for a document and unless you have at least View access to any document revision, you will not see that the document exists. That’s it.

Now, to your main problem, I think, which is that User 2 does not have access to the document.

I think that, for some reason, you think that, just because User 2 created a work order, and that work order was connected to the document (by user 1), it means User 2 should get access to the document. This is outside the control of Docman really, and has everything to do with what access rules are defined on the work order side. I actually don’t remember those rules (they are not in Docman), but I don’t think it is as simple as that the creator of the work order gets access. That is now why work order is able to control the access.

The work order document access rules is only meant for B2B Contracting, I think, and not for B2E (“normal” use of IFS). Here lies the problem, I think, in how you think the work order can control the document access.

It’s hard to blame you for not understanding how a work order controls the document access, because I am not sure it has been documented.

I just checked the source code and, this is my understanding of the access checks done from a work order (and please remember that B2B Contracting is the reason we have enabled this):

1. If the document is not released, the access from the object is “none”. This means that no access will be given to the user unless he already have it from some other access line.
2. If you are the vendor of a work order, and your user has that Vendor No set as the CONTRACTOR_ID property on the user, then the access will be View.
3. The next part of the code, and I will quote a comment in the code here, does this: “Check if the contractor available in the contractor list”. If that is true, then the access is also View.

If I were to guess, you expected a work order to affect the document access in some quite different, perhaps simpler, way, am I right?

Also, as you can see I only mentioned ”none” or :”View” access. That is, again, part of the context of B2B Contracting here. This is about enabling some contractors view access to documents connected to work orders. They never get Edit or Admin access, for example. It also does not matter what default access levels or what actual access levels you set on the document revision, because the work order will never “grant” a higher access than View.

Now, what is it that you try to achieve here, and why? What is the purpose of giving user 2 access? What flow is this? Etc.

Possibly you should not even use object controlled access here, since it might not do what you want, when the document is connected to a work order.

Hi again,

I will divide the answer into several.

As mentioned earlier, I recommend you ignore the default object access levels for now, until you understand how the access mechanism works for object controlled access.

On an “object access line”, in Document Revisions / Access Definition, the check boxes determine the “theoretically maximum allowed access” from the object, if the object grants it. This is very important to understand.

As I explained earlier, the document access logic for work orders either grants “none” (no access) or “view”. So, it does not matter if you select the Edit or Admin check boxes in Document Revisions / Access Definition. The access will never be higher than View.

On the other hand, should the object grant higher access than what the line under Document Revisions / Access Definition says, then the latter wins. So an object might want to grant the user Admin access, but Document Revisions / Access Definition says View. In that case, the access will never be higher than View, from that line.

PS. It can sometimes help to use the Access / Results tab, to let the system show what is the resulting access for each user given the current access definition. There you can see from what source, or what type of access is the result.

It will not help you understand how work order calculates the access though. Only the documentation can do that.