Weblog

{done} Release Notes OpenACS 5.4.3

Created by Alvaro Rodriguez, last modified by Benjamin Brink 29 Jun 2017, at 11:54 AM

Release Notes OpenACS 5.4.3

Note: This release notes were created based on the change log from tag openacs-5-4-2-final to openacs-5-4-3-final on the branch oacs-5-4. (view full change log) 

ACS-MAIL-LITE

Envelope sender disappeared during the refactoring of send between 5.3 and 5.4 and therefore was set using the from address. This led messages to be identified as junk by SPF, and bounces to be sent back to the user. This is a fix that puts the correct envelope sender back.
Since acs_mail_lite::send now accepts more than one TO address, the user_id part of the bounce address is set to 0 if there are more than one receiver.

ACS-TEMPLATING

Fix: Close tag for label was generated even when the opening one wasn't present.

Implementation of implicit association in forms to satisfy checkpoint 10.2 (label tag must wrap the form widget).

Remove the use of table to layout the date widget so it will now output valid HTML strict.

SEARCH

fix for bug #3154

don't hardcode localized string ("feeling lucky" was working only for english)

This work has been done for the .LRN Consortium

Admin Package RFC

Created by Ryan Gallimore, last modified by Benjamin Brink 29 Jun 2017, at 11:51 AM

Site administration tasks such as permissioning, bulk mandatory notifications, and navigation to admin areas are cumbersome or unavailable. They are thrown together into the acs-subsite package when they should be offered in their own package. 

(DAVEB The admin pages are in acs-subsite for a good reason, I think. They are tied to each subsite, so you can manage the administration of a single subsite. Now that it is possible (although maybe not easy quite yet) to define a subsite install with pre-defined packages underneath it, it would make sense to split out the admin to a separate package which could be customized).

This wiki will allow interested contributors to offer suggestions along the lines of an Admin Package. This package may only actually be a series of patches applied to existing packages; or it may be a new package altogether.  Since most of the functions themselves already exist, this package will most likely consist of consolidating or calling existing code, and cleaning up the UI.
 

A New Kind of Administrator

The Site Administrator for OpenACS may have originally also been the package developer and the system admin. But now clients are taking on the role of subsite manager. Tech neophytes are granting permissions, mounting new packages and approving members. This is especially the case in Non-Profit organizations using OpenACS on a limited budget. They just can't afford to pay their vendor to admin the site. So they ask us to teach them how to do it.  Thus the context and identity of the Administrator has changed, requiring us to raise the bar on usability for all major Admin functions.
 

1) Notifications

Notifications for OpenACS were developed under it's web community context to allow only users to sign up for their own notifications. In a corporate environment or a setting in which members are required to receive certain e-mails, bulk subscription is a requirement. For instance a web company which uses bug tracker to manage change requests will create a subsite for each client with a bug-tracker under each one. Then the administrator will have to sign the user up for notifications manually, every time. The preferred functionality would allow one initial sign up of a group to notifications for a logger application. Then all subsequent members joining the group would be automatically signed up for notifications.

Victor Guerra has patched notifications with user and group subscription functionality which works quite well. But it is still tied to the package. A single interface for all notifications spanning *across* subsites is necessary.

• Subscribe/Unsubscribe individual users and groups to notification to package notifications.

2) Permissions Management 

Administrators routinely work with users, groups and application permissions, but these are spread out across the site. Site wide permissioning tasks such as granting 10 applications in a subsite different permissions is extremely tiresome requiring multiple navigation clicks to navigate from permission screen to permission screen. The genius of the OpenACS permissioning system is obscured by a poor UI. A single interface for permissions would make large admin tasks like this much easier.

• Grant/Revoke any privilege on any application on any subsite
• Easily navigate around subsites via a tree

3) Group Management

Admins must be able to view which groups a member belongs to, and be able to remove that member. This feature already exists. In addition, admins must be able to easily:

• Add a member to any group from that members detail page.
• Manage a related group's membership and properties.

4) Member Management

/acs-admin/users/ is a good search tool for maintaining members, and it is available through a developer support link, but it is not implemented on the Members list where it might be used most effectively by administrators and non-administrators with member list access. Also site administrators cannot rely on developer support as they may not have  permissions.  On the members page admins should be able to search for a user via an AJAX lookup field by name and e-mail address. We can borrow this from FreeMED. Once a member is selected, the member screen available to admins listing notifications, permissions, group memberships and the existing links in /members/one.tcl will appear.

• Add subsite membership buttons to Membership detail page (Invite, Remove, Ban)
• Join member to any group

Developed under the subsite model,  many UI and human interactive features satisfied local subsite requirements, or the requirements of very small sites. As OpenACS expands, the UI must accommodate the desire of site wide administrators to notify, permit and manage users anywhere on the site.

5) Site Map and Subsite Applications Redundancies

