We have chosen Alfresco for our project because Alfresco meets most of the functional requirements we need.
Share is a great app, nevertheless it has too much functionality for our scenario, much more than we need in our project. This is the reason of posting this question, we don't know what's the best option: either customize Share creating custom pages, custom dashboard, custom actions and metadata etc. or create a new web application that interacts with the repository.
Roughly, we have these requirements:
Custom header with custom menu, disabling direct access to Repository (users only can collaborate using Sites)
Custom dashboard that contains
On the left, list of Sites
On the center, custom dashlets which shows several content in different ways and formats
One of the dashlet would be a "dynamic" dashlet as I explain in my last question
Custom document details page, with custom actions and custom metadata
I would like to know opinions based on experience, explaining when and why would be a good idea to create a new web app that interacts with the Alfresco repository or when to customize Share according to your needs. I'm highly interested on knowing Share customization limits.
Thanks.
Alfresco Share doesn't really have any limitations, it's already an UI built upon the repository.
I've seen Share modification till the sky and one can't even see it's Share any more.
The things you've described above are just templating and building the rightfully freemarker templates/js to view the piece of information.
If you take a good look at the default templates with their regions and shift around the default regions you'll see that you don't need heavy customizations to achieve a different layout.
The only thing one probably lacks is experience with Share.
Related
Problem Statement
I'm working on building out a single-page Django web app and am trying to implement the following functionality:
- All viewers of the page are associated with a state. There are buttons on the page which enable viewers to change their state.
- The application stores a list of all current viewers of the page, and their associated states. Whenever a user changes their state, this stored list of viewers updates with this new information.
- The application should display how many people are online (viewing the page) at a given time.
Blockers
I'm unsure of how to collect a list of all current viewers of a page in Django, nor how to collect how many users are currently viewing the page.
Ideally, my application would not require a login to use: therefore, I'd rather either associate viewer state with a user object that doesn't require sign-in, or not associate viewer state with a user object (I'm still new to user objects though, so forgive me if this point doesn't make complete sense).
What I'm Looking For
A discussion of higher-level strategies which I can use to implement this functionality, or other places to look to gain insight in tackling my problem. I'm pretty new to Django, so I'd appreciate it if answers also direct me to locations in my Django project which are of relevance (e.g. "Consider doing X in views.py, then..."). Alternatively, if there are GitHub projects you know of with similar functionality, if you could direct me to them to investigate further, that would also be appreciated.
I'd be happy to offer further clarification as required. Thanks in advance!
For a project I want to show/export all visitors with visitortags from an engagement plan. The export is for creating an overview and checking purposes. It's important to show the business I have done my work correctly. I prefer a way without writing any programcode.
Does anyone know how to do this?
Thanks a lot.
Jordy
This is not possible by default in Sitecore, so you will have to write some code.
If you click the supervisor you will be able to see the USERS in a state in an engagement plan, but not VISITORS. Even though you can see the users, you won't be able to see the visitor tags, for that given user.
I'm not sure the best way to ask this, but is it possible to reuse a custom object type defined in one app so that it aggregates on the timeline with objects of the same type from another app?
I see news articles doing this in my own timeline, such as Guardian and Yahoo news articles appearing in the same aggregate box. I'd like to do this with my main blog as well as another blog project, both of which are about puzzles. Since I have the object type defined as thegriddle:puzzle in my app, can I use that object type with a second app in order to make the items aggregate together? (i.e. "Solved Puzzles" listing puzzles solved on The Griddle and on the second blog)
I have run into the same concern and have found no way around the limitation of 1 app -> 1 domain.
You may have some luck if you associate the Website URL to one domain and the Mobile URL to another. But to be honest that is silly and probably doesn't even deserve being mentioned.
So as far as I can tell, the answer is no, not at this time. Although I hope this issue is resolved soon. Maintaining 4-5 apps / submitting action object approval for each is a timesink.
As far as two items from different apps showing up in the same stream - that could be because they are grouped by opengraph actions or objects.
References:
Facebook open graph timeline application - How to connect/use other objects in your own timeline application
Personal experience.
This question is (I think) about object/row level permissions in Django.
We are building a community and need to be able to set permissions based on actions that users take. For example, you should not be able to start a thread until you have posted so and so many answers.
Also, the users should be able to remove content that belongs to themselves. Based on the Django documentation, it seems like the standard framework does not support permissions for instances.
Should we build on the "empty" API that Django supplies, or should we use an app for this like django-guardian, django-rules, etc? Which ones would you in that case recommend?
Thank you!
you should not be able to start a thread until you have posted so and so many answers.
You don't need to use per-object permissions for that. Actually, you don't need to use permissions for that at all. Just check if user meets the requirements in your views.
Or you can use standard django permissions engine. Create permissions like "Start a Thread", then set up signals to track when users add answers. When singal is emitted check if a user has enough answers and grant him the "Start a Thread" permission.
It's up to you to decide which one works better for you.
Also, the users should be able to remove content that belongs to themselves.
This can be done with per-object permissions. But if it's the only reason to use them then I'd just add a field author to your models and use a simple item.author == request.user check to test if user can delete the item.
So, my general advice is to keep it simple. Analyze your needs. Per-object permissions is a powerful tool which may be an overkill in your situation.
I recommend you to go with Django-guardian.
Django-guardian
Great, DRY, maintained and well-tested app, that solves the issue. As of today, this is the most maintained and actively developed library for implementing per-object permissions.
We are currently using django-guardian in one of our big projects and are very pleased with stability and functionality.
Django-guardian source code is very simple and easy to understand because it is built upon the permission code in Django core.
However, there is a minor issue with Django permissions for proxy models which is not fixed in Django core thus making it really tricky to set permissions (global and per-object alike) for them. One of the ways to overcome this is to declare all permissions in a non-proxy object and query for them every time when you need to check for permission to access a proxy model.
Per-object permission library by OSU Open Source Lab
It is more of a standalone application than Django-guardian and supports older versions of Django. This app is relatively well maintained. (I personally haven't used it.)
Other solutions form older posts.
But most of them are poorly maintained.
Of course, if you need to implement only a few minor checks, row-level permissions are overkill, just like Andrey said.
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.