I'm struggling at building a website with Django. On that website, I want to have a lot of information about TV shows. I want my user to be able to insert and modify information. The information needs to be moderated, a change should not be published before being accepted by a moderator.
I came across django-moderation as a solution to that aspect.
My user will log into another instance of django-admin, with different user rights.
I'm adding django-guardian to deal with per-object permissions.
I'm lost a bit lost now. I think I'll find how to interface all those things, and it will work in a few weeks after reading all the docs, making all the mistakes, etc...
I am wondering thou if the architecture makes sense, if are software components I am missing out on.
Thank you for your consideration.
edit : BTW, working with django 1.7 on python 3.4
django-moderation looks interesting, I haven't used it. There's not a lot of activity in the project, but it's active. I think it will suit the use-case you have in mind. I considered django-guardian recently for a project and rejected it in favour of extending tastypie's authorizations. I think my use case was a bit different, I needed to maintain constraints on foreign key relationships that were hard to express with django-guardian. If you only intend to allow or reject read/write permissions and don't need to validate anything beyond rudimentary data points, it will do a good job (in that case, use Django's model validators).
In general: Django has a wide assortment of easily included apps. in general: if you can solve it with pip install, do so.
Related
I think I read all the documentation and I'm still confused on wether LB4 is ready for production use?
As I understand, it still misses Many-to-Many relationship and some OpenApi specs implementation. The documentation is very scarce so it left me very confused.
We are currently searching for good node REST solution and LB4 looks very promising with things like TS and dep. injection(more modular design), but it looks like we'll have to skip this one for now. Is anyone using this at all? I would be very glad to hear some experiences.
We have used it for one of our application. I agree that there are some gaps but for most of the stuff, you can handle it pretty well in loopback 4. The most significant reason for that is the awesome extensibility of LB4. That's the reason why we could do authentication, authorization, bpm integration, etc. in our application by creating Components in LB4.
After we were done with it, we thought about sharing our experience with open source world. So, we published a loopback 4 starter application which demonstrates a multi-tenant architecture, supports authentication via passport strategies (using loopback4-authentication extension we created), supports simple permission keys based authorization (using loopback4-authorization extension we created), soft delete entity (using loopback4-soft-delete extension we created) and DB revisioning, upgrades (using db-migrate package).
Hope it helps clear your doubts about loopback 4. Trust me, its an awesome framework with lots of futuristic goals.
I want to know how to divide a project having a hierarchical structure into applications. Let's say that I'm trying to build something like github.com.
In github.com, an account has some repositories, which have some features like code, issues, or pull requests. And those features have references to other features. In this case, which is an application and which is not? At that time, should I put applications in the root directory or in an application directory as sub-applications?
In an ideal world, each app would be independent of the others, or only loosely coupled to the others. But in many real world situations, there are often so interdependencies that it's hardly worth trying to abstract them.
So, then, in that case.. the best way to separate them is to divide them into functional groups where the majority of the views, models etc in each app are used solely within the app. So, given your github example, the "issues" could be their own app. The issues app would have specific views that are related solely to displaying, editing and serving (ajax requests, etc) issues, models for storing issues and their ongoing status, templates which are solely responsible for rendering issue views, issue entry for example, issues per user, issues per project, details of a particular issues. There's actually a lot of issue-specific code.
And yes, by the time you're done, you'll have for example foreign keys from those issue models to user models and to perhaps a commit model, a project model.. many interdependencies that would prevent the issues app from working without the presence of other apps. But logically, when it's time to work on the issue system, you'll know where to go.. because all the issue code is in one place. All the default issue settings are in issues/settings.py for example, all the tables primarily related to issues will be prefixed with the app_label eg. issues_issue, issues_comment.. etc..
So basically, try to break it up on the basis of core functionality, and minimize the number of dependencies.. or at least, try to avoid circular dependencies.. eg, some apps will have many other apps depending upon them, some will have none. Try to avoid a deadly embrace. But, in the end, dependencies will happen.
In some cases, you may be able to implement optional dependencies, eg.. when something happens in App A, Model_A, it should trigger something happening in App B, Model_B.. but only if App B is installed. There are ways to do this less-closely-coupled behavior, such as Django's signal system
https://docs.djangoproject.com/en/2.0/ref/signals/
But this is not as reliable as a foreign key, so do not go out of your way to loosely couple things which will never be uncoupled.
Try to divide things into apps on the basis of closely coupled functionality, eg. views that are related to other views. Put things which all your apps rely upon into your master app or into a library.. and you'll find that your code is much easier to maintain as it grows.
I would put the applications at the level of your manage.py file in your main project, then you can easily run this command: python manage.py startapp login_app. Then you can have a structure like so:
main_project
login_app
codeissues_app
pullrequests_app
It's not possible to create independent apps for every app in your project. I suggest you to follow the domain driven design. (google it)
So imagine you are building a ecommerce shop. You would have something like:
your_project_folder
docs
readme
static
your_project
domain # here you put the models logic
cart
products
payment
shipping
tax
infrastructure # your packages to interface with other services
paypal
stripe
interface
rest
another_rest
presentation
public_site
...
This is just an example of how you can divide the project. Than you must have boundaries. In the domain folder you must group the packages (and so design your model) to not permit cross references.
Interface, Infrastructure and Presentation can access to the Domain.
The Domain should be more stricter. Have a look here: https://martinfowler.com/bliki/BoundedContext.html
Anyway this is just the surface of the subject. Depends a lot of what kind of project you are building and what are the requirements. Have a look at the Domain Driven Design.
currently I am looking implementing access control in Django. I've read about the built-in permission, but it does not takes care per object basis. For example, I want permissions like "Only the creator can delete his own items". So I read about django-guardian. Then again, after thinking about it, it may be difficult to manage and check if constraints ever change.
I look at the next popular permission management app called django-rules. This seems to suit what I require. However, I believe django-rules requires a model instance to be involved (hence object level) i.e if I require a simple view like "member's area", it does not perform this function.
This has led me to think about using both the contrib's permission for the latter scenarios and django-rules for the former. My question here, is how easy will it be to manage both permission frameworks?. For instance, I have different groups of users. I am worried about overlapping scenarios whereby the admin added a particular permission in the admin system (to allow access to a view), thinking that should suffice but turns out to be bounded by constraints set by the rules.
I believe this is a common case and I humbly seek your advices and recommendations based on your experiences.
If you're doing this through Django admin site, you can override methods such as has_delete_permission(). These get request and object as arguments, so you can use it to set up rules like "User X can delete only his own objects".
I'm trying to configure a wiki to allow a two staged approval process. The basic work flow requires something like:
A group of users submits a short form
After admin approval, a larger form becomes available to the group
The group submits the larger form
After admin approval, the page (filled by the form) becomes public
I've been looking at TikiWiki and MediaWiki for a while trying to configure each to get even close to this model, but I'm having some problems.
With TikiWiki, it seems like the approval stage should be a transition, either changing the group permissions to allow access to a new tracker or changing the form category to close one form and open the other, but I haven't been able to nail down the permissions for that configuration.
With MediaWiki, the main problem seems to be that the back-end was not made to have complex permissions. I've been using SMWHalo along with SemanticForms to construct this, but I can't find anything like Tikiwiki's transitions for changing the permissions for either the group or the form automatically.
I'm a bit new to Wiki development and I know that there are a lot of options for wiki frameworks, so I'm asking for suggestions for a good work flow for this product. My goal is to only start actually touching the framework code to make the final adjustments and not to start off modifying an already well developed code base.
You should really ask yourself why you want this and why you want this in a wiki.
A Wiki's main advantage is being quick and easy and thus encouraging to the user. Adding approval stages will discourage users to participate. The hardest part in any wiki is not preventing vandalism or false information. The hardest part is to encourage participation.
If you really need a difficult approval workflow you might want to look at CMS systems. AFAIK typo3 has something like this built in.
If really you want to go with a wiki and an approval process, for DokuWiki you could have a look a the publish plugin: http://www.dokuwiki.org/plugin:publish
The FlaggedRevs extension to MediaWiki adds a basic permissions workflow:
http://www.mediawiki.org/wiki/Extension:FlaggedRevs
However, it's geared more at controlling changes to existing pages, not adding entirely new ones. You could set it up to create new pages as drafts and defaulting the public view to show only approved versions, but it sounds like you want to hide unapproved versions entirely, which would require some extra hacking (and, as Andreas says, kind of defeats the point of a wiki in the first place).
I am relatively new to Django and this is a more general 'concept' question.
For a client I need to construct an expansive database holding data returned from a series of questionnaires as well as some basic biological data. The idea is to move away from the traditional tools (i.e. Microsoft Access) and manage the data in a mysql database using a basic CRUD interface. Initially the project doesn't need to live on the web, but the next phase will to be to have a centralized db with login and admin page.
I have started building the db with Django models which is great, and I want to use the Django admin for the management of the data.
My question is: Is this a good use of Django? Is there anything I should consider before relying on django for the whole process? And is it advisable to us the Django runserver for db admin on a client's local machine (before we get to the web phase).
Any advice would be much appreciated.
Actually, your description sounds exactly like the sort of thing for which Django is an ideal solution. It sounds more complex and customized than a CMS, and if it's as straightforward as your description then the ORM is definitely a good tool for this. Then again, this sounds exactly like an appserver-ready problem, so Rails, Express for Node.js, or even ChicagoBoss (if you're brave) would be good platforms for this kind of application.
And sure, Django is solid enough you can run it with the test server for local clients before you go whole-hog and run the thing on the web. For that, though, I recommend Apache/mod_wsgi, and if you're going to be fault tolerant there are diamond architectures (one front end proxy with monitoring failover, two or more appserver machines, one database with hot spare) and more complex (see: sharding) architectural layouts you can approach later.
If you're going to run it in a client's local setting, and you're not running Windows, I recommend looking into the screen program. It will allow you to detach the running job into the background while making diagnostics accessible in an ongoing fashion.