Allow multiple levels of Premium content

I, too, would definitely like to see multiple levels of Premium. I'm currently working on a site that needs three levels of access -- one for anonymous users, one for authenticated users (not assigned to any other role), and one for paid subscribers.

Node Option Premium is great for creating the distinction needed between level 1 and level 2 ... but it's level 3 that has me worried. It would be great to have another level of Premium for the paid subscribers; that would solve so many problems!

As would being able to associate Premium with certain Taxonomy terms; we have a need for that on our site, too.

I am just in the process of developing a magazine site which has the same requirement (i.e. one for anonymous users, one for authenticated users, and one for paid subscribers), so would find such an enhancement really useful.

That said, even as it stands I think this is a really useful module, especially the facility to manage access at individual node level rather than simply at content level as is the case I believe with the 'Premium' module. So despite my comments on the enhancement, many thanks to anrikun for the module to date.

I have just marked #1128770: Allow multiple levels of Premium content as a duplicate of this issue.

I do think Multiple levels should be added too.
This should not be tied to taxonomy by itself but the module should provide everything necessary (whether hooks or Rules actions & triggers) so that it is possible to achieve association with taxonomy terms, using Rules or a sub-module.

Currently, nopremium manages a $node->premium property that can be 0 (non-premium) or 1 (premium).
It should not be difficult to manage greater values (up to 9).

The default behaviour would be that any user who has access to a premium N full content could also access premium < N full contents.

Node Option Premium's last release is only 2 weeks ago and I need to spend time on other modules (starting by CKEditor Link 6.x-2.x). So I don't think I will work on this feature before 1 month or so.

If you want to work on this (Mikl?) in the meantime, you're welcome!

Subscribing.

Reviewing the current architecture of nopremium module, I am leaning to the conclusion that it'll be better to continue the Premium codebase instead.

Altering the node table is not the way to go, in my opinion, and Premium already has more features, like scheduling. I hope to get maintainership of the Premium module as per #1119168: Premium has been forked.. If this fails, I intend to promote my sandbox fork to a real project: http://drupal.org/sandbox/mikl/1078824

Altering the node table is, in this case, the best way to ensure maximum integration with core as premium is just an extra node option, like status, promoted and sticky. There is nothing bad about adding a single field to an existing table: that is what hook_schema_alter() is here for. And if you decide to uninstall the module, the premium field is cleanly removed.

I totally disagree with you when you say that Premium has already more features. Please read the project page again: almost none of the features listed on it are in Premium: per node type access, CCK, Rules, Views, etc.
And about scheduling, this can be easily done through Rules scheduler (this is stated on the project page too).

To finish, you will notice that Node Option Premium has 6.x and 7.x versions, and 0 bug reports so far.

Feel free to create a different project if you prefer. There is no problem about that. After all, that's what I did!

Well, the same integration could be provided just as well by having an external table, like premium does. If all module developers altered core tables willy-nilly, Drupal would be a mess.

While the work you've put into this is laudable, I find it regrettable that you decided to change the underlying model for the module, especially given that the new model you have chosen is less flexible, and makes it a lot harder to do what I have done in my fork of Premium, namely multiple configurable levels with CTools export support.

I wish we could work on this together, but hacking core tables is not my idea of fun.

Thanks @mikl for noticing this module hacks the node table! Clearly not a module to be touched even with a very long pole. @anrikun, please take the advice offered in this thread.

@berenddeboer, @mikl: Adding a field to an existing table through hook_schema_alter() is not a hack!

Read http://api.drupal.org/api/drupal/modules--system--system.api.php/functio... and have a look at the provided official example from modules/system/system.api.php: it adds a custom field to the core users table.

Another example: the i18ntaxonomy sub-module (part of the Internationalization module, reported to be used by more than 35,000 sites) adds several extra fields to taxonomy_vocabulary and taxonomy_term_data, both core tables. (@berenddeboer: I suggest you post an issue in Internationalization's issue queue too to ask users to keep away from that module!)

To finish, you should notice that so far Node Option Premium has 0 bugs reported.

@anrikun, obviously an example has to use a table that exists in core right? I think it doesn't imply hacking core tables is the way to go.

And that the internationalization module does it, does not mean it's OK in every other case.

I was just offering a bit of advice. I don't think any Drupal site builder expects that a third party module changes core data tables, so a bit of warning is in order.

although many modules (i18n, uuid, etc) do alter existing tables a better approach would likely be to create your own table related through nid (or vid). imho. :)

i need the functionality of multiple levels of premium content so will be checking this module out as well as the Premium Content module (which i hope when ported from D6 Premium module started with the numerous improvements i added to that module here: #642392: full node access control, hide cck fields, multiple roles and msg per role)