[#SAK-11026] Failure to list a database hierarchy file in sakai.properties will deny user access to library search

Sakai

Failure to list a database hierarchy file in sakai.properties will deny user access to library search

Created: 06-Aug-2007 15:23 Updated: 23-Oct-2008 07:48

Component/s:

Citations (SVN Module)

Affects Version/s:

post-2.4

Fix Version/s:

None

Time Tracking:

Not Specified

2.4.x Status:	None
2.5.x Status:	None
2.6.x Status:	None

Description

« Hide

If a file-name returned by configService.getDatabaseHierarchyXml() was not supplied among the values injected at start-up time, the file will not have been loaded into the cache, and it will never be loaded. So users requiring that particular set of categories will never be allowed to use library search.

In contrast, when a request is received requiring a config.xml file that was not loaded at startup, the new file is cached and the new file-name is added to the list of files being watched for changes.

All

Comments

Work Log

Change History

Subversion Commits

Sort Order:

Ascending order - Click to sort in descending order

[ Permlink | « Hide ]

Steve Smail - 07-Aug-2007 11:47

At present, only the category and configuration files injected at startup time will be honored - no additional category or config files can be added "on-the-fly".

Initially, the config file behavior was as Jim described it in the problem description - you could add new files "on-the-fly", and they would be added to both the cache and the "watch list".

I wound up (kind of arbitrarily) eliminating that feature for now - I ran into problems implementing it for the category files, and I didn't want the category and configuration files to behave differently. If this is something we see as critical, we can look at it again.

For now, it probably makes sense to leave this assigned to me.

[ Permlink | « Hide ]

Steve Smail - 07-Aug-2007 12:08

Some additional observations on potential "points of confusion":

-- If you try to upload a category or config file using the "display name" box to provide a name that matches one of the names injected at startup time, the uploaded file is not honored

-- If you upload a file to the config folder that has the same name as an existing configuration file, the new file is not loaded into cache. However, there are now two files in the config folder that have the same "display name", and it's no longer obvious which one is the "real" configuration file.

This is not a problem with "upload new version", which causes the cache to update as expected.

[ Permlink | « Hide ]

Steve Smail - 20-Sep-2007 13:23

Hi Jim - if it's ok with you, I'd like to resolve this as "will not fix". I think we verbally agreed that the exisiting behavior is ok - if I'm remembering this incorrectly, please let me know.

Steve

[ Permlink | « Hide ]

Steve Smail - 15-Oct-2007 08:00

We intend to revisit this issue in the 2.6 timeframe.

It may be best to remove the list of configuration files from sakai.properties altogether.

The goal in doing this is to allow "on-the-fly" configuration changes, governed only by the site-specific Java code provided to handle OSID configuration.

[ Permlink | « Hide ]

Peter A. Knoop - 29-Sep-2008 08:35

Is this work still targeted for 2.6? If not, please update the Fix Version appropriately. Thanks.