Re: Ponder and ERRest (was "Re: ERGroupware and ERRest")
Re: Ponder and ERRest (was "Re: ERGroupware and ERRest")
- Subject: Re: Ponder and ERRest (was "Re: ERGroupware and ERRest")
- From: Ramsey Gurley <email@hidden>
- Date: Mon, 05 Oct 2015 14:32:32 -0700
ERUsers can probably do what you want. You would create a role named Admin and then override the
10 : (entity.model.name = 'ERUsers' or pageConfiguration = 'CreateERUser') => crudAuthorization = "er.users.delegates.AuthorizationDelegate.INSTANCE" [ERDEnumAssignment]
rule with something like
100: (entity.model.name = ‘ERUsers’ and session.objectStore.user.roles.roleName contains ‘Admin’) => crudAuthorization = “er.auth.SimpleCRUDAuthorization.ALLOW_ALL” [ERDEnumAssignment]
or some other CRUDAuthorization instance that allows you to do what you want.
On Oct 5, 2015, at 1:18 PM, Flavio Donadio <email@hidden> wrote:
> I must be insane! I didn’t mean ERGroupware, but Ponder!
>
> Please, replace any occurrence of “ERGroupware” with “Ponder” in my original text.
>
> Sorry for the noise.
>
> Flavio
>
>
>> On 05/10/2015, at 17:08, Flavio Donadio <email@hidden> wrote:
>>
>> Hello,
>>
>>
>> I am on the planning stage of a new REST-web-service-based app with a Cocoa client.
>>
>> In my head, it makes sense to have a web interface (a Direct Action or D2W app) just for user management, where the administrative users would be able to create/edit/delete users and specify their abilities (which entities a user can fetch/create/edit/delete, maybe with roles support). From what I’ve seen, ERGroupware is able to do just that. Am I correct?
>>
>> In my ERRest routes [in the ERRest (main) app], I would check if the user has the necessary ability and act accordingly. I could also have some properties on the client-side app (Cocoa-based) that would drive the UI (enable or disable UI elements) based on user’s abilities/role.
>>
>> Is my logic good so far? Is this feasible?
>>
>>
>> Regards,
>> Flavio
>> _______________________________________________
>> Do not post admin requests to the list. They will be ignored.
>> Webobjects-dev mailing list (email@hidden)
>> Help/Unsubscribe/Update your Subscription:
>>
>> This email sent to email@hidden
>
>
> _______________________________________________
> Do not post admin requests to the list. They will be ignored.
> Webobjects-dev mailing list (email@hidden)
> Help/Unsubscribe/Update your Subscription:
>
> This email sent to email@hidden
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Webobjects-dev mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden