a customer is interested in a solution that protocols whether certain documents in a plone intranet have been read by certain users.
maybe someone reading this knows if there are existing addons that mostly fulfill this task or can be used to build upon.
functionality should be:
invite users to read a document within 5 (configurable) days (based on role/group, maybe separate window to select from portal users)
store invitation date and users on this document (or separate database) (collective.watcherlist?, ??)
email users that they should read this document (can be done with content rules mailtogroup/role)
email users with open invitations after 4 days that only one day is left (cronjob, script)
email admin which invitations have been ignored (overdue invitations - cronjob)
view on the object that lists status of all invitations (read and unread with invitation and reading date)
i think marking as read is best done by the users explicitly (button "mark as read") (otherwhise it's hard to tell if the whole file was downloaded by the user)
(fire event that marks invitations as read. maybe also write entry to collective.auditlog / collective.fingerpointing)
If you are willing to write a relatively simple add-on (some views, a viewlet, a few persistent utility setup handlers, and some runscripts for cron), you could use this as a storage mechanism:
Big disclaimer: this only stores/indexes named principal-to-content relationships, not dates. Advantages:
(1) not tied to only PAS users, should you want to invite unauthenticated users;
(2) Handles token (hash of relationship signature) generation and token-to-user storage for use in your emailed links.
(3) If you want to bolt dates on to this, I would suggest storing a BTree/mapping of keys/tokens to datetime objects for invite/expiry time(s).
If you are constraining this to only users with logins and authentication, Z2.log could have what you make this a post request, put something in the URL to identify, and use:
If your use case is unauthenticated users submitting a form (e.g. mark as read button), using collective.subscribe to store a "has read" relationship would be easy enough.
If you used collective.subscribe for storage, you would store the following person-to-content relationships:
invited (marked as such).
emailed (email was actually sent).
read (user marked item as read with button).
If you build on collective.subscribe, you could write this as an add-on with (a) registrations for collective.subscribe (example: collective.inviting uses setuphandlers to install local, persistent utilities); (b) browser views (invitation, form handler for marking, and a viewlet for your button below content); (c) cron jobs for sending mail.
It's hard to say if it is a good fit for your requirement (specifically because it depends on the nature of the documents), but you may want to have a look at Plomino for this.
If it is a good fit, implementing the business logic that you describe against Plomino documents would be very simple.
Both could work, but Rapido would be more accurate than Plomino on that case (Rapido works better when it is about to integrate custom features with Plone base features).
as we're running a std. plone 4.3 intranet i don't think plomino/rapido is the best fit.
asked the ploneintranet people and will look at the addons you suggested above to see if the help me save time/money.
@frisi doesn't handle you whole usecase but I've used this as part of similar solutions - https://github.com/collective/redomino.tokenrole. It handles the ability to have temporary unique links to view objects. Adding the ability to record if an invitation has been "used" into token role might be a nice feature.
If by "read" status of an invitation, you mean tracking email opening, I'd recommend sendgrid. Actually that's probably a better way to track clicks on links too. We've integrated sendgrid tracking reports into plone before. Code is very old though.