Weblog

Bugtracker Cleanup Project

Created by Dave Bauer, last modified by Benjamin Brink 29 Jun 2017, at 03:10 AM

Currently (Wednesday, May 9, 2007) there are 228 open bugs in OpenACS and .LRN https://openacs.org/bugtracker/openacs/. (Note I had to multiple 25 time the number of full pages  of bugs and tack on the last 3 on the last page the numbers next to the filters don't reflect the actual current state.) The list of bugs in the bugtracker does not reflect the reality of the release status of the toolkit. That is, the core developers and the automated tests show that OpenACS core and .LRN are pretty stable and work as expected.

There are some quite old bugs, along with suggestions, todos and more reported in the bugtracker. Its quite possible a bug was fixed without a developer noticing a reported bug in the bugtracker that should have been closed. Some bugs have become irrelevant due to changes in OpenACS since the bug was first reported.

Around OpenACS 5.1 there were even goals for number of open priority 1 bugs (0) before a release was declared final. I think it is a good goal to have the bugtracker reflect the real status of a release.

To do this we need volunteers to go through existing bugs, and check if they are still relevant, check for patches, and close the bug, fix it, or as for help in resolving a bug.

Here is a proposal for a procedure to meet this goal

 

1. Test is a bug can be duplicated on the newest release of OpenACS 5.3.1 or .LRN 2.3.0. If not it should be marked not reproducible and closed. If more information is necessary that should be marked and the bug reassigned to the original submitter.
2. If the bug is reproducible, and the tester does not feel they have the knowledge to fix the bug themselves, a request for assistance should be made. At this point a more experienced volunteer will need to help out. It would be wonderful, although it is not required, if volunteers ask for help, then take this advice to learn more about the toolkit, and try to fix it themselves. This is definitely NOT required to contribute to this effort. Anyone who can try to reproduce a bug on a test server can contribute.
3. If a decision needs to be made, whether a bug should be fixed, for core packages, the OCT should decide. For .LRN packages that are released with .LRN, the .LRN Leadership Team should decide. For other packages, it would be great if someone who uses or develops with the package will step up as maintainer and make that decision.

This is meant as a quick simple proposal to get a discussion going, and hopefully a volunteer effort organized to make the bugtracker reflect the real status of the code. Any suggestions are welcome.

--

suggestions:

1. bug bash. Maybe coincide with a Tcl/Tk conference (for those not following the Tk part).

 

 

 

Documentation Project

Created by Robert Taylor and Ryan Gallimore, last modified by Benjamin Brink 24 Jun 2017, at 04:21 AM

The managing of OpenACS documentation has evolved a few different ways. Instead of working on a unified consensus in managing the OpenACS documentation, there are primarily three efforts:

Approach 0: Continue updating docbook documentation via CVS (for those with access to CVS).

Approach 3: en:New_Documentation_Process is migrating the original OpenACS docbook docs to an xowiki instance.

Approach 4: en:Documentation_Project_Plan is building new documentation based on how the brain likes to chunk using subsystems. 

See en:Documentation_Project_Discussion for current status.

YUI Project

Created by Ryan Gallimore, last modified by Gustaf Neumann 11 Jun 2017, at 10:33 AM

Notes on an OpenACS wrapper for YUI

• There is some consensus to use YUI over other JS libraries, e.g. jQuery.
• Use most complete version - YUI library
• YUI Loader for dynamic loading.  Each wrapper function in OpenACS loads only the YUI components that it needs.  This is preferable to sending the full 250 KB gzipped library for every page.
• Download YUI sources from package directory or Yahoo's CDN.
• Always combine sources into one HTTP download if using CDN
• UI tests (Selenium IDE/RC) should be written for all wrappers to facilitate testing during development and when YUI is upgraded.
• Wrappers will be defined by specific tasks like perform an AJAX request and return the response into a div.  The wrapper will take care of loading all required sources into the page.

YUI Theme [Suggestion]

 

 

• Provide a package openacs-theme-yui, which is based on the YUI CSS Foundation

nlunt: A word of warning regarding YUI Loader:
While it sounds like a good idea to load only the modules that are needed, my experience has shown that there may be more benefit to loading a single gzipped file for the javascript and css portions of YUI for a total of 250K that is cached after the first load. This sounds like a lot to load for every page, however, loading just the base modules of YUI may exceed that amount because the individual JavaScript and css files for each module are not gzipped. Loading all of YUI uncompressed is about 1M, so there is considerable benefit in loading the files compressed.

Package Object Types

Created by Dave Bauer, last modified by Gustaf Neumann 02 Jun 2017, at 02:29 PM

This describes the discussion for TIP#120 https://openacs.org/forums/message-view?message_id=1482643

 

APM Packages are all of the same acs_object_type of 'apm_package'.

I propose creating an acs_object_type for each package type as a subtype of apm_package.

This would allow for a hierarchy of package types. The most common example we might think of is dotlrn. The dotlrn package could be a subtype of the subsite package. This would allow an easier way to determine if a package takes on the role of a subsite type package and it could greatly simplify all the code that has to be special-cased to determine if dotlrn is installed.

This would also allow simplification of the case when a new package is created to customize the user interface of another package. For example, many people would like to customize the forums package, to change the style of user interface. If we had a custom-forums package type that was sub-typed from forums, we could have a simple and consistent mechanism to defer pages to the parent package type for handling. This would allow much easier reuse of pages and would make it very simple for local customizations to be handled safely without worrying about accidentally adding custom code back into OpenACS.

 The immediate goal of this work is to make the dotlrn package a subtype of the acs-subsite package. I have done preliminary work to turn dotlrn communities (groups) into application groups of the dotlrn package also. This should make it easier to do an upgrade to an existing dotlrn install that will support subsite based dotlrn.

Previous work includes the https://openacs.org/api-doc/proc-view?proc=subsite%3a%3apackage%5fkeys subsite::package_keys procedure. This basically is a hard coded list of packages that fulfill the subsite role. Defining children of a subsite object_type would allow greatly flexibility and use the existing features of the toolkit.

 Steps to implement

1) Make a new object_type for existing package_types when a new package type is created. Default is subtype of apm_package.

2) Add parameter to package create code to specify package super-type

3) Add tag to info file super-type which is optional and will default to apm_package. This tag will have the same behavior as requires element so Tcl libraries are loaded of the super-type.

4) Add attribute to apm_package_types for inherit_ui_p to specify if URL resolution will go up the package type hierarchy.

5) Update apm_paramaters to support setting parameters for the super-type package parameters up the package type hierarchy. Allow sub-typed packages to override the default value of an inherited parameter.

6) Fix package loading to load Tcl libraries in package dependency order.

 

---

Comments by Don Baccus:

Let's think about UI issues for a moment ... I have an idea to toss out

Currently, abstract URL resolution works like this:

 1. If a file or template at [acs_root_dir]/www/${url_path} exists, return it

2. If a file or template at [acs_root_dir]/packages/[ad_conn package_key]/${url_path} exists, return it

3. 404

 We can extend this if we allow package sub-typing ...

replace 2 with ...

2. set package_key [ad_conn package_key]

2a. while no file exists at [acs_root_dir]/packages/$package_key/$url_path do

2b.   if parent type is apm_package, break, else set package key to parent type's package key

2c. od

2d. if exists - return file or template

In other words, allow for the inheritance of parent package UI.

 Often, of course, this isn't always desirable, so an apm package type would want to have a "don't inherit UI" attribute.  You'd do this, for instance, if you were going to brand new UI for an existing package.  Say ... a portlet.

Inheriting the UI though allows for some things.  For instance, dotlrn could be mounted at /, no need to mount an acs-subsite instance at all as is done now because its UI would already be available (assuming dotlrn was derived from acs-subsite).

How would this impact performance?  Not at all, if the request processor's performance mode is enabled, and when it's not, who cares?

---

Comments by Gustaf Neumann:

Defining package types as acs-object-types and allowing sub-typing/sub-classing for packages using these is a good idea. As presented at the OpenACS conference in Guatemala, xotcl-core and xowiki support this already since about a year. So is it possible to define the s5-package by reusing xowiki in a few lines of code. Other examples were presented by Victor Barrios (mashup) or Stefan.

Subtyping acs-object-types is just the first step, the (desired) implication are something which might need more discussions. Some changes are desirable for the package manager or the request processor.

Note, that in the xo* packages, it is not only the case that packages are object-types, but that package instances are objects (actually xotcl objects), which provide the package instance specific context for a request. Package instance objects are initialized at the begin and deleted at the end of a request.

Below i will use the term "reused package" for the superclass (the more general package) and the term "specialized package" for the subclass (the more specific package, inheriting from the superclass package).

Here are a few items from my experience:

 

1. package loading: if a package reuses an other package via sub-classing, it should load the library files (.../tcl/*tcl) of the sub-classed package as well and initialize it. Daveb, why not use requires tag in the info file? If there is more than one package reusing the same package the library is loaded more than once.
2. package parameters: a specialized package should inherit the package parameter definitions of the reused package(s)
3. per-request files (../www/*) and context management: it is desired/necessary to share some of the per-request files and to allow a per-package-instance initialization (constructor)

For the three issues, the xo* packages use the following strategy:

• package loading:  
  Since the loading order of apm-packages at boot-time is mostly alphabetical, there must be a way to say to load required packages. In particular, the specialized package should load the library files of the reused package (e.g. s5 should load the library files of xowiki) Daveb Would it make more sense to just fix packages to load in required order?
   
  • Working solution in xo*:
    Add a line like the following to e.g. the first loaded file of the s5 package (the specialized package) to indicate the dependency of xowiki (the reused package)
    
    ::xo::db::require package xowiki
    
    This call checks, if the library files of the specified package are already loaded and load it via apm_source, if not (see as well http://alice.wu-wien.ac.at:8000/s5-xowiki-talk-guatemala/presentation?slideshow=1&pagenr=5)
     
  • Desired solution:
    While the working approach works fine with moderate effort, it can be improved via the apm-package manager. It should be possible to specify in the package manager "this package is a subclass of some other package" an add the specialized package automatically to the dependency list. The apm* procs should sort the dependencies in a topological order and load the packages this way. There would be no need to figure out what the first loaded file is, since the order is on the package level. Daveb yes APM needs to have support to specify when you create a package. Roc The topological load order is desirable, but at this moment standard OpenACS mostly just loads the libraries that's why we don't see problems often, while in xo* packages you actually use it for construction, right? (that was the problem I detected). Will be good to use topological for subtypes and package dependencies.
     
• package parameters:
  Without any support, it would be required to replicate the definition of the package parameter of the reused packaged in the specialized package. Extending/altering the package definitions in reused package would have to be repeated as well in all specialized packages (maybe over some specialization levels)
   
  • Working solution in xo*:
    xotcl-core has an object oriented package parameter code that searches parameters on the superclass hierarchy of the specialized package. This leads to several space and speed improvements (see e.g. http://alice.wu-wien.ac.at:8000/s5-xowiki-talk-guatemala/presentation?slideshow=1&pagenr=6 and following pages). The interface of the oo-code mirrors the interface of the classical interface (e.g. parameter get). The implementation does actually more than just searching along a path, it avoids redundancy as far as possible)
     
  • Desired solution:
    The current implementation allows just to share package parameters, if the specialized package actually wants to overwrite some parameters, it cannot do it, since it uses the old shared/parameters?package... scripts, that are not OO aware. So, currently, to alter parameters they have to be copied or the shared/parameter code has to be adapted.  It should be possible alter the default value of a parameter in a specialized package for further inheritance or other instances of a reused package. It is as well desired to add permissions, maybe, not every package admin should be allowed to alter all package parameters (e.g. changing policies in xowiki in a dotlrn-like installation, where package-admins are teachers/lecturers/...) Daveb I think there is a good proposal around to make this work by scoping parameters at the package level or package instance level that would help here. Permissions is an interesting idea but probably more complex than we need to get started. Roc Will be good implement parameter sharing / reuse (and less redundancy) for non-xo* apps.
     
• per-request files and per-instance context management:
  The specialized package will share some files from the reused package (e.g. www/admin), but it also wants to perform some package specific initialization
  • Working solution in xo*:
    the specialized packages use index.vuh files for www and www/admin, all per-request files use ::pkgkey::Package initialize to resolve the context of a package instance and to call the package initialization (see e.g. http://alice.wu-wien.ac.at:8000/s5-xotcl-core-tutorial/presentation?slideshow=1&pagenr=66 and http://alice.wu-wien.ac.at:8000/s5-xotcl-core-tutorial/presentation?slideshow=1&pagenr=79 from the xotcl-core tutorial).

    An example for the redirector is https://raw.githubusercontent.com/openacs/s5/master/www/admin/index.vuh

    The approach with index.vuh works quite well, since physical existing files override the virtual (index.vuh) redirect. So, all per-request files in www/* in the specialized package, which should be different from the reused package, can be put to the www/* directory of the specialized package (e.g. s5). Not sure, how this approach works over multiple specialization levels.
     

  • Desired solution:
    As Don points out, the search for files could be done automatically by the request processor in case the package is a specialization of another package. This approach has no problems with multiple specialization levels. One has to sort out as well the interactions of .vuh files and package hierarchy search. Roc The request-processor solution is the best and cleaner.
    
    It is as well desirable to call from the request-processor the package specific initialization DAVEB. What is a package specific initialization? This seems to refer to xowiki based packages that have initialization procedures that setup the context for the request. I believe this is not a core feature yet.

Migration from CVS to GIT

Created by Victor Guerra, last modified by Gustaf Neumann 02 Jun 2017, at 01:17 PM

IMPORTANT!!! by no means the statements written in this page are official. At the moment one should consider this information just and only for experimental purposes. There are no official decisions made by the OCT so far regarding migration to GIT or any other source control tool.  At the moment CVS is the official tool used and you can navigate the project history and code at our official code and history inspector Fisheye OpenACS

Tools to consider for the migration:

• GIT includes a tool for the migration of CVS repositories called git-cvsimport.
• The cvs2svn project provides support for converting a CVS repository into GIT. The tool is called cvs2git

Structure of the GIT Repository:

• One git repository hosting the entire code base of OpenACS (including contrib and all packages) vs. multiple repositories (provide separate git repositories managed via modules/subdirs/...)
• A single large repository seems not realistic, since many sites have site-speciifc modules, since there projects like ProjectOpen and others having developed a long range of maintained packages. But are 300+ separate repositories manageable with reasonable effort (maybe mr is currently the best option, we have good experiences with this). However, this decision has large impact on tagging and release management (see below)

Where could the repositories live (?):

• Official repositories on openacs.org machine? Having remote-mirrored repositories on github so developers can clone and share patches using github. -- jiml: many tools which could get similar function to github (forking, pull requests),,,  can we put up a gitorious on a test site with maybe 50gb of repo space so all the committers can have their own?
• Using github.com as our official source code site? or Bitbucket?

Points to consider before | when migrating to GIT: 

• Release-management: Installing-software-from-repository code is based on release "channels" and cvs-tags in order to define which channels are available to users ( https://openacs.org/repository/) and to provide the recent packages for that channel.  In principal, similar tags could be used as well in git, but there are several differences. CVS tags are per file, git tags are per repository (if the git repository contains e.g. all packages, there is no way to tag a single package as e.g. OpenACS 5.9 compatible with e.g. tag "openacs-5-9-compat"). It is possible to work with separate git repositories and work with git modules and/or subtrees, but this means that we have 300 repos to manage (all could have separate branches and tags), and single commits covering multiple repos are not supported). This means, that one needs higher level tools and recommended workflows to manage developments on the core source repositories (branches, tags) and site-specific packages and local modification as well as site-specific release and feature branches
• Depending on the decision of the structure it is necessary to provide git-guidelines similar to cvs-guidelines and the code retrieving and generating .apm packages has to be rewritten.
• Application for voting on oct-elections depends on commits history ( most likely this will transparent since we use fisheye.openacs.org  for fetching information about commit history, and fisheye provides one and one only interface for querying data, so the fact that the code is being controlled by cvs or git is irrelevant ... but since fisheye is configured for CVS, it has to be newly built for the resulting infrastructure, or it has to be dropped/replaced by github/bitbucket or others.

Current state:

• Since 2014 Victor Guerra (Vienna University of Economics) has created an unofficial mirror on github https://github.com/openacs which contains a daily mirror of the CVS repositories at openacs.org. It consists of an openacs-core modules plus a separate repository for every non-core package.

Forums Project

Created by Tracy Adams and Carl Blesius, last modified by Gustaf Neumann 20 Apr 2017, at 06:00 PM

Project Initiation: Tracy Adams and Carl Blesius

Project Team: Don Baccus, Dave Bauer, Ishir Bhan, Andrew P, Rob, Alfred Essa

Key: (1) high priority, (2) medium priority, (3) will do it if we have extra time

Development to be done on HEAD

History

Our forums have been good for years, let's make them great! 

Goals

• Expand Forums to make it serve as mailing list software
• Give forums a facelift with a focus on improved usability
• Make OpenACS forums best in class

Package Design Notes

A given forum package instance supports multiple individual forums, each of which supports forum threads and then messages.  This is a bit a-typical of OpenACS packages, which each forum would be it’s own package instance.   That bears to question – should the forum package instance be one and only one forum?  This might save work as we could use package-level services like parameters for each forum. After some discussion, we decided to keep the design as is, that is, each forum instance will have multiple forums as there will be extensive forum-level functionality.

Bugs to fix

• #2880 - "Anonymous Post" options sends out notification from poster's email pending DONE(Tracy)
• #2733 - "Subscribe Others" in Forums Broken: pending…. (just block it out as it is very broken) DONE (Tracy)
• #2704 - message posting broken if javascript disabled: ??...
• After you post, you see a view that is in the middle of a thread. You should be scrolled down to where you post is, but you shouldn’t loose the context. DONE (TRACY)

The project will do these bugs first and then check them into the 5.2 branch.

Attachments

• See Site Wide Image Upload Widget
• Adding attachments is currently complicated and requires mounting an extra attachments and file storage packages and intricate setup.
• (1) Modify forum attachments the use content repository directly (and require no setup)
• (1) Modify the user interface to allow for attachment to be uploaded with the initial post.
• (1) For gif, jpg, png attachments, have them appear inline. (resized if too big)
• (2) Have the use of attachments a property of a given forum.
• (2) Have the use of attachments in the forums of a package instance a property of the forum package.
• (3) Have maximum file size a parameter of the forum packages.

Portraits

• (2) Users should be able to upload their portrait (if it doesn’t exist) when they submit a post.
• (1) The user’s portrait should be displayed (with an appropriate size) along with their post.
• (3) Use of portraits should be configurable at the forum level and the forum package instance level.
• (1) (investigate) – Is image magic quick enough to resize on the fly or do we have to store an appropriate size. Or is it easy to store a series of sizes right away? DAVEB-Two options, 1) generate thumbnail, medium, full size when uploaded like photo-album. 2) lazily generate the sizes and store them in the file system when they are requested. For portraits I think it make sense to just generate the right sizes, its also easier to code.
• DAVEB: Solution Grove has code for displaying portraits along with posts. It uses the acs-subsite portrait for this. This is committed to HEAD in CONTRIB (1-23-07)

Categories

• (1) When a thread is started, the user can choose relevant categories.
• (1) User should (parameterized) be able to add a new category.
• (2) Use of categories should be parameterized at the forum and forum package instance level.
• (1) View of threads in a given category in a given forum.
• (2) View of thread in a given category in a given forum package instance.
• (2) Forum administrator should be able to pick which categories are used.

Ratings

• A registered user must be able to rate a comment.
• A forum must can be configured to allow (or not) ratings.

Consolidated Views

• View of all threads in a forum package instance.
• View of all threads in forums where you are a member.

Forum Membership

• Add ability to have forums where there is a group of official members.
• (2) Users can join in the following ways
  • Open (will inherit from the site map, and therefore the permissions from the package instance)
  • Approval Process (break inheritance)
  • Closed (must be added by admin) (break inheritance)
• (2) When users join (either by themselves or admin), an option to sign up for notifications is given.
• (1) Pages to view forum members
• (1) Admins can mass add people or mass invite people (optionally adding them to email notification)
• (1) Admins can remove people
• (1) Members (configurable) can see member list

Administrators

• Each forum should support a list of administrators
• If you have admin on the forum instance, you should be able to administrate each forum (later feature)
• Administrators of a forum should be able to add other administrators.
• Support Anonymous postings. DAVEB please clarify, I am guessing this means, allow users with permission to post, to post without revealing their identity, as opposed to letting the public post without logging in.

 

Notifications

• Users can sign up to notifications for a forum or thread.
• Users should have a consolidated page where they can control all their notifications.
• Users should be able to turn off all notifications (ideally for a given period of time)

BroadCasts

• (1) Administrators should be able to send out a broadcast to all forum members (messages that are sent by email regardless of notification setting)

Incoming Email (Dependent on OCT)

• (1) Integrate with OCT’s incoming email design.

Should support the following

• (1) Respond to post (using the message_id of the post)
• (1) Starting new threads (using the forum_id of the forum)
• (2) Subscribing to forum (maltes: Isn't this notifications?)
• (2) Unsubscribing from a forum (maltes: Isn't this notifications?)

Parameters

• Each forum should have a way to configure parameters. Additional ones:
  • From address – do you show the person’s email or specific a default email (maltes: we have this already)
  • Configuring subject and footer and header
  • New subscriber welcome message

Moderation

• In a moderated forum, posts must be approved before they are sent
• There is a selected list of moderators
• There can be a selected list of people whose posts are not moderated
• Moderators can ask for notifications on new submitted posts

Blocking

• Users can be marked to be blocked.  These users will not get links to reply or post.

Posting and Viewing

• (1) View count (maltes: we have this already using the views package). 
• (1) Items you haven’t viewed (what's new package)
• (1) Option to force preview (instead of post/preview)
• (1) (Configurable) Time to edit the post (this is a feature in Moodle that is nice... e.g. you have 5 min to edit this post)
• (2) maltes: Time to be allowed to edit a post. E.g. you should only be allowed to edit and delete your posting for the first 24 hours.

Spam/Bounce filters

• Regular expressions can isolate potential spam and bounced post for moderation (we might be able to package the code in the mailing list manager for this). maltes: there is a suggestion to base this on procmail.

Search before post (MS)

• When the user types in the title of a forum posting that searches for the keywords and gives back a list of relevant forum postings at the bottom of the forums entry form (and yes, this screams ajax).

• Give the user the option to view the postings (collapsible view) and map them for linking with the forum posting (see next point).

 

Related items

• (1) This post is related to this document.  This post is related to this user.

Import/Export (Dependent on Don/Jeff)

• (1) Importing/Export Mailing list archive (don? jeff?)
• (3) UseNet?
• (1) Fixing issues with Merging users
• (2) Check for duplicate posts and remove

Templates

• (1) Provide a way to change the template for a post, thread and the forum (either easily understood and/or way to upload)

Search (Dave)

• (1) 1 forum
• (1) All forums you are in
• (1) All forums you have access too

Calendar View (Don)

• Provide calendar view (Don)

Ecommerce G2

Created by OpenACS community and package contributors, last modified by Benjamin Brink 15 Feb 2017, at 10:55 AM

Introduction

ecommerce-g2 is an initiative to adapt OpenACS's heritage of en:ecommerce and related packages to meet newer ecommerce related objectives and values.

ecommerce-g2 packages use a blend of current OpenACS coding, ecommerce and security standards, and are built to offer low overall cost for code maintenance. 

Project is currently led by Benjamin Brink in the open and cooperative spirit of the OpenACS community.

Stable versions are available at: https://github.com/openacs-ecg2

All are welcome to participate.

page information

• Last modified: 2017-02-15 10:55:33.681706+01

OpenACS 5.9 HTML validity fixes

Created by Gustaf Neumann, last modified by Gustaf Neumann 15 Jul 2016, at 06:48 AM

Fixed validity of the following (mostly admin) pages:

 /acs-admin/
 /acs-admin/apm/
 /acs-admin/apm/packages-install
 /acs-admin/apm/packages-install-2
 /acs-admin/apm/packages-install-3
 /acs-admin/apm/packages-install-4
 /acs-admin/apm/version-callback-add-edit
 /acs-admin/apm/version-callbacks
 /acs-admin/apm/version-dependencies
 /acs-admin/apm/version-dependency-add
 /acs-admin/apm/version-edit
 /acs-admin/apm/version-files
 /acs-admin/apm/version-i18n-index
 /acs-admin/apm/version-parameters
 /acs-admin/apm/version-view
 /acs-admin/auth/
 /acs-admin/auth/authority
 /acs-admin/cache/
 /acs-admin/developer
 /acs-admin/install/
 /acs-admin/install/install
 /acs-admin/monitor
 /acs-admin/users/
 /acs-admin/users/bouncing-users
 /acs-admin/users/complex-search
 /acs-admin/users/one
 /acs-admin/users/registration-history
 /acs-admin/users/user-add
 /acs-content-repository/admin/
 /acs-content-repository/admin/mime-types/
 /acs-content-repository/admin/mime-types/extensions
 /acs-lang/
 /acs-lang/admin/
 /acs-lang/admin/batch-editor
 /acs-lang/admin/edit-localized-message
 /acs-lang/admin/export-messages
 /acs-lang/admin/import-messages
 /acs-lang/admin/localized-message-new
 /acs-lang/admin/lookup
 /acs-lang/admin/message-conflicts
 /acs-lang/admin/message-list
 /acs-lang/admin/package-list
 /acs-lang/admin/set-system-timezone
 /acs-service-contract/
 /admin/applications/
 /admin/applications/application-add
 /admin/attributes/edit-one
 /admin/configure
 /admin/group-types/
 /admin/group-types/delete-rel-types-exist
 /admin/group-types/rel-type-add
 /admin/groups/  (elements-by-group-type, elements-by-group-type)
 /admin/groups/delete
 /admin/groups/one
 /admin/groups/rel-type-remove
 /admin/host-node-map/
 /admin/manage-email-privacy
 /admin/object-types/
 /admin/object-types/one
 /admin/parties/one
 /admin/permissions
 /admin/rel-segments/
 /admin/rel-segments/new
 /admin/rel-segments/new-2
 /admin/rel-segments/one
 /admin/rel-types/
 /admin/rel-types/new
 /admin/rel-types/one
 /admin/rel-types/roles/
 /admin/rel-types/roles/edit
 /admin/rel-types/roles/new
 /admin/rel-types/roles/one
 /admin/relations/add
 /admin/relations/one
 /admin/relations/remove
 /admin/site-map  (folder add, rename)
 /admin/subsite-add
 /api-doc/
 /api-doc/content-page-view
 /api-doc/deprecated.html
 /api-doc/display-sql
 /api-doc/package-view
 /api-doc/plsql-subprogram-one
 /api-doc/proc-browse
 /api-doc/proc-search
 /api-doc/proc-view
 /api-doc/procs-file-view
 /api-doc/tcl-proc-view
 /calendar/admin
 /calendar/admin/calendar-edit
 /calendar/admin/permissions
 /calendar/cal-item-new
 /calendar/calendar-item-types
 /calendar/view
 /categories
 /categories/cadmin/
 /categories/cadmin/category-links-view
 /categories/cadmin/category-parent-change
 /categories/cadmin/object-map
 /categories/cadmin/synonyms-view
 /categories/cadmin/tree-copy
 /categories/cadmin/tree-copy-view
 /categories/cadmin/tree-view
 /comments
 /comments/admin
 /doc/

 /download/
 /download/admin/
 /download/admin/report-by-ip
 /download/admin/report-by-user
 /download/admin/repository-ae
 /download/admin/repository-metadata
 /download/admin/repository-reasons
 /download/admin/repository-types
 /download/help
 /ds/
 /ds/css-edit
 /ds/css-list
 /ds/request-info
 /ds/shell
 /file-storage/
 /forums/
 /forums/admin/
 /forums/admin/forum-edit.html
 /forums/admin/forum-new.html
 /forums/admin/permissions.html
 /forums/forum-view.html
 /forums/message-post
 /forums/message-view.html
 /forums/search
 /forums/user-history.html
 /members/
 /members/user-batch-add
 /news
 /news/admin
 /news/item-create
 /notifications/manage
 /notifications/request-change-frequency
 /notifications/subscribers
 /permissions/
 /permissions/one
 /pvt/home
 /request-monitor/
 /request-monitor/last100
 /request-monitor/running
 /request-monitor/stat-details
 /request-monitor/throttle-statistics
 /request-monitor/who-is-online
 /request-monitor/who-was-online-today
 /shared/community-member
 /shared/parameters
 /shared/whos-online
 /test/admin/
 /user/email-privacy-level
 /user/portrait/upload
 /xowiki/admin
 /xowiki/admin/list
 /xowiki/admin/permissions

 

 

Known Problems

• double "id": 
  Example: /admin/rel-types/new-2?supertype=membership_rel
   
• developer-support breaks validation (adds "div" immediately after "ul" due to include):
  Example: /admin/groups/
  Solved, by adding ability to suppress div wrapper via <include ds=0 src=...>

 

Interface / CSS Coding Guidelines

Created by Robert Taylor, last modified by Gustaf Neumann 21 Mar 2016, at 09:48 AM

OpenACS roadmap states:

Define a reasonable set of default CSS classes and ids that can be reused across the toolkit. Remove package specific CSS classes and ids in most cases and replace with site-wide ones. Allow for easy CSS-based themes.

Related pages:

• en:Theming_Project
• en:dotlrn-zen-project

related forum threads:

• OpenACSZen
• LRN Gardens
• ad_form and css
• CSS Gardens (part 2)
• Default CSS for OpenACS 5.0
• TIP: theming changes (approved)
• css styles for the documentation project / xowiki
• OpenACS skinning
• A proposal: CSS Styles and module hooks in OpenACS 4
• Disabilities Discrimination Act (UK)

See also, the OpenACS coding guidelines.

.LRN

Created by Emmanuelle Raffenne, last modified by Gustaf Neumann 19 Oct 2015, at 08:48 AM

.LRN Project

.LRN Home Page - The Official .LRN Home Page

.LRN bug tracker - Use the Open ACS bug tracker to report and check status on bugs for all sections of .LRN. If you need to report a bug and you are not sure what code is causing it, use the "2-dotLRN General" category. Otherwise select the package. Note that all the dotLRN packages are at the bottom of the list.

Get Involved! - how to participate in the community

.LRN Versions

Last stable release: 2.5.0

Next release: see .LRN 2.5 Release Management 

Download from .LRN download page

.LRN Installation

To install .LRN follow the instructions at .LRN_Installation

.LRN Governance

This .LRN Governance page is a proposal based on a meeting by Carl Blesius, Carlos Kloos, Roceal Hernandez and Caroline Meeks.  

Useful Resources

Site Specific Documentation

Official test servers

Page Information

• Last modified: 2015-10-19 08:48:56.668188+02