[Building Sakai] How to create and define tools custom roles

[Tiago Gaspar]

Hi Guys,

I'm working on a tool for Sakai that requires specific roles. Not
system-wide roles, but specific tool roles. I couldn't find any
documentation regarding that. I could implement my own solution to the
problem, but I would like to follow the Sakai way of doing it. Is
there a Sakai for doing it? :-)

Appreciate,
Tiago.
_______________________________________________
sakai-dev mailing list
sakai-dev@...
http://collab.sakaiproject.org/mailman/listinfo/sakai-dev

TO UNSUBSCRIBE: send email to sakai-dev-unsubscribe@... with a subject of "unsubscribe"

[Steve Swinsburg-3]

Hi,

Your tool can define its own permissions and then a user in a site  
with those permissions can be granted access to certain functions of  
your tool. The roles aren't system wide, they are site-wide, so this  
should sort you out. The only thing that is system wide are user  
types, but once in a site, a user is assigned a role.

For your tool to register it's own permissions, check out  
authz.api.FunctionManager.

Then, if you go to the Admin Realms tool, find a site then find the  
roles in that site you can set the permissions for the roles. You'd  
then add these updated permissions to the realm templates for new  
sites (and backfill them to existing sites, but thats a separate issue).

You can also see here for some more info about roles in sites:
http://steve-on-sakai.blogspot.com/2009/05/roles-in-sakai-sites.html

cheers,
Steve

On 22/10/2009, at 11:36 AM, Tiago Gaspar wrote:

> Hi Guys,
>
> I'm working on a tool for Sakai that requires specific roles. Not
> system-wide roles, but specific tool roles. I couldn't find any
> documentation regarding that. I could implement my own solution to the
> problem, but I would like to follow the Sakai way of doing it. Is
> there a Sakai for doing it? :-)
>
> Appreciate,
> Tiago.
> _______________________________________________
> sakai-dev mailing list
> sakai-dev@...
> http://collab.sakaiproject.org/mailman/listinfo/sakai-dev
>
> TO UNSUBSCRIBE: send email to sakai-dev-unsubscribe@...
>  with a subject of "unsubscribe"

_______________________________________________
sakai-dev mailing list
sakai-dev@...
http://collab.sakaiproject.org/mailman/listinfo/sakai-dev

TO UNSUBSCRIBE: send email to sakai-dev-unsubscribe@... with a subject of "unsubscribe"

[Tiago Gaspar]

Hi Steve,

Thanks for the response! I liked your suggestion to use Sakai Realms,
it would make permissions much more flexible. But it would require a
manual configuration of roles and permissions every time the tools is
installed. Is there a way a tool itself can do that configuration
through some API, or some config file, in order to make that process
transparent to the sakai admin ?


Thanks again,

Tiago.



On Wed, Oct 21, 2009 at 11:27 PM, Steve Swinsburg
<steve.swinsburg@...> wrote:

> Hi,
>
> Your tool can define its own permissions and then a user in a site with
> those permissions can be granted access to certain functions of your tool.
> The roles aren't system wide, they are site-wide, so this should sort you
> out. The only thing that is system wide are user types, but once in a site,
> a user is assigned a role.
>
> For your tool to register it's own permissions, check out
> authz.api.FunctionManager.
>
> Then, if you go to the Admin Realms tool, find a site then find the roles in
> that site you can set the permissions for the roles. You'd then add these
> updated permissions to the realm templates for new sites (and backfill them
> to existing sites, but thats a separate issue).
>
> You can also see here for some more info about roles in sites:
> http://steve-on-sakai.blogspot.com/2009/05/roles-in-sakai-sites.html
>
> cheers,
> Steve
>
> On 22/10/2009, at 11:36 AM, Tiago Gaspar wrote:
>
>> Hi Guys,
>>
>> I'm working on a tool for Sakai that requires specific roles. Not
>> system-wide roles, but specific tool roles. I couldn't find any
>> documentation regarding that. I could implement my own solution to the
>> problem, but I would like to follow the Sakai way of doing it. Is
>> there a Sakai for doing it? :-)
>>
>> Appreciate,
>> Tiago.
>> _______________________________________________
>> sakai-dev mailing list
>> sakai-dev@...
>> http://collab.sakaiproject.org/mailman/listinfo/sakai-dev
>>
>> TO UNSUBSCRIBE: send email to
>> sakai-dev-unsubscribe@... with a subject of
>> "unsubscribe"
>
>

