Solved

Document Access -> Person ID '*' -> IFS 9

  • 26 March 2021
  • 6 replies
  • 319 views

Userlevel 6
Badge +14

We have a generic Person ID that is used at our company, which when used signifies that everyone at the company has access to viewing the document. This generic Person ID is an asterisk (*). When this is listed in the Person ID, there is no security to prevent anyone from viewing the document.

I have three questions:

1- Is there a way to deny viewing access to a user even when the asterisk is used in the Person ID field?  

2- How can I control who belongs to this group signified by the asterisk?

3- If the two questions above are impossible, would it be possible to create a warning pop up window event that will prevent specific users from accessing certain classes of documents, and in the moment when the user clicks to view an event it will reject the access? I know how to create pop up warning windows but in using an event, but in this case nothing could fire the event. Any idea or example? Screenshots would be helpful or a tutorial document.

 

icon

Best answer by Mathias Dahl 26 March 2021, 18:04

View original

This topic has been closed for comments

6 replies

Userlevel 7
Badge +30

Unfortunately, you cannot always combine having a person with Person ID = * with using the “Person ID = * feature” in document access, and have things work like you want to.

But, firstly, just so that you know, you can use the “Person ID = *” functionality in Docman without actually having such a person defined in the system.

Options:

  • Remove the “*” person. Unless it is used in places that prevent you from doing so.
  • Create another generic person and use that in your access templates and/or access definitions. Perhaps it would actually be better since then you can give it a name that actually tells you what it is for. Like “GENERICDOCMANPERSON” (or whatever).
  • Define a person group with all persons in it and use that in the Group ID field. This might be cumbersome, or not, depending on how many persons you want to include. A custom event could then make sure that new persons are added automatically if you want to avoid manual work.

I hope one of these options would help.

 

Userlevel 6
Badge +14

Unfortunately, you cannot always combine having a person with Person ID = * with using the “Person ID = * feature” in document access, and have things work like you want to.

But, firstly, just so that you know, you can use the “Person ID = *” functionality in Docman without actually having such a person defined in the system.

Options:

  • Remove the “*” person. Unless it is used in places that prevent you from doing so.
  • Create another generic person and use that in your access templates and/or access definitions. Perhaps it would actually be better since then you can give it a name that actually tells you what it is for. Like “GENERICDOCMANPERSON” (or whatever).
  • Define a person group with all persons in it and use that in the Group ID field. This might be cumbersome, or not, depending on how many persons you want to include. A custom event could then make sure that new persons are added automatically if you want to avoid manual work.

I hope one of these options would help.

 

For question# 3

If the two questions above are impossible, would it be possible to create a warning pop up window event that will prevent specific users from accessing certain classes of documents, and in the moment when the user clicks to view an event it will reject the access? I know how to create pop up warning windows but in using an event, but in this case nothing could fire the event. Any idea or example? Screenshots would be helpful or a tutorial document.

Is there a way to do it using an event to reject access to a particular user?

Userlevel 7
Badge +30

Before spending time on the third question, do you have any comments on the three options I presented? I would see those as the main options.

 

Userlevel 6
Badge +14

Before spending time on the third question, do you have any comments on the three options I presented? I would see those as the main options.

 

Yes, your previous idea from my questions 1 and 2 are the best options. However, Mathias, if I change the person_Id * it will prompt many IT requests to add different users to different groups later. We have more than100,000 documents where person_id * is granted access. Right now, I just need to block two users from viewing the documents. For that reason, I am asking if I can disable only 2 users when person_id * is included in the access pool? 

Userlevel 7
Badge +30

I see. Well, I still recommend against having a person with Person ID = * in the system, at least for the purposes of Docman. It is not hard to update your current access records with a new person. Also, as mentioned, a custom event can keep a person group up-to-date, if you want to try that option.

The only official way to block someone, or revoke access, who has already got access (for example from a person group), is to add a separate line for the person, with his/her person ID, and set that line to have no access (all three access levels should be cleared). Having said that, for the special handling that we have for Person ID = * I am not sure we can do that. But you could try it and see.

The last option, which is mostly a hack, and I am not sure it will work, is to add a custom event to the table behind the File Operations Log screen. We log each file operation there, including View. Again, if it works, the custom event could check the access of the document, or check for a specific document or whatever, and, for some users, raise an error. This *might* stop the user from viewing the document, but I have not tested it myself.

By the way, do you need the “*” person for other purposes? If not, you can remove it. As mentioned it is not needed.

 

Userlevel 6
Badge +14

I see. Well, I still recommend against having a person with Person ID = * in the system, at least for the purposes of Docman. It is not hard to update your current access records with a new person. Also, as mentioned, a custom event can keep a person group up-to-date, if you want to try that option.

The only official way to block someone, or revoke access, who has already got access (for example from a person group), is to add a separate line for the person, with his/her person ID, and set that line to have no access (all three access levels should be cleared). Having said that, for the special handling that we have for Person ID = * I am not sure we can do that. But you could try it and see.

The last option, which is mostly a hack, and I am not sure it will work, is to add a custom event to the table behind the File Operations Log screen. We log each file operation there, including View. Again, if it works, the custom event could check the access of the document, or check for a specific document or whatever, and, for some users, raise an error. This *might* stop the user from viewing the document, but I have not tested it myself.

By the way, do you need the “*” person for other purposes? If not, you can remove it. As mentioned it is not needed.

 

Thanks.