Usability - Productivity - Business - The web - Singapore & Twins
$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.
[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:
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.
dirfile (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).
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
#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.