_______________________________________________
sakai-dev mailing list
sakai-dev@...
http://collab.sakaiproject.org/mailman/listinfo/sakai-dev

TO UNSUBSCRIBE: send email to sakai-dev-unsubscribe@... with a subject of "unsubscribe"

[Steve Swinsburg-3]

Hi Tiago,

Once your tool's service comes up, and it's functions are registered,  
then they are available to the whole system. This happens when Tomcat  
starts your service, not when the tool is added. So, you can then  
backfill this new permission into every role in every site you want  
once Sakai is up.

So lets say you need the permission 'mytool.view' in a certain role in  
your site (say 'access') for your tool to display something. Once  
Tomcat is up, you could go into the Realm for a site that doesn't even  
have the tool installed, and you'll still be able to set the  
permissions for various roles.

Being a fan of the web services, I wrote an additional method to add  
to SakaiScript.jws called copyRole(). If you set the permissions in  
the roles in your !site.template.xxx realm, you can then iterate over  
every site you want and sync up the roles from the template site to  
add this new permission in.

Some more info about this is here:
http://steve-on-sakai.blogspot.com/2009/05/roles-in-sakai-sites.html
under the heading 'Populating new/updated roles to existing sites'.

If you haven't got your web services enabled, see here for how to do  
it, including how to secure them:
http://steve-on-sakai.blogspot.com/2009/05/enabling-web-services-in-sakai-and.html

cheers,
Steve


On 23/10/2009, at 2:05 AM, Tiago Gaspar wrote:

> Hi Steve,
>
> Thanks for the response! I liked your suggestion to use Sakai Realms,
> it would make permissions much more flexible. But it would require a
> manual configuration of roles and permissions every time the tools is
> installed. Is there a way a tool itself can do that configuration
> through some API, or some config file, in order to make that process
> transparent to the sakai admin ?
>
>
> Thanks again,
>
> Tiago.
>
>
>
> On Wed, Oct 21, 2009 at 11:27 PM, Steve Swinsburg
> <steve.swinsburg@...> wrote:
>> Hi,
>>
>> Your tool can define its own permissions and then a user in a site  
>> with
>> those permissions can be granted access to certain functions of  
>> your tool.
>> The roles aren't system wide, they are site-wide, so this should  
>> sort you
>> out. The only thing that is system wide are user types, but once in  
>> a site,
>> a user is assigned a role.
>>
>> For your tool to register it's own permissions, check out
>> authz.api.FunctionManager.
>>
>> Then, if you go to the Admin Realms tool, find a site then find the  
>> roles in
>> that site you can set the permissions for the roles. You'd then add  
>> these
>> updated permissions to the realm templates for new sites (and  
>> backfill them
>> to existing sites, but thats a separate issue).
>>
>> You can also see here for some more info about roles in sites:
>> http://steve-on-sakai.blogspot.com/2009/05/roles-in-sakai-sites.html
>>
>> cheers,
>> Steve
>>
>> On 22/10/2009, at 11:36 AM, Tiago Gaspar wrote:
>>
>>> Hi Guys,
>>>
>>> I'm working on a tool for Sakai that requires specific roles. Not
>>> system-wide roles, but specific tool roles. I couldn't find any
>>> documentation regarding that. I could implement my own solution to  
>>> the
>>> problem, but I would like to follow the Sakai way of doing it. Is
>>> there a Sakai for doing it? :-)
>>>
>>> Appreciate,
>>> Tiago.
>>> _______________________________________________
>>> sakai-dev mailing list
>>> sakai-dev@...
>>> http://collab.sakaiproject.org/mailman/listinfo/sakai-dev
>>>
>>> TO UNSUBSCRIBE: send email to
>>> sakai-dev-unsubscribe@... with a subject of
>>> "unsubscribe"
>>
>>
> _______________________________________________
> sakai-dev mailing list
> sakai-dev@...
> http://collab.sakaiproject.org/mailman/listinfo/sakai-dev
>
> TO UNSUBSCRIBE: send email to sakai-dev-unsubscribe@...
>  with a subject of "unsubscribe"

