I have a multi-tenant SaaS app and I’d like to have a demo account (tenant) that prospective customers can sign in to and get a feeling for all the features.
It would have to be limited in various ways: User creation/editing would be restricted. No notification emails would be sent. The data would be reset at midnight every night.
The two ways I thought of doing it are: (1) lots (and lots) of conditionals throughout the views, controllers, etc to restrict features and redirect/inform visitors, or (2) keep a clone of the app on a separate domain with the key features restricted in the code, but talk about duplication!
I think something similar to that would benefit your app from a UX perspective vs the demo app; you want users to have the ability to save data they made as a prospective user, not direct users to two different apps, etc.
Thanks @ZombieHarvester, I do use CanCan for authorization but I was hoping to avoid using a bunch more conditionals in my code. Practically every part of the UI would need some kind of conditional to cater for, what I assume would be, less than 1% of usage of the app.
@dstrunk - that wasn’t how I was thinking the demo account would work but you raise a very good point, maybe I should do it that way.
My original thought was to have a permanent demo account that allowed the visitor to wander around and try out all the features. I had no intention for them to be able to convert the account into a real one. Content creation would be strictly limited and email notifications would be disabled.
However I could change the approach and allow a prospective customer to create their own sandboxed account, try out the features and then convert if they wanted to.
@weavermedia, if your code needs “a bunch more conditionals”, it might be a sign that its time for some refactoring to decouple stuff/make the app more modular.
Agreed @ZombieHarvester, that statement did sound a little worrying. In fact what I should’ve said was “a bunch of conditionals”.
The app is quite vanilla and the views are reasonably clear of conditionals at the moment but using CanCan to authorize for a demo account would add a whole layer of behaviour and a lot more <% if can? :update, @article %> than I would ideally like.
Refactoring to decouple & modularize just to support 1% traffic is too big a job to consider for now (sole developer ) but if we deem the demo account in the future to be that important it’s certainly the way to go.
Well, i have a multi-tenant multi role app to support. Different plans for accounts and different user roles inside accounts (making it a 2d matrix of policies), so that kind of conditionals is nothing new to me. I plan to move them from views to css/js to keep controls in pages making them invisible when needed (cleaner views and works better with caching, since i can serve same html to different roles)
Your problem whilst different seems to be confronted by the same problems devs have with rolling out new bleeding edge features to a sub group of users.
I’d imagine the easy but brittle way to achieve that would be tons of conditionals too. For that reason there are a couple of gems that handle it elegantly.
This one called rollout seems to be very popular (1300+ stars) and I think it even has a railscast too.
Whether you can use it to achieve your demo version I dont know but you could take a look under the hood to see how it avoids conditionals.
I use Devise and in my User model I have an ‘account_type’ field which is set to ‘demo’. You could use callbacks in the application controller to check if the current user account type is demo and replace your email gateway model with a one that doesn’t send notification emails.
Alternate way, Pundit has an Application level policy and you could add some code like this:
Thanks @robodisco - that gem has been on my ‘check this out’ list for a while. It looks really useful.
@Daryl - I like the idea of just swapping out the email sender, nice. If I blocked all email sending ability the other features could go more or less unmonitored since the demo account would be reset every midnight. And I like how it keeps conditionals out of the views and in the controllers where they seem (a bit) more at home.
) but if we deem the demo account in the future to be that important it’s certainly the way to go.