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 @Mathias Dahl 

Thank you for the reply. 

I now understand that Restricted access is completely independent and can not be over ridden by default object access levels. So, issue connection with restricted access is solved.

Then I tried this scenario. 

Scenario 3:

From user2 created a document with no Restricted Access under document class2. 
Under persons and groups I added no users. Hence there should not be access filtering based on users for the document class 2. 

Then under default object access levels of the document class2, I checked up to Admin access.
Then User2 created a work order. 
User2 made a document revision with documentclass2  and connected the work order ID as the object. 
Then document was visible from the work order. 


Afterwards, I logged in from the user 1 and went to the work order. 
different to previously scenarios 1&2, since no restrict access was imposed, user 1 could see the attachment of the document in the work order. (Earlier the detail about attachment is also not visible) 
But when user1 tried to open the document he is getting this: 
 

Then I actually went to the document revision and checked under Access tab, which users have given access to the document 1202709. 

 

It included only user2 and the work order object anyway. (I wonder how this setting was fetched automatically for the users. It looks like it is limited only to the user who created the document and object which is connected to the document) 

So my problem is,
even the uesr1 has access to the work order, why he could not open the document 1202709, even when under default object access admin check box was ticked for that document class for the work order object.

I read about the part you mentioned about 

“”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.””

Does this theory apply here  as well? 

If so Mathias, 

can you kindly provide me an example to understand between two users, and an object(work order) how the document can behave when the document class is set up with default object access levels please? 

When I searched in the help,  in Default object access levels it says, for example take edit access- 

“Edit Access
If this check box is selected, and the Admin check box is not selected, this will be the maximum allowed access given to a user with access to an object belonging to the corresponding object type, when this object is connected to a document of the corresponding class. “ 

So according to this, the user1  has access to the work order(object) 
And by object level the document has been given the Admin access even.
But still user1 can not open the document through work order object. 

Please help.

Regards
Dhananji 




 

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.

And about this:

So my problem is,
even the uesr1 has access to the work order, why he could not open the document 1202709, even when under default object access admin check box was ticked for that document class for the work order object.

As I mentioned, you think the object access from work orders mean or do something it does not. It’s for B2B Contracting, for granting view access to contractors working on work orders. If you are not planning to use B2B Contracting, you will be disappointed in what “work order document access” do for you. When you say “even the user 1 has access to the work order”, it has no effect on the access on the document, because the work order document access logic does not look at that.

I understand if this is hard to understand but, each unique type of business object (like work order here) can have totally different ways to calculate the access, and you cannot guess how it works. Either it has been documented (some areas might to it, some might not) or you need to read the source code to understand how that object grants the access.

I think you should file a support case (to the work order team) such that they can make sure this is documented clearly. This is what is said today:

You can find that documentation here:

https://docs.ifs.com/ifsclouddocs/21r1/CreateAndMaintainDocument/AboutDocumentAccess.htm?StandAlone=true

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.