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)

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.