Loading...
 
[edu.t.o] Development

[edu.t.o] Development


ws doubts

posts: 52
A problem for me in trying workspaces is the lack
of knowledge about what it was supposed to do.

I produced a patch to make aulawiki-1.6 work on tw-2.2 without ever knowing what aulawiki-1.5 was doing in tw 1.9

So I would like to point a few major doubts I've been carrying with
me for a while, probably common to anyone trying to evaluate workspaces for any project

1) How can 'teacher' create a GrupoC?
Can he be limited to create GrupoC only of predefined
types? Be/become automatically admin of 'GrupoC'?
2) tiki_p_admin_workspace
Should having object perms 'p_admin_workspace' on a
workspace allow you to to assign perms to all WS resources?
And also to all/certain child workspaces'?
3) is 'Owner' a special role that has not to be deleted and how
can one replicate its role setup? Has it to do with
'Portfolio'and 'Personal' WS types and how can be replicated?
4) workspace_resources module
Was the 'New Category' button in the admin bar intended to
create a child workspace?
Why are child workspaces listed as categories and can be
deleted as categories?
Sure new ones will come in mind.

Then, as a developer, I'd like to ask you links to any docu, mailing
lists periods, whatever to search about discussions held at the
design of workspaces and its features

pingus
posts: 32
Pingus, everything you point is really interesting. Thanks! biggrin

We have to have something in mind all the time: workspaces are going to become part of tiki x.x as a feature. Because of this, it's important to start working in two parallel directions: one to improve/correct workspaces, other to integrate them in tiki. Both teams must travel in the same (like we are doing wink (!).

I really believe that if we get a very stable aulawiki+workspaces mod, then the integration in tiki is going to be easier.

About the links ...
Well, one feature that it's going to play a vey important role in the new scenario is the profile. And not only in the integration of workspaces in tiki, but also in the management of them.
Data channels and profiles will let the teachers (for example), to create their own workspaces. In the last tikifest in Madrid, Javier Reyes (the author of aulawiki) mentioned that an abstraction layer to manage resources is a must. Profiles and data channels are supposed to do this. So we have to take them into account in the new workspaces, definitely.

I ask you to join the discussion of all these things here.

Other interesting links to read/watch:
-Workspaces
-The videos Xavi has uploaded in the wiki page for the tikifest in Madrid. By the way, Xavi, congratulations!
posts: 52
> Well, one feature that it's going to play a vey important role in the new scenario is the profile.

Yes, I read about profiles, ant it's a logic tool, that can be fun to provide and very practical for an end user to use.

I am actually making my steps up from the code and the actual features/design, so the questions I posed are really important.

I am trying to see what and how can/should be done, then building a container/menu/replicable-profile is just a question of providing the correct links/variables to do it.

Being simplicistic, at the moment I can see a few choices:

a workspace type where, who has tiki_p_admin_workspace objectperms on it, can:
-admin the ws object's itself objectpermissions
-assign individual objectpermissions to all other objects of the WS
-create child workspaces only of a certain type (was that the case
of PERSONAL/PORTFOLIO private sub workspaces?)
-optionally do the same on all/ child workspaces, included
adding parent's WSGRPs with their objectpermissions to them

with 1.6.3x I realized that these things ('teacher' creates a new sub workspaces, 'teacher' admins all WS object perms, 'teacher' admins sub ws, 'teacher' adds parent's ws roles to child workspace) can be done/not done by twiddling with 'tiki_p_admin_workspace object permission of a workspace and this can be made heritable on child workspace type objects. Still messy, but I see it can be done.

> Data channels and profiles will let the teachers (for example), to create their own workspaces.
In the last tikifest in Madrid, Javier Reyes (the author of aulawiki) mentioned that an abstraction layer to manage resources is a must.

Where is he then? :-)
I think he knows a lot about this all.

Giancarlo Pinerolo 'pingus
posts: 158