_______________________________________________
sakai-dev mailing list
sakai-dev@...
http://collab.sakaiproject.org/mailman/listinfo/sakai-dev

TO UNSUBSCRIBE: send email to sakai-dev-unsubscribe@... with a subject of "unsubscribe"

[Tiago Gaspar]

Hi Steve,

I've found a solution that I wanted. Instead of manually creating
specific roles and setting the required permissions in Realms, I'm
using AuthzGroupService to make all those steps transparent to the
Sakai administrator.

The tool automatic creates all the necessary roles and set all the
permissions. Here's some of the code:

     //creates a role
     AuthzGroup ag = authzGroupService.getAuthzGroup(groupId);
     ag.addRole(roleId, roleModel);
     authzGroupService.save(ag);

     //assings a permission
     Role role = ag.getRole(roleId);
     role.allowFunction(permissionId);
     authzGroupService.save(ag);

** the code has been simplified...

The AuthzGroup.addRole (role, roleModel) already creates a role
copying the permissions from another, so I didn't use your webservice.

Here are some useful references:
http://steve-on-sakai.blogspot.com/2009/05/roles-in-sakai-sites.html
http://confluence.sakaiproject.org/display/BOOT/Using+the+AuthzGroup+Service
http://source.sakaiproject.org/release/2.2.1/javadoc/org/sakaiproject/authz/api/AuthzGroup.html

Thanks again for the tips,

Tiago Gaspar.


On Thu, Oct 22, 2009 at 11:46 PM, Steve Swinsburg
<steve.swinsburg@...> wrote:

> Hi Tiago,
>
> Once your tool's service comes up, and it's functions are registered, then
> they are available to the whole system. This happens when Tomcat starts your
> service, not when the tool is added. So, you can then backfill this new
> permission into every role in every site you want once Sakai is up.
>
> So lets say you need the permission 'mytool.view' in a certain role in your
> site (say 'access') for your tool to display something. Once Tomcat is up,
> you could go into the Realm for a site that doesn't even have the tool
> installed, and you'll still be able to set the permissions for various
> roles.
>
> Being a fan of the web services, I wrote an additional method to add to
> SakaiScript.jws called copyRole(). If you set the permissions in the roles
> in your !site.template.xxx realm, you can then iterate over every site you
> want and sync up the roles from the template site to add this new permission
> in.
>
> Some more info about this is here:
> http://steve-on-sakai.blogspot.com/2009/05/roles-in-sakai-sites.html
> under the heading 'Populating new/updated roles to existing sites'.
>
> If you haven't got your web services enabled, see here for how to do it,
> including how to secure them:
> http://steve-on-sakai.blogspot.com/2009/05/enabling-web-services-in-sakai-and.html
>
> cheers,
> Steve
>
>
> On 23/10/2009, at 2:05 AM, Tiago Gaspar wrote:
>
>> Hi Steve,
>>
>> Thanks for the response! I liked your suggestion to use Sakai Realms,
>> it would make permissions much more flexible. But it would require a
>> manual configuration of roles and permissions every time the tools is
>> installed. Is there a way a tool itself can do that configuration
>> through some API, or some config file, in order to make that process
>> transparent to the sakai admin ?
>>
>>
>> Thanks again,
>>
>> Tiago.
>>
>>
>>
>> On Wed, Oct 21, 2009 at 11:27 PM, Steve Swinsburg
>> <steve.swinsburg@...> wrote:
>>>
>>> Hi,
>>>
>>> Your tool can define its own permissions and then a user in a site with
>>> those permissions can be granted access to certain functions of your
>>> tool.
>>> The roles aren't system wide, they are site-wide, so this should sort you
>>> out. The only thing that is system wide are user types, but once in a
>>> site,
>>> a user is assigned a role.
>>>
>>> For your tool to register it's own permissions, check out
>>> authz.api.FunctionManager.
>>>
>>> Then, if you go to the Admin Realms tool, find a site then find the roles
>>> in
>>> that site you can set the permissions for the roles. You'd then add these
>>> updated permissions to the realm templates for new sites (and backfill
>>> them
>>> to existing sites, but thats a separate issue).
>>>
>>> You can also see here for some more info about roles in sites:
>>> http://steve-on-sakai.blogspot.com/2009/05/roles-in-sakai-sites.html
>>>
>>> cheers,
>>> Steve
>>>
>>> On 22/10/2009, at 11:36 AM, Tiago Gaspar wrote:
>>>
>>>> Hi Guys,
>>>>
>>>> I'm working on a tool for Sakai that requires specific roles. Not
>>>> system-wide roles, but specific tool roles. I couldn't find any
>>>> documentation regarding that. I could implement my own solution to the
>>>> problem, but I would like to follow the Sakai way of doing it. Is
>>>> there a Sakai for doing it? :-)
>>>>
>>>> Appreciate,
>>>> Tiago.
>>>> _______________________________________________
>>>> sakai-dev mailing list
>>>> sakai-dev@...
>>>> http://collab.sakaiproject.org/mailman/listinfo/sakai-dev
>>>>
>>>> TO UNSUBSCRIBE: send email to
>>>> sakai-dev-unsubscribe@... with a subject of
>>>> "unsubscribe"
>>>
>>>
>> _______________________________________________
>> sakai-dev mailing list
>> sakai-dev@...
>> http://collab.sakaiproject.org/mailman/listinfo/sakai-dev
>>
>> TO UNSUBSCRIBE: send email to
>> sakai-dev-unsubscribe@... with a subject of
>> "unsubscribe"
>
>

