esme-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Richard Hirsch <hirsch.d...@gmail.com>
Subject Re: Big (first) commit
Date Fri, 01 Jan 2010 08:10:37 GMT
Strange that your commit was registered on this list....

Other comments inline


On Fri, Jan 1, 2010 at 12:47 AM, Ethan Jewett <esjewett@gmail.com> wrote:
> This is kind of making me cringe, but I have several modifications
> that I now am having great difficulty sorting out from each other, so
> for my first commit I'm doing a no-no and going with one really big
> commit. Now that I can create branches and get commits in more easily,
> this shouldn't happen again.
>
> In the latest commit (diff attached), there are mostly new and
> improved tests for the API2 endpoint, as well as the addition of
> several administration/integration-oriented methods requested by Sig &
> team (with tests!). However, there are a few things I think everyone
> should look at:

This is good, because it means that Sig might be able to return to the
official subversion version rather than his own hacked version.

>
> 1. I've added two things to the User object in the User.scala file: A
> new private object "currentRole", and a new method "checkRole". I'm
> using these for the role-based authorization on the new API methods
> (see below).
>
> 2. Role-based authorization checks in API2.scala (see "def authorizationRules")
>
> 3. Adding the role-based authorization checks to the
> LiftRules.dispatch table *before* the API2 methods (see
> "LiftRules.dispatch.append(API2.authorizationRules)")
>
> The way these roles work is that you assign the role to a user in a
> .props file. test.default.props is an example that is used in the unit
> tests of the new API methods and the authorization wrapped around
> them. In a production system you would need to use
> production.default.props
>
> Eventually we should make this use the Lift AuthRole in some manner,
> if only because of the hierarchical structure it supports. We could
> also just create our own role system, but I don't know if I want to be
> responsible for that. I'm not currently using Lift roles because of
> some issues I outlined on the main esme-dev list.

I think this is fine for now but we don't want to recreate the lift
authorization functionality. Is there a migration path possible?

>
> Ok, that's probably enough about this particular commit. These will be
> much shorter in the future also :-)
>
> Also, is there any particular commit message format we're supposed to use?


[ESME-xxx] JIRA title
Extra text

xxx = number from Jira
JIRA title = Jira title
Extra text is optional and says whether it is a patch, etc.

>
> Happy New Year everyone,
> Ethan
>

Mime
View raw message