temp := @Name([Abbreviate]; @ServerName);
When I use this formula in a view from the server, I get the proper server name. But from the same view from a local replica, I get my own user id, and not the server name “local”. Any ideas. Thanks people for any clues.
Subject: RE: @ServerName in a view
If you read the documentation of this function, you’ll see that it’s functioning exactly as designed.
“Local” as a server name is never used in any formula or coding situation. That’s just a value displayed to the user in dialog boxes and what-not.
@Subset(@DBName; 1) will get you “” for local or the server name if the user is using a server replica. If you want to change “” to “Local” then you can use:
@Replace(@Subset(@DBName; 1); “”; “Local”)
I’m a little curious to know why you would want to do this in a view, but hey, it’s your app.
Subject: RE: @ServerName in a view
Andre, the application is very interesting. It is for our European users and the db has employee confidential information. The personal information displayed must remain secure from employees in different countries. Employees from Germany can view other personal employee information, but only those from Germany. Their user id contains the country name - Germany, UK, France, etc. So in many of their views we use the user id in the column views to determine what can be displayed to the user. For example, if the user is from Germany, then the personal information of employees in the database from Germany can be displayed in the view, but if the user is from France, they will not be able to view the personal data on the employee from Germany. However, they will be able to view other non-personal data of all the employees in the database. We use the @Username to determine accessability for each user and this works well on a user’s local replica, but not well on the server views. So if the user is working from the server, we don’t show any personal data in any views. Thus, we check to see if the user is working on the server or the local replica by using the @ServerName function and that works for us. Hope this was not too complicated. Thanks for you initial response.
Subject: RE: @ServerName in a view
That’s NOT security - Yes, the data is not shown in the view, but any user would be able to look at the fields within those documents, either through Document Properties if the design is not hidden, or using backend methods like NotesPeek or Script commands.
If this data is really confidential, I think you need to re-think this !
Subject: RE: @ServerName in a view
Graham, it is not a question of total security, but rather the security precautions taken to protect against data view/access by typical users; the laws consider the possibility for illegal “technical” or “hacker” invasion which could and might happen. Anyone caught using these techniques to “invade” data could be prosecuted and users are aware of this and the laws. They sign statements to that affect.
Subject: You can get into serious legal hot water if you don’t do better than this
There seems to be something of a fine line here between information you deliberately display and information you just hope nobody bothers to try too hard to see.
We’re not talking here about techniques used to gain illegal access to an application, but standard features of the Notes client that people can use to display information about documents. For instance, users can create their own views in an application. This is not a hacker technique and is not considered illegal. It’s a routine method for personalizing the interface of a Notes application. In their own personal view, the user can add whatever columns they want, not subject to your control.
For another situation that’s even more likely, suppose someone wants to do a full-text search. They search for some word that is part of the private information, and it’ll show them all documents that match that word. So although the view does not display the word in any column, the user can still see which documents contain that word – wouldn’t that be a breach of the privacy law? Are you going to arrest the user now because they searched for a word and didn’t realize they would have to add search terms to restrict the search to the documents they are supposed to be able to see this information in?
Furthermore, do they have access to servers in other countries over the network? If a user in France opens the replica on the Germany server, won’t they be able to see all the Germany data? This can easily happen by accident, for instance if someone using a different replica sends them a doclink, view link or database link. Or if the user’s normal server is down, and their client tries to find another replica.
I think I would be very afraid to use your application. It would be too easy to get thrown into jail.
There is also the matter of due diligence on your part. To a certain extent you can assume that your users are going to not try to hack into the system. But – though I’m not any kind of legal expert – I suspect your company may still have some liability if someone can show that the supposedly private information can be obtained with just a few keystrokes, using client features that are well documented.
Subject: RE: You can get into serious legal hot water if you don’t do better than this
Don’t get carried away. The European division management understand the application a lot better than you might think and the country laws. this isn’t their first notes application in this area. They have blessed the solution and are VERY satisfied. That is what counts, right?
Subject: RE: You can get into serious legal hot water if you don’t do better than this
Right – until their oversight gets them arrested. I think the general level of understanding here is a little lower than you estimate. All it would take is a single user complaint to an ombudsman to bring the whole house of cards down.
Subject: RE: You can get into serious legal hot water if you don’t do better than this
Right. Managers cannot be expected to understand the technical consequences of a Domino design. They only know what their technical staff tells them.
As the technical staff with responsibility for this application, Mr. Rellinger understands some of the consequences of the proposed design – since I have explained them, he should. As a technical professional, it’s his ethical responsibility as well as his only possible legal defense to make sure that the managers who approve this design are aware of these issues, and this notification had better be in writing, preferably signed and dated by the managers in question.
Because if this ends up in court, these managers may well claim that they were unaware that users could accidentally view supposedly secure data because Mr. Rellinger failed to tell them so.
This is serious business. John, I feel you could possibly go to jail or at least get fired for ignoring these issues – especially if, as anyone can see from reading this forum, it should come out that you were specifically warned about them.
Subject: RE: You can get into serious legal hot water if you don’t do better than this
When I said that the application has already passed managements requirements for the solution they requested, that includes management review of the solution requirements as well as the ‘technical’ requirements have been reviewed by notes ‘technical’ experts in the EUROPEAN division and they know notes a lot more than you give them credit for. I repeat, this is not their first notes application in this area, but rather one of SEVERAL. There is no fear or worry of jail or firing or legal defense required, or any other problems at this time, so lets move on!
Subject: RE: You can get into serious legal hot water if you don’t do better than this
“as well as the ‘technical’ requirements have been reviewed by notes ‘technical’ experts in the EUROPEAN division and they know notes a lot more than you give them credit for.”
Based on the original question in this thread, and the proposed architecture for the overall solution that you’ve described here, I suspect they know very little about Notes.
Has anyone shown them, say, copying the document into their Mail database, going to the All view and hitting Alt+Enter?
What’s distressing, John, is that you list a us.ibm.com email address here? Do you really work for IBM?
Subject: I’m taking this offline with John.
Subject: Correct. If you want to control read access to documents, use the provided document-level read security control: Readers fields.
It would be easy to create one role per OU and then assign each OU that role in the ACL using */OU/Acme:
Subject: RE: Correct. If you want to control read access to documents, use the provided document-level read security control: Readers fields.
Bruce, thanks for the information. We also are using “roles” assignment to users. There are over 50 roles that can be assigned to users, some may get many roles, others only one role assigned. This allows the users to access the documents as the “roles” are also used in readers fields on each document. But after granting access, we need to protect access to certain data on the form, and we use the user id and the documents “country” field to help accomplish that. Thanks again
Subject: Now I see. Then either encryption or storing the sensitive data in another database and retrieving it via @dblookup/etc would be secure ways of controlling that access.
Except the sensitive data wouldn’t display in views.
Subject: @ServerName in a view
Because that’s the way it works. Please read the help file.
Dan