This is a modification of the existing Notes/Domino Resource Reservations database template.

The application's core code was left intact and - for the most part - unchanged. It should still respect the classic Notes interface and Calendar & Scheduling functionality.

The modifications allow for the core functionality to be used via the XPages interface.

This application does have it's specifics and slightly differs in behavior from the original though. I had to “reverse-engineer” some code and guesstimate the parts, where the program flow dives under the hood into undocumented functions. In other places I introduced some additions that - in my opinion - could improve the usability of the application. See respective sections for more information.

!!!!PLEASE NOTE!!!! that this is a work-in-progress. The application is still in development, although largely complete. I encourage you to thoroughly test everything before considering it's use.

Site Profiles

Site Profiles should be working exactly as they work in the original application. No changes here.


The core principle of resources stays the same. You pick 1 of 3 categories of resource (room/resource/online meeting place) and submit a request for it's registration within the system. The request - as with original application - is submitted into Administration Requests database where it gets processed according to the rules specific to your server settings. After that the resource eventually shows up in the Local free time info (busytime.nsf) database and in lookups/resource picks.

However, the original database signed the Administration Request document with the ID of the current user. Unfortunately, this option is not yet available in core functionality on the Web. Therefore, the XPages interface performs this task a little differently:

  1. All necessary checks are performed.
  2. The resource is submitted into the database, but does not show up in views/lookups yet.
  3. A special agent runs on the server (every 15 minutes - starts automatically) designated as the Administration server of the database. The agent submits the Administration Request for resource registration/modification/deletion on behalf of the user, but signs the Request with the server's ID.
  4. Request is processed by Administration Requests service.

One improvement on the original Resource mechanism - it is now possible to create multiple time ranges for resource availability (e.g. resource is available on Moday from 9:00 to 13:00 AND from 14:00 to 20:00). The time ranges get properly recorded in the Local free time info database.

Reservation Requests

The core functions of Reservation Requests stay the same. The parts related to classic and Calendar & Scheduling interaction remain totally unchanged. There are some specifics for XPages interface though - the functionlity was slightly changed to introduce new/modify old features:


> + -> addition to/improvement upon the base application functionality
> - -> regression of base functionality
> ~ -> modification of base functionality (i.e. works differently)

+ Users can now place reservations on up to 5 rooms/resources simultaneously. Works for both - free resource lookup & free time lookup of fixed resources. The respective requests are spawned as separate documents for each resource using the same time ranges the user originally specified. The number of resources available for reservation at one time is fixed programmatically at 5 for performance reasons.
+ It is possible to combine reservations on different types of resources (i.e. room/resource) within one request. The proper type will be recorded into the respective document field automatically based on the resource you selected. For all those times you wished you could reserve the room AND a projector at the same time…
+ It is now possible to span the reservation over multiple days. So - in theory - it is possible to place a reservation for e.g. 36 hours straight.
~ It is impossible now to create a Custom repeating schedule for a reservation. Instead the user can add/remove instances of a repeating reservation directly in the list. All instances of a repeating reservation are shown in a special section of the page. “Repeats” button is now needed only to add a set of specifically repeating reservations (e.g. every Monday) to the list of all instances.
~ All repeating reservations are now created as “Custom scheduled” requests (i.e. with a “C” flag).
+ It is now possible to combine several patterns to repeating reservations in a single request. E.g. make the reservation repeat daily the first month and happen once every 2 weeks the second month.
- It is impossible to provide a Custom repeating schedule for a Quick Reservation. This is a regression of baseline functionality.
~ It is impossible to add new instances of a reservation when editing an existing reservation, but it is possible to remove instances and move instances around (either as a single instance, or as a set of all instances). The rest of editing functionality stays the same to the base application.
~ The decline/delete notices that get sent to users upon resource owner action are now generated with MIME body rather than RichText. The plan is to - ideally - transfer all notifications into MIME-mails. But this will require reworking core functionality, and hence - a lot of effort.

Reservation processing mechanisms (i.e. approve/reject/transfer/delete) stay the same - no changes here.

System Requirements

This application relies on various controls from XPages Extension Library.
Therefore, in order to use it, you would need a Domino server of at least version 8.5.3 with Upgrade Pack 1 installed, or a 9.0+.

Or you can try to use older versions of XPages Extension Library supplied by the community:
However, please do keep in mind that the application HAS NOT been tested with older versions, so there's no guarantee it will work.

Known Issues

  • Most of the testing was done using Web. There was little to no Notes testing (didn't have the time for it, unfortunately). So the application MAY behave erratically when used in Notes client (especially on a local copy).
  • Current user lookups are only performed on NAB of the Administration Server. There is currently no specific support for Extended Directories and/or Directory Assistance.
  • If the resource was already processed into the Administration Requests database, but the RnRMgr/SchedMgr processes have not yet caught on to this yet and created a respective freetime document inside busytime.nsf, the resource may show up in lookups as available 24/7. This needs some additional testing and fixing.
  • There is no mobile-enabled interface. You may use the standard Web interface on mobile devices, but your experience will vary.
  • There is not much in terms of styling and decoration.

Misc Notes

  • There are some mechanisms in place to allow for “embedded” interface. The idea is to eventually make the application “widget-ready”, so that it can later be embedded on a widget level into any external system (e.g. portal). No one really needs an isolated standalone resource reservations application…
  • There is a simplistic REST service in place. Some of the manipulations with reservations are done via this service provided directly from the XPage the user is working with. The idea is to broaden this service to enable this application to provide a fully-functional REST interface to manipulate reservation requests. Sure, you can use DAS…but for developers not familiar with Lotus and/or Resource reservation this is not too wieldy. Sure, free resource lookup is nice. But being able to place reservation requests on them without digging too deep is better, in my opinion.
  • The application is localization-enabled. There are (or, rather, SHOULD BE) no hard-coded strings, except for: 1) console logs, 2) some notifications text (I'm working on it). Currently the only language is English.

Full version: see attached README.txt.