Ramble On

We’ve just upgraded a server to 8.5.3. We have an agent that runs as a ‘web user’ but has ‘full admin rights’. The agent basically reads a view with documents that have readers fields and assembles them for display to the user. The agent needs to grab info from a protected database so has ‘full administration rights’. Previously the documents were read with the ‘users’ access permissions. So readers fields were obeyed. Various versions of this code has run this way for 10 years. Under 8.5.3 this is not the case. The readers fields are being ignored. Has anyone else experienced this issue?

Posted in Domino

I’m posting this on behalf of my colleague David Harding (@dharding) who’s been investigating XPages Single Copy Design. I think it’s best I leave it to Dave to explain:

We are looking to roll out XPages Single Copy Design to several thousand databases.  So far, we have not been able to find a recommended practice for rolling out the XPages Single Copy Design flag and template path to all of these databases.

Documentation on the Lotus Notes and Domino Application Development wiki (http://www-10.lotus.com/ldd/ddwiki.nsf/dx/Single_Copy_XPage_Design#Does+employing+SCXD+typically+have+a+positive+or+negative+affect+on+speed+of+performance%3F) suggests that setting the options in the template should propagate to databases that inherit from that template.

Quote from page:

“Is it true that selecting or de-selecting SCXD in a template does not propagate to applications already created with that template?

This is not the case. If a template is set to use a SCXD database and an application is created from this template then the new application will have the XPages from the SCXD database. And changing the template to say another SCXD or no SCXD database set will reflect in the database that inherits its design from the template.”

In testing, we have not found this to be the case.  Testing adding in the Xpage template path and checking the flag in the template*, combined with all combinations of HTTP Restarts and Design updates do not seem to visibly update the database.properties file in the inheriting database to include the $XPageSharedDesign and $XpageSharedDesignTemplate items.

*When I say Template here, I am referring to the ntf file that the database inherits from, not the Xpages source database that will be the path in the $XpageSharedDesignTemplate item in the database.properties file.

In an attempt to find an alternative, reliable method of deploying this setting we have looked at using a NotesNoteCollection to access the database.properties file and adding in the values.  There doesn’t seem to be an obvious way to locate this file, though tests have indicated that it is the only one in the database with a $Daos item, so we have been able to get a hold of it by filtering for that in the NotesNoteCollection.

So the questions are, is there a ‘best practice’ for rolling out the Single Copy XPage flag? Is the NotesNoteCollection method a no-go area?  Why are our experiences with the template not in line with the claims in the aforementioned quote?

Posted in Domino, XPages

If you use Domino’s HTTP GZIP compression, you may have issues with your Google Search Appliance reporting:

Malformed HTTP header: empty content

It appears that the Google box will tell Domino that it accepts compressed content in the HTTP headers even though it is unable to process the content. Luckily I found an easy solution on the Google Search Appliance support forum.

The solution is to add headers to the Google Box’s http requests.

1. Open the GSA admin interface.
2. Select ‘Crawl and Index‘ -> ‘HTTP Headers‘
3. In the ‘Additional HTTP Headers for Crawler’ enter:

Accept-Encoding: *;q=0

Posted in Domino, Google Search Appliance