Web Lists / Tables

Created by Malte Sussdorff, last modified by Gustaf Neumann 24 Apr 2017, at 08:44 AM

If you have a table to be displayed on your webpage, use listbuilder (template::list::create) to create it. There is some documentation here and https://openacs.org/wiki/list%20builder which will be moved here real soon now ;).

One standard, which you should try to follow for re-usability, is to put the created list in a separate include file, so you could call it from various pages and packages. Things to keep in mind when doing this:

• Pass a list of rows so you know which columns should be displayed on your page
• Name the "orderby" field specific to the type of list: "tasks_orderby" "projects_orderby"
• You might want to do the same with filters (to be on the safe side)

OpenACS/.LRN for Ubuntu

Created by Héctor Romojaro, last modified by Gustaf Neumann 20 Apr 2017, at 10:32 PM

for developers

Created by OpenACS community, last modified by Gustaf Neumann 20 Apr 2017, at 06:44 PM

OpenACS for developers

Features

Besides the quality components of Openacs (See: en:openacs-system), OpenACS has these enterprise-quality features for developers:

• high-performance XML data processing with easy, powerful Tcl scripting functionality using en:tdom (as of OpenACS version 5.0)
• XOTcl object-oriented scripting, which combines the ideas of scripting and object-orientation in a way that preserves the benefits of both (as of OpenACS version 5.3)
• Automated testing (see: en:Testing_with_Selenium and en:testing-with-tclwebtest)
• Flexible and easy caching, for improving the performance of your websites. https://openacs.org/doc/tutorial-caching.html
• programming in Tcl with AOLserver - A lightweight, simple, extremely fast scripting language that features a clean, easy-to-understand API (Application Programming Interface) for generating websites from the database. (See: https://openacs.org/doc/programming-with-aolserver.html )
• pooled DB connections (which reduces database connection startup and tear down time), much like the technique JDBC uses, but predating it by many years. (See: http://www.aolserver.com/docs/admin/dbadmin.html#2 )
• Component package system for easy installation and upgrading of packages (See: https://openacs.org/doc/apm-design.html
• Upgrade paths for code and database schemata (See: https://openacs.org/doc/tutorial-upgrade-scripts.html )
• Full internationalization, including an excellent workflow for translating content into new languages. (See: https://openacs.org/doc/i18n.html )
• Fully functional content repository and content management system. (See: https://openacs.org/doc/cms/cms-intro.html )
• An elegant templating system that separates code from presentation of content. (See: https://openacs.org/doc/templates.html )
• An object system that resides on top of the database, permitting site developers to create complex applications using an object API. Examples include an object level permissions system, audit trails, and ability to relate one object to another. (See: https://openacs.org/doc/object-system-requirements.html )
• OpenACS is released as open source under the GPL license, with millions of lines of open-sourced applications available to use as examples. There are also pre-written packages for you to use or adapt.

---

will be pulling in docs from here: https://openacs.org/doc/acs-package-dev.html and https://openacs.org/doc/acs-plat-dev.html

• OpenACS: robust web development framework (PDF)
• XOTcl for OpenACS developers (PDF) - includes basics of object-oriented programming
• OpenACS Tcl API
• OpenACS PL/SQL calls
• OpenACS Coding Standards

Integrated Development Environments (IDE)

These text editors are commonly used when coding on OpenACS:

• en:ide-emacs
• en:ide-vi 

Bibliography and Credits

See en:doc-credits.

Marketing Team

Created by Caroline Meeks, last modified by Gustaf Neumann 20 Apr 2017, at 06:31 PM

OpenACS/.LRN Marketing Team 

Goals

The Marketing Team works to improve adoption and recognition of OpenACS including .LRN and other OpenACS projects.

• [Marketing Projects]
• Marketing_Docs_Index

Team Members

Team members are those people who are want  to be on the team or are proposed to be on the team, and willing to contribute to it, those members will be selected and ratified.  Terms and roles and responsibilities will be determined by the Marketing Team.  This process will be reviewed in a year to see if a more formal process is needed.

 

The Decision Making Process

Goals

• Make it easy for motivated people to make decisions and implement them with minimal overhead.
• Give the elected OCT and .LRN Board oversight over decisions without requiring too much time. 

Process

1. All members of the  OCT, .LRN Board and Marketing Team subscribe to a designated Forum, email list or Wiki page.
2. Members of the Marketing Team are responsible for reaching out to the appropriate people while making major decisions. Depending on the decision this includes the greater OpenACS community, the OpenACS, .LRN Board and/or membership, and the .LRN Leadership committee.
3. When an individual believes he has done an appropriate level of communication and consensus building on a decision he posts it in the designated place.
4. If no one objects or calls for a vote the decision is confirmed in 2 weeks.
5. If people agree they need take no action; however if there is disagreement or concern, any member of the Board, OCT or Marketing Team may “Call for a Vote” on any decision posted to the decision forum within 2 weeks of the post.
   • The .LRN Board should only call for a vote on things that relate to .LRN brand or dotlrn.org and only the .LRN Board members vote.
   • The OCT should only call for a vote on things that relate to the OpenACS brand or openacs.org or have a technical component that relates to the core (training materials might be an example). In an OpenACS related issue only OCT members vote. The role of the OCT maybe temporary as its charter was to deal with technical issues. However it is currently the only elected body of OpenACS. We will revisit this issue in a year.
   • In the rather unlikely situation where the distinction between OpenACS and .LRN is not clear and its controversial issue then either should call for a vote and both organizations should try to come to agreement. 
6. A decision is upheld with 2 Yes and 0 No’s or a 2/3 majority of all members of the appropriate organization (either the OCT or .LRN Board).  This is usually 5 people.

Informal description of the process

If you have an idea you'd like to implement, discuss it with people who care, post in OpenACS and/or talk about it in an online or meeting or conference. . After you have listened, post your decision Then implement it.  Mostly we all want the same things and we need action.  The OCT and .LRN Board vote is available as an oversight and in those hopefully infrequent times when there is significant dissent.

This is an interim  process 

This process is based on a discussion at the Vienna Conference. There were many different ideas about whether the Marketing Team should be directly elected or report to the current elected boards. There was also discussion about two teams (OpenACS and .LRN) versus 1 team.  This process is the simplest we think could work and our intent is to revisit these questions in a year (or less) and refine the process as needed.

The Marketing Team will be formed when both the OCT and the .LRN Board approve its formation.

 

Source control

Created by OpenACS community, last modified by Gustaf Neumann 20 Apr 2017, at 06:22 PM

 
A Source Control system keeps track of all of the old versions of your files. It lets you recover old files, compare versions of file, and identify specific versions and groupings of files such as for controlled deployment.

the OpenACS reference platform and the OpenACS.org repository (where you can get patched and development code in between releases) use cvs.

This is a place to add notes about other source controls and services used by the community..

 

Guidelines

First READ the official cvs rules https://openacs.org/forums/message-view?message_id=185506

These rules apply whichever source control tool OpenACS is using at the time. As of this writing, we are still using CVS.

 

1. Don't mix bug fixes and new work
2. Don't commit code before it is tested in a clean environment (new working copy)
3. If possible, have someone else test your fix
4. Branch when necessary, don't be afraid of it (but ask OCT first)

1. Don't mix bug fixes and

• Be liberal with working copies. If you need to merge custom code into OpenACS, checkout a new working copy. Don't be stingy. Disk space is cheap. This prevents many problems by reducing accidental commits.
  • bottom line: don't mix bug fixes and new work! If you have a checkout of OpenACS you are developing some new package or feature for an existing package, and you run into a bug, fix the bug in a clean checkout of OpenACS. This is the only sane way to make sure you 1) actually fix the bug and 2) don't commit other changes that don't pertain to the bug fix.

2. Don't commit code before it is tested in clean environment

• Review your changes before committing. If possible ask someone else to look. Do a cvs -qn update to see if the commit is not changing any files you did not expect. Use cvs diff to compare your changes to the respository.
• So for committing code back to OpenACS from your local repository you should have 2 copies
  • 1) your local code
  • 2) a working copy of OpenACS HEAD
• You should make all changes in the working copy and fully test it, running automated tests and checking to make sure you did not accidentally change something or add in client specific  code that is not reusable by OpenACS.

3. If possible, have someone else test your fix

• this should be self-evident, a second pair of eyes always helps to find something you missed.
• if another person is not possible, write an automated test, in fact, write one anyway! 

4. Branch when necessary, don't be afraid of it (but ask OCT first)

• Large projects should be done on a branch. This is a pain with CVS, but it is the only sensible way to do this. Examples include any project that will span a major release cycle. It is the responsibility of the person doing the branch to keep up to date with HEAD and to merge and have the code tested. It is sensible to test in a working copy BEFORE committing the code.

Ideas

Here is my heretical idea. I think we must have another branch. Here is how it would work.

1) developer has a working copy.

2) develop commits code to HEAD

3) code is merged to testing branch

4) code is tested

5) code is moved to release branch

Yes, this is extra work. I believe it is worth it. It is a serious pain with CVS. We started using svnmerge.py for Subversion on our private repository and I saw immediate improvements in process. In this case I think having a well defined process AND tools that facilitate the process are key. OpenACS lacks a well defined process, discipline, and tools to facilitate the process. I believe we need to work harder to define this process and I would like to collaborate with the community on this.

 

Assessment Section Display Types

Created by Dave Bauer, last modified by Gustaf Neumann 20 Apr 2017, at 06:16 PM

 

Big Picture

 We are not 100% sure that we understand everything a display can or should do.

 What is clear is that:   The assessment author should be able to pick from the predefined list of display types.

We think the display type is a first step towards a UI that lets you pick a type of test/survey/quiz etc. and then sets sensible defaults. But right now its pretty confusing.  It doesn't seem to make a lot of sense as to what is controlled by the display type and what is a setting for a section.

Current Plans
We want to reorganize the display type attributes and the section functional attributes to make more sense. 

Display types currently control some display attributes of an assessment section. Right now an assessment author can create a new display type which exposes confusing and complex attributes such as a chunk of ADP code to display the assessment. Because it can involve ADP code we are assuming at this point that creating a new display type should be done by a site-wide admin.  So we intend to restrict access in the UI to creating display types.

Right now display types to be specific to the package instance level but its not clear that is the desired behavior, however we do not have immediate plans to change it. 

Display type refers to the style of display. Right now it also controls the number of questions per page. This seems wrong, Number of questions per page, is a functional attribute and should be set per section. The number of questions should not be tied to how the questions are formatted. An assessment author should be able to use any number of questions on a page with any display type.

Future thoughts: (we are not currently funded to implement these ideas)

Recently the default adp template for an assessment form has been rewritten with semantic HTML that should be suitable for most display types. The visual design can be changed with CSS. This leads me to believe that display types should evolve into CSS style declarations instead of ADP code.

Right now display types are per package instance. In general we'd want site wide display types that can be used by any assessment author in any assessment package instance. For example, with dotlrn, each class has a separate assessment package instance, but the display types may be reused across the whole site.

 

 

One Assessment's Administration Page

Created by Caroline Meeks, last modified by Gustaf Neumann 20 Apr 2017, at 06:15 PM

url stub: /assessment/asm-admin/one-a?assessment_id=12309

 A test example: http://mgh.zill.net/assessment/asm-admin/one-a?assessment_id=12309

Here is a new idea: Lets use a tabbed interface with the following tabs.

 Assessment Name Admin | Results | Section 1 Name |  Section 2 Name

Thus we can cut down on the really long pages and make it easy for people to move between sections.

 

Assessment Name Admin 

On the one assessment admin page add in the export and permissions we took out from the top level admin page. Display the current values of all the many configuration settings an assessment can use. Since we now have sections and questions on another page we can use the space here to show these details and let people change them one by one. I believe this will be less intimidating then the current form which seems to ask you for 20 incomprehensible decisions right up front.  Eventually we can add links to help text that would explain why you might want to use these different options.

Results

We aren't going to deal with the details of the results page right now, but in day to day operation the results are the most important most used part of the admin interface. It should be easier to get to and we should devote a full page to a UI for browsing and getting to the results you want.

Sections

 New Look would be something like

 

1. Section 1 (SEC_12312) Edit | Preview |  Triggers | Add New Section

• Lets either use icons or words in class=button. Mixing them is not working. I think words are easier for now.
• Search for a new section is a particular form of adding a new section. It should be an option AFTER you click Add New Section
• Edit Display types actually edits the package wide display type. This should be done from the top level page.
• Everything you might want to do with triggers can be dealt with after you click triggers.
• Moving a section should be done from the Edit page. We can present a UI that lets people say exactly what section they want this section to follow. Should be easier then incrementally using arrows.
• Delete should be an "Extreme Action" on the edit page.

Items (Questions)

 

New Look

2. Last Name  ( QUE_4551)  2 triggers Preview

Edit | Move Up | Move Down | Delete | Copy | New Question 

• Hide the details of the question until someone clicks Preview then use CSS to display the entire question inline.
• Searching for questions is a specific way of adding a new question so it should be an option on the new question page. \
• Trigger administration should be an option on the Edit page. I think we need to keep a visual reminder here when triggers are defined for a question as that is a pretty important and unusual event.

We can repeat Add a New Question and then below that Add a New Section at the bottom of the page for convenience. Remove all references to searching as per above.

 

 

User Parameter Package - RFC

Created by Ryan Gallimore, last modified by Gustaf Neumann 20 Apr 2017, at 06:14 PM

There seems to be a need in OpenACS for user-defined parameters. These might include customizing a menu, personalizing a site style template, or even removing or adding includes and panels.

 Here's an initial brainstorm of possible field types:

• Personalized text - user defined text or titles, such as the title of a personal subsite homepage
• Turn on/off toolbar buttons
• Color picker
• CSS stylesheet
• Turn on/off includes (e.g. Solution Grove homepage)
• Change site theme (e.g selva) - is this possible?

The best part of this is that it is dead easy to add new parameters via the APM.

Please post your comments here.

Ryan Gallimore - Viscous Media

CM: What would the user facing UI for this look  like? Parameters are such a horrid UI.

I was talking to a person from the MIT media lab who works on a site for kids there. Their site allows the kids to use the CSS personalization for My Space. This means that there are all sorts of cool themes for the kids without the site owners having to program them.  T. The problem they have is that some of the themes have very very My Space specific things, like hide the 3rd table in the 4th div, which is of course quite different on their site then My Space's.  Nevertheless, this is an idea we might want to use, making out stuff compatible either My Space or another system with a wide variety of themes so we get a lot of looks for "free"

 

Daveb: what do you mean by user-editable parameters? Do you mean "preferences"? Is this for administrators or regular users.  

Ryan: by user-editable pages I mean regular users, and yes you could call them preferences, but users would  be editing parameters directly in oacs. As far as UI goes, I think the current UI for parameters would work well - perhaps with more field validation.

Maltes: There exists a user_preferences table and this is where your custom applications should store it's values. Then just write a page with form callback hooks (look at callback::contact::special_attributes::ad_form_values::contract and callback::contact::special_attributes::ad_form_save::contract respectively in /contacts/www/contact-add.tcl) which will allow the packages to extend the form with the variables they allow the user to edit. This way you only need one page e.g. in acs-subsite /pvt/edit_preferences where the user can change all his / her user_preferences, including the ones already stored in this table. Each package would then (for each parameter it wants to have a user setting for):

• Extend user_preferences by adding the column
• Write a form extension callback implementation
• Write a form save callback implementation
• Add the code that deals with the parameter's return somewhere

Obviously it would make sense for the last step to have a cached procedure "user::get_preference -name -user_id". And we should probably enforce a naming convention like "${package_key}_$pref_name" so we are not accidentally running into name conflicts on the table.

Webinar - Part 1 - Basics

Created by Marcin Kuczkowski, last modified by Gustaf Neumann 20 Apr 2017, at 06:05 PM

OpenACS Basics - Part 1

On 2006-10-15 Tracy Adams gave a webinar for developers on OpenACS basics. Here are notes, that might be of use for people who are starting to learn the toolkit. For example for easy copy-n-paste during learning sessions.

We assume the reader has a working instance of OpenACS at hand. If not, there are other sections of xowiki, that cover the installation and configuration of OACS.

Configuration for the turorial 

The default config puts the files of the toolkit to:

/var/lib/aolserver/service0

In this case, the dir of our interest for now, will be:

/var/lib/aolserver/service0/www

 We will edit all our tutorial files in that directory.

Hello, world! 

 OACS uses combination of Tcl and ADP pages for clear separation of logic and presentation. Tcl pages are just a Tcl scripts and ADP are HTML pages with some extra tags. However the early versions of the toolkit rendered pages within Tcl. We will use some of the earlier features of the toolkit.

Open a file "helo-1.tcl" in the path:

/var/lib/aolserver/service0/www

and put there:

# helo-1.tcl # return standard HTTP headers ReturnHeaders ns_write "hello, world!"

 now, open Your Firefox and go to:

http://yourhost/helo-1

or maybe with the port number: 

http://yourhost:8000/helo-1

instead of "yourhost" put the name or IP of the host of the edited instance of OACS. It also refers to all examples which follow.

Note the lack of .tcl extension at url. OACS has a Request Processor, that figures out the right extension and fetches the file.

ReturnHeaders - returns HTTP headers to the browser ns_write - just writes string to the browser

The docs for the entire system can be found at:

http://yourhost/doc

Note also very useful API browser and search boxes at:

http://yourhost/api-doc 

( maybe the URL will need also the port number, depending on Your config, for example:

http://yourhost:8000/api-doc 

)

Set a value

 To use a variable just put a value in it:

# helo-2.tcl
ReturnHeaders
# first, set the value for a
set a 10

# then use it
ns_write "value of a is $a"

The value of the var can also be a string:

# helo-3.tcl
ReturnHeaders
# first, set the value for a
set name "John"

# then use it
ns_write "My name is $name"

To get the value of the var:

# helo-4.tcl ReturnHeaders set a 10 # let's use the value of a for new var: set b $a ns_write "<br/> value of b is $b" # we can also do this like that: set c [set b] ns_write "<br/> value of c is $c"

The form [set varname] form of getting the value of the var seems at first a bit too long, but it comes in handy when doing some metadata manipulations.

Call a func

To evaluate the function ( or call a procedure ) use [ ] as follows:

# helo-4b.tcl ReturnHeaders set a 10 # let's use the value of a for new var: # expr is a func that returns the result of the math expression given # as the argument. using square braces we call this func set b [ expr $a + 5 ] ns_write "<br/> value of b is $b"

 Lists are simple

To create a list:

# helo-5.tcl
ReturnHeaders
set mylist [ list "red" "green" "blue" ] 
ns_write "<p> mylist is: $mylist"

( TODO: more on the lists - creation, adding, deleting, finding, etc...)

More complex structures: ns_set  

See the docs on ns_set: http://panoptic.com/wiki/aolserver/Ns_set.

 

 

# helo-6.tcl ReturnHeaders

# create a new set with a name "the_name_of_the_set": set vars_by_names [ ns_set create the_name_of_the_set ] # the name of the set is different that the name of the # variable, that contains that set # put some variables into the set: ns_set put $vars_by_names red   $red ns_set put $vars_by_names green $green ns_set put $vars_by_names blue  $blue # how many things do we have in the bag? set size [ ns_set size $vars_by_names ] ns_write "size of the set:  $size " # let's show them: ns_write "<br>red:   [ ns_set get $vars_by_names red   ]" ns_write "<br>green: [ ns_set get $vars_by_names green ]" ns_write "<br>blue:  [ ns_set get $vars_by_names blue  ]" # the same, but better: ns_write "<hr/>" set size [ ns_set size $vars_by_names ]

#     counter     condition      change the counter for { set i 0 } { $i < $size } { incr i } {     set key   [ns_set key   $vars_by_names $i]     set value [ns_set value $vars_by_names $i]     ns_write "<br/> $key: $value " }

Parameters for the page

It is very simple to control the way the parameters from query string go to our page:

#helo-7.tcl
ad_page_contract {
    demonstrates using of ad_page_contract
} {
    id:integer
}

ReturnHeaders
ns_write "id is: $id"

1. try to reach the page http://yourhost/helo-7 without the query string     the page should display the message about input problems

2. try the same with the url: http://yourhost/helo-7?id=123    the page should write the message: "id is 123"

3. try the same with the url: http://yourhost/helo-7?id=asdf    the page should display the message about id not being the integer

The parameter can be optional:

#helo-8.tcl ad_page_contract {     demonstrates using of ad_page_contract } {     id:integer,optional }

set id "<b>not necessary but optional</b>" ReturnHeaders ns_write "id is: $id"

Access control 

Using ad_conn, we can discover many useful info: 

# helo-9.tcl

# check if the user is logged in, redirect if not ad_maybe_redirect_for_registration ReturnHeaders # id of the user set user_id [ad_conn user_id] ns_write "user_id: $user_id" # peer's IP set user_ip [ad_conn peeraddr] ns_write "<p> user's IP: $user_ip"

Logic and Presentation

Now let's get to Tcl + ADP stuff which allows to separate the work of the designer from the work of the developer.

Most of the pages in OACS consist of at least Tcl and ADP components. Here is how:

In most cases Tcl and ADP pages are named the same, except for the extension. It is possible to explicitly call the presentation page from the script. See the docs for ad_return_template.

In the following example we will use helo-10.tcl and helo-10.adp.

in Tcl we do some data manipulation

# helo-10.tcl ad_page_contract {     demonstrates TCL and ADP combination     and multirow } {     id:integer,optional } -properties {     a:onevalue     alist:multirow }

set a 10 # create the multirow multirow create alist no name      color # add rows multirow append alist 1  Adam      red multirow append alist 2  Ben       blue multirow append alist 3  Catherine green multirow append alist 4  Danae     black

then we present it in ADP. Put the script below into helo-10.adp: ( note: remove the space between @ and the name of the variable below; I do not know how to escape the @ )

<master> <p>     the value of a is @ a@ </p> <blockquote>     <multiple name="alist">         <li> @ alist.no@ - @ alist.name@ ( color: @ alist.color@ )

</li>     </multiple> </blockquote>

 now open the page in browser:

http://yourhost:8000/helo-10

That's all.

The webinar took place on Sunday 2006-10-15 at 2:30 P.M. Eastern time.

Many thanks to Tracy Adams, who was presenting the material.  

( corrections welcome, especially of my english )

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)