Geek & Poke hits (as so often) the nail in the middle of the head. I suspect a lot of large corporations inability to adopt stems from the fact that corporate reporting gets more and more optimistic when going upwards the corporate ladder. Blogging rules forbit me to share if that happens inside my current employer too (or not)

So you made it into the NSF. What you can do (or not) depends to a great extend on what you see. What you can see depends on your access level and membership in eventual existing Readers and Authors items (we commonly refer to items as fields, but that's not exact. Fields are the placeholders in forms to enable users to enter items, either explicit by typing them in or implicit by executing their formulas. Items is what gets stored in documents).
There is one item and two item types that govern the visibility of a document for all users and servers. The item has already been introduced in Part 1: $PublicAccess. If this item exists and is set to "1" (Text!!) a document is considered a public document. If the item is missing or "0" the document is considered a standard document.
The two item types are Authors and Readers items (mostly added by means of Readers and Authors fields). There can be more than one of each per document, but there is a limit per item type of 32k for all entries of all items of that type. The document properties (see below) also allow to specify readers, but that's just some UI. If anything else than "Readers and above" is specified there, an item with the name $Readers gets created and stored in the document.
Read protection gets activated on a document by document basis once one of the items of type Readers in the document has a non-empty value. The presence of Readers items alone doesn't activate read protection. Domino does inclusive access rights. So once you activate Read protection you have to list (explicit or implicit) all readers to a document. Domino doesn't have a concept of "all except ..."

A common fallacy is to add " to ensure access" the server name or server group name to a document into a Reader item (with the help of a computed Readers field). This activates Read Protection even if it might not be necessary (Read protection costs CPU power, so you don't want it when you don't need it). A better approach is to either add them to an Authors item or anyway have only one computed Readers field that has the server group or role in its formula and pulls in other names using Names items (from user entered Names fields). I often included a Authors item with the value [Joshua] without actually having this role in the ACL (Anybody gets the reference?). Authors items do not activate Read Protection but entitle a member of an Authors item to see a document (you only can edit what you see). So we end up with the following read access table:

To determine membership in the permitted Authors or Readers Domino evaluates your name, your group memberships and your roles (for local replicas you need to switch on "Enforce consistent ACL" for that to work).

Have you paid a visit to Lotus Greenhouse lately? IBM features the upcoming Lotus Connections 3.0 there to try. There are a number of interesting observations to be made beyond the core improvements to Lotus Connections. Lotus Connections sports the upcoming IBM OneUI v3 and I expect the documentation being available at the usual spot once it is released. One interesting structure to note is the 4 basic tabs: Home, Profiles, Communities and Apps. Apps now hosts Bookmarks, Blogs, Files, Wikis, Activities and Forums (which makes the Latin speaker in me cringe: correct would be Fori, but that never made it into English grammar):

There is no reason why that Apps menu couldn't host access to Quickr or your custom applications. So Lotus Connections evolves into the Lotus lead application. Looking at the OneUI you can see how it is evolving. This is one more reason to stick to OneUI for your custom applications. A simple CSS update will bring you in line with the new styles. Jeffrey Veen once taught me: Websites are about structure, layout and behaviour. Structure is provided by HTML, layout by CSS and behaviour by JavaScript. OneUI is all about structure - You don't need to agree with the CSS. Feel free to change anything inside the { }. Below you see the evolution from OneUI v2 to OneUI v3. Will we see user contributed OneUI themes anytime soon?


Can you spot the difference?
Update: The v3.0 documentation is out

One of the nice effects of XPages is the influx of "young blood" to Domino development. While they have no problems with " the other skills", all things Domino are new to them. Since the first homework I give them is to subscribe to planetlotus.org and create an account on bleedyellow.com to chat with us, I'll post some more entry level articles to help them along. This post is one of them. It introduces Security and Access Control in Domino.
Access Control is strictly hierarchical in Domino. If any access attempt on a higher level fails it doesn't matter if you would have access on a lower level. The resource is locked away. It is like: "it doesn't help you that your car is unlocked if you can't get into the garage where it is parked". The access levels are: server, directory, database and document.

1. Establish the users identity (or the lack of it). This can be through the Notes PKI, Username and Password, a X509 certificate or one of the supported SSO schemes (like LTPA). Authentication is triggered explicit by a logon request (&Login) or implicit when a resource is accessed that requires more access than the current level (that applies to anonymous and authenticated users in the same way)
2. Once identiy is established Domino checks if that user is allowed to access the directory and NSF
3. The ACL is opened and checked what the user can do. This can range from No Access to Manager

The access to a server is governed by the server document and the Internet configuration documents for your Internet domains/subdomains. Default for all Notes clients is to require authentication. Notes client authentication happens with the use of Notes' PKI infrastructure, so the server must trust your ID, OU or O. This happens implicit when you belong to the same OU or O. Once you are authenticated the Domino server can check your authorization. It uses your full X500 compliant name for that (like CN=Peter Pan/OU=Toons/O=Disney). Using a standard Internet protocol like http(s), pop3, smtp or imap authentication uses username and password. For http(s) there is also an option using X509 certificates. Once you have authenticated you also are "known" to the Domino server with your full qualified name X500 style. That name might look different if you store users not in the Domino directory (or an additional NSF based directory) but in LDAP. Stored in LDAP your name could follow LDAP syntax and look different (like cn=Peter Pan,ou=Toons,o=disney). Quite often your admin will allow anonymous access to your Domino server (for convenience in the Intranet or for general viewing in the Internet). In this case you are known as Anonymous. This is also the case if you use Domino designer to web preview a local NSF. Once Domino has established who you are (Authentication) it checks what you can do (Authorization). So you might successful authenticate but the Domino server figures (based on your identity including group memberships) you are not "on the guest list" and will deny you access.
Once you gain authorised access to the server Domino checks the next level of authorisation. If you access an NSF inside the Domino data directory that would be the Access Control List (ACL) of the respective NSF. However when a database is stored in a directory that is linked using a Domino Directory Link an additional authorization check is performed against the security list in the dir file (I haven't seen much use of that, but it is a valid option - especially if you want to hide the existence of an NSF from fellow server users).
The next level check is the ACL.

I'm using vPost, a service by Singapore's postal service to ship stuff I oder online. vPost provides me with an US, European and Japanese shipping address, so I can take advantage of free "local" shipping or get stuff from vendors that don't ship overseas. After a few teething problems the service works reasonable well, I can recommend it in general. You have to compare shipping rates from the vendor since vPost might not always be the cheapest option. However vPost needs to pay more attention to security. They have the basics right and use https on all their site, so that's OK. They also leverage on " Verified by Visa" that uses one-time tokens via SMS to secure transactions. The improvements needed are after you enter your credit card details and hit next:

1. The credit card number is displayed in full (other sites only show a few digits). So someone peeking over the shoulder can note it (same applies to the expiry date)
2. The security code is displayed. It shouldn't be shown AT ALL.
3. Being security concious (and not liking tracking cookies) I don't allow cookies from other websites. VPost requires me to lower my security standards. I'm sure that could be avoided

Some work to be done.

Lotus Symphony 3.0 has been in Beta for a while. Features have been frozen for quite some time and it can't be long before its release. The Symphony development team is now moving to code beyond 3.0. While this is not an official process, now is a good time to head over to the Lotus Symphony Ideaspace, proudly provided by Elguji Software. Share your ideas and vote on ideas you find there. The Symphony team listens to the space (that doesn't mean that they follow the requests, but at least they know about it). My favourites are (besides the speed and fidelity improvements of course):

• Make ODF the default format for the LotusLive Collaborative Editor (a.ka. Concorde)
• Allow to open HTML from the File-Open menu (or command line)
• Provide MailMerge to send results as eMail body
• Add XForms capabilities to Symphony and let the dataset be stored in an NSF

Any application of reasonable size has parameters that configure it. Be it the salutations, the names of departments or the task priorities. In classic Notes and Domino application you typically find @DBColumn, @DBLookup or @GetProfileField to retrieve these values. Short of @GetProfileField you could do the same in an XPages application. However I would advocate a different approach. These are the steps:

1. Create a SSJS script library. Call it "ApplicationConfiguration[ForNameOfYourApp[Group ] ] "
2. Create one JavaScript object (see source below), call it "[ NameOfApp ]Config" (e.g companyConfig)
3. Create inside this object functions that start with get and the Parameter you want to retrieve (e.g. getDepartments)
4. In your application you then include that library and simply use the object with its function (e.g. companyConfig.getDepartments() )

What you do inside that object isn't that important for this approach. It is of course important for maintainability, performance etc., but that's a story for another time. So you can stick to your @DBColumn or @DBLookup for starters (until you learn better). So why would you want to follow that approach? There are 2 reasons: abstraction and flexibility. Inside your XPage you have an uniform way to access parameters without risking that 2 script libraries have an identically named function (e.g. getLocations() where one retrieves sales locations and the other manufacturing locations) that clash. The object name will help to distinguish them. Furthermore the call to the function is independent from the actual implementation. Doing a @DBLookup/@DBColumn for rather static values might not make a lot of sense, so some caching might make sense. Instead of building that into every page you can leave that to the function -- adding caching or reading config values differently will not change its signature (signature is the fancy way of saying: how it is called and what it returns). There is an additional reason why you want to stick to the " getParameterName()" syntax. It will allow you, if you want to, to replace your SSJS object with a managed bean that allows you more flexible options how to retrieve and cache your parameters. With a managed bean you also could use parameters directly in XPages' expression language (EL). You gain the option instead of writing #{JavaScript:companyConfig.getDepartments()} the more compact and understandable EL syntax #companyConfig.departments}. As said: only if you want to. Sticking to that syntax i SSJS doesn't have, as far as I can see, any substantial drawback. Planning for that keeps your options open.
As usual YMMV.