Feature Idea: Multiple types of 'read'

[smudge]

Let me start by quoting the fish shell docs and state that, since "configurability is the root of all evil," I am knowingly proposing something that might seem a bit evil.

That said, I think it would be really useful to have different types of "read" state. The use case I have in mind is the ability to mark records as having been viewed on the index action, as opposed to having been actually clicked and opened. (i.e. distinguishing between records that have never been seen in any form, vs records that haven't yet been 'read' in full)

Another use case could be for records that go out in a digest email -- marking records as 'emailed' ensures that the same records won't be included in the next digest. This allows for more flexible scheduling of such emails (for instance, sending an email as soon as 10 records exist that haven't been 'emailed').

So, in short, different types of read -- 'read', 'seen', 'emailed', 'viewed', etc -- all powered by the same underlying infrastructure of tracking and marking elements as having been verbed at a specific timestamp by (or to) a specific user.

The schema changes would probably involve adding a read_type column which would default to 'read', and then updating the queries so that they search by a specified read type (also defaulting to 'read'). So the defaults would cause the gem to behave exactly as it does now.

I am actually quite happy to work on a pull request, but I thought I'd field the idea first.

[ledermann]

Nice idea, I like it. But remember that the database model of this gem is based on the assumption, that the goal is something like inbox zero: In the long run, every user should read all the records. This keeps the table of read markers small, which is important for performance.

But if someone uses your enhancement to manage emailed records but there is no goal to email all records, this gem wouldn't be suitable.

We should keep this assumption in sight. Nevertheless: If you want to add this feature, I would be happy to merge your pull request.

In addition of your use cases I see reading vs. archiving: The records first have to be read, later they will be archived. In the long run: All of them.

Regarding the table attribute to be added: It should not be named read_type, because attributes ending with _type are mostly used for polymorphic associations. Maybe verb, action or activity (perhaps prefixed with read_) are candidates for a good name.

In addition, I see some other potential naming conflicts, e.g. the name of this gem and the methods act_as_reader and acts_as_readable. Don't know how to solve this, yet.

P.S.: Great quote, btw... :-)