Hi my name is Samvit Majumdar. Im from New Delhi, India.Im pursuing
undergraduate study in Birla Institute of Technology and
Science,Pilani,India. My major is IT. Im in my second year.
While working on a project using Django ( www.bits-apogee.org/2011/
) , I came across few ideas that can be incorporated in Django.
Some of them are discussed below.
Roles in Django User model
While working on a project using Django, I came across many ideas that
can be incorporated in Django.
One of them is a concept of Roles.
A website has many users with various functions like manager, content
editor, administrator etc.
For each function we can have different set of data associated with
them .
eg :
For a manager, one may need his contact number , address, workplace
etc.
For content editor, one may need only contact number and not this
work address, home address etc.
Need :
Currently we can only associate 1 user profile class with a user
and call user.get_profile()
This can be quite inconvenient when one is need of many profiles.
Another way is to Inherit the User class.
Proposal :
A new class Role can be created. The user model has to modified only
a bit as only one foreign key has to be added i.e. "role".
Role class would look something like this :
class Role():
permissions = a list type entity or a Group ( which is
predefined )
profile = a class associated with a role
...
After this while developing we can create a new Role by inheriting
the above defined class :
eg :
( Rough Draft )
class Manager(Role):
permissions = 'Managers' #a group with permissions
profile = ManagerProfile
...
the class ManagerProfile would look like:
class ManagerProfile(models.Model):
phone = models.IntegerField()
address = models.TextField()
mobile_no = models.IntegerField()
....
so in this way while creating a user a role can be associated with
it, so only necessary data can be stored in the database.
Accessing profile :
The profile can accessed from user.get_profile(). This function would
be modifiled to get contents of the user.role.profile
Off-line Mode setting
Many time on production environments we make changes to the site. The
site goes through many development phases. There is sometimes few
hiccups while migrating from development to production environment.
Introduction of a off-line setting can be very useful in these cases.
OFFLINE = True # setting sugessted
When its true all the views gets redirected to a single view named
offline. The template to be rendered can be named offline.html.
Administrators can access the site via admin interface. This setting
will not effect the admin application. Also when admins are logged in
they can view the site normally and changes can be made fast without
any inconvenience to other users on the site.
Changes to the Admin application
Select box in filters
When there are many ( > 100 ) filters on the right panel of the admin
view objects interface.
The page gets indefinitely extended to and its quite inconvenient to
select one of them.
Instead a simple select box can be used if no. of elements is more
than 30( example ).
Admin view objects
The admin interface has no permission as “view objects” . This is
really userful feature and can be incorporated in Django.
Timeline
1st week : Designing models for roles. Considering all aspects needed
to be included in the model.
2nd Week : Writing the models. Dealing with all the key aspects of
it. Maitain backward compatibility
3rd week : Testing the written models in a development environment.
Note all furthur changes that may be required
4th week : Debugging the models.
5th week : Testing in production environment. Implementing it in a
real project. Also note all the
difficulties and errors faced.
6th week : Final composition of the model to be drafted.
7th week : Development on the Offline mode setting. Note down key
aspects and vulnerabilities.
8th week : Implementing the Offline mode setting.
9th week : Testing the offline setting in an actual project. And
debugging simultaneously.
10th week : Tweaking the admin app. Also survey what all developers
would like to include in the admin app for future and current
references.
11th week : Documentation of all the projects and changes.
12th week : Documentation and feedback.
So that is all that I would like to propose at this time. Any
suggestions , improvements and constructive critisism is always
welcome.
Regards,
Samvit
--
You received this message because you are subscribed to the Google Groups
"Django developers" group.
To post to this group, send email to django-developers@googlegroups.com.
To unsubscribe from this group, send email to
django-developers+unsubscr...@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/django-developers?hl=en.
