Created by Malte Sussdorff, last modified by Gustaf Neumann 26 Oct 2016, at 01:13 PM
To monitor your server with Nagios you can use the check_http command.
Use
check_http -h <yourip> -u /SYSTEM/dbtest -s "success"
To obtain the HTTP critical status if OpenACS can't return success, which can be either because the server isn't running or the database connection has failed.
Created by Emmanuelle Raffenne, last modified by Gustaf Neumann 22 Oct 2016, at 09:34 AM
| Summary: | A Course Management System |
| Description: | Course Management |
| Maturity: | Mature |
| This package depends on: | acs-kernel acs-subsite acs-admin acs-mail-lite acs-lang attachments new-portal profile-provider user-profile |
| Packages that depend on dotlrn: | attendance chat-portlet content-portlet courses dotlrn-admin dotlrn-ae dotlrn-application-track dotlrn-assessment dotlrn-attendance dotlrn-bboard dotlrn-beehive dotlrn-bm dotlrn-calendar dotlrn-cards dotlrn-catalog dotlrn-chat dotlrn-content dotlrn-curriculum dotlrn-datamanager dotlrn-dotlrn dotlrn-ecommerce dotlrn-edit-this-page dotlrn-eduwiki dotlrn-evaluation dotlrn-expense-tracking dotlrn-faq dotlrn-forums dotlrn-fs dotlrn-homework dotlrn-imsld dotlrn-jabber dotlrn-lamsint dotlrn-learning-content dotlrn-lorsm dotlrn-messages dotlrn-mmplayer dotlrn-news dotlrn-news-aggregator dotlrn-photo-album dotlrn-portlet dotlrn-quota dotlrn-recruiting dotlrn-research dotlrn-static dotlrn-survey dotlrn-syllabus dotlrn-tasks dotlrn-user-tracking dotlrn-weblogger dotlrn-wikipedia dotlrn-wps dotlrn-xowiki eduwiki eduwiki-portlet evaluation expenses ims-ent learning-content learning-content-portlet messages messages-portlet planner random-photo-portlet research-portlet static-portlet tasks-portlet theme-selva theme-zen xowiki-portlet |
| Package parameters: |
|
| Open Bugs: | 51 |
| All Tracked Issues: | 141 |
| Latest Bug Opened: | 2017-08-21 Error on removal of dotLRN user |
| Latest Bug Fixed: | 2017-04-09 dotlrn::do_abort returns with an "error" code. |
| Top Bug Submitters: | Carl Robert Blesius (23) Caroline Meeks (14) Nima Mazloumi (11) Emmanuelle Raffenne (6) Anja Wicht (6) |
| Top Bug Fixers: | Peter Marklund (22) Lars Pind (15) Don Baccus (10) Emmanuelle Raffenne (9) Tracy Adams (7) Jeff Davis (5) Joel Aufrecht (3) |
| # Tcl Procs | 0 |
| # Tcl Lines | 0 |
| # Tcl Blank Lines | 1 |
| # Tcl Comment Lines | 0 |
| # Automated Tests | 0 |
| # Stored Procedures | PG: 0 ORA: 0 |
| # SQL Lines | PG: 0 (blank 1 comments 0) ORA: 0 (blank 1 comments 0) |
| # ADP pages | 0 |
| # ADP lines | 0 |
| # Include pages (dotlrn/lib/) | 0 |
| # Documentation pages | 0 |
| # Documentation lines | 0 |
| Browse Source | Not installed |
| Github Repository: | https://github.com/openacs/dotlrn/tree/oacs-5-10 |
See proposal for comprehensive email event handling
For details about dotlrn, see http://dotlrn.org/
Created by Rocael Hernández Rizzardini, last modified by Gustaf Neumann 22 Oct 2016, at 09:10 AM
add event listener for a single ID or for a CSS class. When using this call, the provided JavaScript snipped will be added suitable for content security policies (by adding nonces).
Example:
template::add_event_listener \
-id edit-tags-control \
-script [subst {document.getElementById("edit_tags").style.display="block";}]
Adds javascript code to an event handler in the body tag. Several javascript code blocks may be assigned to each handler by subsequent calls to template::add_body_handler.
Add a script to the start of the body section of the document to be returned to the users client.
There was no easy way to add onload event to openacs, unless you edit www/site-master.tcl, but now you can define within you own package what functions you want to be for onload javascript event. This tcl callback definition will work for any page.
ad_proc -public -callback subsite::header_onload -impl my_onload {} {
return the function to load when the page is served
} {
return {my_javascript_function();}
}
Or in case you want it for a single page, or for you custom template, use the template property to send it:
<property name="body(onload)">
my_javascript_function();
</property>
Alternatively, as the on_load property tag has been deprecated, you could in your .tcl file set a variable
set my_function_name "my_javascript_function();"
then in the .adp
<property name="body(onload)">
@my_function_name;noquote@
</property>
Created by Emmanuelle Raffenne, last modified by Benjamin Brink 22 Oct 2016, at 04:41 AM
| Summary: | Portlet for the "new-portal" system for the DotLRN |
| Description: | |
| Maturity: | Mature |
| This package depends on: | dotlrn new-portal |
| Packages that depend on dotlrn-portlet: | dotlrn-dotlrn |
| Package parameters: |
|
| Open Bugs: | 1 |
| All Tracked Issues: | 6 |
| Latest Bug Opened: | 2005-02-28 HTMLArea breaks .LRN Custom Portlet for non IE/Mozilla users |
| Latest Bug Fixed: | 2013-09-16 bad package name for a Message_key. |
| Top Bug Submitters: | Stan Kaufman (1) Jarkko Laine (1) Samir Joshi (1) Carl Robert Blesius (1) Emmanuelle Raffenne (1) |
| Top Bug Fixers: | Lars Pind (2) Don Baccus (1) Emmanuelle Raffenne (1) Gustaf Neumann (1) |
| # Tcl Procs | 0 |
| # Tcl Lines | 0 |
| # Tcl Blank Lines | 1 |
| # Tcl Comment Lines | 0 |
| # Automated Tests | 0 |
| # Stored Procedures | PG: 0 ORA: 0 |
| # SQL Lines | PG: 0 (blank 1 comments 0) ORA: 0 (blank 1 comments 0) |
| # ADP pages | 0 |
| # ADP lines | 0 |
| # Include pages (dotlrn-portlet/lib/) | 0 |
| # Documentation pages | 0 |
| # Documentation lines | 0 |
| Browse Source | Not installed |
| Github Repository: | https://github.com/openacs/dotlrn-portlet/tree/oacs-5-10 |
Created by Emmanuelle Raffenne, last modified by Benjamin Brink 22 Oct 2016, at 04:40 AM
| Summary: | Helper routines for dotLRN applets |
| Description: | |
| Maturity: | Mature |
| This package depends on: | dotlrn dotlrn-portlet |
| Packages that depend on dotlrn-dotlrn: | None |
| Package parameters: | None |
There is no package with the name "dotlrn-dotlrn" known to bug-tracker.
| # Tcl Procs | 0 |
| # Tcl Lines | 0 |
| # Tcl Blank Lines | 1 |
| # Tcl Comment Lines | 0 |
| # Automated Tests | 0 |
| # Stored Procedures | PG: 0 ORA: 0 |
| # SQL Lines | PG: 0 (blank 1 comments 0) ORA: 0 (blank 1 comments 0) |
| # ADP pages | 0 |
| # ADP lines | 0 |
| # Include pages (dotlrn-dotlrn/lib/) | 0 |
| # Documentation pages | 0 |
| # Documentation lines | 0 |
| Browse Source | Not installed |
| Github Repository: | https://github.com/openacs/dotlrn-dotlrn/tree/oacs-5-10 |
Created by Gustaf Neumann, last modified by Benjamin Brink 22 Oct 2016, at 04:40 AM
| Summary: | |
| Description: | |
| Maturity: | New Submission or Maturity Unknown |
| This package depends on: | dotlrn datamanager-portlet datamanager |
| Packages that depend on dotlrn-datamanager: | None |
| Package parameters: | None |
There is no package with the name "dotlrn-datamanager" known to bug-tracker.
| # Tcl Procs | 0 |
| # Tcl Lines | 0 |
| # Tcl Blank Lines | 1 |
| # Tcl Comment Lines | 0 |
| # Automated Tests | 0 |
| # Stored Procedures | PG: 0 ORA: 0 |
| # SQL Lines | PG: 0 (blank 1 comments 0) ORA: 0 (blank 1 comments 0) |
| # ADP pages | 0 |
| # ADP lines | 0 |
| # Include pages (dotlrn-datamanager/lib/) | 0 |
| # Documentation pages | 0 |
| # Documentation lines | 0 |
| Browse Source | Not installed |
| Github Repository: | https://github.com/openacs/dotlrn-datamanager/tree/oacs-5-10 |
Created by Emmanuelle Raffenne, last modified by Benjamin Brink 22 Oct 2016, at 04:39 AM
| Summary: | |
| Description: | |
| Maturity: | New Submission or Maturity Unknown |
| This package depends on: | acs-content-repository acs-subsite assessment categories dotlrn |
| Packages that depend on dotlrn-catalog: | dotlrn-ecommerce |
| Package parameters: | None |
There is no package with the name "dotlrn-catalog" known to bug-tracker.
| # Tcl Procs | 0 |
| # Tcl Lines | 0 |
| # Tcl Blank Lines | 1 |
| # Tcl Comment Lines | 0 |
| # Automated Tests | 0 |
| # Stored Procedures | PG: 0 ORA: 0 |
| # SQL Lines | PG: 0 (blank 1 comments 0) ORA: 0 (blank 1 comments 0) |
| # ADP pages | 0 |
| # ADP lines | 0 |
| # Include pages (dotlrn-catalog/lib/) | 0 |
| # Documentation pages | 0 |
| # Documentation lines | 0 |
| Browse Source | Not installed |
| Github Repository: | https://github.com/openacs/dotlrn-catalog/tree/oacs-5-10 |
Author: Nima Mazloumi
After talking to Carl and Dave I would like to propose the following extensions to dotlrn-catalog: Please forgive my poor englisch and feel free to contact me for further questions.
In order to keep dotlrn-catalog simple all new extensions should be realized as sub types of the object type dotlrn_catalog. Thus we don't introduce new attributes to the dotlrn_catalog table. Instead the new sub type shall provide it's own table and attributes.
In order to support several sub types dotlrn-catalog has to be modularized in a way that those fragments specific to a type so-to-speak infused in the right way. For this two concepts shall serve as a solution:
Includelets are the standard way to include adp files within others. The characteristic in this case is that the adp file included is determined by the given sub type used. For this purpose dotlrn_catalog will contain a supfolder lib with serveral subfolders named exactly by the sub type name. Depending on the given type right system will select the right includelet and render the view.
In this case the tcl files have to be extended transparently depending of the given sub type. For this purpose we would like to suggest the usage of callbacks. Depending of the extension form (exclusive or composition) either the callback directly or an implementation for a given type is called to extend the behaviour of the package.
The default behaviour of dotlrn-catalog will be how it is right now. Administrators are able to create new course items, associate assessments to them and link them to dotlrn communities. The only difference will be how the pages are composed. With the above propsed solution the default installation will only know the object type dotlrn_catalog and therefore only include includlets for this type and also only call callback implementations for this type. This solution will not require any changes to the datamodel.
To achieve this solution forms, lists and type-specific fragments need to ge generated dynamically depending of the object type. You can see it partially implemented in the course-add-edit file in the current dotlrn-catalog package.
To achieve this dotlrn-catalog uses already now the new CR TCL API.
This is done via a new package parameter called SupportedTypes which will contain the list of available types to the system. The default version of dotlrn-catalog will only know the type dotlrn_catalog. In order to use the other types as well more types must be entered to the list.
Thus at runtime OpenACS will check for the available types and make them available to the installation.
The Unversity of Mannheim has implemented a package called groups which has be used productively in Mannheim for almost one year and which is used by professors to organize the registration process for their courses.
Next to standard attributes like group name, start date, end date, description and the like, which is also available in dotlrn-catalog for courses the packages provides attributes like
Thus an administrator can create a new group type with the above characteristics and let the system take care of the registration process. For this purpose the administrator can select from different join policies. The default policy is the First-Come-First-Served which corresponds to the open policy. The second one is the requires approval which speaks for itself. The third and new policy is by preferences.
This policy allows students to choose from a list of 1 or more available parallel courses. The idea behind this is that often the same course is given during a semester on different days and hours during the week in order to keep the classes small. Since some of them are more appealing than others - maybe one is on monday morning or the other on friday evening - the preffered ones the to explode while other courses are visited sporadically. To solve this problem we don't let the students join direclty a course. Rather we allow the student to indicate which courses he can imagine to join and which not. This we call white and black list. Once the registration process is over. We let the system automatically distribute the students to the courses taking in mind the size restrictions of the course as well as the choices of the students.
In order to integrate this in dotlrn-catalog we propose the creation of a new sub type of dotrn_catalog called dotlrn_registration which contains the above parameters.
Thus the administrator will have the choice to create a new course based on dotlrn_catalog or dotlrn_registration. Depending of the type further actions or informations will be available to students. Students interested in a course of the type dotlrn_registration need to register during a given period. Depending of the join policy they can either join a course or request membership or have to make a choice.
Installations interested in using the new type have to add the type to the package parameter SupportedTypes.
The type dotlrn-registration will provide other features like:
We have a course called "Introduction to Accounting". This course is offered every semester for undergraduate students. Usually around 800 students attend this lecture. Due to the number of students the lecture is accompanied by up to 8 seminars - all with the same content but usually on different times in order to allow students to be more flexible. Still some seminars are more apealing than others. This could be because of the time, the location, the tutor...Since the sizes of the seminars are rstricted by teh number of seats available students have indicate which seminar the prefer compared to the others. Depending on the configuration set by the course administrator the students have submit a ranking or simply tell which seminar they prefer most and which less. Any number in between is configurable. Once the registration process is over the system recommends a distribution which can be double checked by the course administrator. Finally the distribution is confirmed and 8 subgroups in dotlrn are created and the memberships assigned. If the course administrator wishes all accepted students are notified. He can also notifcy the rejected students or add them to a waiting list.
In order to allow the above scenario it takes the professor 2-3 minutes to define it and further 5 minutes to trigger the distribution. The algorithm to optimize the above problem is takes for a situation of 1000 students and 1000 seats (1 mio elements matrix) around 4 min on a 1-CPU 3.1 Ghz Intel Box.
We have also implemented the distribtion types first-come-first-served as well as random.
after taking a close look at dotlrn-ecommerce (DE) and dotlrn-catalog (DC) I would like to suggest some changes since there are a lot of catalog specific stuff hidden in DE. This is especially:
dotlrn_ecommerce_section table:
section_id,course_id,community_id,section_name,date_time_start,date_time_end,daily_p,
weekly_p,max_participants,waiting_list_p,notify_waiting_number,show_participants_p,
show_sessions_p,description (a)
product_id,account_code_revenue,account_code_expense,member_price_number,non_member_price,show_price_p (b)
age,qualified_age_low,qualified_age_high (c)
As you can see (a) apply to courses as well. We in Mannheim for instance have several courses
that are split into sections. Thus why not remove those from dotlrn_ecommerce_section to a new
dotlrn_course_section table that should be moved to DC.
dotlrn_ecommerce_section would inherit from dotlrn_course_section and only add attributes under (b) and would stay in DE.
Regarding the attributes (c) I believe that they should be handled in a third table part of DE since in future
there might be many more parameters like age, that could play a role. After talking with Carl I think we can
solve this through the new admin defined filters that are associated to a course/section and an applicant. Thus if
the parameter age matters, the admin defines that filter and the associated rule. Anyway. I just think there is
room for improvement here.
max_participants is used twice once here and once in ecommerce. Why is that?
dotlrn_ecommerce_section is not a acs object at all. Why is that? It could also be a CR item, no?
those types are available. Why should the UI offer ecommerce specific stuff, or assessment specific code or sections
if a course admin only wants to have his course listed in the catalog where a second course admin in the same institution
wants to offer a commercial course and a third a course with several sections and registration process.
Right now we have the policy "eat or die" either use DC or DE. But what we really need is an adjusting UI depending
on the course type. Looking at DE the UI is too overwhelming to a course admin who only wants to use the sections part
or in future the filters.
This package could deal with the whole registration process like type of join policies available, type of status possible,
filters, assessment, registration_start_date, registration_end_date, automated registration depending on student choices...
<<>>As a conclusion. I would like to recommend several packages that focus on a specific type:
- dotlrn-catalog --> courses and optionally sections
- dotlrn-registration --> adding registration process, communities (optional), membership status, filters, assessment (optional)
- dotlrn-ecommerce
Several wizards shall be offered to the admin to go through the whole course administration process.
The site admin should have the choice to activate permitted features. The course admin should have the choice to choose from them.
The UI should adapt to the given type.
One question I have is: seperation into several packages is better but we need one package that plays the role of facade. One that knows the extensions and that includes the bits and pieces depending to the selected course type. Any idea how we could solve this?
Created by Emmanuelle Raffenne, last modified by Benjamin Brink 22 Oct 2016, at 04:37 AM
| Summary: | .LRN-wide admin pages. Initially created as a singleton with automount at /dotlrn/dotlrn-admin. These can be changed if and when .LRN supports multiple instances. |
| Description: | Contains pages and scripts for configuring .LRN --- managing users, departments, terms, classes and so on. |
| Maturity: | New Submission or Maturity Unknown |
| This package depends on: | dotlrn |
| Packages that depend on dotlrn-admin: | None |
| Package parameters: | None |
There is no package with the name "dotlrn-admin" known to bug-tracker.
| # Tcl Procs | 0 |
| # Tcl Lines | 0 |
| # Tcl Blank Lines | 1 |
| # Tcl Comment Lines | 0 |
| # Automated Tests | 0 |
| # Stored Procedures | PG: 0 ORA: 0 |
| # SQL Lines | PG: 0 (blank 1 comments 0) ORA: 0 (blank 1 comments 0) |
| # ADP pages | 0 |
| # ADP lines | 0 |
| # Include pages (dotlrn-admin/lib/) | 0 |
| # Documentation pages | 0 |
| # Documentation lines | 0 |
| Browse Source | Not installed |
| Github Repository: | https://github.com/openacs/dotlrn-admin/tree/oacs-5-10 |
Created by Gustaf Neumann, last modified by Benjamin Brink 22 Oct 2016, at 04:36 AM
| Summary: | Portlet for XoWiki |
| Description: | |
| Maturity: | Immature |
| This package depends on: | dotlrn new-portal xowiki |
| Packages that depend on xowiki-portlet: | dotlrn-xowiki |
| Package parameters: |
|
There is no package with the name "xowiki-portlet" known to bug-tracker.
| # Tcl Procs | 0 |
| # Tcl Lines | 0 |
| # Tcl Blank Lines | 1 |
| # Tcl Comment Lines | 0 |
| # Automated Tests | 0 |
| # Stored Procedures | PG: 0 ORA: 0 |
| # SQL Lines | PG: 0 (blank 1 comments 0) ORA: 0 (blank 1 comments 0) |
| # ADP pages | 0 |
| # ADP lines | 0 |
| # Include pages (xowiki-portlet/lib/) | 0 |
| # Documentation pages | 0 |
| # Documentation lines | 0 |
| Browse Source | Not installed |
| Github Repository: | https://github.com/openacs/xowiki-portlet/tree/oacs-5-10 |
Created by Gustaf Neumann, last modified by Benjamin Brink 22 Oct 2016, at 04:36 AM
| Summary: | DotLRN Integration (Applet) for XoWiki |
| Description: | |
| Maturity: | Immature |
| This package depends on: | dotlrn xowiki-portlet |
| Packages that depend on dotlrn-xowiki: | None |
| Package parameters: | None |
There is no package with the name "dotlrn-xowiki" known to bug-tracker.
| # Tcl Procs | 0 |
| # Tcl Lines | 0 |
| # Tcl Blank Lines | 1 |
| # Tcl Comment Lines | 0 |
| # Automated Tests | 0 |
| # Stored Procedures | PG: 0 ORA: 0 |
| # SQL Lines | PG: 0 (blank 1 comments 0) ORA: 0 (blank 1 comments 0) |
| # ADP pages | 0 |
| # ADP lines | 0 |
| # Include pages (dotlrn-xowiki/lib/) | 0 |
| # Documentation pages | 0 |
| # Documentation lines | 0 |
| Browse Source | Not installed |
| Github Repository: | https://github.com/openacs/dotlrn-xowiki/tree/oacs-5-10 |
|
|||||||||||||||||||||||||||||||||||||||||||||
|
|||||||||||||||||||||||||||||||||||||||||||||
|
|||||||||||||||||||||||||||||||||||||||||||||
|
|||||||||||||||||||||||||||||||||||||||||||||