The Site Map and the Subsite Application tab are redundant pages.  Both split the site tree, node mounting, adding deleting, and renaming. This should be under a single interface, probably using the Site Map UI (or a better Tree UI).
 

Objects, Interactions and User Interface 

Members, Groups, Notifications and Permissions interact in the following ways to give us our ideal UI: 

(Image no longer exists. Original url: http://openacs.viscousmedia.com:8080/files/view/Objects.gif )

Next Steps After Installation, Debian Specific

Created by Kenneth Wyrick, last modified by Benjamin Brink 29 Jun 2017, at 11:38 AM

Next-Steps

After following:

Debian Installation Instructions

Documentation
nano /usr/share/doc/openacs|dotlrn/README.daemontools on openacs package.

apt-get install daemontools daemontools-run

# OpenACS
nano /etc/default/openacs

... or ...

# .LRN
nano /etc/default/dotlrn       

# OpenACS
/etc/init.d/openacs stop

   ... or ...
 

# .LRN
/etc/init.d/dotlrn stop

# OpenACS
ln -s /usr/share/openacs/etc/daemontools /etc/service/openacs

... or ...
 

# .LRN
 
    

ln -s /usr/share/dotlrn/etc/daemontools /etc/service/dotlrn

Now you can control the dotlrn service using the svc command:
* To start the service: svc -u /etc/service//openacs or dotlrn
* To stop the service: svc -d /etc/service//openacs or dotlrn
* To restart the service: svc -t /etc/service/openacs or dotlrn
 

apt-get remove --purge openacs or dotlrn

apt-get install openacs or dotlrn

Edit the config.tcl file:
nano /etc/openacs|dotlrn/config.tcl

Change the following parameters to fit your needs:
set hostname Your hostname
set address to Your public IP

and found that I had to figure out how to:

su - $OPENACS_SERVICE_NAME
pg_dump -f /var/lib/aolserver/$OPENACS_SERVICE_NAME/database-backup/before_upgrade_to_4.6.dmp openacs-dev
ls -al /var/lib/aolserver/$OPENACS_SERVICE_NAME/database-backup/before_upgrade_to_4.6.dmp
exit

The $OPENACS_SERVICE_NAME
which I thought would be "dotlrn"
turned out to be "www-data"

Next I found there was no /var/lib/aolserver but there are /var/lib/dotlrn and /var/lib/postgresql

The default paths show the locations that were decided upon (in early 2004) so below we will try to document were things are in a standard dotlrn installation, now.

1. From .LRN CVS

a) Create a local repository

b) Download to your local repository

nano /var/log/aolserver4/dotlrn/error.log

1. Installation
2. configuration

Securing your system

Created by Benjamin Brink, last modified by Benjamin Brink 29 Jun 2017, at 11:33 AM

It's imperative that you secure your installation. As Jon Griffin repeatedly warns us, "No distribution is secure out of the box."

A Reference Platform implements some basic precautions, but security is a process, not a condition. If you are responsible for a computer hooked to the internet, you are responsible for learning some rudiments of security, such as monitoring the state of a computer, maintaining patch levels, and keeping backups.

We recommend these resources:

• Securing and Optimizing Linux - version 3  (Free PDF Guide)

• Jon Griffin's notes on RedHat security (from archive.org 22 June 2006)

• Linux Administrators Security Guide 

• Strategies for Keeping a Secure Server

• Bruce Schneier's Crypto-Gram, especially The security patch treadmill and Monitoring First.

Content Security Policies (CSP)

OpenACS supports CSP starting with version 5.9.1.

Install a *nix-based operating system (OS)

Created by OpenACS community, last modified by Benjamin Brink 29 Jun 2017, at 11:30 AM

Follow the installation directions that come with the distribution.

There are generally 2 strategies at this point:

1. Install an OS with minimum programs, or
2. Install a suite of programs, for example choose between a developer set or desktop set.

Precaution

For a quick installation, we recommend the two scripts at naviserver-openacs. These will install OpenACS from scratch on a variety of systems (including Debian/RHEL Linux or Mac OS X). Detailed dependencies are listed during the build process.

For other ways to install or try OpenACS See openacs-system-install.

Steps for manually installing OpenACS

We recommend installing only the OS to minimize the chances of conflicts resulting from installing 2 or more copies of one of the OpenACS system components (openacs-system).

Many additional programs, such as a build environment (gcc), Mail Transport Agent (MTA), and source control system, are also needed for a fully operational installation. Most of these are included with a basic OS installation.

Install some helper software

You might want to install some of these after a minimum OS install, since OpenACS administration usually assumes you have these (or alternates) installed:

• wget
• emacs or vi/vim
• bash shell (usually automatically installed with Linux distributions)
• gcc or equivalent (along with standard distribution source libraries) - if you plan to install software from source.
• ImageMagick or GraphicsMagick - used by some packages for server side image processing
• aspell - used to offer spell checking in forms

