Weblog

OpenACS Reference Platform

Created by OpenACS community, last modified by Robert Taylor 29 Dec 2017, at 03:23 PM

These are the defaults we create and use during the standard installation process, in helper scripts and other places. None of these locations are set in stone - they're simply the values that we've chosen.

Default directories for a standard install

Some instructions provide cut and paste conveniences

In order for some copy and paste instructions to work in your bash shell, you must set the environment variable $OPENACS_SERVICE_NAME. Add this line to your .bashrc or .profile_bash file to set the environment variable for a specific user:

export OPENACS_SERVICE_NAME=service0

To set it globally so that it works for any new users or special service users you may create, add the above line to the file /etc/profile

$OPENACS_SERVICE_NAME is set to the value of service0 on a default install. Change service0 to a word that better represents your project. The other values we recommend you leave unchanged unless you have a reason to change them.

A service name ($OPENACS_SERVICE_NAME) should be a single word, letters and numbers only. If the name of your site is one word, that would be a good choice. For example "$OPENACS_SERVICE_NAME" might be the service name for the OPENACS_SERVICE_NAME.net website.

Some discussion that lead to these default values: https://openacs.org/forums/message-view?message_id=82934

Commit Messages

Created by Gustaf Neumann, last modified by Gustaf Neumann 29 Dec 2017, at 10:11 AM

• Write your commit message in the imperative present tense: Use "Fix bug" and not "Fixed bug" or "Fixes bug." This convention matches up with commit messages generated by commands like git merge and git revert. It should start with a verb like "Fix", "Add" or "Change".
• Commit message should contain a title and an optional body.
• The title of the commit message should be a capitalized, short (50 chars or less) summary, not ending with a period.
• The title can be followed by the body, an explanatory text, if necessary. Title and body are separated by an empty line. The blank line separating the summary from the body is critical (unless you omit the body entirely); tools like rebase can get confused if you run the two together.
• The body should be wrapped to 72 characters.  The body can contain multiple paragraphs, containing plain text or bullet points. The bullet points should be typed as a hyphen or asterisk with blank lines in between. Use a hanging indent for longer bullet points
• Make white-space changes separately

See also:

• http://tbaggery.com/2008/04/19/a-note-about-git-commit-messages.html
• https://robots.thoughtbot.com/5-useful-tips-for-a-better-commit-message
• https://github.com/torvalds/linux/pull/17#issuecomment-5659933

Cookie Consent Widget

Created by Gustaf Neumann, last modified by Gustaf Neumann 22 Dec 2017, at 06:55 PM

Package Specification Summary for Package: cookie-consent

Bug Tracker Summary for Package: cookie-consent

There is no package with the name "cookie-consent" known to bug-tracker.

Code Metrics Summary for Package: cookie-consent

Integration of the Cookie Consent Library into OpenACS

The Cookie Consent Library is and Cookie Consent to be free and open sourced library for for alerting users about the use of cookies on a website.  It is designed to help you comply with the hideous EU Cookie Law and not make you want to kill yourself in the process. So we made it fast, free, and relatively painless.

Details:
    https://cookieconsent.insites.com/
    https://github.com/insites/cookieconsent/

This package integrates the Consent Plugin with OpenACS, in particular with OpenACS subsites.

So far, this package supports on the "inform" type of cookie consent policies. When the "opt-out" or "opt-in" variants of the policies should really include all types of cookies (even session-cookies) the user would not be able to login to the site. However, most countries stick for now to the "inform" policy, and the detailed regulation are still in flux.

Features:

•  Configure the appearance of the cookie consent widget via the following parameter (on acs-subsite):
   

  CookieConsentEnabled	0|1
  CookieConsentPosition	bottom|top|pushdown|left|right
  CookieConsentLayout	block|classic|edgeless|wire
  CookieConsentPalette	oacs|honeybee|mono|neon|corporate
  CookieConsentLearnMoreLink	https://cookiesandyou.com/
  CookieConsentDefaultPalette

   

• Usage from CDN (out-of-the box) or from a local copy (download your local copy via   "Site-Wide Admin" link in /acs-admin/)
• Support for host-node-mapped subsites
• Internationalized with OpenACS message keys

Installation

1.  Install this package via the OpenACS Package Manager
2.  Add this package to the templating system
    
   •  OpenACS 5.10.0d2 or newer:
      The cookie consent widgets uses the "subsite::page_plugin" callback, so no changes on templates are necessary. Make sure, you update also acs-bootstrap-installer to 5.10.0d2 or newer to obtain the updated blank-master
      
   • OpenACS 5.9.1:
     Add to the top of your blank-master.tcl the following snippet:
      ================================================================
     if {[info commands ::cookieconsent::initialize_widget] ne ""} {
           ::cookieconsent::initialize_widget
     }
     ================================================================
