parameters. The first allows the specification of a task name.
Non-maintenance tasks are not defined as part of availabl_tasks so we
can't get the name from the task definitions. The 2nd allows the
specification of a context when the task is completed.
Don't join through to the users table; that won't work in embedded
mode. Instead, add Tasks_Model::owner() that calls user::lookup() and
refer to the object directly in the view.
Add Admin_Maintenance:remove_finished_tasks() so that we can easily do
old task cleanup.
Hide Running / Finished sections if there aren't any running or
finished tasks.
them a nice "Welcome to Gallery 3" dialog. The text in there needs a
little work but it's a start.
In the process, re-build the install.sql using the scaffolding code.
batch::start() before starting a series of events, and batch::stop()
when you're done.
In batch mode, the notification module will store up pending
notifications. When the batch job is complete, it'll send a single
digested email to each user for all of her notifications.
Updated the scaffold and local_import to use this. Haven't modified
SimpleUploader yet.
when the hooks are run, we haven't added all the installed modules to
the path, So if a module defines a hook it will never be run.
This change runs any module defined hooks as part of the gallery initialization.
Starting a batch call batch::operation(name, item). In the case of
adding photos name = add and item is the parent of the new items.
When the operation is finished the batch::end_operation(name) is
called.
operation and end_operation events are called. Handlers
(i.e. item_created) can call batch::in_progress(name) to determine if
a batch is being processed.
start_batch and end_batch add and remove the batch id from the
session. Modules wishing to do batch processing, just need to fire
the start_batch and end_batch events. Other modules that need to be
aware of batches (i.e. notifications) just check the session for "batch_id".
events: start_add_batch and end_add_batch. The parameter is a batch
id which is generated on the first add request. The protocol is call
the add_photo as many times as required and then call finish when
done.
Also renamed the add method in local_import to add_photo so it is
consistent with simple_uploader
task.php
* Added a owner_id field to the task database
* Modified the admin maintenace to show the owner of the task
<<**** Requires a reinstallation of core ****>>
working through setting up the database access to support table
prefixes. (Ticket#68)
Before going ahead, just wanted to check this approach... whatcha think?
Tim Almdal
Bharat Mediratta
Chris Kelly
Chad Kieffer