|
|
 |
- last updated a few seconds ago
Wednesday 14 Feb 2007
LDEV-1146: Increase login field length to 255. Also fixed up fullname field to better accomodate people will long first names and surnames
LDEV-1146: Increase login field length to 255.
LDEV-1146: Increase login field length to 255. Also increased the workspace folder name to 255 as found that it wasn't long enough for a user with two very long names, while testing the login field changes.
LDEV-1146: Increase login field length to 255 Had to change login field edit box to take longer length, so made most of the fields wider (there was plenty of room on the page).
Added option to hide the tool in deploy.xml, hideTool (boolean), now to hide a tool (for instance scribe), you can put a flag in the tool's build.properties hideTool Also, added a tool update script path, which defaults to "${build.deploy}/sql/updateTo${tool.version}.sql These will be generated when you do create-deploy-tool ant task
make reading user.changePassword more robust
added changePassword=false to default/minimal constructors
fix mistake where change_password had 'not-null=true'
Now the deploy-tool update Copies jars and wars and language files and updates the lams_tool table with the tool_version, the only thing left to do is allow for an update script to be written by a tool developer
updated lams translator list (welsh) for about lams dialog
add spinning 'loading.gif' when user imports
send extra 'no. of sessions' attribute to jsp, doesn't cause javascript warnings like before
handle v1 user with no orgrights without causing null exception, even though a v1 user should always have at least 1 orgright
updated lams translator list (welsh) for about lams dialog
fixed monitor - remove lesson problem ldev-1096
Tool-deployer upgrade, checks the db for tool_signature and tool_version, stops if current tool is up to date, installs entire tool if the signature is not present in the db TODO: update db and jar and war files if tool exists, but is not the newest version
Fixed problem which arose when deploy-tools is called. The generated deploy.xml was pointing to the wrong sql scripts, the problem originated in the build.xml of the tools, now fixed my bad
Skeleton for a new ToolDBUpdater class It will: * Check if the tool exists in the db * Check if the tool to be installed is newer than the current * Update the db with the current tool information
Tuesday 13 Feb 2007
Changing the tool's build.xml to copy the .jar and .war to the build/deploy folder, and updates the deploy.xml to point to these files
Changing the tool's build.xml so the create-deploy package copies the .war and .jar files from build/lib to /build.deploy The deploy.xml is also updated to point to the jar and war in build/deploy
Changing the build.xml of all the tools so the generated deploy.xml points to the sql scripts in the build/deploy/sql folder instead of the db/sql folder
Changes to build, so the tool deployer can put the tool_version in the deploy.xml when the tool is build. Now, the tool_version in tool_insert.sql must be replaced by @tool_version@, and the actual tool version goes in the buld.properties under tool.version
Changes to build, so the tool deployer can put the tool_version in the deploy.xml when the tool is build. Now, the tool_version in tool_insert.sql must be replaced by @tool_version@, and the actual tool version goes in the buld.properties under tool.version
Changes to build, so the tool deployer can put the tool_version in the deploy.xml when the tool is build. Now, the tool_version in tool_insert.sql must be replaced by @tool_version@, and the actual tool version goes in the buld.properties under tool.version
LDEV-1144: Two bugs: * The submit is trying to call a javascript function that does not exist. I can't find any code that suggests it ever existed! * The pages are trying to load up a css file that doesn't exist. At least in this case, the file did exist in the past but it was removed. Removed the onsubmit call and the css reference.
Changes made to all tools, so they should be made in the example tool Changes to build, so the tool deployer can put the tool_version in the deploy.xml when the tool is build. Now, the tool_version in tool_insert.sql must be replaced by @tool_version@, and the actual tool version goes in the buld.properties under tool.version
Changes made to all tools, so they should be made in the example tool Changes to build, so the tool deployer can put the tool_version in the deploy.xml when the tool is build. Now, the tool_version in tool_insert.sql must be replaced by @tool_version@, and the actual tool version goes in the buld.properties under tool.version
Changes to build, so the tool deployer can put the tool_version in the deploy.xml when the tool is build. Now, the tool_version in tool_insert.sql must be replaced by @tool_version@, and the actual tool version goes in the buld.properties under tool.version
Changes to build, so the tool deployer can put the tool_version in the deploy.xml when the tool is build. Now, the tool_version in tool_insert.sql must be replaced by @tool_version@, and the actual tool version goes in the buld.properties under tool.version
lams-tool_deploy generates a tool_version entry for a tool's deploy.xml
|