3. Configure the CookieConsent* parameters of the subsite (e.g. of the main subsite) in the section "Cookie Consent"

Prerequirements:

The implementation uses nx from the next-scripting framework.

    https://next-scripting.org/xowiki/

which is automatically installed for XOTcl2 via naviserver-openacs

It works best with OpenACS 5.10.0d2 or newer, but works as well with 5.9.1 (see INSTALLATION section above) or earlier versions supporting Content Security Policy (CSP), and probably with  earlier versions as well, when CSP code is commented out.

Richtext CKEditor 5

Created by Gustaf Neumann, last modified by Gustaf Neumann 21 Dec 2017, at 09:28 AM

Package Specification Summary for Package: richtext-ckeditor5

Bug Tracker Summary for Package: richtext-ckeditor5

There is no package with the name "richtext-ckeditor5" known to bug-tracker.

Code Metrics Summary for Package: richtext-ckeditor5

In general, the CKEditor 5 can be used via CDN (zero configuration, default) or via local files. One can use /acs-admin/ (section Site-wide Service Administration to download a version to your local site to reduce latency or to use local modifications.

So far, CKeditor 5 is not released yet, this integration is just minimal, no xowiki formfield support is included yet.

.LRN Accessibility

Created by Olga C. Santos, last modified by Gustaf Neumann 25 Oct 2017, at 08:34 AM

From quite a long time .LRN community has been moving towards producing both accessible interfaces and services for all. Accessibility analysis on previous releases have been done such as Tristan Kalnins-Cole's under Dorian Peter's (dotLRN Director of Visual Design) supervision. This lead to the unofficial conclusion that version 2.1.3 was level A compliant.

Selva theme was designed to make easier the customization of the look and feel of .LRN, improving navigation and usability. Moreover, unlike other .LRN templates, it is strongly based on CSS. Therefore, it can be easily seen that Selva theme was a step forward in considering accessibility issues.

During the development of version 2.2.0 we have been working to assure that .LRN 2.2.0 with Selva theme is compliant at least with W3C WAI WCAG 1.0 level A. In this sense, three new categories of bugs have been created in the Bug Tracker and are being used to report problems regarding accessibility. So far, within the framework of several R&D projects in which aDeNu Research Group at UNED is involved, we have compiled several accessibility analysis performed by some of our partners (Soluziona) and research groups within UNED to translate the problems found at different development stages to .LRN/OpenACS bugs and discuss them in the .LRN IRC Tuesday meetings. "This work has led to the release of .LRN 2.2.0 as W3C WAI WCAG 1.0 level A compliant, except for LORS package (there is a strong incompatibility between the SCORM RTE and WCAG 1.0, which is to be solved with WCAG 2.0). Moreover, there may be some minor level A bugs reported found here, which are to be solved."

The planning for next version is to achieve WC3 WAI WCAG level AA and take into account, when available, specific guidelines from national regulations such as the American Section 508, UK SENDA, Australian DDA, German BITV or Italian Stanca. Our plans are to consider WCAG 2.0 as soon as they are officially released as well as other WAI documents (e.g. ATAG and UAAG).

In order to improve the accessibility quality of dotLRN, we ask you to use W3C Web Content Accessibility bug types to report any problems encountered so they are taking into account when developing.

Update for dotLRN 2.3

See Zen project and external evaluations on Educational packages [1], [2].

Information on the progress is also done in periodic dotLRN/OpenACS conferences:

• Fall 2006
  • Session Towards full Accessibility in LMS
• Spring 2007
  • Improving Accessibility, Usability, and Code Quality of .LRN and OpenACS: The .LRN Zen Project [3]
  • Workshop on Experiences on Accessible eLearning Platforms

Last modified: 2017-10-25 08:34:57.234495+02

Ajax Helper

Created by Hamilton Chua, last modified by Gustaf Neumann 25 Oct 2017, at 08:32 AM

Package Specification Summary for Package: ajaxhelper

Bug Tracker Summary for Package: ajaxhelper

There is no package with the name "ajaxhelper" known to bug-tracker.

Code Metrics Summary for Package: ajaxhelper

Ajax Helper is a package created to assist OpenACS developers incorporate Ajax into their web applications. It is composed of helper procs that wrap javascript functions that perform DHTML effects and Ajax. 

Ajax Helper incorporates javascript from Thomas Fuch's Scriptaculous Javascript Library (http://script.aculo.us) and Yahoo's User Interface Library or YUI ( http://developer.yahoo.com/yui/ ).

Tutorials on how to use Ajax Helper :

Introduction to Ajax Helper with Simple Effects
http://web.archive.org/web/20111221205659/http://www.solutiongrove.com/blogger//one-entry?entry%5fid=266153

Using Ajax
http://web.archive.org/web/20060715115103/http://www.solutiongrove.com:80/blogger/one-entry?entry%5fid=268010

Simple Drag and Drop
http://web.archive.org/web/20060715115051/http://www.solutiongrove.com:80/blogger/one-entry?entry%5fid=266155

Current Release on CVS HEAD : AjaxHelper 0.87d
includes Scriptaculous v.1.7.3 Beta, YUI v. 2.3.0 and ExtJs 1.1.1
 

Assessment Admin UI

Created by Caroline Meeks, last modified by Gustaf Neumann 20 Oct 2017, at 05:25 AM

TODO LIST

• Update this page with the latest work
• Carl will fill in here... 

 The current UI is very confusing and cluttered.

Our vision of a final UI is that a assessment creator would pick a type of assessment he wants and the site will set all defaults appropriately for it. However, the first attempt to do this was a failure so we are working on an incremental approach that we think will provide value with minimal effort. Our intent is that later we move to an even friendlier UI.

 Incremental Improvement Vision:  The current user experience is: every time you create anything you are confronted by many many choices, most of which you can ignore. Similarly all the admin pages have many repeated buttons and its not clear when you want to do what.  Thus our goal is:

• Creation pages are very very simple and useful defaults are set for everything.
• Objects then have one button to an Edit page that has all the complex things you can do with the object.

Related Pages:

• Assessment Admin Index
• One Assessment Admin Assessment one-a 

Screenshots

These are screenshots of the work in progress.

Simplified quick assessment creation form. 

One Assessment Admin Page 

One Section Admin Page

 Add a question page.

First the original question form:

Now the new form. The question creation process used to require filling out 3 forms. We compressed it to one form by removing unused settings, and making intelligent default decisions. Some more work needs to be done. Assessment has a huge amount of complex features and it is not clear how they are used together to create a certain type of assessment. It is clear that all of the settings rarely need to be used together.

Official Test Servers

Created by Gustaf Neumann, last modified by Gustaf Neumann 19 Oct 2017, at 11:53 AM

Currently none

{done} OpenACS 5.3.x releases

Created by Rocael Hernández Rizzardini, last modified by Gustaf Neumann 19 Oct 2017, at 11:53 AM

OpenACS 5.3.x Releases

Update: OpenACS 5.3.0a1 is available for download https://openacs.org/projects/openacs/download/one-revision?revision_id=494139 or by checking out openacs-5-3-0a1 tag from CVS. Work continues on the oacs-5-3 branch in CVS
 

The main goal is to have acs-core to pass all the automated tests (PG 8.1.x & Oracle 9i).

We plan to branch for oacs-5-3 in September 2006. 

Many bug stomp where we actually create, fix, update tests for acs-core has been done. 

Bug-stomp: 21-22 sept. 06. Focus on have all the actual test pass for acs-core (no more new test), plus start classifying the bugs in the bug-tracker. Based on the results of this bug-stomp we'll decide when to branch and what should be included (bug-fixes) in next release.

Check the Official Test Servers

Feature Requests for OpenACS.org's XoWiki

Created by Robert Taylor, last modified by Gustaf Neumann 19 Oct 2017, at 08:51 AM

Overview: 

Most of the Feature Request are complete.  THANK YOU GUSTAF AND DAVE! I am adding a few minor enhancement requests and removing the completed requests.

Participants:

Some comments to the requests from Gustaf Neumann

Comments and responses by Robert Taylor

Feature Requests:

1.  DELETING DOCUMENTS - Normal users should not have DELETE privileges, but administrators should.  As an administrator I don't see a DELETE option in the menu in the top right hand of ever page.  Perhaps DELETE should go between NEW PAGE and INDEX items.

    Added delete button on the view page. mostly useful, when the default listing of all entries is replaced by a tailored index page
 

2.  HIERARCHICAL CATEGORIES - Left hand menu needs to properly show SUBCATEGORY WITHING SUBCATEGORY in a hierarchical relationship.  Clearly one thing we will have to take into consideration is hierarchy layout and spacing issues - do we preload all categories or do we just preload a preset number of levels down and then dynamically load the rest below a certain threshold. Dave mentioned the ui component has to be coded up to handle that type of layout.

     Hierarchical display of categories added to the version in CVS head. Spacing is a matter of style-sheets.  

3.  XINHA SUPERPOWERS - Xinha is one amazing editor, and just looking at their page it's still  not complete.  I think we need to look at stripping some of the features out of our Xinha install on XoWiki.  This should probably be based around generating a STYLE GUIDE for the wiki and basing our Xinha hacking on that.  Dave mentioned it is possible to take away Xinha features fairly easily so we will look at that further.

 xinha is configured via plugins (see http://xinha.gogo.co.nz/xinha-nightly/examples/full_example.html). xowiki uses per default the following settings, which are some standard options plus the OacsFs plugin contributed by Günter Ernst and me.  The standard behavior  can be modified by the settings of the WikiForm (in xowiki-procs) for the whole installation. a per-instance setting will follow in the future

4.  ADMINISTRATION SECTION - If you select the "WOIKI" item in the location area on the page (OpenACS Home : xowiki : New XoWiki Page) the link seems to alternate between the INDEX page and ADMIN page although it seems a bit random.  I think this is probably a bug, but it should be changed to the following:

a) Selecting XOWIKI in the location of the page should always go to INDEX just like the item "INDEX" the the wiki page UI does. 

b) For administrator we should add and item ADMIN to the wiki page admin menu so that the administrator can go to the admin section and work on templates, delete documents, etc.

 can't reproduce a. xowiki in the breadcrums and index both point to oacs.orig/xowiki, so they should return same values. in earlier versions  there was a caching bug, which is - i think - gone since end of Feb.

concerning permissions etc. currently, xowiki uses a simple permission system: it checks write permissions on the folder, these write permissions are used distinguishing admins and readers. future versions should have a much richer permission system, where one can use alternatively different permissions policies based on per page permissions (this is however, much more expensive and will use much less caching). for now, do you folks want in addition to the new delete entry also an admin button in case a user has write permissions on the folder?

5.  PRINT PAGE - All users should have an item in the wiki page menu (for every wiki page) labeled "PRINT".  This action would refresh the page content and / or bring up a popup with the content of the page in a printer friendly format without various user interface components.

6.  IMPORT / EXPORT DIR TREE - The ability to import/export a directory tree of XoWiki documents has use for OpenACS.org and arguably as a general XoWiki feature. In the case of OpenACS, exporting would allow these /xowiki pages to be saved into static pages so that they can be read independently of OpenACS.org and independent of having a local running OpenACS system.

Problem example: OpenACS moves documentation to XoWiki. Documentation is no-longer available as static pages on local machine(s). Users/admins become dependent on reading docs from OpenACS.org or spidering the pages using wget etc.. of course most likely during the busiest times that OpenACS is being accessed ;) etc. etc.

