FEATURE: Seeding Plans should set the choice of plans on the home page

[nikolay12]

I changed the plans in the database yet the view does not change. This is not DRY.

[DanielKehoe]

Keep in mind that the application is designed to accommodate plans and permissions that don't have a one-to-one correspondence. For example, there can be a role for an administrator who doesn't have a plan at all.

Please provide more details so I can reproduce the issue. Did you log in as admin? Where did you change the user's plan? In the Upmin Admin panel?

[nikolay12]

A foreign key does not have to be NOT NULL. A User model just needs a reference to the Plan model. The problem is that currently the Plans are hard-coded at 3 different places in the code base - the db seed routine, the User model and the Visitor View. A fourth place they appear in is the Stripe account. I am OK with having a local copy of the Stripe Plan Table but 3 codebase copies is a bit too much.

[DanielKehoe]

The initial values for Plans are seeded in the _create_planservice.rb file.

It suppose you could add code to the _create_planservice.rb file to use the Stripe API to configure the plans for Stripe, however it is a one-time configuration so I don't believe it's worth the effort to add code to automate it.

In the User model, the enum role: [:user, :admin, :silver, :gold, :platinum] are actually roles for access control, not Plans. They happen to correspond to Plans in the example, but that is didactic, the roles could be given different names and don't have to match Plans.

In the Visitor index view, on the price matrix, the names of plans are hard-coded and passed as parameters to the sign-up form. You could implement the price matrix as a select box and populate from the database if you want.

I appreciate your interest in improving the application to make it useful for more developers and follow best practices. I don't see there is an issue here, though. Perhaps you could fork and show a better implementation? This is open source, after all, and sometimes contributing code makes a better implementation more obvious.

[DanielKehoe]

@nikolay12 it would be helpful to me if you could say whether there is an actual problem with the application not working as expected. You said:

I changed the plans in the database yet the view does not change.

It's not clear to me how you changed the plans and how the application failed. What steps can I take to reproduce the failure? Was there a failure, or are you simply suggesting a change to the architecture for best practices?

[nikolay12]

I somehow assumed that initialising the Plan Table would have populated the corresponding View. Instead, the View is hard-coded. But you can regard this just as a feature suggestion so, please, feel free to close the issue.

[DanielKehoe]

Thanks for the clarification. Keep in mind that these are example applications and starter applications. My intent is to provide basic functionality with the simplest possible code, so it is easy to grasp the principles.

[nikolay12]

I'm quoting here one of your earlier replies: "It suppose you could add code to the create_plan_service.rb file to use the Stripe API to configure the plans for Stripe, however it is a one-time configuration so I don't believe it's worth the effort to add code to automate it."

Daniel - this is what the code actually does. I reckon the payola gem uses the Stripe API to populate the plans as the plans are created in Stripe if they don't exist under these IDs. So your tutorial is not accurate inasmuch as creating the plans in Stripe manually is redundant once you have set them up in create_plan_service.rb. Thus the codebase is, actually, somewhat DRYer than either of us thought.

There is, however, one minor point - the currency set up by create_plan_service.rb in its current incarnation is the US dollar. Whereas setting the plans manually in Stripe allows you to use a different currency.