> Being simplicistic, at the moment I can see a few choices:
>
> a workspace type where, who has tiki_p_admin_workspace objectperms on it, can:
> -admin the ws object's itself objectpermissions
ok
> -assign individual objectpermissions to all other objects of the WS
ok
> -create child workspaces only of a certain type (was that the case
> of PERSONAL/PORTFOLIO private sub workspaces?)
yes

> -optionally do the same on all/ child workspaces, included
> adding parent's WSGRPs with their objectpermissions to them

yes, pingus, your design is desirable!

> with 1.6.3x I realized that these things ('teacher' creates a new sub workspaces, 'teacher' admins all WS object perms, 'teacher' admins sub ws, 'teacher' adds parent's ws roles to child workspace) can be done/not done by twiddling with 'tiki_p_admin_workspace object permission of a workspace and this can be made heritable on child workspace type objects. Still messy, but I see it can be done.
>
> > Data channels and profiles will let the teachers (for example), to create their own workspaces.
> In the last tikifest in Madrid, Javier Reyes (the author of aulawiki) mentioned that an abstraction layer to manage resources is a must.
>
> Where is he then? :-)
> I think he knows a lot about this all.

Yes, pingus, you are right, he knows a lot. He did his best coming along to the recent TikiFestMadrid to explain as much as possible in person of what he had done up to date, and unluckily, he's not able to keep coding the workspaces anymore (according to what he told us), but told rlopez, mangapowerx and aldo on some hints on where and how to keep going.

> Giancarlo Pinerolo 'pingus

Thanks for all your work, Giancarlo.

We are all doing our best to make Tiki (code and community) grow better (and more bug free).
posts: 32
>
> > Being simplicistic, at the moment I can see a few choices:
> >
> > a workspace type where, who has tiki_p_admin_workspace objectperms on it, can:
> > -admin the ws object's itself objectpermissions
> ok
> > -assign individual objectpermissions to all other objects of the WS
> ok
> > -create child workspaces only of a certain type (was that the case
> > of PERSONAL/PORTFOLIO private sub workspaces?)
> yes
>
> > -optionally do the same on all/ child workspaces, included
> > adding parent's WSGRPs with their objectpermissions to them
>
> yes, pingus, your design is desirable!

I agree with you on all these points biggrin , and thanks for all the work. I will test 1.6.3 this week, probably on friday (busy week).


Xavi, do you know if the people in Montreal are going to update mods.tikiwiki.org with 1.6.2.b? The code from pingus and I is up in the svn server.

Pingus I have seen you uploaded a tar file with the files you modified from 1.6.2.b to 1.6.3x in the tracker. Thanks! This friday I will commit the changes if they for me in tiki 3 wink

We stay in contact.
posts: 52

> Pingus I have seen you uploaded a tar file with the files you modified from 1.6.2.b to 1.6.3x in the tracker. Thanks! This friday I will commit the changes if they for me in tiki 3 wink

I'd tell you to try 1.6.3x through, especially as 'teacher' or whatever sub-admin you prefer.
The major change is capability to admin perms of all ws objects, and of child ws and child ws objects (if he has'tiki_p_admin_workspace' for parent ws in RolePerms) through navigating child workspaces from the resources module (that keeps 'current workspace' set to the parent)

There's an errant bug that when he edits a wiki page with categories enabled site-wise, page looses its category and workspace.
You need to uncheck
"Permission to all (not just any) of an object's categories is required for access" in tiki-admin.php?page=category
Maybe that's solved in the cvs version or in 3.0.
Also I could't allow categorization of resources (eg show categories in editing a page) if not by acting on global perms, as I wrote in tiki-devel

good luck

giancarlo pingus

posts: 158
HI Pingus:

> A problem for me in trying workspaces is the lack
> of knowledge about what it was supposed to do.
> I produced a patch to make aulawiki-1.6 work on tw-2.2 without ever knowing what aulawiki-1.5 was doing in tw 1.9