7.  PAGE REVISION (AS TIMESTAMP) - Exporting files (request 6) would bring about questions of comparing file exports (at least on a page by page basis). Having a page revision displayed on each page as a timestamp would help to reduce any ambiguity as to which statically exported page is more current --regardless of export technique (wget, XoWiki export feature etc.)

Bugs

• xowiki is not visible in IE. Must be a CSS issue. Has someone an idea why this happens?
  • no kidding?!  doesn't work in i.e. will post bug
  • fixed. this was an unclosed script tag in the  xowiki installation on opeancs.org
• For some reason I always get a popup window: "Error reading Language-File (/resources/acs-templating/xinha-nightly/plugins/OacsFs/lang/de.js) - Syntax Error: missing ; before statement"
  • must be something on oacs.org, does not show-up on other installations. i have developed the plugin, and do not have the mentioned file.
• The CodeMatrix includes need a little clean up: left alignment and top valignment for each heading
  • must be done by someone at oacs.org or vinod. most probable some CSS fiddling.

Display

• Page language: Wouldn't it be more readable and less technical if we would not display the language shortcut "en:" or other before each link to a wiki page?
  • one can use arbitrary labels in a reference between square brackets.
• The category tree on the left breaks long names which is ok but the next line should have more left margins in order to start right after the dot. Another solution would be to cut off the tail of long names
  • CSS fiddling. should be done by someone with CSS knowledge and  taste. uses currently the original settings  https://openacs.org/resources/acs-templating/mktree.css from http://www.mattkruse.com/javascript/mktree/documentation.html|mktree

Further Features

• support for NOTIFICATIONS for xowiki so that you are notified if a page was added or changed
• List view for category nodes that displays all children on the right when you click on it.
  • don't understand. you mean, without expanding the current page?
• Display the name of the person who edited the page in "Latest Page edits (ADP portlets/categories-recent {name {Recent Entries by Categories} max_entries 30)

Packages

• Any chance that we ca define a sub type PackagePage that automatically provides the info, bug-tracker and code metric includes?
• Some kind of traffic lights that shows green, yellow or red depending on the maturity of the package, db support
• More categorization for packages: Core, Non-Core is too technical, no?
• When clicking on a category it would be great if the list of all packages within the category are displayed as APM does on upgrade/installation time.
  • sounds like a different or additional category tree