D
D
dr sbtn2016-05-14 17:33:59
Django
dr sbtn, 2016-05-14 17:33:59

What should be my algorithm of actions when developing a site?

Trial project.
site where users will add lyrics.
Access will be carried out depending on the role of the user: unregistered (they can only see a list of songs on the site that have already been filled in by someone), registered ones (they can add their own compositions - more precisely, "form" the name of the song, artist, drive in the text), moderators (actions of registered users + can make changes to what was added by another user), admin (can do everything - change, delete such entries ..)
(identification and authentication, as I understand it)
Now I painted only models. (and maybe not even the fact that she did it right)
If you need code with models, shout.
Help, explain what should be my sequence of actions now? this is hardly important, but I use pycharm on windows, the server and database are built-in.

Answer the question

In order to leave comments, you need to log in

4 answer(s)
U
Uber Noob, 2016-05-14
@dawasaturday

1. Create a database structure
2. Create a database according to this structure in it, make a status field for users - 0 ordinary user 1 - moderator for example
3. Write separately the output of articles, user registration, adding texts, test
4. Add the moderation functionality, test
5. You dress all this in design, although I am now designing, I am doing the layout after 2 steps

R
Roman Kitaev, 2016-05-14
@deliro

The jung user has a default is_staff flag, which allows you to enter the admin panel. You can use it. Also default rights.

S
sim3x, 2016-05-14
@sim3x

No models
No authentication
You have a user story - describe it in steps and write the code you need to implement it
and start with tests chimera.labs.oreilly.com/books/1234000000754

A
Alexey Ovdienko, 2016-05-23
@doubledare

You write models
If it is necessary - you expand model of the User
You write .
And now the magic: in views where only registered users should have access, you attach the decorator @staff_member_required or @login_required to the function
if the Views are CBV - write a mixin

class LoginRequiredMixin(object):
    """
    A login required mixin for use with class based views. This Class is a light wrapper around the
    `login_required` decorator and hence function parameters are just attributes defined on the class.

    Due to parent class order traversal this mixin must be added as the left most
    mixin of a view.

    The mixin has exaclty the same flow as `login_required` decorator

    """
    @method_decorator(login_required)
    def dispatch(self, request, *args, **kwargs):
        return super(LoginRequiredMixin, self).dispatch(request, *args, **kwargs)

Version 1.9 already has this mixin, and then you simply inherit it in the view. The order of inheritance is important. On the right, there should always be a parent view that inherits from, and on the left, other views and mixins.
class CreateSongView(LoginRequired , CreateView):
You can cut access with mixins . Templates are
a little different:
{% if user.is_authenticated %} or something like is_admin or you can implement everything using access permissions:
Create groups in the admin panel, distribute each its access, and then in the template and views it will be possible to check by type has_permission('poll.add')

Didn't find what you were looking for?

Ask your question

Ask a Question

731 491 924 answers to any question