• last updated 13 hours ago
Constraints
Constraints: committers
 
Constraints: files
Constraints: dates
Remove wrong first argument

set the displayed_object_id to the forum_id for edit operations

    • -0
    • +1
    /openacs-4/packages/forums/www/message-post.adp
Use package_id as "displayed_object_id" for "item-create" and "revision-add"

    • -0
    • +1
    /openacs-4/packages/news/www/item-create.adp
Improve robustness, when no displayed_object_id is given

CKEditor Reform

- Add basic support for the standard "filebrowser" plugin,

which is part of all CKEditor presets

- The filebrowser plugin supports image uploads to the server and

to browse/select images already attached to this object

(based on displayed_object_id)

- Bump version number to 0.13

reduce verbosity

    • -2
    • +2
    /openacs-4/packages/xowf/tcl/xowf-procs.tcl
Cleanup of yesterdays changes (based on experiences with learn@wu)

    • -123
    • +171
    /openacs-4/packages/xowf/tcl/xowf-procs.tcl
Add safety belt in case the page_template is not instantiated

    • -2
    • +8
    /openacs-4/packages/xowiki/tcl/xowiki-procs.tcl
Whitespace changes

    • -96
    • +96
    /openacs-4/packages/xowf/tcl/xowf-procs.tcl
add missing file

Shared Workflow Definitions (Part 2)

When shared workflow definition are used, a different management of

object specific code is necessary, since one definition seves for many

objects, and it is not freshly created per object. Therefore, a new

concept is introduced for workflow definitions, named "object-specifc"

Instead of writing in a workflow definition

Action save

state initial -actions {save}

[my object] proc foo {} { ns_log notice "===foo==="}

one has to write now:

Action save

state initial -actions {save}

:object-specific {

:proc foo {} { ns_log notice "===foo==="}

}

where the object-specific is evaluated once per request for every

involved workflow instance in the context of the object (a [self]

in this block refers to the object).

In case a [my object] is encountered and sharedWorkflowDefinition is

activated, a warning is produced and the code falls back to old-style

shared workflow definitions.

    • -145
    • +279
    /openacs-4/packages/xowf/tcl/xowf-procs.tcl
    • -7
    • +3
    /openacs-4/packages/xowf/www/index.vuh
Major overhaul of the CKEditor support

- support for ckfinder interface "imageUploadUrl"

(as used in the "uploadimage" plugin)

- Improved configurability through config files

Small improvement for portrait management (deletion)

Exploit existing on delete cascade constraints when we delete a portrait, instead of deleting stuff manually.

Also, put remaining logics into a proc and use it in acs_user::delete to address legit use case of people wanting

to remove a user permanently without removing portrait in advance.

fix: make sure to pass displayed_object_id always to the next master template

fix: make sure to pass displayed_object_id always to the next master template

Turn off shared workflow definition as indicated in the last message

    • -1
    • +1
    /openacs-4/packages/xowf/tcl/xowf-procs.tcl
Add Feature: Shared Workflow Definitions

Background: so far, xowf stored workflow definitions in the workflow

context, which is generated for every instantiated workflow instance

due to the needs of the State Pattern. While the old approach works

perfectly fine, when pre request only one or a few workflow instances

are created, but is inefficient, when e.g. 100 or more instances of

the workflow definition are created.

Now, the instances can share the definition, which is shared based on

the revision_id of the workflow FormPage.

OLD: obj <-> obj::wf_ctx

NEW: obj <-> obj::wf_ctx <(n)----> wf_definition

OLD scenario:

- the wf_definition was part of the context (no distinction)

- navigation from wf_ctx (and wf_definition) to object was possible

via "info parent"

NEW scenario:

- the wf_definition is separate

- one wf_definition can be used for multiple wf_ctx

- new methods are required instead of "info parent"

to navigate between these cooperating objects

* xowf::WorkflowPage.wf_context

* xowf::WorkflowConstruct.wf_context

* xowf::Context.wf_container

The navigation from a WorkflowConstruct (e.g. State) to the wf_ctx

is slow and fragile if not following usual programming conventions

and should e avoided (the methods of these constructs have the obj

passed in, so this path should not be necessary in most situations)

- as long the contents of the wf_container is constant, it can be

shared in the per-thread cache.

For now, the new feature is turned off by default via variable

::xowf::sharedWorkflowDefinition, but this will change in the future.

    • -8
    • +8
    /openacs-4/packages/xowf/lib/online-exam.wf
    • -190
    • +318
    /openacs-4/packages/xowf/tcl/xowf-procs.tcl
    • -4
    • +8
    /openacs-4/packages/xowf/www/index.vuh
Make so that refreshing of theming subsite parameters doesn't include locally modified subsites

This includes also moving of logic to identify local modifications in a proc

Regenerate ADP files

Add feature: overwrite generated ADP files only when necessary

Cases might be:

- ADP file list

- Generator updated

Fix: close link target (<a name ...>); backport from HEAD

Fix: close link target (<a name ...>)

Added procs to quickly issue refresh of subsite theme parameters from current theme defaults. This is useful in a context with many subsites using the same theme, when desired behavior at upgrade is to have them reload all parameters automatically.

Fix typo

Remove dependency on calender for message-key

merged changes from the oacs-5-9 branch and resolved conflicts

    • -0
    • +289
    /openacs-4/Announce-OpenACS-5.9.0
    • -0
    • +511
    /openacs-4/Announce-OpenACS-5.9.1
    • -36687
    • +221521
    /openacs-4/ChangeLog
  1. … 7820 more files in changeset.
undo untested last minute check

Fix typo

Flush cache also for ancestors of nodes when mounting a package

Unify version comparison logics so we always use apm_version_names_compare instead of other db api as apm_package_version__version_name_greater plus handcrafted queries which also might behave slightly differently