20120714

Acting as somebody else

Lino now generally supports “acting as somebody else” (aka “switching between different user roles”).

  • New table Authorities (Vollmächte) : In your user settings you can give authorities to other users. These other users then get the possibility to act in your name.

  • For users who have authority to act as at least one other user, the “User button” (in the top right corner) is now a menu with two entries:

    • “My settings” (the action which until now was triggered by the simple button)

    • “Act as…” which opens a submenu containing one entry for each user who has given me a mandate.

  • System administrators (User.level >= ‘admin’ have automatic authority to act in any user’s name.

This caused quite some little code changes: (search for subst_user and is_home_page in linolib.js and ext_ui.py). subst_user is now parsed and handled already in the middleware (lino.utils.auth). The last problem was: when acting as somebody else, after updating an event in the CalendarPanel (e.g. by resizing it), the PUT request didn’t pass the su parameter. Which lead to a wrong summary field (the one for the real user). Lino.set_subst_user also configures the eventStore. Reproduceable in http://127.0.0.1:8000/api/cal/Panel and http://127.0.0.1:8000/api/cal/Panel?su=7 after resizing an existing event.

http://code.google.com/p/lino/source/detail?r=8c6d25d02f2f.

My settings

As noted earlier, users who are not system administrators were not able to edit their own User Detail. Lino even doesn’t generate the definition for the User Detail form because they have no access to users.Users.

  1. Benutzer, die nicht Systemverwalter sind, können momentan ihr Benutzerkonto nichtmal sehen: ein Klick auf den Benutzerbutton oben rechts führt zu einer Fehlermeldung in der JS-Console.

    Da will ich noch was drüber meditieren. Liegt daran, dass ein Detail-Fenster momentan die gleichen Zugriffsbedingungen (required) hat wie die Tabelle, in der es definert ist (für users.User ist das users.Users), und weil instance_handler einfach die detail_action der _lino_default_table ohne nachzuprüfen, ob der Benutzer die view permission hat. Am besten wäre wahrscheinlich, wenn instance_handler() (und href_to(),row_summary()… ) den Benutzer mitbekommen und es nachprüfen, und wenn wir ein DetailLayout separat mit required versehen können.

Solved this using the new actor lino.modlib.users.models.MySettings.

Miscellaneous

  • The references to the source files of each in https://www.lino-framework.org/autodoc/index.html weren’t correct when it was a package. New function lino.utils.srcref() used in /docs/conf.py.

  • translations

  • ManageAccessRequest now also has a separate insert_layout. Several fields were (wrongly) declared blank=True.

  • Uploads now also has a separate insert_layout. Adding an Upload is more intuitive.

  • Worked on lino.tutorials.t1.

  • summary_row is now being called with the ar and not the ui as first argument.

  • Team.eml.html now uses HttpRequest.build_absolute_uri for the link:

    <a href="$ar.request.build_absolute_uri('/api/cal/MyPendingInvitations')">Meine offenen erhaltenen Einladungen</a>
    

    And even better:

    <a href="$ar.absolute_uri("cal.MyPendingInvitations")">Meine offenen erhaltenen Einladungen</a>
    

The national_id field of ManageAccessRequest may not be blank, but WithPerson (where it is defined) doesn’t know that. It declares the field with blank=False. So I added the following to cbss.models:

dd.update_field(ManageAccessRequest,'national_id',blank=False,help_text="""\
The SSIN of the person to register/unregister/list.
""")

Later I got a ValidationError “{‘national_id’: [u’Dieses Feld darf nicht leer sein.’]}” for an IdentifyPersonRequest.

Explanation: the WithPerson mixin wrongly wasn’t declared abstract. So I had an additional database table without even noticing it: +1 for Django!