_______________________________________________
sakai-dev mailing list
sakai-dev@...
http://collab.sakaiproject.org/mailman/listinfo/sakai-dev

TO UNSUBSCRIBE: send email to sakai-dev-unsubscribe@... with a subject of "unsubscribe"

[Steve Swinsburg-3]

Hi Tiago,

Thats fine and will work nicely in your situation, but if you want to  
contribute the tool back to the community, others wont be able to  
customise the permission set to their environment. People may (and do)  
use custom roles apart from the standard ones, this approach will not  
work for them. IMO forcing permissions onto specific roles isn't the  
best approach. If its only an in house tool it will work for you  
though :)

cheers,
Steve


On 26/10/2009, at 12:42 AM, Tiago Gaspar wrote:

> Hi Steve,
>
> I've found a solution that I wanted. Instead of manually creating
> specific roles and setting the required permissions in Realms, I'm
> using AuthzGroupService to make all those steps transparent to the
> Sakai administrator.
>
> The tool automatic creates all the necessary roles and set all the
> permissions. Here's some of the code:
>
>     //creates a role
>     AuthzGroup ag = authzGroupService.getAuthzGroup(groupId);
>     ag.addRole(roleId, roleModel);
>     authzGroupService.save(ag);
>
>     //assings a permission
>     Role role = ag.getRole(roleId);
>     role.allowFunction(permissionId);
>     authzGroupService.save(ag);
>
> ** the code has been simplified...
>
> The AuthzGroup.addRole (role, roleModel) already creates a role
> copying the permissions from another, so I didn't use your webservice.
>
> Here are some useful references:
> http://steve-on-sakai.blogspot.com/2009/05/roles-in-sakai-sites.html
> http://confluence.sakaiproject.org/display/BOOT/Using+the+AuthzGroup+Service
> http://source.sakaiproject.org/release/2.2.1/javadoc/org/sakaiproject/authz/api/AuthzGroup.html
>
> Thanks again for the tips,
>
> Tiago Gaspar.
>
>
> On Thu, Oct 22, 2009 at 11:46 PM, Steve Swinsburg
> <steve.swinsburg@...> wrote:
>> Hi Tiago,
>>
>> Once your tool's service comes up, and it's functions are  
>> registered, then
>> they are available to the whole system. This happens when Tomcat  
>> starts your
>> service, not when the tool is added. So, you can then backfill this  
>> new
>> permission into every role in every site you want once Sakai is up.
>>
>> So lets say you need the permission 'mytool.view' in a certain role  
>> in your
>> site (say 'access') for your tool to display something. Once Tomcat  
>> is up,
>> you could go into the Realm for a site that doesn't even have the  
>> tool
>> installed, and you'll still be able to set the permissions for  
>> various
>> roles.
>>
>> Being a fan of the web services, I wrote an additional method to  
>> add to
>> SakaiScript.jws called copyRole(). If you set the permissions in  
>> the roles
>> in your !site.template.xxx realm, you can then iterate over every  
>> site you
>> want and sync up the roles from the template site to add this new  
>> permission
>> in.
>>
>> Some more info about this is here:
>> http://steve-on-sakai.blogspot.com/2009/05/roles-in-sakai-sites.html
>> under the heading 'Populating new/updated roles to existing sites'.
>>
>> If you haven't got your web services enabled, see here for how to  
>> do it,
>> including how to secure them:
>> http://steve-on-sakai.blogspot.com/2009/05/enabling-web-services-in-sakai-and.html
>>
>> cheers,
>> Steve
>>
>>
>> On 23/10/2009, at 2:05 AM, Tiago Gaspar wrote:
>>
>>> Hi Steve,
>>>
>>> Thanks for the response! I liked your suggestion to use Sakai  
>>> Realms,
>>> it would make permissions much more flexible. But it would require a
>>> manual configuration of roles and permissions every time the tools  
>>> is
>>> installed. Is there a way a tool itself can do that configuration
>>> through some API, or some config file, in order to make that process
>>> transparent to the sakai admin ?
>>>
>>>
>>> Thanks again,
>>>
>>> Tiago.
>>>
>>>
>>>
>>> On Wed, Oct 21, 2009 at 11:27 PM, Steve Swinsburg
>>> <steve.swinsburg@...> wrote:
>>>>
>>>> Hi,
>>>>
>>>> Your tool can define its own permissions and then a user in a  
>>>> site with
>>>> those permissions can be granted access to certain functions of  
>>>> your
>>>> tool.
>>>> The roles aren't system wide, they are site-wide, so this should  
>>>> sort you
>>>> out. The only thing that is system wide are user types, but once  
>>>> in a
>>>> site,
>>>> a user is assigned a role.
>>>>
>>>> For your tool to register it's own permissions, check out
>>>> authz.api.FunctionManager.
>>>>
>>>> Then, if you go to the Admin Realms tool, find a site then find  
>>>> the roles
>>>> in
>>>> that site you can set the permissions for the roles. You'd then  
>>>> add these
>>>> updated permissions to the realm templates for new sites (and  
>>>> backfill
>>>> them
>>>> to existing sites, but thats a separate issue).
>>>>
>>>> You can also see here for some more info about roles in sites:
>>>> http://steve-on-sakai.blogspot.com/2009/05/roles-in-sakai- 
>>>> sites.html
>>>>
>>>> cheers,
>>>> Steve
>>>>
>>>> On 22/10/2009, at 11:36 AM, Tiago Gaspar wrote:
>>>>
>>>>> Hi Guys,
>>>>>
>>>>> I'm working on a tool for Sakai that requires specific roles. Not
>>>>> system-wide roles, but specific tool roles. I couldn't find any
>>>>> documentation regarding that. I could implement my own solution  
>>>>> to the
>>>>> problem, but I would like to follow the Sakai way of doing it. Is
>>>>> there a Sakai for doing it? :-)
>>>>>
>>>>> Appreciate,
>>>>> Tiago.
>>>>> _______________________________________________
>>>>> sakai-dev mailing list
>>>>> sakai-dev@...
>>>>> http://collab.sakaiproject.org/mailman/listinfo/sakai-dev
>>>>>
>>>>> TO UNSUBSCRIBE: send email to
>>>>> sakai-dev-unsubscribe@... with a subject of
>>>>> "unsubscribe"
>>>>
>>>>
>>> _______________________________________________
>>> sakai-dev mailing list
>>> sakai-dev@...
>>> http://collab.sakaiproject.org/mailman/listinfo/sakai-dev
>>>
>>> TO UNSUBSCRIBE: send email to
>>> sakai-dev-unsubscribe@... with a subject of
>>> "unsubscribe"
>>
>>
> _______________________________________________
> sakai-dev mailing list
> sakai-dev@...
> http://collab.sakaiproject.org/mailman/listinfo/sakai-dev
>
> TO UNSUBSCRIBE: send email to sakai-dev-unsubscribe@...
>  with a subject of "unsubscribe"

