Sell access to resources without ACLs

[Mark-H]

The current way resources can be sold requires on creating separate user groups for each, requiring quite some insight into the MODX ACLs to use.

A better solution would be for DigitalProduct to manage what resources a user has access to, and allow access based on the presence of the secret code or a user relation. To enforce it users should then place a simple snippet on the resource that needs protecting which can either redirect away if not allowed, and/or have different chunks to either render the content or an add to cart form of sorts.

[isaacniebeling]

OH GOD YES PLEASE (but multiple resources, and maybe defining a "landing page"?) The site we've been working on currently uses ACLs and it's a nightmare. It won't be feasible for long, sooooo if this doesn't get built, I'll be looking at somehow building it within the next 6-12 months anyway.

One thing to think about: Menus. If it's a single resource, a menu isn't necessarily an issue, but for our use case, purchasers have access to a Training Home, and below that the courses they have access to (currently just one). Then, depending on which "version" of the product they purchased (all actually separate products), they have access to a document library, a "fun downloads" page ("fun" is doing a lot of heavy lifting there), potentially a control panel of sorts where they can invite their staff to sign up and take the training, and one (or two) of a few other pages.

They also have access to some profile-editing-type pages, but those can probably be controlled via "standard" ACLs, so it might be worth allowing both adding user groups and specifying additional pages.

It would also potentially be worth allowing some way to hook into that snippet for additional, custom conditions and/or allowing a "time" for how long they have access to those resources -- n days from purchase or whatever (with that, once recurring billing is handled, it'd probably need some way to "renew" their access on success).

Writing all this out, I also realized I need to have some level of access control for trainees as well; our system currently has a table where they're connected to an organization, and the org is connected to the purchaser, so we'd probably build some kind of custom snippet based on (or calling) the snippet that handles checking access. Perhaps, in that case, there'd be a way to pass in a specific user ID? That way, we could have a snippet that looks at the current user and gets the org admin's user ID, and THAT's the ID that the access snippet uses? (And again with the menuing...)