• last updated 18 hours ago
Constraints
Constraints: committers
 
Constraints: files
Constraints: dates
fix typo

Move test from acs-kernel to acs-tcl, add remarks

Fix typo

Bring the logics to parse a datetime from lc_time_fmt into an own private utility lc_datetime_to_clock and reuse it also when we convert from one timezone to another

Test cornercase encountered in practice: a user claims a timezone different to that of the system and creates a calendar item in various formats

This test currently fails, because when we convert the time between the user and the system timezone, we are too strict and allow only the "long" timestamp format "%Y-%m-%d %H:%M:%S"

Allow also dates in the "short" time format, as they may be supplied to the api in such form e.g. by the calendar package

Fixes lang_test__lc_procs automated test

Extend test suite to check that also dates in the "short" time format are supported

This test will fail

Extend test cases

Assume a cal_item is also an acs_object

Qualify source tables in query

Extend testing of data validation

removed obsolete code

update CDN source

The previous CDN site stopped working

generalized handling of error pages in disconnected stage

    • -12
    • +8
    /openacs-4/packages/xowiki/tcl/package-procs.tcl
Cleanup leftover library: latest javascript assumes XMLHttpRequest is supported

Reimplementation of the captcha

We drop the previous awkward implementations that would either not scale or require external dependencies. Instead, we adopt the approach in use at https://fossil-scm.org/, where a random string is converted to an ASCII art.

The ASCII art itself comes from the Fossil source code.

    • -13
    • +10
    /openacs-4/packages/captcha/captcha.info
    • -202
    • +343
    /openacs-4/packages/captcha/tcl/captcha-procs.tcl
Fix selector for the click all list callback

Chat reform

The goal of these changes is to reduce the "mode" specific javascript code in the chat implementation and reduce server-side guessing of browser capabilities.

- In the MessageRelay class from xotcl-core, we rework the javascript code sent to the connection when doing scripted streaming to make less assumptions about the functions defined in the parent scope

- In the chat code from xowiki, we move most of the logics to guess the mode into javascript, where we can test the actual capabilities of the browser without relying on the user agent

- The previously 4 javascript files dependant on the chat mode have been made into one

    • -3
    • +3
    /openacs-4/packages/xowiki/xowiki.info
    • -112
    • +17
    /openacs-4/packages/xowiki/tcl/chat-procs.tcl
When the mode is "streaming", use Server Sent Events instead of a "plain" endless request

This has the advantage of a clearer, less hacky api, which, for instance, does not require manual parsing of the partial response.

    • -3
    • +3
    /openacs-4/packages/xowiki/xowiki.info
    • -10
    • +9
    /openacs-4/packages/xowiki/tcl/chat-procs.tcl
Cleanup leftover method: its logics were moved to the MessageRelay class

    • -15
    • +1
    /openacs-4/packages/xowiki/tcl/chat-procs.tcl
Prefer portable idiom

Replace deprecated idiom

Reduce divergency between Oracle and Postgres codebase

Cleanup long deactivated code

Fix typo

Improve documentation

Cleanuo commented code

Whitespace cleanup

Move custom calendar widget javascript implementation out of the core.js and into a separate file

In core/maintained packages, this widget is used only by template::widget::textdate (which in turn is used nowhere). For this widget, we can include the relevant code on-demand.

Direct usages found in unsupported packages have been adapted by adding the extra requirement on the fly.

It is unclear if we should keep maintaining a calendar widget in our codebase, however, as the current one still works (kudos to the original author), we do not deprecate it for the time being.

It is also true that a custom widget provides a way to customize the look and feel of date fields, which is otherwise completely delegated to the browser.

Various packages, including the core, provide custom css styling for the current widget.

Move custom calendar widget javascript implementation out of the core.js and into a separate file

In core/maintained packages, this widget is used only by template::widget::textdate (which in turn is used nowhere). For this widget, we can include the relevant code on-demand.

Direct usages found in unsupported packages have been adapted by adding the extra requirement on the fly.

It is unclear if we should keep maintaining a calendar widget in our codebase, however, as the current one still works (kudos to the original author), we do not deprecate it for the time being.

It is also true that a custom widget provides a way to customize the look and feel of date fields, which is otherwise completely delegated to the browser.

Various packages, including the core, provide custom css styling for the current widget.

  1. … 3 more files in changeset.