<?xml version="1.0" encoding="UTF-8"?>
<rss version="2.0" xmlns:atom="http://www.w3.org/2005/Atom" xmlns:slash="http://purl.org/rss/1.0/modules/slash/">
  <channel>
    <language>en-us</language>
    <title>Tiki RSS feed for forum: [edu.t.o] Development</title>
    <description>Latest posts to this formThings related to delopment of Tiki for educational purposes</description>
    <image>
      <url>https://edu.tiki.org/img/tiki/Tiki_WCG.png</url>
      <title>Feed logo</title>
      <link>https://edu.tiki.org/</link>
    </image>
    <pubDate>Tue, 03 Nov 2026 18:35:21 +0000</pubDate>
    <generator>Laminas_Feed_Writer 2 (https://getlaminas.org)</generator>
    <link>https://edu.tiki.org/</link>
    <atom:link rel="self" type="application/rss+xml" href="https://edu.tiki.org/tiki-forum_rss.php?forumId=1"/>
    <item>
      <title>aulawiki-workspaces 1.7.4.1 with category permissions</title>
      <description><![CDATA[ I finally succeeded in converting all aulawiki-workspaces (versionm 1.7.4.1 for tw 4.x) in using category permissions instead of objectpermissions.

It should do so only if categories are featured.

It will, as before, apply all the permissions defined in the RolePerms template groups, to the various groups that have a role for a that workspace's type (eg Teacher, Student)
So the base is always defining proper perms for the templates groups RolePerms-Teacher, RolePerms-Student RolePerms-Member@DOCGROUP etc
Without this, no categ nor object perms will be applied, thus falling back to global perms: no workspace roles.

Now  tiki-workspaces_objectpermissions.php offers the opportunity to copy the default perm from the templates into individul objectperms for every object, thus allowing to override category perms (that apply to eg ALL wiki  pages in workspace) with particular, different objectperms for an individual object (eg a single wiki page with different perms than the others)

I think this is my last step in reapproaching the  official development for workspaces, and I will commnicate to the developers' list that I intend to pass  over the whole stuff to anyone interested in taking it forward.

The new aulawiki-4x is available for install as a mod by pointing to
http://workspaces.altervista.org/mods
as mod provider

I am afraid I didn't incorporate any further commit made to svn, eg the css change xavi did.]]></description>
      <pubDate>Fri, 22 Jan 2010 23:17:52 +0000</pubDate>
      <link>https://edu.tiki.org/tiki-view_forum_thread.php?comments_parentId=362</link>
      <guid>https://edu.tiki.org/tiki-view_forum_thread.php?comments_parentId=362</guid>
      <slash:comments>0</slash:comments>
    </item>
    <item>
      <title>Aulawiki-workspaces on tw 4.1</title>
      <description><![CDATA[I think I succeded in having basic aulawiki-workspaces on tikiwiki 4.1.
Will need to test further.
The adaptation mainly involved
*classes that extended TikiDB now extend TikiDb_Bridge
*classes extending tikilib now use:
+$this->query instead of $this->db->query 
*method tikilib->convert_sortmode now is $tikilib->convertSortMode

various other small fixes all related to the previous changes in class extends

So far I tried creating wiki, blog, tracker, forum, filegal with success

Workspaces Objectperms templates system also seems to work on created object.

Also module workspaces_my works.

Now I wonder if it is the case to go on this path, and where to. I think the logical course would be to transparently switch from/to category permissions for workspace resources, so as to meet the ''other development'' path somewhere.

And then I might leave this to its destiny, and to anyone who dares continuing.

The mod is available as ''__aulawiki-4x__''for test install on tw 4.1 by setting mods provider
http://workspaces.altervista.org/mods/]]></description>
      <pubDate>Sat, 09 Jan 2010 11:09:34 +0000</pubDate>
      <link>https://edu.tiki.org/tiki-view_forum_thread.php?comments_parentId=357</link>
      <guid>https://edu.tiki.org/tiki-view_forum_thread.php?comments_parentId=357</guid>
      <slash:comments>0</slash:comments>
    </item>
    <item>
      <title>Reassestment of edu.two</title>
      <description><![CDATA[I did quite a few chenges at the ws setup here at edu.two.
I just point themm out quickly because I am fused as of now.

* Applied workspace permission to the WSDOC workspace by:
** defining new roles: Member@DOCGROUP & Admin@DOCGROUP
** defining the ROLEGRPMember@DOCGROUP  and ROLEGRPAdmin@DOCGROUP, that will include respectively all ''Members' and 'Admins' roles groups. Just an utility group to eg: assign same modulel to all ''Admins' or ''Members'' across workspaces 
** adding only these as roles to the DOCGROUP ws type
** kept the actual WSGRPDOC workspace, but recreated most of the resources, which where anyway emplty placeholders to get the correct objectperms assigned to the new roles. 
** kept the image Gallery and Home which had already stuff in them, and manually assigned objectperms for the new roles
** made the new WSGRPWSDOC-Member@DOCGROUP group ''allow_join'' and modified the subscribegroups module so that people will join/leave this by pressing the button
** took away some perms at Registered and gave them to the RolePerms-xxx templates,, so that only people at specific roles for specific workspaces will have these objectperms. Less global perms, more objectperms.
** a bounch of other small changes that I ask you to notify if anything gowes wrong

__TODO or NOT-TODO__
* move the docu structures inside the workspace category and assign correct objectperms for these 
* remove users from WSGRPWSDOC, they have all been imported into WSGRPWSDOC-Member@DOCGROUP now, and WSGRPWSDOC has no more perms, these are all assigned to WSGRPWSDOC-Member@DOCGROUP. 
So users of the WSGGRPWSDOC can be removed. 
WSGRPWSDOC should be the including group of all other ws groups, but with no objectperms, perms, nor users assigned. Just an utility group to assign eg: modules to everyone in the workspace.]]></description>
      <pubDate>Sat, 19 Dec 2009 11:42:31 +0000</pubDate>
      <link>https://edu.tiki.org/tiki-view_forum_thread.php?comments_parentId=344</link>
      <guid>https://edu.tiki.org/tiki-view_forum_thread.php?comments_parentId=344</guid>
      <slash:comments>0</slash:comments>
    </item>
    <item>
      <title>peculiarity of tiki-p_admin_wsorkspace as global perm</title>
      <description><![CDATA[Following what I found in the code, I made some attention as to:

global perm (eg to 'Editors') __tiki_p_admin_workspace will always be granted__ 
also in case of same or any other ws objectperms assigned for the ws object.

So if Editors have tiki_p_admin_workspace they will be able to admin all workspaces

In this case I think workspaces make a ''unique''' case of a global perm that is not superceded by object perms.]]></description>
      <pubDate>Fri, 18 Dec 2009 19:09:21 +0000</pubDate>
      <link>https://edu.tiki.org/tiki-view_forum_thread.php?comments_parentId=343</link>
      <guid>https://edu.tiki.org/tiki-view_forum_thread.php?comments_parentId=343</guid>
      <slash:comments>0</slash:comments>
    </item>
    <item>
      <title>reconsidering the workspace desktop...</title>
      <description><![CDATA[I was thinking about this lately.
The ws desktop works like this:

-when we create a workspace type, it is like a kind of prototype for the creation of new workspaces of that type
-we also define a base ws desktop for that type
-when we create a new ws of that type, an admin (or delegate ws admin) has also the possibility to define a specific desktop for this workspace, different from the prototype one, with different modules etc.

So when that ws is opened, if it has his onwn specific desktop, you'll get that. Otherwise you'll fallback to having the prototype desktop, as defined for that ws type.

But in what does a desktop differs from a normal wiki page, with wikiplugin modules placed in it?

-With a wiki page you can have better placing of columns, using tables, so you can have a row that comprises two columns for example.
- with a wiki Page any member with edit permissions can add stuff to the page
- with a wiki page you can assign perms to it, so that eg: delegated admins (member of a WSXX-Teacher group) can modify all of it, Students only parts of it.
- You can still force people to see that page after login, by setting it as a 'group Homepage', obtaining the same effect of a Desktop.

An alternative way could be to define a Desktop with just one module: the workspaces_viewpage module, that will just show a well manufactured page like above

This would give more flexibility and finer permissions on the Desktop layout, and take away a lot of code.
Supposed there exist a way to do it automatically for all workspaces... But I think this can be worked out


What do you think]]></description>
      <pubDate>Tue, 15 Dec 2009 11:46:06 +0000</pubDate>
      <link>https://edu.tiki.org/tiki-view_forum_thread.php?comments_parentId=339</link>
      <guid>https://edu.tiki.org/tiki-view_forum_thread.php?comments_parentId=339</guid>
      <slash:comments>0</slash:comments>
    </item>
    <item>
      <title>mod-workspace_calendar vs mod-calendar_new</title>
      <description><![CDATA[Since in tw 3.x there's a new setup pref: __$smarty_security__, defaulte value is on.
This feature prevents php code inside smarty, for security reasons.
because of this new feature, aulawiki.1.7.2 cannot work in tw 3.x, unless you set it off.
I had to replace mod-workspace_calendar with mod-calendar_new

Please take alook at the smarty template of mod-workspace_calendar:
[http://tikiwiki.svn.sourceforge.net/viewvc/tikiwiki/mods/trunk/features/aulawiki/templates/modules/mod-workspaces_calendar.tpl?revision=19210&view=markup|mod-workspaces_calendar template as before latest update]

It's a lot of php meshed inside smarty! Taking away all php code means rewriting the calling module completely! When there exist a nice, maintained and up to date one named mod-calendar_new.

This is the reason why I switched on using the cherry mod-calendar_new module.]]></description>
      <pubDate>Fri, 04 Dec 2009 17:46:16 +0000</pubDate>
      <link>https://edu.tiki.org/tiki-view_forum_thread.php?comments_parentId=318</link>
      <guid>https://edu.tiki.org/tiki-view_forum_thread.php?comments_parentId=318</guid>
      <slash:comments>0</slash:comments>
    </item>
    <item>
      <title>How a user joins the workspace</title>
      <description><![CDATA[I tried the ''__subscribegroup__'' wikiplugin
[http://doc.tikiwiki.org/PluginSubscribeGroup-PluginSubscribeGroups]
and here are a few gotchas to use it for allowing joining a workspace.
!!!#activate the subscribegroup wikiplugin
this is done through the plugin tab on the textarea admin page
/tiki-admin.php?page=textarea
!!!# In Groups Administration 
*All the group you wanna people to be able to join (eg DemoGuests) must be marked as
++''__User can assign to the group himself__''
*As you want already Registered users to be able to join another specific group:
++Registered group must have ''__tiki_p_subscribe_groups__'' permission set
!!!# If you want people to be able to choose the DemoGuests group at registration time 
in the Login admin page
tiki-admin.php?page=login
you must mark both 'Registered' and ''DemoGuests' as 
''__Users can select a group to join at registration__''
(note that if you mark __only__ DemoGuests, users can't select anything, just become members of DemoGuests. So mark at least two, otherwise there will be no selection choice)
!!!# prepare a wiki-parsed user module like 'join_workspace_module', or a wiki_page, with the following code
~np~ 
{SUBSCRIBEGROUP(group=DemoGuests,
subscribe="Subscribe to %s", unsubscribe="Leave %s", 
subscribe_action=OK, unsubscribe_action=OK) /}
 ~/np~

this wikiplugin is smart, so by himself  will display ''Subscribe...'' if the user is not subscribed, ''Leave...'' if he's already in that group

you can make it so that it will be shown to anyone except to members of FOO group :

~np~
{GROUP(notgroups="FOO")}{SUBSCRIBEGROUP(group=DemoGuests,
subscribe="Subscribe to %s", unsubscribe="Leave %s",
subscribe_action=OK, unsubscribe_action=OK) /}
{GROUP}
 ~/np~

You can then make a link to the page, or assign the module to all 'registered' group.]]></description>
      <pubDate>Fri, 04 Dec 2009 17:30:04 +0000</pubDate>
      <link>https://edu.tiki.org/tiki-view_forum_thread.php?comments_parentId=317</link>
      <guid>https://edu.tiki.org/tiki-view_forum_thread.php?comments_parentId=317</guid>
      <slash:comments>0</slash:comments>
    </item>
    <item>
      <title>Follow up on current developments for Aulawiki Mod</title>
      <description><![CDATA[Hi:

AulaWiki mod has been updated by pingus to work with Tiki 3. 
There a some minor details to solve in order to make it 100% compatible with ((doc:Tiki3)), the current Long Term Support (LTS) version of Tikiwiki, once ((doc:Tiki4)).0 was released and support for ((doc:Tiki2)).x was ceased.

I'll add below in this public forum (nowadays that we have edu.tw.o back up running again), a copy of the current thread that pingus and I were having, so that anyone interested can jion the thread, comments, etc. (:wink:)

{QUOTE(replyto=>Pingus)}
Of course you can post it there too.
In fact I'd add that mod-workspace_calendar was a calendar code completely written inside the tpl file, and very hard to take the {php} out of it.
I looked at mod-calendar_new.tpl and it was quite OK for me, so I found a way to use it by passing to it (including it into mod-workspaces_calendar.tpl) the ws-calendars array selected by mod-workspaces_calendar.php
I then tested it also on 2.2 (the only 2.x at hand) and the mod-calendar_new.php of 3.3 works great on 2.2, while the one shipped with 2.2  doesn't.

For what's about clipboard, print,  I've never used nor tried them, and it's mostly php-produced javascript stuff... I'd leave them for now. 
Same for gradebook, have no idea what it's supposed to do.

./templates/tiki-workspaces_zones.tpl  can be removed from the tree

--- Mer 2/12/09, Xavier de Pedro  ha scritto:

> > Da: Xavier de Pedro
> > Oggetto: Re: edu.tw.o is back up + AulaWiki for Tiki 3 (LTS)
> > A: giancarlo
> > Data: Mercoledì 2 dicembre 2009, 11:00
> > Btw, since we have a shiny new
> > edu.tw.o site with tiki 3.3, do you mind 
> > if I copy your message there at the "devel" forum from
> > edu.tw.o and we 
> > keep the thread there?
> > 
> > So that anyone interested can join the thread of
> > contribute, etc.
> > I don't mind copying you post myself there, but I'd like to
> > have your 
> > confirmation, of course!  :-) 
> > Xavi

{QUOTE()}
Xavier de Pedro wrote:

>> >>
>> >> doing a search I found 6 (in descending order of importance/urgency)
>> >>
>> >> ./templates/tiki-workspaces_resource_types.tpl
>> >> ./templates/tiki-workspaces_zones.tpl  **** WAS NOT USED
>> >> ./templates/modules/mod-workspaces_calendar.tpl
>> >> ./templates/aulawiki-view_gradebook.tpl  ** DONE NOTHING
>> >> ./templates/tiki-workspaces_print_page.tpl *** DONE NOTHING
>> >> ./templates/tiki-workspaces_copy_to_clipboard.tpl ** DONE NOTHING
>> >>

Only fixed as of now are:

./templates/tiki-workspaces_resource_types.tpl
./templates/modules/mod-workspaces_calendar.tpl

included the scripts calling them, other included/including tpls etc.

In particular:

-the list of addable resources has been moved as properties of
resourceslib inside
 lib/workspaces/resourceslib.php

this brought me to change also a few other scripts and templates

-mod-workspaces_calendar was a complete php rewrite of the already
existing mod_calendar, inside smarty. I saw that mod-calendar_new.php
has all the features, missing only to be passed the correct calendars,
so I decided to call it instead of rewriting it all inside smarty.
It is slightly different (less compact) in view: the standard
mod-calendar.new layout.

In practice it now uses mod_calendar_new.php module, but passing to it
the workspace calendars. Less code to maintain.
Notice that this works only with mod-calendar_new.php provided by tw
3.3. For the one in tw 2.x couldn' be passed a calendar array as
module_params (didn't use these there), and it will not work there

./templates/tiki-workspaces_zones.tpl is not used anywhere, it seems.

I also put back all PHP_SELF to REQUEST_URI, because that was not the
cause of the malfunctioning at ub.edu, rather it was a buggy PHP, but
caused a not found after adding a new ws resource.

this is the list of all modified stuff.

M    tiki-workspaces_types_resources.php  * smarty+PHP_SELF
M    aulawiki-assignments_admin.php * PHP_SELF
M    tiki-workspaces_modules.php *PHP_SELF
M    templates/tiki-workspaces_copy_to_clipboard.tpl * PHP_SELF
M    templates/modules/mod-workspaces_calendar.tpl * REWROTE
M    lib/workspaces/resourceslib.php * Added resources list
M    modules/mod-aulawiki_view_assignment.php * PHP_SELF
M    modules/mod-workspaces_clipboard.php * PHP_SELF
M    modules/mod-workspaces_calendar.php  * REWrote
M    modules/mod-workspaces_resources.php * SMARTY

Committed revision 23594

Tell me if there's something not working
	
Giancarlo
{QUOTE}
{QUOTE}]]></description>
      <pubDate>Wed, 02 Dec 2009 18:36:40 +0000</pubDate>
      <link>https://edu.tiki.org/tiki-view_forum_thread.php?comments_parentId=314</link>
      <guid>https://edu.tiki.org/tiki-view_forum_thread.php?comments_parentId=314</guid>
      <slash:comments>0</slash:comments>
    </item>
    <item>
      <title>aulawiki 1.7 on tiki 2.x</title>
      <description><![CDATA[Hi Pingus:

I've tested to day aulawiki mod (1.7.0), ionstalled from mods interface, and it worked fine on a tiki 2.4 from mods.tikiwiki.org :-)
Step by step :-)

BTW, I've committed a partial css file to make it display properly (the bundled workspaces.css theem has brokwn layout for me on tiki 2.x sites).
The text is here:
http://www.ub.edu/optics/tiki/ws1
using a modified eatlon theme, adding the workspaces_only.css and eatlon.css (in this case) to the custom theme.

The first thing I miss here (everything works fine, other wise, so far), is the ability to add calendars to workspace types or workspaces. Are they gone?
Do they work for you?]]></description>
      <pubDate>Mon, 11 May 2009 14:11:13 +0000</pubDate>
      <link>https://edu.tiki.org/tiki-view_forum_thread.php?comments_parentId=310</link>
      <guid>https://edu.tiki.org/tiki-view_forum_thread.php?comments_parentId=310</guid>
      <slash:comments>0</slash:comments>
    </item>
    <item>
      <title>testing aulawiki 1.7: first issues</title>
      <description><![CDATA[Hi all:

I've upgraded http://moviments.net/cursos from 2.4 to tiki3beta4, and installed aulawiki 1.7.
Since I was not sure about the safety of installing 1.7.0 through mods (admin mods seems broken in tiki3), I've just copied all the required files from 1.7.0 to  their respective locations.

My first issue is:

Fatal error: Call to undefined method PEAR_Error::fetchRow() in /home/httpd/tiki30svn/lib/workspaces/typeslib.php on line 70

while attempting to visit an url like: ws100, which corresponds to a workspace desktop

Anyb ody succeeded using this?
http://mods.tikiwiki.org/Dist/features-aulawiki-1.7.0.tgz]]></description>
      <pubDate>Thu, 07 May 2009 16:51:31 +0000</pubDate>
      <link>https://edu.tiki.org/tiki-view_forum_thread.php?comments_parentId=306</link>
      <guid>https://edu.tiki.org/tiki-view_forum_thread.php?comments_parentId=306</guid>
      <slash:comments>0</slash:comments>
    </item>
  </channel>
</rss>
