• last updated 7 hours ago
Constraints
Constraints: committers
 
Constraints: files
Constraints: dates
Added archiving of items, reduced usage of images for icons

When an item is archived, it is not shown to plain users. Internally,

when an item is archived, the publish status is changed to "expired"

and removed from search/syndication. When an item is archived, it can

be brought via "toggle-publish-status" to state "production" again.

Future versions might rename the item in such conditions, but

currently, it is NOT renamed, so one cannot create one more item in

the same folder with the same name.

For realizing this functionality, the includelet "form-usages" accepts

now an additional optional value for "-buttons" named "archive". The

publish status toggle can be used now for switching from

"production"->"ready", "ready"->"production" and

"expired"->"production".

Additionally, the usage of .png images as icons was reduced by CSS

elements for easier styling (e.g., for different themes) and for

reducing less server requests and better responsiveness. In particular

the images for active.png and inactive.png are not necessary any more

and were removed.

Bumped version number to 5.10.1d8 to enforce loading of the message

keys.

    • -8
    • +25
    ./www/resources/xowiki-yui-specific.css
white-space changes

solve property resolution in form-usages by avoiding lookups from the current item to reduce side effects

CVS: ----------------------------------------------------------------------

fix form field property resolution: in form-usages, default values were overruling the specified properties

define javascript input handler for formfield class numeric to prevent non-numeric input while preserving the multi-lingual interpretation

Update jquery-ui to version 1.13.0 to mitigate high severity XSS vulnerabilities

    • -11
    • +15
    ./www/resources/jquery/jquery-ui.css
    • -740
    • +1080
    ./www/resources/jquery/jquery-ui.js
    • -10
    • +3
    ./www/resources/jquery/jquery-ui.min.js
Fix the branch performing get_page_from_item_ref when multiple parent_ids are specified, rename the loop variable so that the original argument is not lost

Use a trivial lookup: content::item::get might perform many queries, in particular on success

Init the item_id to 0 in the loop: if not, in case of multiple objects A and B, if the resolving of A suceeds and that of B fails, the id of A will be assigned to B

make log messages more uniform (no need to start with actual proc name)

Don't try query parameters when resolving standard pages

make sure to html-quote error message

reduce cache hits on nsv "::chat::Chat" and on "::chat::Chat-ID-options"

replace deprecated calls in test

make log entries more uniform

reduce verbosity

don't mangle navigational dots in item-refs

Fix typo, fix expected value in test

    • -2
    • +2
    ./tcl/test/xowiki-admin-tests-procs.tcl
Adjust expected value in xowiki.xowiki_test_cases automated test

    • -1
    • +1
    ./tcl/test/xowiki-admin-tests-procs.tcl
do not allow names containing only dots as wiki names

These names are now as well mapped via method normalize_name to underscores

improve german message keys (spelling, comma, spaces, orthogonality)

  1. … 3 more files in changeset.
Fully qualify the parameter command to not conflict with the class having the same name in the ::xo namespace

prefer standard OpenACS API for accessing parameters

Support for pool questions in the test-item family

Features:

- select random questions from some folder

(Currently siblings, i.e., folders of the same package instance)

- one exam can have multiple pool questions, potentially from other pools

- pools can be links to other folders (which are no siblings)

- The current folder can be used as well as a pool folder. In this

case, other not-used items can be selected as replacement items

given these match the specified filter characteristics

- Question filtering

* filter by item type:

allow one to select from all/some/some item types

(mc, sc, short text, reordering, composite, ...):

use as replacement items only examples of these types

* filter by minutes and/or points:

use as replacement items only items with matching points/minutes

* filter by language:

use as replacement items only items in a certain language

* Filter per item name pattern:

use as replacement items only items matching a name.

When (short-) names are used systematically, one can e.g.

use the date in the name and specify only items from e.g.

one year ago, via "*2020*", or from some chapter "*ch01", ...

Certainly, it is also possible to use different item

folders for this

Potential further steps:

- Currently, exams containing pool questions are treated as

auto-correctable (which implies automated exam-review (Einsicht), when

from the question pools only question from strictly closed questions

are selected (MC, SC, Ordering). Depending on the detailed settings,

also other item types could be possible (via correct-when), but this

requires a deeper analysis of every question, which is so far not

performed.

- Categorized items: technically, the infrastructure is mostly here to

allow also filtering by categories. This would allow one to select

e.g. from technical questions, case examples, knowledge transfer

questions, research-oriented questions... which are orthogonal to

the filtering currently available. Every lecturer can define

own categories depending on their needs, we could provide

university-wide category-trees, etc. Of course, one could also

define separate pools for these purposes, but categorizing is

probably more convenient and more flexible.

- Performance: when question pools become large (500+ questions) and

the cohorts as well (500+), the current version might require more

tuning. The only critical time is the exam-start, where the random

question placeholders have to be resolved for every student. The

approach from this weekend uses basic caching, but maybe this has to

be extended.

- Protecting selected questions: Question pools are more detached from

an exam than single exercises, a lecturer might have in mind. One

should not allow one to delete questions/question pools when these are

in use. Probably deletion should be a move to a trash-can, which is

actually, an issue for all exams, but getting more important with

pool questions.

- Handling of potential duplicates: When items are pulled from a

question pool, a replacement item is selected by making sure that

this item does not occur already in the query selection. Therefore,

one can safely draw two questions from the same question pool

without fearing that a student gets the same question twice.

This duplicate checking might require some fine-tuning:

* the system checks for duplicates in an exam via POOL/NAME.

* if a lecturer uses two pool-questions in an exam pointing to the same pool,

the systems makes sure, the same question is not used twice.

* however, if a teacher adds a question q1 to pool1 and the same question to pool2,

these two instances have different item ids and are regarded as two different

questions. One could make a test for only checking NAME (without POOL),

but then it might be the case that certain questions are not accepted

although these are different, because they have the same name.

- Statistics: so far, i have not provided any special answer

statistics for treating pool questions.

  1. … 10 more files in changeset.
minor cleanup and improved documentation

ease usage of "folder" includelet functions in other code by provide defaults

added optional link to "new" pulldown menu

    • -1
    • +2
    ./resources/prototypes/Parameter.form.page
extend/debug simplified where/unless query language

modernize idiom

use fully qualified cmd name in directdispatch