|
blog entries
CubicWeb 3.9 brings several improvements that we'll want to use, and the 1.9
version of the file cube has a major change: the Image type has been dropped in
favor of an IImage adapter that makes code globally much cleaner (although this
is not directly visible here). So the first thing to do is to upgrade our cube to the
3.9 API. As CubicWeb releases are mostly backward compatible, this is not
mandatory but it's easier to follow changes as they come than having a huge
upgrade to do at some point. Also, this remove deprecation warnings which are a
bit tedious...
Since we only have very few lines of code, this step is pretty simple.
Actually the main thing we have to do is to upgrade our schema, to remove occurrences
of the Image type or replace them by the File type. Here is the (striped) diff:
class comments(RelationDefinition):
subject = 'Comment'
- object = ('File', 'Image')
+ object = 'File'
cardinality = '1*'
composite = 'object'
class tags(RelationDefinition):
subject = 'Tag'
- object = ('File', 'Image')
+ object = 'File'
class displayed_on(RelationDefinition):
subject = 'Person'
- object = 'Image'
+ object = 'File'
class situated_in(RelationDefinition):
- subject = 'Image'
+ subject = 'File'
object = 'Zone'
class filed_under(RelationDefinition):
- subject = ('File', 'Image')
+ subject = 'File'
object = 'Folder'
class visibility(RelationDefinition):
- subject = ('Folder', 'File', 'Image', 'Comment')
+ subject = ('Folder', 'File', 'Comment')
object = 'String'
constraints = [StaticVocabularyConstraint(('public', 'authenticated',
'restricted', 'parent'))]
class may_be_readen_by(RelationDefinition):
- subject = ('Folder', 'File', 'Image', 'Comment',)
+ subject = ('Folder', 'File', 'Comment',)
object = 'CWUser'
-from cubes.file.schema import File, Image
+from cubes.file.schema import File
File.__permissions__ = VISIBILITY_PERMISSIONS
-Image.__permissions__ = VISIBILITY_PERMISSIONS
Now, let's set the dependency in the __pkginfo__ file. As
3.8 simplifies this file, we can merge __depends_cubes__ (as introduced in the
first blog of this series) with __depends__ to get the following result:
__depends__ = {'cubicweb': '>= 3.9.0',
'cubicweb-file': '>= 1.9.0',
'cubicweb-folder': None,
'cubicweb-person': None,
'cubicweb-zone': None,
'cubicweb-comment': None,
'cubicweb-tag': None,
}
If your cube is packaged for debian, it's a good idea to update the
debian/control file at the same time, so you won't forget it.
That's it for the API update, CubicWeb and cubicweb-file will handle other stuff for
us. Easy, no?
We can now start some more fun stuff...
The first thing I've noticed is that people to whom I send links to photos with
some login/password authentication get lost, because they don't grasp they have
to login by clicking on the 'authenticate' link. That's probably because
they only get a 404 when trying to access an unauthorized folder, and the site
doesn't make clear that 1. you're not authenticated, 2. you could get more
content by authenticating yourself.
So, to improve this situation, I decided that I should:
- make a login box appears for anonymous, so they see at a first glance a place
to put the login / password information I provided
- customize the 404 page, proposing to login to anonymous.
Here is the code, samples from my cube's views.py file:
from cubicweb.selectors import is_instance
from cubicweb.web import box
from cubicweb.web.views import basetemplates, error
class FourOhFour(error.FourOhFour):
__select__ = error.FourOhFour.__select__ & anonymous_user()
def call(self):
self.w(u"<h1>%s</h1>" % self._cw._('this resource does not exist'))
self.w(u"<p>%s</p>" % self._cw._('have you tried to login?'))
class LoginBox(box.BoxTemplate, basetemplates.LogFormView):
"""display a box containing links to all startup views"""
__regid__ = 'sytweb.loginbox'
__select__ = box.BoxTemplate.__select__ & anonymous_user()
title = _('Authenticate yourself')
order = 70
def call(self, **kwargs):
self.w(u'<div class="sideBoxTitle"><span>%s</span></div>' % self.title)
self.w(u'<div class="sideBox"><div class="sideBoxBody">')
self.login_form('loginBox')
self.w(u'</div></div>')
The first class provides a new specific implementation of the default page you
get on a 404 error, to display an explicit message for anonymous users.
Thanks to the selection mechanism, it will be selected for anonymous users,
since the additional anonymous_user() selector gives it a higher score than
the default, and not for authenticated since this selector will return 0 otherwise
(hence the object won't be selectable).
The second class defines a simple box, that will be displayed by default with
boxes in the left column, thanks to default box.BoxTemplate'selector. The HTML
is written to match default CubicWeb boxes style. To get the actual login form,
we inherit from the LogFormView view which provides a login_form method
(handling some stuff under the cover for us, hence the multiple inheritance), that
we simply have to call to get the form's HTML.
Another thing we can easily do to improve the site is... A nicer index page
(e.g. the first page you get when accessing the web site)! The default one is
quite intimidating (that should change in a near future). I will provide a much
simpler index page that simply list available folders (e.g. photo albums in that
site).
from cubicweb.web.views import startup
class IndexView(startup.IndexView):
def call(self, **kwargs):
self.w(u'<div>\n')
if self._cw.cnx.anonymous_connection:
self.w(u'<h4>%s</h4>\n' % self._cw._('Public Albums'))
else:
self.w(u'<h4>%s</h4>\n' % self._cw._('Albums for %s') % self._cw.user.login)
self._cw.vreg['views'].select('tree', self._cw).render(w=self.w)
self.w(u'</div>\n')
def registration_callback(vreg):
vreg.register_all(globals().values(), __name__, (IndexView,))
vreg.register_and_replace(IndexView, startup.IndexView)
As you can see, we override the default index view found in
cubicweb.web.views.startup, getting back nothing but its identifier and selector
since we override the top level view's call method.
In that case, we want our index view to replace the existing one. We implement
the registration_callback function, in which we code a
registeration of everything in the module but our IndexView, then we register it
instead of the former index view.
Also, we added a title that tries to make it more evident that the visitor is
authenticated, or not. Hopefully people will get it now!
There are still a few problems I want to solve...
- Images in a folder are displayed in a somewhat random order. I would like to
have them ordered by file's name (which will usually, inside a given folder,
also result ordering photo by their date and time)
- When clicking a photo from an album view, you've to get back to the gallery
view to go to the next photo. This is pretty annoying...
- Also, when viewing an image, there is no clue about the folder to which this
image belongs to.
I will first try to explain the ordering problem. By default, when accessing related
entities by using the ORM's API, you should get them ordered according to the target's
class fetch_order. If we take a look at the file cube's schema, we can see:
class File(AnyEntity):
"""customized class for File entities"""
__regid__ = 'File'
fetch_attrs, fetch_order = fetch_config(['data_name', 'title'])
By default, fetch_config will return a fetch_order method that will order on
the first attribute in the list. We could expect to get files ordered by
their name. But we don't. What's up doc ?
The problem is that files are related to folder using the filed_under relation.
And that relation is ambiguous, eg it can lead to File entities, but also to
Folder entities. In such a case, since both entity types don't share the
attribute on which we want to sort, we'll get linked entities sorted on a common
attribute (usually modification_date).
To fix this, we have to help the ORM. We'll do this in the method from the ITree
folder's adapter, used in the folder's primary view to display the folder's
content. Here's the code that I've put in our cube's entities.py file, since
it's more logical stuff than view stuff:
from cubes.folder import entities as folder
class FolderITreeAdapter(folder.FolderITreeAdapter):
def different_type_children(self, entities=True):
rql = self.entity.cw_related_rql(self.tree_relation,
self.parent_role, ('File',))
rset = self._cw.execute(rql, {'x': self.entity.eid})
if entities:
return list(rset.entities())
return rset
def registration_callback(vreg):
vreg.register_and_replace(FolderITreeAdapter, folder.FolderITreeAdapter)
As you can see, we simply inherit from the adapter defined in the folder cube,
then we override the different_type_children method to give a clue to the ORM's
cw_related_rql method, that will generate the rql to get entities
related to the folder by the filed_under relation (the value of the
tree_relation attribute). The clue is that we only want to consider the File
target entity type. By doing this, we remove the ambiguity and get back a RQL
query that correctly orders files by their data_name attribute.
- Adapters have been introduced in CubicWeb 3.9 / cubicweb-folder 1.8.
- As seen earlier, we want to replace the folder's ITree adapter by our
implementation, hence the custom registration_callback method.
Ouf. That one was tricky...
Now the easier parts. Let's start by adding some links on the file's primary view
to see the previous / next image in the same folder. CubicWeb provides a
component that do exactly that. To make it appear, it has to be adaptable to
the IPrevNext interface. Here is the related code sample, extracted from our
cube's views.py file:
from cubicweb.selectors import is_instance
from cubicweb.web.views import navigation
class FileIPrevNextAdapter(navigation.IPrevNextAdapter):
__select__ = is_instance('File')
def previous_entity(self):
rset = self._cw.execute('File F ORDERBY FDN DESC LIMIT 1 WHERE '
'X filed_under FOLDER, F filed_under FOLDER, '
'F data_name FDN, X data_name > FDN, X eid %(x)s',
{'x': self.entity.eid})
if rset:
return rset.get_entity(0, 0)
def next_entity(self):
rset = self._cw.execute('File F ORDERBY FDN ASC LIMIT 1 WHERE '
'X filed_under FOLDER, F filed_under FOLDER, '
'F data_name FDN, X data_name < FDN, X eid %(x)s',
{'x': self.entity.eid})
if rset:
return rset.get_entity(0, 0)
The IPrevNext interface implemented by the adapter simply consist of the
previous_entity / next_entity methods, that should respectively return the
previous / next entity or None. We make an RQL query to get files in the same
folder, ordered similarly (eg by their data_name attribute). We set
ascendant/descendant ordering and a strict comparison with current file's name
(the "X" variable representing the current file).
- Former implements selector should be replaced by is_instance or
adaptable selector with CubicWeb >= 3.9. In our case, is_instance is used to
tell our adapter to get File entities.
Notice that this query supposes we wont have two files of the same name in the
same folder. Fixing this is out of the scope of this blog. And as I would like
to have at some point a smarter, context sensitive
previous/next entity, I'll probably never fix this query (though if I had to, I
would probably choose to add a constraint in the schema so that we can't add
two files of the same name in a folder).
One more thing: by default, the component will be displayed below the content
zone (the one with the white background). You can change this in the site's
properties through the ui, but you can also change the default value in the code
by modifying the context attribute of the component:
navigation.NextPrevNavigationComponent.context = 'navcontentbottom'
context may be one of 'navtop', 'navbottom', 'navcontenttop' or
'navcontentbottom'; the first two being outside the main content zone, the two
others inside it.
Now, the only remaining stuff in my todo list is to see the file's folder. I'll use
the standard breadcrumb component to do so. Similarly as what we've seen before, this
component is controlled by the IBreadCrumbs interface, so we'll have to provide a custom
adapter for File entity, telling the a file's parent entity is its folder:
from cubicweb.web.views import ibreadcrumbs
class FileIBreadCrumbsAdapter(ibreadcrumbs.IBreadCrumbsAdapter):
__select__ = is_instance('File')
def parent_entity(self):
if self.entity.filed_under:
return self.entity.filed_under[0]
In this case, we simply use the attribute notation provided by the ORM to get the
folder in which the current file (e.g. self.entity) is located.
The IBreadCrumbs interface is a breadcrumbs method, but the default
IBreadCrumbsAdapter provides a default implementation for it that will look
at the value returned by its parent_entity method. It also provides a
default implementation for this method for entities adapting to the ITree
interface, but as our File doesn't, we've to provide a custom adapter.
Now that greatly enhanced our cube, it's time to release it and to upgrade production site.
I'll probably detail that process later, but I currently simply transfer the new code
to the server running the web site.
However, there's some commands to get things done properly... First, as I've added some
translatable string, I have to run:
$ cubicweb-ctl i18ncube sytweb
To update the cube's gettext catalogs (the '.po' files under the cube's i18n
directory). Once the above command is executed, I'll then update translations.
To see if everything is ok on my test instance, I do:
$ cubicweb-ctl i18ninstance sytweb
$ cubicweb-ctl start -D sytweb
The first command compile i18n catalogs (e.g. generates '.mo' files) for my test
instance. The second command starts it in debug mode, so I can open my browser and
navigate through the web site to see if everything is ok...
In the 'cubicweb-ctl i18ncube' command, sytweb refers to the cube, while
in the two other, it refers to the instance (if you can't see the
difference, reread CubicWeb's concept chapter !).
Once I've checked it's ok, I simply have to bump the version number in the
__pkginfo__ module to trigger a migration once I'll have updated the code on
the production site. I can check the migration is also going fine, by
first restoring a dump from the production site, then upgrading my test instance.
To generate a dump from the production site:
$ cubicweb-ctl db-dump sytweb
pg_dump -Fc --username=syt --no-owner --file /home/syt/etc/cubicweb.d/sytweb/backup/tmpYIN0YI/system sytweb
-> backup file /home/syt/etc/cubicweb.d/sytweb/backup/sytweb-2010-07-13_10-22-40.tar.gz
I can now get back the dump file ('sytweb-2010-07-13_10-22-40.tar.gz') to my test
machine (using scp for instance) to restore it and start migration:
$ cubicweb-ctl db-restore sytweb sytweb-2010-07-13_10-22-40.tar.gz
$ cubicweb-ctl upgrade sytweb
You'll have to answer some questions, as we've seen in an earlier post.
Now that everything is tested, I can transfer the new code to the production
server, apt-get upgrade cubicweb 3.9 and its dependencies, and eventually
upgrade the production instance.
This is a somewhat long post that starts showing you the way CubicWeb provides a
highly configurable user interface, as well as powerful and reusable
components. And there are a lot of others like those!
So see you next time for part V, where we'll probably want to do more ui stuff!
CubicWeb 3.9.0 went out last week. We now have tested it in production and fixed the remaining bugs, which means it is now show time!
The 3.9 release development was started by a one week long sprint at the
beginning of May. The two goals were first to make it easier to customize the look and
feel of a CubicWeb application, and second to do a big cleanup of the javascript
library. This led to the following major changes.
- We introduced property sheets, which replace former external_resources
file, as well as define some constants that will be used to 'compile' cubicweb
and cubes' stylesheets.
- We started a new, clean cubicweb.css stylesheet, that tries to keep up
with the rhythm. This is still a work in progress, and by default the old
css is still used, unless specified otherwise in the configuration file.
- We set the bases for web functional testing using windmill. See test cases
in cubicweb/web/test/windmill/ and python wrapper in
cubicweb/web/test_windmill/ if you want to use this in your own cube.
- We set the bases for javascript unit-testing using qunit. See test cases in
cubicweb/web/test/jstests/ and python wrapper in
cubicweb/web/test_jscript/ if you want to use this in your own cube.
- We cleaned the javascript code: the generic stuff moved into the cw
namespace, the ajax api is now much simpler thanks to more generic and
powerful functions. As usual backward compatibility was kept, which means
that your existing code will still run, but you will see tons of deprecation
warnings in the firebug console.
- We implemented a simple documentation extraction system for javascript.
Just put ReST in javascript comments, and get all the power of sphinx
for documenting your javascript code.
But that's not all! There are also two major changes in 3.9.
The first major change is the introduction of adapters, also found in the
Zope Component Architecture and documented in the GoF book. This will
allow for better application design and easier code reuse. You
can see several usage in the framework, for instance the "ITree" adapter in
cubicweb.entities.adapters, the "IBreadCrumbs" adapter in
cubicweb.web.views.ibreadcrumbs, or still the "ICalendarable" adapter in
cubicweb.web.views.calendar.
The second major change will benefit directly to end users: we worked with our
friends from SecondWeb to expose the ranking feature found in postgres
full-text search. This clearly improves the user experience when doing
full-text searches. Ranking may be finely tuned by setting different weights
to entity types, entity types attributes, or even be dynamically computed
per entity instance. Of course, all this is done in an adapter, see
"IFTIndexableAdapter" in cubicweb/entities/adapters.py.
Other minor changes include:
- support for wildcard text search for application using postgres >= 8.4 as
backend. Try searching for 'cub*' on cubicweb.org for instance.
- inline edition of composite relation
- nicer, clickable, schema image of the data model
- enhanced support for the SQLserver database
Enjoy!
The HAVING clause, as in SQL, has been originally introduced to restrict a query according to value returned by an aggregat function, e.g.:
Any X GROUPBY X WHERE X relation Y HAVING COUNT(Y) > 10
It may however be used for something else...
For instance, let's say you want to get people whose uppercased first name equals to another person uppercased first name. Since in the WHERE clause, we are limited to 3-expression (<subject> <relation> <object>), such thing can't be expressed (believe me or try it out). But this can be expressed using HAVING comparison expression:
Person X WHERE X firstname XFN, Y firstname YFN HAVING X > Y, UPPER(XFN) = UPPER(YFN)
Nice, no? This open some new possibilities. Another example:
Person X WHERE X birthday XB HAVING YEAR(XB) = 2000
Get it? That lets you use transformation functions not only in selection but for restriction as well, which was the major flaw in the RQL language.
Notice that while we would like this to work without the HAVING clause, this can't be currently be done because it introduces an ambiguity in RQL's grammar that can't be handled by yapps, the parser's generator we're using.
The 'reledit' feature is the one that makes attributes/relations editable in entity's primary view for authorized users (you know, the pen that appears when your mouse is over a field's value, clicking on it making a form to edit this field appears).
This is a nice feature, but you may not want it. It can be easily deactivated everywhere it's used automatically in the site by using the code snippet below:
from cubicweb.web.views import editforms
class DeactivatedAutoClickAndEditFormView(editforms.AutoClickAndEditFormView):
def should_edit_attribute(self, entity, rschema, form):
return False
def should_edit_relation(self, entity, rschema, role, rvid):
return False
def registration_callback(vreg):
vreg.register_and_replace(DeactivatedAutoClickAndEditFormView,
editforms.AutoClickAndEditFormView)
To avoid cluttering my database, and to ease file manipulation, I don't want
them to be stored in the database. I want to be able create File/Image entities
for some files on the server file system, where those file will be accessed to
get entities data. To do so, I've to set a custom BytesFileSystemStorage storage
for the File/Image 'data' attribute, which holds the actual file's content.
Since the function to register a custom storage needs to have a repository
instance as a first argument, we have to call it in a server startup hook. So I added it
in cubes/sytweb/hooks.py :
from os import makedirs
from os.path import join, exists
from cubicweb.server import hook
from cubicweb.server.sources import storage
class ServerStartupHook(hook.Hook):
__regid__ = 'sytweb.serverstartup'
events = ('server_startup', 'server_maintenance')
def __call__(self):
bfssdir = join(self.repo.config.appdatahome, 'bfss')
if not exists(bfssdir):
makedirs(bfssdir)
print 'created', bfssdir
storage = storages.BytesFileSystemStorage(bfssdir)
set_attribute_storage(self.repo, 'File', 'data', storage)
set_attribute_storage(self.repo, 'Image', 'data', storage)
- how we built the hook's registry identifier (_regid__): you can introduce
'namespaces' by using their python module like naming identifiers. This is
especially important for hooks where you usually want a new custom hook, not
overriding / specializing an existent one, but the concept may be used for
any application objects
- we catch two events here: "server_startup" and "server_maintenance". The first
is called on regular repository startup (eg, as a server), the other for
maintenance task such as shell or upgrade. In both cases, we need to have
the storage set, else we'll be in trouble...
- the path given to the storage is the place where a file added through the ui
(or in the database before migration) will be located
- be aware that by doing this, you can't write queries that will try to
restrict on the File and the Image data attribute anymore. Thankfully we don't usually do that
on a file's content or more generally on attributes for the Bytes type
Now, if you've already added some photos through the web ui, you'll have to
migrate existing data so that the file's content will be stored on the file-system instead
of the database. There is a migration command to do so, let's run it in the
cubicweb shell (in actual life, you'd have to put it in a migration script as we
saw last time):
$ cubicweb-ctl shell sytweb
entering the migration python shell
just type migration commands or arbitrary python code and type ENTER to execute it
type "exit" or Ctrl-D to quit the shell and resume operation
>>> storage_changed('File', 'data')
[........................]
>>> storage_changed('Image', 'data')
[........................]
That's it. Now, the files added through the web ui will have their content stored on
the file-system, and you'll also be able to import files from the file-system as
explained in the next part.
Hey, we're starting to have some nice features, let's give this new web
site a try. For instance if I have a 'photos/201005WePyrenees' containing pictures for
a particular event, I can import it to my web site by typing
$ cubicweb-ctl fsimport -F sytweb photos/201005WePyrenees/
** importing directory /home/syt/photos/201005WePyrenees
importing IMG_8314.JPG
importing IMG_8274.JPG
importing IMG_8286.JPG
importing IMG_8308.JPG
importing IMG_8304.JPG
The -F option tell that folders should be mapped, hence my photos will be
all under a Folder entity corresponding to the file-system folder.
Let's take a look at the web ui:
Nothing different, I can't see the new folder... But remember our security model!
By default, files are only accessible to authenticated users, and I'm looking at
the site as anonymous, e.g. not authenticated. If I login, I can now see:
Yeah, it's there! You can also notice that I can see some entities as well as
folders and images the anonymous users can't. It just works everywhere in
the ui since it's handled at the repository level, thanks to our security model.
Now if I click on the newly inserted folder, I can see
Great! I get my pictures in the folder. I can now give
a nicer name to this folder (provided I don't intend to import from it anymore, else already
imported photos will be reimported), change permissions, title for some
pictures, etc... Having good content is much more difficult than having a
good web site ;)
We started to see here an advanced feature of our repository: the ability
to store some parts of our data-model into a custom storage, outside the
database. There is currently only the BytesFileSystemStorage available,
but you can expect to see more coming in a near future.
Also, we can now start to feed our web-site with some nice pictures!
The site isn't perfect (far from it actually) but it's usable, and we can
start using it and improve it on the way. The Incremental Cubic Way :)
So see you next time to start tweaking the user interface!
CubicWeb 3.8.0 went out last week, but now we have tested it, produced
a 3.8.1, it's show time!
One of the most important change is http server update to move from deadend
twisted.web2 to twisted.web. With this change comes the possibility to configure
the maximum size of POST request in the configuration file (was hard-coded to
100Mo before).
Other changes include:
- CubicWeb should now be installable through pip or easy_install.
This is still experimental, and we don't use it that much so please,
give us some feedback! Some cubes are now also "pipable" (comment, blog...),
but more will come with new releases.
- .execute() function lost its cache key argument. This is great news since
it was a pain to explain and most cubicweb users didn't know how to handle
it well (and I'm thre greatest beneficer since I won't have to explain over
and over again)
- nicer schema and workflow views
- refactored web session handling, which should now be cleaner, clearer, hence
less buggy...
- nicer skeleton generation for new cubes, cleaner __pkginfo__ (you don't have
to define both __depends__ / __depends_cubes__ or __recommends__ /
__recommends_cubes__ in the general case, and other cleanups)
Enjoy!
This post will cover various topics:
- configuring security
- migrating an existing instance
- writing some unit tests
Here are the read permissions I want:
- folders, files, images and comments should have one of the following visibility rules:
- 'public', everyone can see it
- 'authenticated', only authenticated users can see it
- 'restricted', only a subset of authenticated users can see it
- managers (e.g. me) can see everything
- only authenticated users can see people
- everyone can see classifier entities (tag and zone)
Also, unless explicity specified, the visibility of an image should be the same as
the visibility of its parent folder and the visibility of a comment should be the same as the
one of the commented entity. If there is no parent entity, the default visibility is
'authenticated'.
Regarding write permissions, that's much easier:
- the anonymous user can't write
- authenticated users can only add comment
- managers will add the remaining stuff
Now, let's implement that!
Proper security in CubicWeb is done at the schema level, so you don't have to
bother with it in the views, for the users will only see what they have access to.
In the schema, you can grant access according to groups or RQL expressions (users
get access if the expression return some results). To implements the read
security defined above, groups are not enough, we'll need to use RQL expressions. Here
is the idea:
- add a visibility attribute on folder, image and comment, with a vocabulary
('public', 'authenticated', 'restricted', 'parent')
- add a may_be_read_by relation that links folder, image or comment to users,
- add hooks to propagate permission changes.
So the first thing to do is to modify the schema.py of my cube to define these
relations:
from yams.constraints import StaticVocabularyConstraint
class visibility(RelationDefinition):
subject = ('Folder', 'File', 'Image', 'Comment')
object = 'String'
constraints = [StaticVocabularyConstraint(('public', 'authenticated',
'restricted', 'parent'))]
default = 'parent'
cardinality = '11' # required
class may_be_read_by(RelationDefinition):
subject = ('Folder', 'File', 'Image', 'Comment',)
object = 'CWUser'
We can note the following points:
- we've added a new visibility attribute to folder, file, image and comment
using a RelationDefinition
- cardinality = '11' means this attribute is required. This is usually hidden
under the required argument given to the String constructor, but we can
rely on this here (same thing for StaticVocabularyConstraint, which is usually
hidden by the vocabulary argument)
- the 'parent' possible value will be used for visibility propagation
Now, we should be able to define security rules in the schema, based on these new
attribute and relation. Here is the code to add to schema.py:
from cubicweb.schema import ERQLExpression
VISIBILITY_PERMISSIONS = {
'read': ('managers',
ERQLExpression('X visibility "public"'),
ERQLExpression('X visibility "authenticated", U in_group G, G name "users"'),
ERQLExpression('X may_be_read_by U')),
'add': ('managers',),
'update': ('managers', 'owners',),
'delete': ('managers', 'owners'),
}
AUTH_ONLY_PERMISSIONS = {
'read': ('managers', 'users'),
'add': ('managers',),
'update': ('managers', 'owners',),
'delete': ('managers', 'owners'),
}
CLASSIFIERS_PERMISSIONS = {
'read': ('managers', 'users', 'guests'),
'add': ('managers',),
'update': ('managers', 'owners',),
'delete': ('managers', 'owners'),
}
from cubes.folder.schema import Folder
from cubes.file.schema import File, Image
from cubes.comment.schema import Comment
from cubes.person.schema import Person
from cubes.zone.schema import Zone
from cubes.tag.schema import Tag
Folder.__permissions__ = VISIBILITY_PERMISSIONS
File.__permissions__ = VISIBILITY_PERMISSIONS
Image.__permissions__ = VISIBILITY_PERMISSIONS
Comment.__permissions__ = VISIBILITY_PERMISSIONS.copy()
Comment.__permissions__['add'] = ('managers', 'users',)
Person.__permissions__ = AUTH_ONLY_PERMISSIONS
Zone.__permissions__ = CLASSIFIERS_PERMISSIONS
Tag.__permissions__ = CLASSIFIERS_PERMISSIONS
What's important in there:
- VISIBILITY_PERMISSIONS provides read access to an entity:
- if user is in the 'managers' group,
- or if visibility attribute's value is 'public',
- or if visibility attribute's value is 'authenticated' and user (designed by the 'U' variable in the expression) is in
the 'users' group (all authenticated users are expected to be in this group)
- or if user is linked
to the entity (the 'X' variable) through the may_be_read_by permission
- we modify permissions of the entity types we use by importing them and
modifying their __permissions__ attribute
- notice the .copy(): we only want to modify 'add' permission for Comment,
not for all entity types using VISIBILITY_PERMISSIONS!
- remaning parts of the security model is done using regular groups:
- 'users' is the group to which all authenticated users will belong
- 'guests' is the group of anonymous users
To fullfill our requirements, we have to implement:
Also, unless explicity specified, the visibility of an image should be the same as
the visibility of its parent folder and the visibility of a comment should be the same as the
one of the commented entity. If there is no parent entity, the default visibility is
'authenticated'.
This kind of 'active' rule will be done using CubicWeb's hook system. Hooks are
triggered on database event such as addition of new entity or relation.
The tricky part of the requirement is in unless explicitly specified, notably
because when the entity addition hook is executed, we don't know yet its 'parent'
entity (eg folder of an image, image commented by a comment). To handle such things,
CubicWeb provides Operation, which allow to schedule things to do at commit time.
In our case we will:
- on entity creation, schedule an operation that will set default visibility
- when a "parent" relation is added, propagate parent's visibility unless the
child already has a visibility set
Here is the code in cube's hooks.py:
from cubicweb.selectors import implements
from cubicweb.server import hook
class SetVisibilityOp(hook.Operation):
def precommit_event(self):
for eid in self.session.transaction_data.pop('pending_visibility'):
entity = self.session.entity_from_eid(eid)
if entity.visibility == 'parent':
entity.set_attributes(visibility=u'authenticated')
class SetVisibilityHook(hook.Hook):
__regid__ = 'sytweb.setvisibility'
__select__ = hook.Hook.__select__ & implements('Folder', 'File', 'Image', 'Comment')
events = ('after_add_entity',)
def __call__(self):
hook.set_operation(self._cw, 'pending_visibility', self.entity.eid,
SetVisibilityOp)
class SetParentVisibilityHook(hook.Hook):
__regid__ = 'sytweb.setparentvisibility'
__select__ = hook.Hook.__select__ & hook.match_rtype('filed_under', 'comments')
events = ('after_add_relation',)
def __call__(self):
parent = self._cw.entity_from_eid(self.eidto)
child = self._cw.entity_from_eid(self.eidfrom)
if child.visibility == 'parent':
child.set_attributes(visibility=parent.visibility)
Remarks:
- hooks are application objects, hence have selectors that should match entity or
relation type to which the hook applies. To match relation type, we use the
hook specific match_rtype selector.
- usage of set_operation: instead of adding an operation for each added entity,
set_operation allows to create a single one and to store the eids of the entities
to be processed in the session transaction data. This is a good pratice to avoid heavy
operations manipulation cost when creating a lot of entities in the same
transaction.
- the precommit_event method of the operation will be called at transaction's
commit time.
- in a hook, self._cw is the repository session, not a web request as usually
in views
- according to hook's event, you have access to different member on the hook
instance. Here:
- self.entity is the newly added entity on 'after_add_entity' events
- self.eidfrom / self.eidto are the eid of the subject / object entity on
'after_add_relation' events (you may also get the relation type using
self.rtype)
The 'parent' visibility value is used to tell "propagate using parent security"
because we want that attribute to be required, so we can't use None value else
we'll get an error before we get any chance to propagate...
Now, we also want to propagate the may_be_read_by relation. Fortunately,
CubicWeb provides some base hook classes for such things, so we only have to add
the following code to hooks.py:
# relations where the "parent" entity is the subject
S_RELS = set()
# relations where the "parent" entity is the object
O_RELS = set(('filed_under', 'comments',))
class AddEntitySecurityPropagationHook(hook.PropagateSubjectRelationHook):
"""propagate permissions when new entity are added"""
__regid__ = 'sytweb.addentity_security_propagation'
__select__ = (hook.PropagateSubjectRelationHook.__select__
& hook.match_rtype_sets(S_RELS, O_RELS))
main_rtype = 'may_be_read_by'
subject_relations = S_RELS
object_relations = O_RELS
class AddPermissionSecurityPropagationHook(hook.PropagateSubjectRelationAddHook):
__regid__ = 'sytweb.addperm_security_propagation'
__select__ = (hook.PropagateSubjectRelationAddHook.__select__
& hook.match_rtype('may_be_read_by',))
subject_relations = S_RELS
object_relations = O_RELS
class DelPermissionSecurityPropagationHook(hook.PropagateSubjectRelationDelHook):
__regid__ = 'sytweb.delperm_security_propagation'
__select__ = (hook.PropagateSubjectRelationDelHook.__select__
& hook.match_rtype('may_be_read_by',))
subject_relations = S_RELS
object_relations = O_RELS
- the AddEntitySecurityPropagationHook will propagate the relation
when filed_under or comments relations are added
- the S_RELS and O_RELS set as well as the match_rtype_sets selector are
used here so that if my cube is used by another one, it'll be able to
configure security propagation by simply adding relation to one of the two
sets.
- the two others will propagate permissions changes on parent entities to
children entities
Security is tricky. Writing some tests for it is a very good idea. You should
even write them first, as Test Driven Development recommends!
Here is a small test case that'll check the basis of our security model, in
test/unittest_sytweb.py:
from cubicweb.devtools.testlib import CubicWebTC
from cubicweb import Binary
class SecurityTC(CubicWebTC):
def test_visibility_propagation(self):
# create a user for later security checks
toto = self.create_user('toto')
# init some data using the default manager connection
req = self.request()
folder = req.create_entity('Folder',
name=u'restricted',
visibility=u'restricted')
photo1 = req.create_entity('Image',
data_name=u'photo1.jpg',
data=Binary('xxx'),
filed_under=folder)
self.commit()
photo1.clear_all_caches() # good practice, avoid request cache effects
# visibility propagation
self.assertEquals(photo1.visibility, 'restricted')
# unless explicitly specified
photo2 = req.create_entity('Image',
data_name=u'photo2.jpg',
data=Binary('xxx'),
visibility=u'public',
filed_under=folder)
self.commit()
self.assertEquals(photo2.visibility, 'public')
# test security
self.login('toto')
req = self.request()
self.assertEquals(len(req.execute('Image X')), 1) # only the public one
self.assertEquals(len(req.execute('Folder X')), 0) # restricted...
# may_be_read_by propagation
self.restore_connection()
folder.set_relations(may_be_read_by=toto)
self.commit()
photo1.clear_all_caches()
self.failUnless(photo1.may_be_read_by)
# test security with permissions
self.login('toto')
req = self.request()
self.assertEquals(len(req.execute('Image X')), 2) # now toto has access to photo2
self.assertEquals(len(req.execute('Folder X')), 1) # and to restricted folder
if __name__ == '__main__':
from logilab.common.testlib import unittest_main
unittest_main()
It is not complete, but it shows most of the things you will want to do in tests: adding some
content, creating users and connecting as them in the test, etc...
To run it type:
[syt@scorpius test]$ pytest unittest_sytweb.py
======================== unittest_sytweb.py ========================
-> creating tables [....................]
-> inserting default user and default groups.
-> storing the schema in the database [....................]
-> database for instance data initialized.
.
----------------------------------------------------------------------
Ran 1 test in 22.547s
OK
The first execution is taking time, since it creates a sqlite database for the
test instance. The second one will be much quicker:
[syt@scorpius test]$ pytest unittest_sytweb.py
======================== unittest_sytweb.py ========================
.
----------------------------------------------------------------------
Ran 1 test in 2.662s
OK
If you do some changes in your schema, you'll have to force regeneration of that
database. You do that by removing the tmpdb* files before running the test:
[syt@scorpius test]$ rm tmpdb*
BTW, pytest is a very convenient utilities to control test execution, from the logilab-common package.
Prior to those changes, Iv'e created an instance, fed it with some data, so I
don't want to create a new one, but to migrate the existing one. Let's see how to
do that.
Migration commands should be put in the cube's migration directory, in a
file named file:<X.Y.Z>_Any.py ('Any' being there mostly for historical reason).
Here I'll create a migration/0.2.0_Any.py file containing the following
instructions:
add_relation_type('may_be_read_by')
add_relation_type('visibility')
sync_schema_props_perms()
Then I update the version number in cube's __pkginfo__.py to 0.2.0. And
that's it! Those instructions will:
- update the instance's schema by adding our two new relations and update the
underlying database tables accordingly (the two first instructions)
- update schema's permissions definition (the later instruction)
To migrate my instance I simply type:
[syt@scorpius ~]$ cubicweb-ctl upgrade sytweb
I will then be asked some questions to do the migration step by step. You should say
YES when it asks if a backup of your database should be done, so you can get back
to the initial state if anything goes wrong...
This is a somewhat long post that I bet you will have to read at least twice ;)
There is a hell lot of information hidden in there... But that should start
to give you an idea of CubicWeb's power...
See you next time for part III!
- photo gallery;
- photo stored onto the fs and displayed through a web interface dynamically;
- navigation through folder (album), tags, geographical zone, people on the
picture... using facets;
- advanced security (eg not everyone can see everything). More on this later.
One note about my development environment: I wanted to use packaged version of
CubicWeb and cubes while keeping my cube in my user directory, let's say ~src/cubes.
It can be done by setting the following environment variables:
CW_CUBES_PATH=~/src/cubes
CW_MODE=user
The new cube, holding custom code for this web site, can now be created using:
cubicweb-ctl newcube --directory=~/src/cubes sytweb
Almost everything I want to represent in my web-site is somewhat already modelized in
existing cubes that I'll extend for my needs:
- folder, containing Folder entity type, which will be used as both 'album' and
a way to map file system folders. Entities are added to a given folder using the
filed_under relation.
- file, containing File and Image entity type, gallery view, and a file system
import utility.
- zone, containing the Zone entity type for hierarchical geographical
zones. Entities (including sub-zones) are added to a given zone using the
situated_in relation.
- person, containing the Person entity type plus some basic views.
- comment, providing a full commenting system allowing one to comment entity types
supporting the comments relation by adding a Comment entity.
- tag, providing a full tagging system as an easy and powerful way to classify
entities supporting the tags relation by linking the to Tag entities. This
will allow navigation into a large number of pictures.
Ok, now I'll tell my cube requires all this by editing cubes/sytweb/__pkginfo__.py:
__depends_cubes__ = {'file': '>= 1.2.0',
'folder': '>= 1.1.0',
'person': '>= 1.2.0',
'comment': '>= 1.2.0',
'tag': '>= 1.2.0',
'zone': None,
}
__depends__ = {'cubicweb': '>= 3.5.10',
}
for key,value in __depends_cubes__.items():
__depends__['cubicweb-'+key] = value
__use__ = tuple(__depends_cubes__)
Notice that you can express minimal version of the cube that should be used, None meaning whatever version available.
from yams.buildobjs import RelationDefinition
class comments(RelationDefinition):
subject = 'Comment'
object = ('File', 'Image')
cardinality = '1*'
composite = 'object'
class tags(RelationDefinition):
subject = 'Tag'
object = ('File', 'Image')
class filed_under(RelationDefinition):
subject = ('File', 'Image')
object = 'Folder'
class situated_in(RelationDefinition):
subject = 'Image'
object = 'Zone'
class displayed_on(RelationDefinition):
subject = 'Person'
object = 'Image'
This schema:
- allows to comment and tag File and Image entity types by adding the
comments and tags relations. This should be all we have to do for this
feature since the related cubes provide 'pluggable section' which are
automatically displayed in the primary view of entity types supporting the
relation.
- adds a situated_in relation definition so that image entities can be
geolocalized.
- add a new relation displayed_on relation telling who can be seen on a
picture.
This schema will probably have to evolve as time goes (for security handling at
least), but since the possibility to change and update the schema evolving
is one of CubicWeb features (and goals), we won't worry and see that later when needed.
Now that I have a schema, I want to create an instance of that new 'sytweb'
cube, so I run:
cubicweb-ctl create sytweb sytweb_instance
hint: if you get an error while the database is initialized, you can avoid having to reanswer to questions by running
cubicweb-ctl db-create sytweb_instance
This will use your already configured instance and start directly from
the database creation step, thus skipping questions asked by the 'create'
command.
Once the instance and database are fully initialized, run
cubicweb-ctl start sytweb_instance
to start the instance, check you can connect on it, etc...
We will customize the index page, see security configuration, use the Bytes FileSystem Storage... Lots of cool stuff remaining :)
And that's great news, after several months of development (things started moving
in the beginning of august 2009...), it should be available on our Debian repositories
and ftp site in the next few hours.
So, we can say this release contains a (too) large set of improvements and
refactorings. I'll talk about the most important ones here.
First of all, the namespace cleanup... 3.6 is a step towards cleaning the entity
classes (hence more generally appobject), which are used for a lot of
things, making it impossible to tell for sure what could be used or not as an
attribute or relation name. We decided to declare identifiers starting with \_cw or cw\_
reserved for the core classes. A lot of methods have been deprecated to cleanup the
base appobject class namespace. The remaining methods on entity classes will
be removed in future version, by the introduction of an ORM for database related
methods, and by the (most probable) introduction of ZCA adapters for other aspects.
The most notable renaming are:
- .req -> ._cw
- .rset -> .cw_rset
- .row -> .cw_row
- .col -> .cw_col
This is probably what you'll see first when upgrading to 3.6: a huge stack of deprecation warnings on your screen :)
Hooks are now regular appobjects, with selectors (don't forget to reuse
Hook.__select__, remember that !). They should simply implement __call__
with no argument (well, only self) and will get info previously passed as
argument as instance attributes, according to the matching event.
EnvBasedTC, ControllerTC, WebTest, RepoBasedTC are all gone. Simply use
CubicWebTC, with an unified API similar to what you use in cubicweb-ctl shell and in usual development.
You can now specify a custom storage for attributes of entities stored in the
system source. This mechanism is used to provide a way to store Bytes attributes
(such as File.data for instance) as files on the file-system instead of BLOBs in
the database. You can configure which attributes should use this storage for your instance and then everything is transparent.
In your schema definition file:
- "symetric" should be correctly spelled "symmetric" :)
- "permissions" was renamed to "__permissions__"
Also, permissions for relations are now supported per definition, not per type, at the cost of a visible impact when writing/reading the schema.
We worked hard to keep backward compatibility, but you shouldn't upgrade to 3.6 without checking that everything is fine... Check notably:
- forms, if you're using custom forms by overriding internal methods
- import for date functions from cubicweb.utils (they moved to logilab.common.date)
CubicWeb 3.6 comes with a set of 37 cubes "3.6"-ready to avoid too much warnings!
Enjoy!
We held a one day sprint last week in our Paris office, trying to improve CubicWeb's documentation.
There is a huge work to do on this, much more than we can do on a one day sprint, even with many people. But you have to begin with something :)
So, after a quick meeting to define priorities:
- Stéphanie, Charles and later Sandrine (from her US home-office), began to add some documentation and screenshots to cubes. They started with the following cubes: addressbook, person, basket, tag, folder, forgotpwd, forge, tracker, vcsfile, keyword, blog and comment.
- Julien explored sphinx abilities to build the index and extract docstrings. He applied this to improve the documentation of selectors.
- Adrien (ach) and Celso, our friend from Mexico, tackled the task to improve the tutorial from a beginner's point of view.
- Arthur added some pieces of documentation found in our intranet, mailing-list...
- Pyves worked on a cubicweb-ctl command to generate schema images (png) for cubes, to include them in the cube's documentation.
- Adrien (adim) and I helped the various teams.
Huum, I think I did not forgot anyone...
If there is still a lot to do (we need more doc sprints, stay tuned), this is really a nice start! This site should soon be updated to include more valuable cubes description and online documentation extracted from the contributed doc.
Last week we held a cubicweb sprint in our new Paris office !
We were a nice number of people: 7 from the Logilab's crew, including Sandrine, our US representative, Celso and Carlos from Mexico, plus some others guests and colleagues working on (cubicweb based of course) customer projects.
The objective of the sprint was to kick out the 3.6 version of cubicweb, a big refactoring release started by Adrien and I a few months ago. Unfortunatly we had been preempted by some other projects and the cubicweb development branch was simply painfully following changes done in the stable branch.
Also, we decided to start using mq as a basis for code review. The sprint was a nice opportunity to test and see if it was actually usable for both developer and code reviewer. But more on this latter :)
The tasks to achieve to get this release out were:
- resurrect the default branch after 3 months of nasty bugs introduced by simply merging from the stable branch without any time to test
- update main cubes to the new test / uicfg / hooks / members api
- finish the editcontroller (which handle post of most web forms) refactoring
- finish the relation permissions change, including migration
- update the documentation
- test real applications
Of course this was ambitious :) Among those point 0. and 1. and 3. took us much more time than I expected. The editcontroller work (2.) has not been finished yet, and we didn't find any time for the documentation (4.).
Besides this, everyone (well, me at least ;) enjoyed its time while working hard all together in our new meeting room! The 3.6 version still needs a little work before being released, but the development branch is definitly back, with a great bunch of cubes ready. Among them : comment, tag, blog, keyword, tracker, forge, card, nosylist, etc...
So many thanks to everyone, and particularly to our Mexican friends Carlos and Celso... Tequila! ;)
By the way the good news is that we plan to do more sprints like this now that we've some room for it!
|
