-
Notifications
You must be signed in to change notification settings - Fork 121
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Feature Idea: Multiple types of 'read' #59
Comments
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 In addition, I see some other potential naming conflicts, e.g. the name of this gem and the methods P.S.: Great quote, btw... :-) |
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.
The text was updated successfully, but these errors were encountered: