The print version is now live on Amazon.com, with electronic edition and other vendors to follow.
| Doctor Dead, A Percy and Quincey Adventure |
San Francisco, 1904: Thirteen-year-old Percival Drew expected to spend the summer doing little more than tinkering with those new-fangled gasoline-powered motorcars. But that was before an insane scientist took an unhealthy interest in his cousin Quincey's very rare blood type... Before people began vanishing from the streets, to reappear as the mad doctor's undead minions... Before the villains infernal devices gave him the ability to strike at will, destroying all who opposed him! With chaos descending on San Francisco, only two boys know the secret to defeating the undead doctor. But can they act in time?
We've been having a problem with one customer who was migrating their on-premises mail users into SmartCloud Notes, because they ade a mail template change in their on-premises environment after giving us "staging" replicas of some users' mail files. The DESIGN task on the users' on-premises servers updated their mail file designs from the template, and this change replicated to users' local replicas (MMRs in this case). When the users replicated their local mail files with the service, the on-premises design changes were more recent than the design on SCN, and "won" the replication conflict. This resulted in local mail replicas with a "mixed" design of design elements from two different templates.
End users don't have access to update the design of their SmartCloud mail files, but they're using their local mail files so still see the error messages resulting from this mixed design.
Our recommended measure to prevent this, is to turn off the DESIGN task on the users' mail servers (including clustered servers) and make sure you know about all server replicas.
Alternately, if customers don't want to turn off DESIGN, they can process the user mail files to prevent template updates by removing the "inherit from" template name, and scanning for design elements that inherit from a specific template. But turning off DESIGN is probably simpler and safer.
We're adding instructions to the on-boarding process to prohibit any changes to user mail files design after their replication to the staging server, and updating our training materials. We'll cover this in an upcoming partner call, but meanwhile, I thought I should mention it in case there any ongoing rollouts where it may be an issue.
I thought I should note this change, since there's nothing in the "liveAdmin" UI (as yet) to indicate how it works. That will have to wait until we can translate the explanatory text into all our supported languages. But you can use the new functionality now.
If you have a set of SmartCloud Notes users that you want to -- let's say -- assign a new mail file design using the web-based administration UI, you used to have to search for the user, select them from the search results, click the button to apply the action, specify the parameters (e.g. which mail template to use), wait for it to complete, then repeat the process with the next user.
Starting now, after you have selected a user from the search results, you can just do another search. Any user you selected, will remain displayed on the results screen, so you can accumulate a list of users through multiple searches. Then, apply the action to all of them at once, only specifying the parameters once. This is especially helpful for provisioning users, where you have to answer several questions. And of course, if you're assigning mail templates, which is slow, it's great to be able to start a batch and have your coffee break.
Please don't forget to check the box for the matching user from the final search -- only selected users will be processed.
Follow this page for a fuller description of this and other new feature announcements.
I recently started using the Domino Designer 9.0.1 client, and immediately noticed this slightly alarming warning in my XPages applications. The product help page "What's new in IBM Domino Designer 9.0.1 Social Edition?" lists several XML elements for which a "role" property is deprecated (search for "Obsoleting of the role property") but it was unclear whether it would still work anyway and how any difference in the build version versus the execution version was a factor. Role is used to tag elements for accessibility, so it's important to us in meeting our accessibility compliance targets.
So I called up the appropriate developer and quizzed him. Here's what I learned:
- The "role" property isn't completely deprecated. There are other elements not in that list, to which it still applies. You still have to specify the role for those.
- For those XPage elements, including viewPanel and pager for instance, that are on the list, the Domino server now automatically supplies a "role" value, so you need not specify a role for those elements.
- However, the property still works, letting you override the server's choice if you need to. You'll just get a warning in the Problems view.
- Since the code to determine the correct role is in the runtime, not in the "build" code, if the application is built by 9.0.1 but executed by an earlier version, the role attribute will not be included in the HTML unless you have specified it– just like now. In that situation, ignore the warning and specify the role anyway.
If you've been doing development work that involves OpenSocial and Domino, I'm interested in quizzing you a little. Please reply privately using my email, which is my first and last name, with underscore, @us.ibm.com.
At about 1:10 in this news clip: http://minnesota.cbslocal.com/2013/06/23/at-the-fix-it-clinic-learn-to-fix-your-electronics-appliances/
Fixin' stuff. As I do.
A little while ago I wrote about our process for prioritizing bugs for fixing. Mathieu Pape has a related idea recently posted on IdeaJam, that you might consider supporting if you're interested in this issue. It seems like a good notion to me.
XPages lets you write code to calculate the values for selection lists. The value your code returns may either be an array of strings, using the pipe symbol ("|") as a delimiter between display value and stored value, or it may be an array of javax.faces.model.SelectItem objects, which each contain a display and stored value as separate data items. It's your choice. The latter method, however, is more bulletproof since you don't have to worry about pipe symbols in your data.
Experienced Domino developers are used to specifying the choices for keyword lists -- comboboxes, radio buttons and the like -- using the pipe symbol ("|") as a delimiter between the value displayed and the value stored, hence: "Yes|1", "No|0".
For XPages, the Designer UI provides a separate place for entering the display value and stored value if you have a hard-coded list:
If you need to calculate the value of the selection list at runtime, using the pipe delimiter is still an option. Here, for instance, is the XSP code for two hardcoded choices and two calculated choices (or whatever number the code chooses to return). For simplicity, the calculation produces a constant value, but use your imagination.
<xp:selectItem itemLabel="Yes" itemValue="1"></xp:selectItem>
<xp:selectItem itemLabel="No" itemValue="0"></xp:selectItem>
This works. Or, you can return an array of objects:
Although it's somewhat longer, the nice thing about the latter example is that it doesn't fail if the "display value" contains a pipe symbol. This can occur in any case where you don't control the incoming data (for instance, if the choices are looked up from data in user-created documents). Or, as in my previous blog entry, the pipe symbol is used if you're using an application with localized values in it. When the .properties files are automatically generated, the to-be-translated strings in the foreign-language .properties files are prefixed with a string which includes a pipe symbol:
radioGroup1/xp\:selectItem/@itemLabel=[sq| No ]
So if your strings are somehow derived from .properties files, the application will fail to work in other than the original language until translation is complete. That is, of course, only one way that "|" can get into your data, so if you want to be safe, use the SelectItem object -- even if you have no intention of translating the application.
I may be stating the obvious, but I wasn't the only one on my team caught out by this, so I thought I'd best mention it.
I recently discovered the hard way that there's a problem with using < script > elements in XPages. Always use < xp:scriptBlock > instead. Why, you ask? Either seems to work fine!
BTW if you're thinking the translators will be smart enough to recognize source code when they see it and leave it alone, (1) not a good thing to count on, and (2) the other-language property files will mess up the functionality even before translation starts, because they tag the to-be-translated strings with, e.g. "[zh_TW" at the beginning, which won't still be executable code.
An issue recently came to my attention that (based on my informal poll) has been a thorn in the side for Domino administrators for quite a while. I've been trying to figure out how it is that it's never been fixed.
I'm referring to the fact that end users, when they create or rename a folder, are allowed to use various characters that have special meanings in design element names -- backslash, vertical bar, underscore, forward slash (which causes problems in mobile) and enclosing the name in parens (which makes the folder hidden in the UI). It's a nuisance for administrators, because recovering the "corrupted" folders is hard to do without writing code.
For a long time, we didn't have a bug report for this -- I finally wrote one, SPR # AGUD8USQ68. We didn't have a bug report because nobody ever called it in to Support. We have a system for prioritizing bugs. Recent regressions are at the top of the list. Problems that have been in the product for one release or more, are a distinctly lower priority, unless someone complains about them. By which I don't mean bitching about it in IdeaJam or even asking about it at IBM Connect. The most effective way to boost the priority of an issue, is to call IBM Support and open a PMR. An SPR with one customer report is approximately 100 times more likely to be addressed than one with no reports (especially because the SPR with no reports generally doesn't even exist). An issue with two reports is twice as likely to be addressed as an issue with only one. Reports from development count for approximately nothing. It's all about the customers and partners.
So when a business partner wrote to me recently to complain about this issue, I told him if he really wanted it fixed, he should call it in to support. I personally would love to see a lot of these annoying issues given priority, but people generally only call in to Support when they're blocked -- not when merely annoyed and inconvenienced. So we now have one (1) report about this issue. That's almost certainly not enough to get it fixed in a quarterly release, though it might get into the next major release.
So, if there are issues on your personal list, things about the Notes client, the mail template, or Domino that are an occasional problem, that you feel might be damaging end-user confidence in the products, impairing productivity, or just generally causing annoyance, and you want the annoyance to stop, then call IBM Support and open a PMR. And then call your Domino buddies and encourage them to do the same.
EDIT: You can also weigh in on this specific issue on IdeaJam. Thanks, Mathieu Pape, for posting this.