I want to work on a pet project, a scenario where a user can select a plan and are able to make a number of post based on the plan they are on… Say (bronze, silver or gold). I need help on how to go about it. i will really be happy if someone can guide me through or point me towards a resource i learn from. thank you in Advance,
-
What have you done so far?
- Are you working from an existing code base, or is this something being started from scratch?
-
What do you have questions about?
If you haven’t done so already, I encourage you to completely work through the official Django tutorial and then review the documentation on querysets.
That should give you some ideas on getting started.
Ken
thank you Ken. I am starting the project from scratch and will need a mentor .i have been able to create the accounts apps with the user profile creation, update, login and logout systems functions. what next do i do. i what the user to be able to choose a plan say( tier one tier two or tier three) this will permit him to make posts a specific
number of times.
if u can be my mentor i will really love it
Ok, you’ve now identified what you want to do next -
- What Django component would let you present a page allowing a user to select a plan?
- What could you use to keep track of their selection?
Ken
i am thinking of a view that will be available to the user on login.
the the html page will have three cards(Bootstrap) for the three available options.
secondly, i am thinking of creating a model for each plan
Ok, lets explore the idea of the “model for each plan”.
What you have mentioned to me so far is that the plan is one of three different levels with a different number of posts for each level.
Is there going to be other information that’s different between them?
What I’m really getting to with this is to question whether or not you want different models for each plan, or if you just want one model that has different instances for each plan, where the instance describes what’s unique about that plan.
In addition to that then, you mentioned having a view allowing a user to select a plan. Can you list all the things you need to create that view?
i am sorry for replying late. the models will be the same the difference will only be on the subscription payment
Don’t sweat the delays - this will progress at whatever tempo you can sustain.
But to come back to my second question above - you mentioned having a view allowing a user to select a plan. What do you need to create to have that view? (Or even in a more general sense, if you’re going to create any view, what do you need to do to make it work?)
1 Like
hi ken its been a while.
i was really really sick, i had to let go of coding for some days, but i am ok now and ready to continue learning
i got your reprimand on the other post. its ok
so which should i use?
i am trying to build a web app where people register and join either the free Gold and silver membership. The number of posts that can be made by each user is depends if he is a free, gold or silver user. which method will be best to implement this. The django groups or user type.
remember that each of this users will have to log in and be able to join or change membership from there dashboard. pls your help will be really appreciated.
Groups are probably not the most effective means of handling this. (The intent and functionality of groups is that a User can be a member of multiple groups at the same time, which is not what I think you’re looking for.)
I would look at creating this using the “Profile” style of Extending the User Model. You don’t need to modify the existing model, you can create a separate model that exists with a One-to-One relationship with the User model, containing all the application-specific attributes for that User.
Ken
ok thank you.this is what i have done, i wanted to use email for the authentication so. i created a custume user model using the AbstractBaseUser.
i have also created the user profile…
class profile (models.Model):
user = models.OneToOneField(User, on_delete=models.CASCADE)
profile_image = models.ImageField(default=‘default.jpg’, upload_to = ‘profile_pics’)
date_of_birth = models.DateField(blank=True, null=True)
street = models.CharField(max_length = 100, blank = True, null=True)
city = models.CharField(max_length = 50, blank = True , null=True)
state = models.CharField(max_length = 50, blank = True, null=True)
phone = models.IntegerField ( blank = True, null=True)
zipcode = models.CharField(max_length = 8, blank = True, null=True)
country = models.CharField(max_length = 50, blank = True, null=True)
date_created = models.DateField(default=datetime.datetime.now)
def __str__(self):
return self.user.first_name + " " + self.user.last_name + " " + self.user.username
class Meta:
verbose_name_plural = 'User Profiles'
db_table = 'user_profiles'
i was now thinking of using the practical example here. How to Implement Multiple User Types with Django
Yes, that looks like a workable model as a start. (I’m not sure I would store phone number as an integer - many people are used to seeing phone numbers in a specific format, and unless you’re doing math on a phone number, there’s no reason not to store it in that format.)
However, if you are working with an international set of users, you might want to do a little more research in to how you should store an address.
For example, the full United States zip code is 9 digits. There are also multiple situations where you need two “street” lines instead of just one. (It does all really depend upon your specific needs - it’s possible that these edge cases won’t really affect you at all - but that’s a decision you should make at least knowing what the issues might be. Handling international addresses, names, and telephone numbers is hard.)
Ken
thank you . i have noted your corrections.
but there is a problem.
class User(AbstractUser):
is_free = models.BooleanField(default=False)
is_silver = models.BooleanField(default=False)
is_gold = models.BooleanField(default=False)
class Free(models.Model):
user = models.OneToOneField(User, on_delete=models.CASCADE, primary_key=True)
class Silver(models.Model):
user = models.OneToOneField(User, on_delete=models.CASCADE, primary_key=True)
it doesn’t seem to connect to my users created with (AbstractBaseUser) costume user model
what do i do
should i remove the costume user model. it seems like this tutorial has two different sign up forms. while i have already created one for my costume user model.
does this mean that i will have to remove the costume signup model (AbstractBaseModel) and its form in other to use the abstract user?
or is there a way i can use the AbstractUser with the AbstractBaseUser
Ok, this isn’t how I would recommend modelling this.
You’ve already established in your prior response that you’re going to have a profile model. Therefore, you don’t need to add anything to the User model itself - that’s the reason behind having the Profile model.
Also, my understanding is that a person can be one of “free”, “silver”, or “gold” - not more than one. If I’m right, then your Profile model associated with the membership level would more appropriately be something like:
(Note: I’m doing this strictly from memory, I have no idea what I may have wrong here - I’m just winging this at the moment.)
class Profile(models.Model):
<all the fields you defined above>
membership_level = models.ForeignKey('MembershipLevel', on_delete=models.PROTECT)
class MembershipLevel(models.Model):
level_name = models.CharField(max_length=10)
max_post_count = models.IntegerField()
<any other fields that define what makes each membership level unique such as price>
You then load the MembershipLevel table with one row for each level. From what you’ve shown so far, you’re going to have three rows, one for each of “free”, “silver”, and “gold”.
(Also note: if you see how my code is displayed above, that’s because that code is between two lines consisting only of three backtick (`) characters. That preserves the formatting of the code in the post.)
You can get by with just one sign-up form. Your view will need to create both the Profile and your User object.
If you choose to stay with your custom User object, then you want to make sure that your Profile object has the OneToOne relationship with your User object and not the system default User object. (I also strongly recommend that you don’t name your custom User object “User”. Use something different like maybe “Member” - it’ll save you a lot of confusion later on.)
Ken
thanks ken, i have been doing some things by myself . see the things i have actually achieved.
I created two additional models.
"’
membership_choices = (
('Free','free'),
('Silver','silver'),
('Gold','gold')
)
class MembershipLevel(models.Model):
slug = models.SlugField()
level_name = models.CharField(choices = membership_choices,
max_length=10,
default = ‘Free’)
max_post_count = models.IntegerField( default = 15)
price = models.CharField(max_length=10)
def __str__(self):
return self.level_name
class UserMembership(models.Model):
user = models.OneToOneField(User, on_delete=models.CASCADE)
membershiplevel = models.ForeignKey(MembershipLevel, on_delete = models.SET_NULL, null = True)
def str(self):
return self.user.email
where the UserMembership model is foreign key in the profile model
‘’’
subscription = models.ForeignKey(UserMembership, on_delete = models.SET_NULL, null = True )
‘’’
Please how can i subscribe a user to a plan when click on the subscribe button.
and restrict the number of posts
In the general case, any time you’re trying to figure out how you want to do something, there are three fundamental questions to consider that require very specific answers.
- What does the user need to do to cause this desired action to occur?
- What exactly do you want to have happen?
- What do you want the user to see when they’re done?
So looking at these questions in the context of Subscribing a user to a plan -
-
I’m going to guess that you want the user to press the subscribe button to start this process.
After they do this, is there anything else that they might need to do? (Any other form or confirmation? Even if you do, you might want to ignore that for now, but it is helpful to at least acknowledge that it’s something to be done in the future.) -
Other than just setting the UserMembership model, is there anything else that needs to be done at the time the button is pushed?
-
What is the user going to see after they’ve finished whatever process happens when they push Subscribe?
The specific and detailed answers are going to drive what needs to be done.
Your other question about restricting the number of posts is a completely separate issue. It’s not, strictly speaking, related at all to the subscription process.
If I were doing this, I would tie this in to whatever button or link the user clicks to add a post. So let’s say you have a button called “Add Post”. When a user clicks “Add Post”, you might normally take them to a page where they can add a post. What you want to add that that point is your check to see whether or not they’re eligible to add another post - but then you need to decide what’s going to happen if they’re not eligible to do so.