Patent Application
20080022201
The accompanying drawings, which are incorporated in and constitute part of this specification, illustrate embodiments of the invention and together with the description, serve to explain the principles of the invention. The embodiments illustrated herein are presently preferred, it being understood, however, that the invention is not limited to the precise arrangements and instrumentalities shown, wherein:
Embodiments of the present invention provide a method, system and computer program product for personalized fine granularity access control. In accordance with an embodiment of the present invention, access control attributes can be assigned to each field in an event. Thereafter, when sharing the event in the calendar view of different end users, the event can be rendered with some fields hidden from view according to the permissions of a viewing user, while other fields of the event can be rendered for view. Additionally, private events can be rendered only as a private event, while the content of the private events can remain hidden. In this way, private events cannot masquerade as free time and the privacy of selected content of a shared event can be maintained.
In more particular illustration,
The C&S system can include C&S core logic 140 coupled to a data store of events 160 and a corresponding C&S user interface 200. The C&S core logic 140 can include program code enabled to provide essential calendaring functionality including the creation and management of scheduled events such as those events marked private and those events that are permitted to be viewed by other end users. Additionally, the C&S core logic 140 can be coupled to access control logic 300 for determining when to expose a view to different end users of different scheduled events in the data store of events 160, and when to refrain from exposing a view to different end users of different scheduled events in the data store of events 160.
Importantly, the access control logic 300 can include program code enabled to provide personalized, fine granularity access control to the events in the data store of events 160. To that end, the program code of the access control logic 300 can be enabled to determine access for a particular end user on a field-by-field basis as specified by field level access attributes 150 for each event in the data store of events 160. Consequently, when rendering a view of an event in the C&S user interface 200, only those fields determined to be viewable can be rendered in the C&S user interface 200. Additionally, so as to prevent a private event from masquerading as free time, the program code of the access control logic 300 can indicate in a view of the event in the C&S user interface 200 that a private event occurs during a specified time range without revealing the content of the private event.
In further illustration of the view of events provided within the C&S user interface 200,
As the field attributes are applied to each event in the shared calendar view, only certain fields of each event can be rendered viewable while others can be suppressed from view. Moreover, private events can show as private in the shared calendar view, though the content of the private events can be suppressed from view as shown in
Notably, the access control for viewing events in a shared calendar view can be personalized according to the identity of a viewing end user, or a role of a viewing end user. In this regard, on a field-by-field basis, each field can be assigned a field level access attribute indicating whether the field is to be viewed by an authorized user, user type or role. When an end user attempts to view the field, the field will be revealed only if the identity of the end user or role of the end user matches the field level access attribute. Furthermore, the content of a field may vary according to the identity of the viewing end user or the role of the viewing end user. For instance, whereas one end user may view a field to read “re: Secret Project”, another end user may only view a field to read “re: Project”.
In yet further illustration,
In decision block 320, if the event has not been marked private, in block 330, a first field in the event can be retrieved for processing. In decision block 335, if the field has field attributes permitting the rendering of the field for viewing by the end user, in block 340 the content of the field can be included in the shared calendar view. In decision block 345, if additional fields remain to be processed, in block 330 a next field can be retrieved and the process can repeat through decision block 335. When no further fields remain to be processed for the event, in decision block 350 it can be determined if additional events remain to be processed. If so, in block 315 a next event can be retrieved and the process can continue through decision block 320. Otherwise, the shared calendar view can be rendered in block 355.
Embodiments of the invention can take the form of an entirely hardware embodiment, an entirely software embodiment or an embodiment containing both hardware and software elements. In a preferred embodiment, the invention is implemented in software, which includes but is not limited to firmware, resident software, microcode, and the like. Furthermore, the invention can take the form of a computer program product accessible from a computer-usable or computer-readable medium providing program code for use by or in connection with a computer or any instruction execution system.
For the purposes of this description, a computer-usable or computer readable medium can be any apparatus that can contain, store, communicate, propagate, or transport the program for use by or in connection with the instruction execution system, apparatus, or device. The medium can be an electronic, magnetic, optical, electromagnetic, infrared, or semiconductor system (or apparatus or device) or a propagation medium. Examples of a computer-readable medium include a semiconductor or solid state memory, magnetic tape, a removable computer diskette, a random access memory (RAM), a read-only memory (ROM), a rigid magnetic disk and an optical disk. Current examples of optical disks include compact disk-read only memory (CD-ROM), compact disk-read/write (CD-R/W) and DVD.
A data processing system suitable for storing and/or executing program code will include at least one processor coupled directly or indirectly to memory elements through a system bus. The memory elements can include local memory employed during actual execution of the program code, bulk storage, and cache memories which provide temporary storage of at least some program code in order to reduce the number of times code must be retrieved from bulk storage during execution. Input/output or I/O devices (including but not limited to keyboards, displays, pointing devices, etc.) can be coupled to the system either directly or through intervening I/O controllers. Network adapters may also be coupled to the system to enable the data processing system to become coupled to other data processing systems or remote printers or storage devices through intervening private or public networks. Modems, cable modem and Ethernet cards are just a few of the currently available types of network adapters.
