It is very easy to give permissions to edit a specific page in django cms
However, I didn't find a way to give a permission to edit a page in a certain language.
It's a very common scenario, I have my Spanish, Russian and English editors, and I want that everyone will be able to edit only the pages in their language.
Is there a way of doing it that i'm missing? and if not, what can be done to solve it?
At this moment there is an overhaul done of the page permission in Django CMS. One of the things they want to solve is Permission per language.
https://github.com/divio/django-cms/issues/4598
If everything goes well, it will be released in DjangoCMS 3.4
As of today, there is no way to set permissions on a page+language basis.
The remaining options are to submit a feature request or fork django-cms and implement on your own.
Related
We have a multiple site, multiple language solution. We have a particular site (Site A) where we wish to have English as a "master" language, which is then translated and published in various other languages. We wish to prevent e.g. a French editor being able to edit and publish in any other language than French.
However, the French editor will have both English and French language read/write permissions, for their work on another part of the solution (Site B), so we can't use these to specify directly which permissions they have on Site A. We also use only removal of inheritence to limit role permissions, and never explicit denial, so permissions are cumulative.
Is it possible to create language specific workflows, with associated roles assigned to them, to prevent this editor from editing or publishing items in other languages?
Note: it would also be OK if this editor could publish in all languages, but only language versions that had been moved to the "publishable" state, and couldn't make a foreign language version publishable himself (so that if he did publish e.g. a German version it would only be a finished, publishable version, not a work in progress).
EDIT: To clarify, I don't mind my editor being able to publish all publishable versions of an item, as long as he can only edit in the one language he has ownership of for that site and cannot make other versions publishable.
If not, is there a standard/best practice solution to this problem?
You can force Sitecore to publish only items to which a user has read/write access by changing the following settings in web.config:
Publishing.CheckSecurity = true
Publishing.RequireTargetDeleteRightWhenCheckingSecurity = false
Use Default or Custom Access Rights to Control Whether Users Can Publish an Item
This does mean that you need to separate your roles and permissions out to be quite granular, i.e. you will need separate roles for Site 1 English Editor, Site 1 French Editor, Site 2 English Editor etc.
EDIT: Thanks for the clarification above and I can see where your problem lies. As I mentioned in the comments above, maybe you can hide/disable the language option on the Publish dialog. Just been taking a look at Sitecore.Shell.Applications.Dialogs.Publish.PublishForm and as expected there are a few private methods you would have to replicate, but you can add your own logic to BuildLanguages() to get what you need. Just duplicate sitecore\shell\Applications\Dialogs\Publish\Publish.xml to sitecore\shell\Override and change the codebeside to point to your custom logic.
I hate to add fields to system templates normally, but maybe add another field to /sitecore/templates/System/Language to specify which roles/user can publish that language. You can use the Account Selector Field for this.
You can set security on workflow actions, thus preventing an action being performed by certain users. If that won't solve thing (because the same workflow is involved), you can always revert to implementing a workflow action yourself, this is easy.
I have handled this in the past by creating multiple accounts for the user. In your case, one for Site A in English and one for Site B in English and French. It may not be ideal, but i don't think creating extra languages is either. Good luck!
For a website that is using django zinnia blog, I need the possibility to, beyond authors using the admin to create articles, to have a limited way for non-admin users to create blog entries, in their own specific area, with limited functionality (e.g. preset category, all entries start as draft etc..)
Now I was wondering if I could just create an own small ui for it and create Entries programatically in a django view (not in admin)... (with authors in those cases being non-admin users) ...
Is there any reason why this would be a very bad idea, or is this something that would really break things in Zinnia ?
Thanks in advance
Cheers
Thomas
I've done one part of this a few months ago. The client found the admin interface too complicated and wanted something simpler. I created view/templates that allowed users to add/edit blog entries - There were no major issues.
That said, this was still for admin users - there may be permission issues or hidden assumptions in zinnia that users are admins. I doubt there would be much trouble overcoming them - it's a nicely written app with decent interfaces.
I can show you some code if you're interested.
I'm working on a django project in which users can post articles and vote on them. But the users are not supposed to vote on their own articles. Currently I'm using the permission system with django-guardian. My idea is to grant a kind of 'anti-permission' so that only the author can't vote on their own articles.
My reasoning is that in this way all the permissions can be handled in a unified protocol, separately from view functions(instead of putting conditions inside them). And if there comes future requirements like this, they can be handled elegantly.
But it does not look semantically right to use "permissions" in this way. Just wondering if there's a better way of doing it?
Thanks for your help! :)
Write a manager that takes the context and then returns a list of objects that the user can vote on.
Use this manager in your view.
I'm building a Django-based review website where public users create all of the content on the site. Users create reviews for given items and they also create the items themselves that will be reviewed (providing a description and brief summary of the item, along with a few tags).
My question is this: Should I be using Django's admin features for this website (as in, exposing admin controls to the public users)? Or should I just stick with normal forms? I'm not too familiar with the admin-aspect of Django, and so far I've just been using forms for the website, but I've seen a lot of people talking about Django's admin features, and I'm starting to wonder if I should be using them.
Thanks for any feedback!
Maybe. If the admin functionality covers most of what you want to offer, there's no reason why you shouldn't use it as a starting point.
django.contrib.admin is an application like any other, and provides basically a CRUD interface to your models. Access can be controlled via groups/permissions, just like you would for an application you write yourself. You can give full access to a model with a one-liner, but obviously will have to configure properly when opening up to others.
See also my question
Django AdminSite/ModelAdmin for end users?
and similar questions Exposing django admin to users. Harmful? and How to make Django admin site accessed by non-staff user?
Regarding arguments about the "intended use" of the admin, please note Django's security update at the end of last year: http://www.djangoproject.com/weblog/2010/dec/22/security/ regarding querystring parameters in object lists. Such an update (quote: "an attacker with access to the admin [...]") is a clear indication that the admin's implementation of the permission system is being constantly scrutinized.
No. The django admin is not intended for any end-user.
The django admin feature is intended to assist the website developer, and that is all. Even usage by site administrators is contra-indicated, although in practice most small sites get away with it since they're only talking a few people who can call on the developer personally if they get into trouble.
For your purposes, the review items and the workflow in creating the items is a critical part of your application feature set. The admin will give you ideas, but it would be a mistake to attempt to build your application upon it.
I wouldn't expose the admin interface to regular users. You can use the authentication and user-management side (for your purposes), but it's usually best practice to give users a separate way to manage their objects. You also don't run as much of a risk of granting the wrong privileges to users (or allowing them to grant their own).
Have a read though the docs if you want a better overview about what it can do.
I want to implement Facebook connect login for my Django site and I've checked the already existing apps.
So far, I have found Django-Socialauth, django-socialregistration, and django-facebookconnect for this purpose.
The question is which one to choose, and I would like to hear from other developers who have experience with any of these apps.
It is important for me that the Facebook Connect login app plays nicely with #login_required, with the default auth system, and with django-registration.
Please share your experience :)
Update (11/26/2013): I'm updating my recommendation. Since a sufficient amount of time has passed since I wrote this answer, I would recommend python-social-auth or django-allauth as the best tools for the job. They are active projects with good documentation and support for a lot more than just Facebook. I've had success using both.
I have had the most luck with adapting django-socialregistration with django-registration (0.8). Since you're working with django-registration, you're going to have to do a little bit of work, since all three of those packages assume the role of both the creation and the authentication of the user.
I was just going to explain what needed to be done, but you inspired me to finally get my version out: hello-social-registration.
Like I alluded to, it separates gives the registration functions to a django-registration backend and handles all the authorization itself. I've been using this on my near-beta application for a while now with no problems (I also handed it to a friend to use a few months ago and he got it to work without much modification).
It's definitely not ready to be a plug-and-play reusable application, yet, but hopefully it'll provide you with some insight. :)
By far the most commonly used package for Facebook authentication in Django is Django Facebook:
https://github.com/tschellenbach/Django-facebook
It also gives you access to the facebook APIs using the included Open Facebook api client.
I wanted to implement a basic "Login using Facebook" functionality in my Django app. I didn't want to show the user a form to fill or have her choose a password. I preferred to make it seamless.
Based on my requirements, django_facebook_oauth was the best app for me. It simply allows the user to login using facebook, and gets the user info my Facebook app requests from her (based on my Facebook Auth Dialog). It creates a new user in Django with the user's facebook email, a username and a blank password.
I highly recommend it.
Hi Take a look at fbconnect app that we (actually, Hernani, a guy on our team) put together for osqa (a clone of CNPROG).
You will have to, probably, tinker a bit to adapt that to your needs. It does work with #login_required decorator and the standard django.contrib.auth system, but we do not use django-registration.
Our app also works with openid and password login, but the openid part is tightly coupled with the Q&A component at present.
We may separate it though some time in the future, if anyone might be interested in "anything-signin" django pluggable app or has something better already - pls let us know.
I've used django-allauth and django-facebook on two different projects.
django-allauth was great and provided very good support for logging in and creating user profiles. It could also work with other auth providers, which I didn't implement.
django-facebook worked out of the box, but it's only compatible with Facebook. It also provided simple APIs for fetching users' likes and friends from Facebook directly into the db, which I liked very much!
facebook.get_and_store_likes(user)
facebook.get_and_store_friends(user)
I played with .NET based libraries and found them to be frustratingly out of date. Facebook seems to change their APIs frequently, so if you cannot find a library that is routinely maintained, you will find that you will get halfway through your implementation before you realize that there are serious problems.
I had some success with the javascript API that Facebook publishes and maintains. While the documentation may not be always up to date, I found that I was always within striking distance of the correct implementation (one or two changes needed).