Package: collective.mustread
Track reads on content objects in Plone.FeaturesMark objects as must-readKeep a record of first reads of content objects per userQuery if a specific user has read a specific content objectList top-x of content objects by user reads in a specific time windowCompatibilityPlone 5.2 and Plone 5.1 users should use version 2.x of collective.mustread.
Plone 5.0 users should use version 1.x of collective.mustread.LimitationsThis is not a install-and-forget plugin for Plone.This productdoes not track reads out of the box.
It merely provides a backend you can use for doing so.Development of this backend was sponsored by Quaive.
Quaive has it’s own frontend integration on top of this backend to cater for the specific use cases Quaive needs. We hope that this generic backend is useful for other Plone projects as well.RationaleIf you’d want a naive implementation to track reads, you could simply
create a behavior that stores a list of user ids on every content object.Obviously that would soon destroy your site with database writes.Instead, this backend is designed to:Be compatible with async scheduling, even if it does not provide async itself.Be flexible to support multiple policy scenarios, without having to rewrite or fork the whole backend.Use a pluggable SQL backend instead of the ZODB, both to offload writes and to make it easier to run reporting queries.ArchitectureYou’re forgiven for thinking the architecture below is overly complex.
Please see the rationale above.Not included incollective.mustreadis the frontend and async part:[ user browser ]  -> [ view ] -> [ async queue  ]The backend implementation in this package provides the following:[ @@mustread-hit ] -> [behavior] -> [database store]Let’s narrate that starting at the database end.DatabaseThe database storage provides a rich API as specified incollective.mustread.interfaces.ITracker.By default collective.mustread writes to an in-memory sqlite database.
Data will be lost on zope-server restarts.To persist your data you can use a sqlite-database-file.Either call the@@init-mustread-dbview (to create a sqlite db located in BUILDOUT/var/mustread.db)or set up your database path manually in the registry and call the@@init-mustread-dbview after that
( e.g. to share it with other addons - seeAuditlog compatibility)Auditlog compatibilityIf you’re runningcollective.auditlogon your site, you might consider using the same database (so you only need one active database-connector)The SQL store is derived from thecollective.auditlogimplementation.
We’ve designedcollective.mustreadto be compatible withcollective.auditlogto the point where we’ll even re-use the database connector from auditlog if possible.The database connection is configured via a registry recordcollective.mustread.interfaces.IMustReadSettings. You typically want this to contain the same value as your auditlog configuration.Make sure to call@@init-mustread-dbto create the necessary tables/columns needed by this package in the database.BehaviorsWe provide two behaviors:collective.mustread.maybe_must_readbasically only provides a checkbox where you can specify whether a content object is ‘must-read’.collective.mustread.track_read_enabledactivates view tracking on a content object. We track views even ifIMaybeMustReaddoes not mark the object as ‘must-read’. The reason for this is we’d like to track popular content even if the items are not compulsory.You’d typically activate both these behaviors on the content types you’d like to track.These behaviors are not activated by default - the:defaultinstall profile only provides a browser layer and configures the database connector. It’s up to you to choose and implement your tracking policy in your own projects.The behaviors provide a flex point where you can implement different tracking policies. You could create a behavior that only tracks reads for certain groups of users for example. You can easily do that by creating a new behavior in a few lines of code, with some extra business logic, which then re-uses our extensive read tracking API for the heavy lifting.ViewA helper view@@mustread-hitis available for allITrackReadEnabledMarkeri.e. all objects with thecollective.mustread.track_read_enabledbehavior activated. Hitting that view will store a read record in the database for the content object.In Quaive we will hit this view from our async stack.You could conceivably, instead of this view, provide a viewlet that accesses the tracking behavior and API. Just be aware that doing all of that full sync is a risk. YMMV.There’s also a special debugging view@@mustread-hasreadwhich will tell you whether the user you’re logged in as, has read the object you’re calling this view on.InstallationInstall collective.mustread by adding it to your buildout:[buildout]

...

eggs =
    collective.mustreadand then runningbin/buildoutOr use the built-in buildout:virtualenv .
bin/pip install -r requirements.txt
bin/buildout bootstrap
bin/buildoutUsing collective.mustreadThe minimal steps required to actually usecollective.mustreadin your own project:Installcollective.mustreadand configure a database connector. The default connector is a in-memory database which is not suitable for production.Activate thecollective.mustread.maybe_must_readandcollective.mustread.track_read_enabledbehaviors on the content types you’d like to track, via GenericSetup. Or roll your own custom behaviors.For these content types, hit${context/absolute_url}/@@mustread-hitwhen viewing the content. Ideally you’ll use some kind of async queue at this stage.Use the tracker API to query the database and adjust your own browser views based on your own business logic. The recommended way to obtain the tracker is:from collective.mustread.interfaces import ITracker
from zope.component import getUtility

tracker = getUtility(ITracker)ContributeIssue Tracker:https://github.com/collective/collective.mustread/issuesSource Code:https://github.com/collective/collective.mustreadSupportIf you are having issues, please let us know via the issue tracker.LicenseThe project is licensed under the GPLv2.ContributorsGuido A.J. Stevens,guido.stevens@cosent.netHarald Friessnegger,harald@webmeisterei.comChangelog2.2.1 (2023-06-06)Remove deprecated code.2.2.0 (2022-10-04)Make the test pass on Plone62.1.0 (2022-08-05)Added a newget_most_read_querymethod to the tracker to help integrators
Refs. #17
[ale-rt]2.0.2 (2021-06-28)Fix a deprecation warning [ale-rt]2.0.1 (2021-05-20)Themost_readmethod does not break when trying to fetch objects
that the user cannot view. Fixes #14 [ale-rt]2.0.0 (2020-01-27)Indicate end of database initialization in logs [thet]Support Plone 5.2 and Python2.7, Python 3.6 and Python 3.7 [ale-rt, thet]1.1.1 (2019-03-25)Do not break on the upgrade step that adds columns to the mustread table
[ale-rt]1.1.0 (2017-05-11)Added the possibility to specify engine parameters through the registry
[ale-rt]remove unneeded columns in ORM model (site_name, title, info) [fRiSi]Implemented API for scheduling items as must-read for certain users.
(see collective.contentrules.mustread for usage)This required new database columns. The provided upgrade step works for sqlite databases
but might need changes for mysql or postgres. [fRiSi]Allow to create and configure a database file by using the@@init-mustread-dbview
[fRiSI]1.0.1 (2016-12-28)Provide verbose error logging when database is not accessible [gyst]Trivial testing change [gyst]1.0 (2016-11-24)Initial release.
[gyst]