Design element replication and replacement weird behaviour [Solved]

hcl-bot · July 17, 2008, 8:37am

We are experiencing a strange situation here.

I have a database with multiple replicas accross our network. This database also has a template that is replicated.

The database has three missing views, because there are deletions stubs. The cause of the deletion stubs is still unknown.

Yesterday, the administrator tried to replace the design on one of our servers and failed to do so. I was skeptical, so I created a local replica without the ACL, so I granted myself administrator access to my local database, while I have Editor access on the server.

I did replace the design, and the missing views were correctly replaced, the deletion stubs became design elements. Then I replicated with my server, because I wanted to see how the server would react to the presence of the design elements. To my surprise, the design elements were replicated and the server was up to date, with no deletion stubs.

Then I checked on some other servers after some time, and I saw that the three missing views were appearing everywhere.

This morning, I checked the servers. The deletion stubs are back and the three views are missing again. After some verifications, one server decided this night that the deletion stub was stronger than the design element. We seem to have found the origin and we replaced the design. For now we are waiting to see if there won’t be another server hiding in a corner that won’t force the deletion stub back into our production network (we have around 1500 servers…)

My questions are:

1 - Why did the replication between my machine and the server push the design element on the server while I was only granted Editor access?

[Edit] This is possible due to an ACL checkbox granting the right to design public views to editor access. Solution: remove the checkbox. [/Edit]

2 - How does the replication decide which is stronger; the deletion stub or the design element?

[Edit] I still don’t know the exact answer. However, we found out that one of our server had an older template and that the nightly ‘load design’ created the deletion stub - this template didn’t have the view. Replicating the new template and applying it on this server solved the problem. [/Edit]

3 - Why did my administrator fail to replace the design yesterday while he completed this task with success this morning?

[Edit] I’m still under the strong impression that he did some mistake because he sounded tired when I called him. [/Edit]

Thanks

hcl-bot · July 18, 2008, 10:35am

Subject: design element replication and replacement weird behaviour

I have found two anwsers:

2 - The deletion stub was caused by a design task running on a server (a replication hub) that had a previous version. We replicated the NTF file to the hub and we switch the design task off, since it’s a hub dedicated to replication.

3 - Humans are sometimes tired, exhausted and make mistakes.

Yet, question 1 still remains unexplained. Why did I successfully replicate a design element with editor access?

hcl-bot · July 18, 2008, 12:11pm

Subject: RE: design element replication and replacement weird behaviour

Old stuff but similar to your access (Editor)

It’s an old technote from my archive! In our scenario, people with editors access were able to deleted views from our applications.

Who have the rights to create views on your servers?

Technote

Lotus Notes Knowledge Base

Published

Product Area:

Notes

Date:

99-02-25

Product Release:

Notes 4.x

Document #:

141238

Category:

Workstation/Desktop\Notes Client Functionality\Security

.

This document is based on the following

Software Problem Report(s):

About SPRs

SPR Number:

SVRO3EG3PZ
PDES3QAJTD

SPR Status:

Enhancement Request
Enhancement Request

Fixed in:

Not Applicable
Not Applicable

Editors Can Modify Any Shared Folder, View or Navigator Through ACL Option

Problem:

Starting with Notes 4.0 a new, optional Access Control List (ACL) feature provides editors with the ability to create Shared Folders and Views. This feature is enabled by selecting the “Create shared folders/views” option in the ACL. However, instead of just being able to create new Shared Folders and Views when this feature is enabled, the editors can create, modify or delete any Shared Folder, View, or Navigator in the database.

Solution:

In order to prevent editors from being able to modify or delete Shared Folders and Views that they did not create and prevent them from being able to create, modify or delete Navigators, the “Create shared folders/views” option must be disabled.

Follow these steps to disable this ACL option if it is enabled:

Open the ACL of the database (File, Database, Access Control…).
Select the editor’s name or group to which they belong.
In the list of options to the right of the group/user list, look for the “Create shared folders/views” option.
Deselect the option if it is selected.

In addition, Notes Desktop users, who should not have access to any shared design elements, can edit Shared Folders and Views by right clicking on the View or Folder name in the navigator pane, and choosing “Design View/Folder” if they have been given Editor access to the database with the “Create Shared Folders/Views” option enabled.

This issue has been reported to Lotus Quality Engineering as an enhancement request.

Supporting Information: