Django-monitor: CHANGE LOG
The following changes are there in **Django_monitor 0.2**:
* It lets you sub-class moderated models.
* When you delete an instance of a moderated model, the corresponding
monitor-entry automatically gets deleted.
* The admin-changelist correctly shows you the selected status in the
moderation status filter.
* The Moderation Queue shows the exact number of pending/challenged objects
the current user can view. So if you have customized the ModelAdmin.queryset
method for any model, the queue will take that into consideration.
* Fixed ``setup.py`` and added ``runtests.py``. The latter helps to run
unit-tests at the app-level itself. No need to install it into a project,
just for test. Instead, you may just run ``python runtests.py``.
* Django-monitor contained a bug that pops up when you subclass a moderated
model and enqueue that sub-class also for moderation (Ticket #1). When you
create an instance for a sub-class of any non-abstract model, django creates
corresponding parent class instances too. But no ``post_save`` signal is
emitted for any of those parent instances. Since moderation is invoked on
the ``post_save`` signal, no monitor_entry is created for any of those
parents. The CustomQueryset we use assumes that a monitor_entry will be there
for all moderated model instances. Since it can not find any for the parents,
it always return empty rows when you try to access them. Fixed by adding a
couple of lines in our ``monitor.util.save_handler`` to create monitor_entries
for all moderated parent instances as well.
* Now we have finished implementation of one more TODO things: A single place
to manage monitored objects. The model change-link, ``Moderation Queue``,
under the app, ``Monitor`` in admin-home page leads user to a page listing
the counts of pending/challenged objects for each monitored models.
* ERROR_FIX: In ``monitor.admin.has_delete_permission``, we tried to retrieve
the model class as ``self.opts.model``. It should be ``self.model``. Fixed.
* Now developers can block admin-users from deleting approved objects of
desired models. An additional parameter, ``can_delete_approved``, is added
to ``monitor.nq`` to enable this. Default value is ``True``.
* Django-monitor now generates a ``post_moderation`` signal whenever an object
is moderated. Developers can make use of this if they want to invoke some
function right after moderation. See ``docs/dev_howto.rst`` for details.
* monitor now contains one more utility function, ``get_monitor_entry``.
It will return the monitor_entry that corresponds to the given object.
* The model, ``MonitorEntry`` now supports the following public methods to
+ ``approve``, ``challenge`` and ``reset_to_pending`` to moderate objects
by code. Combining with get_monitor_entry, a developer may write: ::
my_inst = MyModel.objects.create(arg1 = 1)
# my_inst is in pending status now.
# Now it got approved.
+ ``moderate`` does the same job as above but can be used when the moderation
status is not known but stored in some variable. ::
# We want to set status of my_inst to the value stored in say, `status`.
+ ``is_approved``, ``is_challenged`` and ``is_pending`` can be used to make
sure that the desired object is in some particular moderation status. ::
* BUGFIX: There was a bug with our ``save_handler`` function which handled the
post_save moderation. Whenever an object is saved, the function would invoke
``moderate_rel_objects`` which in turn reset status of the objects and all of
its related objects to PENDING_STATUS. ``moderate_rel_objects`` should be
invoked here for newly created objects only. Fixed.
* The documentation is updated to inlcude new changes in code.