_______________________________________________
sakai-dev mailing list
sakai-dev@...
http://collab.sakaiproject.org/mailman/listinfo/sakai-dev

TO UNSUBSCRIBE: send email to sakai-dev-unsubscribe@... with a subject of "unsubscribe"

[Tiago Gaspar]

Hello Steve,

I absolutely agree with you. I believe that one of the nice aspects of
Sakai is to customize permissions. My approach is not to force a set
of permissions, but to initialize the tool's default permissions. That
is done only the first time the tool is deployed.  After the tool is
installed, the permissions are longer changed by the application.

In my experience as a sakai developer, I've notice how complicated it
is to install custom sakai tools. It would be very nice to the
developers community and the sakai users if that processes was
simplified. It would be great to see something like a UI for tools
installation (the sakai admin could download, install and manage tools
like a plugin)... :-)

But I don't expect to see a plugin functionality any time soon. The
sakai architecture has some great qualities but on the other hand is
also very complex. We should develop our tools with our users in mind,
doing our best to simplify when we can and maybe our tools would be
more helpfull... ;-)

Thanks for the great insights,
Tiago.






On Mon, Oct 26, 2009 at 2:45 AM, Steve Swinsburg
<steve.swinsburg@...> wrote:

> Hi Tiago,
>
> Thats fine and will work nicely in your situation, but if you want to
> contribute the tool back to the community, others wont be able to customise
> the permission set to their environment. People may (and do) use custom
> roles apart from the standard ones, this approach will not work for them.
> IMO forcing permissions onto specific roles isn't the best approach. If its
> only an in house tool it will work for you though :)
>
> cheers,
> Steve
>
>
> On 26/10/2009, at 12:42 AM, Tiago Gaspar wrote:
>
>> Hi Steve,
>>
>> I've found a solution that I wanted. Instead of manually creating
>> specific roles and setting the required permissions in Realms, I'm
>> using AuthzGroupService to make all those steps transparent to the
>> Sakai administrator.
>>
>> The tool automatic creates all the necessary roles and set all the
>> permissions. Here's some of the code:
>>
>>    //creates a role
>>    AuthzGroup ag = authzGroupService.getAuthzGroup(groupId);
>>    ag.addRole(roleId, roleModel);
>>    authzGroupService.save(ag);
>>
>>    //assings a permission
>>    Role role = ag.getRole(roleId);
>>    role.allowFunction(permissionId);
>>    authzGroupService.save(ag);
>>
>> ** the code has been simplified...
>>
>> The AuthzGroup.addRole (role, roleModel) already creates a role
>> copying the permissions from another, so I didn't use your webservice.
>>
>> Here are some useful references:
>> http://steve-on-sakai.blogspot.com/2009/05/roles-in-sakai-sites.html
>>
>> http://confluence.sakaiproject.org/display/BOOT/Using+the+AuthzGroup+Service
>>
>> http://source.sakaiproject.org/release/2.2.1/javadoc/org/sakaiproject/authz/api/AuthzGroup.html
>>
>> Thanks again for the tips,
>>
>> Tiago Gaspar.
>>
>>
>> On Thu, Oct 22, 2009 at 11:46 PM, Steve Swinsburg
>> <steve.swinsburg@...> wrote:
>>>
>>> Hi Tiago,
>>>
>>> Once your tool's service comes up, and it's functions are registered,
>>> then
>>> they are available to the whole system. This happens when Tomcat starts
>>> your
>>> service, not when the tool is added. So, you can then backfill this new
>>> permission into every role in every site you want once Sakai is up.
>>>
>>> So lets say you need the permission 'mytool.view' in a certain role in
>>> your
>>> site (say 'access') for your tool to display something. Once Tomcat is
>>> up,
>>> you could go into the Realm for a site that doesn't even have the tool
>>> installed, and you'll still be able to set the permissions for various
>>> roles.
>>>
>>> Being a fan of the web services, I wrote an additional method to add to
>>> SakaiScript.jws called copyRole(). If you set the permissions in the
>>> roles
>>> in your !site.template.xxx realm, you can then iterate over every site
>>> you
>>> want and sync up the roles from the template site to add this new
>>> permission
>>> in.
>>>
>>> Some more info about this is here:
>>> http://steve-on-sakai.blogspot.com/2009/05/roles-in-sakai-sites.html
>>> under the heading 'Populating new/updated roles to existing sites'.
>>>
>>> If you haven't got your web services enabled, see here for how to do it,
>>> including how to secure them:
>>>
>>> http://steve-on-sakai.blogspot.com/2009/05/enabling-web-services-in-sakai-and.html
>>>
>>> cheers,
>>> Steve
>>>
>>>
>>> On 23/10/2009, at 2:05 AM, Tiago Gaspar wrote:
>>>
>>>> Hi Steve,
>>>>
>>>> Thanks for the response! I liked your suggestion to use Sakai Realms,
>>>> it would make permissions much more flexible. But it would require a
>>>> manual configuration of roles and permissions every time the tools is
>>>> installed. Is there a way a tool itself can do that configuration
>>>> through some API, or some config file, in order to make that process
>>>> transparent to the sakai admin ?
>>>>
>>>>
>>>> Thanks again,
>>>>
>>>> Tiago.
>>>>
>>>>
>>>>
>>>> On Wed, Oct 21, 2009 at 11:27 PM, Steve Swinsburg
>>>> <steve.swinsburg@...> wrote:
>>>>>
>>>>> Hi,
>>>>>
>>>>> Your tool can define its own permissions and then a user in a site with
>>>>> those permissions can be granted access to certain functions of your
>>>>> tool.
>>>>> The roles aren't system wide, they are site-wide, so this should sort
>>>>> you
>>>>> out. The only thing that is system wide are user types, but once in a
>>>>> site,
>>>>> a user is assigned a role.
>>>>>
>>>>> For your tool to register it's own permissions, check out
>>>>> authz.api.FunctionManager.
>>>>>
>>>>> Then, if you go to the Admin Realms tool, find a site then find the
>>>>> roles
>>>>> in
>>>>> that site you can set the permissions for the roles. You'd then add
>>>>> these
>>>>> updated permissions to the realm templates for new sites (and backfill
>>>>> them
>>>>> to existing sites, but thats a separate issue).
>>>>>
>>>>> You can also see here for some more info about roles in sites:
>>>>> http://steve-on-sakai.blogspot.com/2009/05/roles-in-sakai-sites.html
>>>>>
>>>>> cheers,
>>>>> Steve
>>>>>
>>>>> On 22/10/2009, at 11:36 AM, Tiago Gaspar wrote:
>>>>>
>>>>>> Hi Guys,
>>>>>>
>>>>>> I'm working on a tool for Sakai that requires specific roles. Not
>>>>>> system-wide roles, but specific tool roles. I couldn't find any
>>>>>> documentation regarding that. I could implement my own solution to the
>>>>>> problem, but I would like to follow the Sakai way of doing it. Is
>>>>>> there a Sakai for doing it? :-)
>>>>>>
>>>>>> Appreciate,
>>>>>> Tiago.
>>>>>> _______________________________________________
>>>>>> sakai-dev mailing list
>>>>>> sakai-dev@...
>>>>>> http://collab.sakaiproject.org/mailman/listinfo/sakai-dev
>>>>>>
>>>>>> TO UNSUBSCRIBE: send email to
>>>>>> sakai-dev-unsubscribe@... with a subject of
>>>>>> "unsubscribe"
>>>>>
>>>>>
>>>> _______________________________________________
>>>> sakai-dev mailing list
>>>> sakai-dev@...
>>>> http://collab.sakaiproject.org/mailman/listinfo/sakai-dev
>>>>
>>>> TO UNSUBSCRIBE: send email to
>>>> sakai-dev-unsubscribe@... with a subject of
>>>> "unsubscribe"
>>>
>>>
>> _______________________________________________
>> sakai-dev mailing list
>> sakai-dev@...
>> http://collab.sakaiproject.org/mailman/listinfo/sakai-dev
>>
>> TO UNSUBSCRIBE: send email to
>> sakai-dev-unsubscribe@... with a subject of
>> "unsubscribe"
>
>

_______________________________________________
sakai-dev mailing list
sakai-dev@...
http://collab.sakaiproject.org/mailman/listinfo/sakai-dev

TO UNSUBSCRIBE: send email to sakai-dev-unsubscribe@... with a subject of "unsubscribe"