search

neo4j-examples / asset_portal

Asset management portal written with Ruby on Rails and Neo4j
13 stars 7 forks source link

Support moderation before publication #15

Open cheerfulstoic opened 9 years ago

asianfilm commented 9 years ago

In a blog context, you would consider the idea of "draft" and "published" assets. Is that what you mean by moderation? In a blog, there are typically hierarchies of user administration power, with "editors" being able to move an article from "draft" to "published" status. This shouts out state machine!

Related to this is the idea of "embargoed" assets, that are only visible after a certain date. I think it makes sense to build this into the Asset Portal also since you can imagine a media agency making its trailers and posters visible to the public on a certain date as part of a campaign. Even between departments.

The other way to model that is having an embargoed category of assets. But then you'd need to complicate things by having assets visible UNLESS they're in the embargoed category, which brings us to the idea of categories as exclusionary as well as inclusionary for permission tracking.

But embargoed status, like a published status, is so common for assets that I think they should be built in. A state machine for assets does make sense, but one can imagine an asset portal for scientific papers requiring more than just "draft" and "published" states, with a threshold of "votes" needed.

Perhaps this idea of moderation by more than one person isn't so unique.

Devise has an interesting plugin called devise_invitable by which users have to be approved by other members before they can sign up. And Trello has voting (optionally) built into its main assets, cards. You should be able to build a better Trello on top of Asset Portal, with card-level permissions.

cheerfulstoic commented 9 years ago

Yeah, that's basically what I mean. Making a new GraphGist portal is part of the idea here and we want to allow people to submit GraphGists publicly but we don't want just anybody posting anything to the website.

One thing that we should be constantly evaluating is: "where are the borders of this project?". It's already going to be a pretty sizable undertaking. I like the idea of embargoed assets, but we aren't aiming to make a blog/publishing platform. Hopefully the asset portal will become a Rails engine and then people can build whatever functionality they like on top of it (including, perhaps, expanding the definition of the Asset model). Hopefully the GraphGist application (using the asset portal engine) will provide a good example of how to do this.

asianfilm commented 9 years ago

Understood on the boundaries issue. As long as one can customise models that inherit from Assets to, for example, introduce a state machine to model their lifetime, your suggestion is fine.

The concept of "embargoed" isn't a simple yes/no thing. It's tied to permissions in general. Rather than modelling who has permission to read an asset, it's who has permission after which date. There is an assumed embargo date built into the system now, which is the creation date. Paid subscribers of an asset library may have access earlier than non-paying subscribers, etc.

I'm not just thinking blogs. Your book assets will have embargo dates set to when the publishers announce the publication. Amazon, for example, can show books before they're published but not before the embargo date of when the publisher announces them, which may be coordinated with other commerce websites, media releases, etc. They will have the data in-house under embargo beforehand.