*nix install guides

some helpful documentation for installing *nix flavors

• Official Debian Guide
• FreeBSD Documentation
• Redhat Manuals
• SuSE documentation

Next, secure your system: system-security

Documentation Introduction

Created by Robert Taylor, last modified by Benjamin Brink 29 Jun 2017, at 10:36 AM

The OpenACS Documentation is organized as follows:

- Core Documentation ( 1:1 direct copy of what exists )

- Package Documentation ( 1:1 direct copy of what exists )

- Subsystems Documentation ( systems multiple-perspectives view )

• for everyone (see en:docs-end-user and marketing at en:Marketing_Docs_Index )
• for administrators (see en:docs-admin )
• for developers (see en:docs-eng and tutorials at: en:INTRODUCTION )

Documentation Process test-doc (Approach 3)

Created by Rocael Hernández Rizzardini, last modified by Benjamin Brink 29 Jun 2017, at 10:33 AM

This is Approach 3 of the en:Documentation_Project as defined in en:Documentation_Project_Discussion.

Official documentation will go into openacs.org/test-doc (to be renamed) generate from there the html pages for documentation, therefore the first result is to update the documentation to reflect current tools, version, correct commands, all done within that wiki instance

The process for generating technical documentation is:

1. Update that documentation wiki instance named doc-head
2. Once the documentation is ready, freeze it doing a export/import process from /doc/head to a new instance (i.e. /doc/5-5-0)
   • No write permissions for the public will be granted to this frozen instances
   • Use an alternate template to distinguish between /doc/head and the frozen ones
3. Generate the static html documentation based on the wiki-frozen instance (/doc/5-5-0) 
   • Using as template_file the view-oacs-docs
     • Available here: http://alice.wu-wien.ac.at:8000/xowiki/listing?m=list
     • Have to be placed on www dir of xowiki package
     • Also the parameter top_includelet have to be in blank for the wiki-frozen instance
     • Example on how the doc will be available in the wiki-frozen instance: http://alice.wu-wien.ac.at:8000/test-doc/for-everyone
   • Options for the static content:
     • One large HTML file and/or (book-print prototype)
     • One HTML file per chapter and/or (tutorial-advance prototype)
     • Same granularity as in /doc/head
     • Get the documentation using wget
       • This wget command should get you the html files for the documentation:
       • wget -kpr -R book <root of the documentation's xowiki instance>
     • The html files will not have an extension, this may cause them to not be interpreted as html and returned as plain text on some web servers, to be safe, rename the files to have an extension. Run the following script on the directory containing the static html files.
       • #!/bin/bash
         
         FILENAMES=`ls . | grep -v "html" | grep -v ".sh"`
         
         for f in $FILENAMES; do
             if [ ! -d "$f" ] ; then
                 FILE_NAME=`echo $f | awk -F ? '{print $1}'`
                 FILE_PARAMS=`echo $f | awk -F ? '{print $2}'`
                 if [ -z "$FILE_PARAMS" ]; then
                     NEW_FILE_NAME="${f}.html"
                 else
                     NEW_FILE_NAME="${FILE_NAME}.html?${FILE_PARAMS}"
                 fi
         
                 if [ ! -f "$NEW_FILE_NAME" ]; then
                     mv $f $NEW_FILE_NAME
                 fi
             fi
         done
         
          
4. Commit into the CVS, branch and tag appropriately following the branch/tag conventions for the specific release.
5. Add a link of this new /doc/5-5-0 into online documentation index openacs.org/doc and a map it in the site map to /doc/current

Then the process can start again for the next documentation release.

To-Do

• Still missing a way to transform to independent html files with index / navigation within it (right now only produces a one big html). (done by Gustaf)
• New /doc has to have a link to the various online (xowiki) frozen versions of the documentation.
• Document the document formatting/markup rules in the wiki instance and the static documentation. 
  • Probably there is already formats for technical documentation available, produced, or at least some guidelines.
• Openacs.org/doc will be replaced with the wiki-documentation (/test-doc instance renamed to /doc/head)
  • Provide an index to link to all frozen documentation releases.
  • Current /doc can be renamed to /doc-5-1
• Assign someone to udpate the documentation, follow the process and release documentation.

Following moved to this context, which is using approach discussed by Malte below:

Malte here:

Instead of doing it manually (though this does have some merit), I would go and modify the script Gustaf provided to import the whole documentation in one go into a new XoWIKI instance with the structure (page_order) that has been added in XoWIKI 0.42 taken from the chapters of the documentation so that we do have an exact mirror of the documentation as it stands now.

Once this is achieved we could go on and assign categories to the documentation, allowing for an alternative view on the documents (so you could say "instead of showing the whole documentation only show the documents for a specific category"). Probably this needs some more detailed discussion with Gustaf finding out how this could be achieved in XoWIKI and what would make most sense. Ideally we could provide a different structure based on the target group (e.g. category) but this is probably shooting too far. Getting categorization and page ordering in a decent shape should provide us a lot of possibilities.

• One can use the follwing script to generate the page objects and load it via xowiki/admin/import into an xowiki instance; this can be improved in many places, but gives you the idea
• # by Gustaf Neumann 
• # load doc pages into xowiki   -gustaf neumann
  # for tdom
  lappend auto_path /usr/local/aolserver4/lib
  package require tdom
  package require XOTcl; namespace import ::xotcl::*
  package require xotcl::serializer
  
  set docpath /usr/local/openacs-4/packages/acs-core-docs/www/
  
  namespace eval ::xowiki {
    Class create Page -parameter { {lang en} {description ""} {text ""}
      {nls_language en_US} {mime_type text/html} name title text }
  
    set c 0
    foreach docpage [glob $docpath/*.html] {
      set f [open $docpage r]; set data [read $f]; close $f
      dom parse -html $data doc
      $doc documentElement root
  
      set content ""
      foreach n [$root selectNodes //body/*] { append content [$n asHTML] \n }
   
      set p [Page create page[incr c] -name en:[file tail $docpage] \
             -title [[$root selectNodes //title] asText] \
             -text [list $content text/html]]
      puts [::Serializer deepSerialize $p]
    }
  }

Suggestion by Rob Taylor: 

1a. Move all but maybe the first and last 2 items from https://openacs.org/doc/dev-guide.html to https://openacs.org/doc/kernel/dev-guide.html and refer to them in context of the kernel package (or whatever package their code is in). That helps developers see appropriate context. (This will likely require a board discussion and TIP

The OpenACS Directory

Created by Gustaf Neumann, last modified by Benjamin Brink 29 Jun 2017, at 04:35 AM

See: The OpenACS Directory

OCT Meetings

Created by Dave Bauer, last modified by Benjamin Brink 29 Jun 2017, at 04:34 AM

See Also: openacs-release-status openacs-todo

Next Meeting: 2010-04-28 18:00 CET/CEST Convert to your local time

Agenda

• Next OCT Election (May 2010)
• OpenACS 5.6 Release Beta Weekend 2010-04-25

Previous Meetings

• 2010-04-21 Minutes
• 2010-03-17 Minutes
• 2010-03-10 Minutes
• 2010-02-24 Minutes
• 2009-09-30 Minutes
• 2009-09-23 Minutes
• 2009-09-16 Minutes
• 2009-09-09 Minutes
•  
• 2009-03-11 Minutes
• 2009-03-04 Minutes
• 2009-02-25 Minutes
• 2009-02-18 Minutes
• 2009-02-11 Minutes
•  
• 2009-01-28 Minutes
• 2009-01-21 Minutes
• 2009-01-14 Minutes

2008

•  
• 2008-06-25 irc log
• 2008-06-18 irc log
• 2008-06-11 irc log
• 2008-06-04 irc log
• 2008-05-28 irc log
• 2008-05-14 irc log
• 2008-05-07 irc log
• 2008-04-30 irc log
• 2008-04-23 irc log
• 2008-04-16 Minutes ( irc log)
• 2008-04-02 Minutes ( irc log)
• 2008-03-12 Minutes ( irc log)
• 2008-03-05 Minutes ( irc log)
• 2008-02-27 Minutes ( irc log)

2007-02-07 Summary

Created by Rocael Hernández Rizzardini, last modified by Benjamin Brink 29 Jun 2017, at 04:32 AM

Agenda:

1. Zen vs. acs-core
1.1. Site master template will have to be changed to be compatible with package changes for zen
In particular content pages need to be wrapped in <div class="main"> (or id= or something)
Solution: we do <div class="main"><slave></div>

1.2. CSS

Don propose we duplicate CSS at the moment rather than try to integrate .lrn zen theme css and core - our schedule's tight as tight can be and this would be faster
Someone has to do it (next meeting we'll determine who does what and probably the overall work plan)
Change to be done in oacs-5-3.
Sharing a single css file comes for 5.4

2. oacs 5.3.1 release
2.1. The zen work above
2.2. Greek translations
2.3. Nothing more other than critical bug fixes that hopefully are well-tested
2.4 Target date: 1st. march alpha.
2.5. NOTICE: people who upgrade existing sites will have to change their layout! To what extent is something we have to figure out in the next OCT meeting.
2.6. To work on the layout enhancements:
check this page:
signup for something
contact: honchos@dotlrn.org  which is the people leading the effort.
.lrn mtg every tuesday at 1700 GMT
2.7. We don't have time to deal with UI clean-up for 5.3.1

Present: lee, don, dave, roc.