Yes, what you are doing is really brave! A pity you couldn't attend to that meeting in Madrid.

> So I would like to point a few major doubts I've been carrying with
> me for a while, probably common to anyone trying to evaluate workspaces for any project
>
> 1) How can 'teacher' create a GrupoC?
> Can he be limited to create GrupoC only of predefined
> types? Be/become automatically admin of 'GrupoC'?

Pingus, that was not coded, as far as I know, but it would be vdery welcome if possible.
As far as I know, where AulaWiki has been used for production, it was the admin (or a single user with admin rights for all workspaces) the one creating them, etc.
But it would be much much more versatile if they could be managed as you say, pingus.

> 2) tiki_p_admin_workspace
> Should having object perms 'p_admin_workspace' on a
> workspace allow you to to assign perms to all WS resources?

I would say yes.

> And also to all/certain child workspaces'?

I would say yes, making it optional (like nowadays, with a checkbox on admin categories, where you can select to apply that to that categ. or also to their childs. So similarly, "allow local admin of this workspace to assign permissions to this workspaces and their children?" (or similar)


> 3) is 'Owner' a special role that has not to be deleted and how
> can one replicate its role setup? Has it to do with
> 'Portfolio'and 'Personal' WS types and how can be replicated?

As far as I know, yes, owner is for personal oprtfolio and learning folders, etc.
"How can it be replicated?" no idea

> 4) workspace_resources module
> Was the 'New Category' button in the admin bar intended to
> create a child workspace?

No idea. Workspaces were creating through the admin interface reported in the documentation (which has images for the workspaces documentation again in edu.tw.o)

> Why are child workspaces listed as categories and can be
> deleted as categories?

? Workspacs are not intented to be managed through categories, but through admin workspaces, afaik. I don't know the code behind, but would it be that if you delete a workspace through categories, you have some left voers in tiki from that workspace? Anyway, nowadays that in Tiki 2+, categories can have the tiki_p_view_categories, (and tiki_p_edit_categorized), those category names from workspaces could be hidden from the list to users or admins, if they shouldn't be able to delete workspaces through categories... (my 2 cents)

> Sure new ones will come in mind.
>
Yes, sure. Thanks for finding way to improve the code further, pingus! :-)

> Then, as a developer, I'd like to ask you links to any docu, mailing
> lists periods, whatever to search about discussions held at the
> design of workspaces and its features

They were initially discussed in Spanish, linked to http://gclub.ub.es/carpetiki/ project. But that project is not alive any more (funding finished, etc.)
So most things are the ones you can see in this site, and the documentation in this site also.

> pingus

Xavi

posts: 52
> > > 2) tiki_p_admin_workspace
> > > Should having object perms 'p_admin_workspace' on a
> > > workspace allow you to to assign perms to all WS resources?
> >
> > I would say yes.
>
> Then you should try 1.6.3x
> Working as 'teacher', with most of the objectperms needed in the RolePerms template, most can be done from the resources module, where you can assign object perms to WS resources, create new ones, and also navigate to child ws still keeping parents' ws, if you've admin on it, so add parents' grup to child and be able to create new objects in child. (key and spanner icons next to the first resource, the workspace itself)
>
> To do this 'teacher' (admin role of parent's) needs to have tiki_p_admin_workspace' and 'tiki_p_create_workspace_resour'
> This needs a switch (new perm? new parent's hardcoded object type? are Personal an Portfolio of these types), or maybe state that having both these perms on parent's is enough?
>
> To allow creation of a new child ws needs modifying tiki_workspaces_admin.php.
>
> > > And also to all/certain child workspaces'?
> >
> > I would say yes, making it optional (like nowadays, with a checkbox on admin categories, where you can select to apply that to that categ. or also to their childs.
>
> Looks like this was thought in conjuction with categories, I'm missing the trait d'union...
>
> Giancarlo

Switch Language