The RecurrenceWidget gives the user a unified interface for telling the system how often certain events occur.
In general recurrences are stored in the recur table, but this is not required. Two basic values describe a recurrence:
-
The period is the time unit of measure (hour, day, month).
-
The frequency is the number of periods between recurrences.
A recurrence with the period set to W (= week) and frequency of 3 will repeat once every three weeks.
To add a new kind of recurring event or item, you need to change data in the database, stored procedures, triggers, and application code. We'll use Invoice in the examples here, with 'I' as the internal code value, even though invoices already use this mechanism (xTuple ERP 3.5.1 and later).
Add a column to the parent table to track the recurrence parent/child relationship. The column name must follow this pattern: invchead_recurring_invchead_id :
ALTER TABLE invchead ADD COLUMN invchead_recurring_invchead_id INTEGER;
COMMENT ON COLUMN invchead.invchead_recurring_invchead_id IS 'The first invchead record in the series if this is a recurring Invoice. If the invchead_recurring_invchead_id is the same as the invchead_id, this record is the first in the series.';
Add a RecurrenceWidget to the .ui for the window that will maintain data of this type (e.g. invoice.ui).
Initialize the widget in the window's constructor:
_recur->setParent(-1, 'I');
Update the widget again when the window gets an id for the object. This usually happens in either the set(), save(), or sSave() method for new objects, depending on the class, and in populate() when editing existing objects:
_recur->setParent(_invcheadid, 'I');
...
_recur->setParent(q.value("invchead_recurring_invchead_id").toInt(), "I");
Ask the user how to handle existing recurrences before saving the data and before starting a transaction. getChangePolicy will return RecurrenceWidget::NoPolicy) if the user chooses to cancel. Then when preparing to insert or update the main record, make sure to set the recurrence parentage. Finally, after the insert/update, save the recurrence and check for errors:
{
RecurrenceWidget::ChangePolicy cp = _recur->getChangePolicy();
return false;
XSqlQuery beginq("BEGIN;");
XSqlQuery qry;
...
if (_recur->isRecurring())
qry.bindValue(":invchead_recurring_invchead_id", _recur->parentId());
...
...
QString errmsg;
if (! _recur->save(true, cp, &errmsg))
{
rollbackq.exec();
return false;
}
...
XSqlQuery commitq("COMMIT;");
return true;
}
To maintain the recurrence relationships, there must be a function that copies an existing record based on its id and gives the copy a different timestamp or date. It must have a function signature like one of these:
-
copy[tablename](INTEGER, TIMESTAMP WITH TIME ZONE)
-
copy[tablename](INTEGER, TIMESTAMP WITHOUT TIME ZONE)
-
copy[tablename](INTEGER, DATE)
The copy function can take additional arguments as well, but they will be ignored by the recurrence maintenance functions. The data type of each argument must be listed in the recurtype table's recurtype_copyargs column (see below) so the appropriate casting can be done for the date or timestamp and an appropriate number of NULL arguments can be passed. The copy function must copy the
There can be a function to delete records of this type as well. If there is one, it must accept a single integer id of the record to delete.
Add a row to the recurtype table to describe how the recurrence stored procedures interact with the events/items of this type ('I' == Invoice).
INSERT INTO recurtype (recurtype_type, recurtype_table, recurtype_donecheck,
recurtype_schedcol, recurtype_limit,
recurtype_copyfunc, recurtype_copyargs, recurtype_delfunc
) VALUES ('I', 'invchead', 'invchead_posted',
'invchead_invcdate', NULL,
'copyinvoice', '{integer,date}', 'deleteinvoice');
If there isn't a delete function, set the recurtype_delfunc to NULL. Existing records will be deleted when necessary with an SQL DELETE statement.
The DELETE trigger on the table should clean up the recurrence information:
CREATE OR REPLACE FUNCTION _invcheadBeforeTrigger() RETURNS "trigger" AS $$
DECLARE
_recurid INTEGER;
_newparentid INTEGER;
BEGIN
IF (TG_OP = 'DELETE') THEN
-- after other stuff not having to do with recurrence
SELECT recur_id INTO _recurid
FROM recur
WHERE ((recur_parent_id=OLD.invchead_id)
AND (recur_parent_type='I'));
IF (_recurid IS NOT NULL) THEN
SELECT invchead_id INTO _newparentid
FROM invchead
WHERE ((invchead_recurring_invchead_id=OLD.invchead_id)
AND (invchead_id!=OLD.invchead_id))
ORDER BY invchead_invcdate
LIMIT 1;
IF (_newparentid IS NULL) THEN
DELETE FROM recur WHERE recur_id=_recurid;
ELSE
UPDATE recur SET recur_parent_id=_newparentid
WHERE recur_id=_recurid;
UPDATE invchead SET invchead_recurring_invchead_id=_newparentid
WHERE invchead_recurring_invchead_id=OLD.invchead_id
AND invchead_id!=OLD.invchead_id;
END IF;
END IF;
RETURN OLD;
END IF;
RETURN NEW;
END;
$$ LANGUAGE 'plpgsql';
- Todo:
- Simplify this so the developer of a new recurring item/event doesn't have to work so hard. There should be a way to (1) have the recurrence widget update the [tablename]_recurring_[tablename]_id column when saving the recurrence (this would save a couple of lines) and (2) there should be a way to simplify or eliminate the code in the DELETE triggers. Some of this stuff really belongs in an AFTER trigger instead of a before trigger.
- See also
- _invcheadBeforeTrigger
-
copyInvoice
-
createRecurringItems
-
deleteInvoice
-
deleteOpenRecurringItems
-
invoice
-
openRecurringItems
-
recur
-
recurtype
-
splitRecurrence
Public Member Functions inherited from Ui_RecurrenceWidget