<?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 forums</title>
    <description>Latest forum topics.</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>Sun, 25 Oct 2026 16:57:23 +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-forums_rss.php"/>
    <item>
      <title>HomePage</title>
      <description><![CDATA[				Use this thread to discuss the page: [tiki-index.php?page=HomePage|HomePage]]]></description>
      <pubDate>Tue, 09 Jan 2018 18:34:32 +0000</pubDate>
      <link>https://edu.tiki.org/tiki-view_forum_thread.php?forumId=2&amp;comments_parentId=367</link>
      <guid>https://edu.tiki.org/tiki-view_forum_thread.php?forumId=2&amp;comments_parentId=367</guid>
      <slash:comments>0</slash:comments>
    </item>
    <item>
      <title>edu.t.o upgraded to 12.x and updated a bit</title>
      <description><![CDATA[Hi all:

This is just to report that edu.t.o has been finally upgraded to use [http://doc.tiki.org/Tiki12|Tiki12] (instead of the Tiki3 that was previously running the site).

And the homepage has been updated a little bit to reflect the associated changes in the code. 

Keep adding your comments, questions  and use cases of Tiki for education in edu.tiki.org!

Yours

Xavier de Pedro (a.k.a. xavi)
One of the edu.t.o admins]]></description>
      <pubDate>Wed, 12 Mar 2014 16:06:20 +0000</pubDate>
      <link>https://edu.tiki.org/tiki-view_forum_thread.php?forumId=2&amp;comments_parentId=364</link>
      <guid>https://edu.tiki.org/tiki-view_forum_thread.php?forumId=2&amp;comments_parentId=364</guid>
      <slash:comments>0</slash:comments>
    </item>
    <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?forumId=1&amp;comments_parentId=362</link>
      <guid>https://edu.tiki.org/tiki-view_forum_thread.php?forumId=1&amp;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?forumId=1&amp;comments_parentId=357</link>
      <guid>https://edu.tiki.org/tiki-view_forum_thread.php?forumId=1&amp;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?forumId=1&amp;comments_parentId=344</link>
      <guid>https://edu.tiki.org/tiki-view_forum_thread.php?forumId=1&amp;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?forumId=1&amp;comments_parentId=343</link>
      <guid>https://edu.tiki.org/tiki-view_forum_thread.php?forumId=1&amp;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?forumId=1&amp;comments_parentId=339</link>
      <guid>https://edu.tiki.org/tiki-view_forum_thread.php?forumId=1&amp;comments_parentId=339</guid>
      <slash:comments>0</slash:comments>
    </item>
    <item>
      <title>Workspace member can't access WSDOC-Home?</title>
      <description><![CDATA[I'm a member of the "Documentation on Workspaces" group, but for some reason I get a permission denied error when I try to access WSDOC-Home.

???

- ))MacLeod((]]></description>
      <pubDate>Wed, 09 Dec 2009 14:23:53 +0000</pubDate>
      <link>https://edu.tiki.org/tiki-view_forum_thread.php?forumId=2&amp;comments_parentId=331</link>
      <guid>https://edu.tiki.org/tiki-view_forum_thread.php?forumId=2&amp;comments_parentId=331</guid>
      <slash:comments>0</slash:comments>
    </item>
    <item>
      <title>Strategy for restricted Workspaces?</title>
      <description><![CDATA[__Given:__  

* A project management Workspace is accessible only by members of the Workspace group.  Other users of the Tiki site (except admins) have no read access to it.

* Wiki page ABCDEF was created by a user who is ===not=== a member of the Workspace group.


__Problem:__  A member of this restricted Workspace group categorizes wiki page ABCDEF as part of the Workspace category.  The user who created the page can no longer access it.


__Question:__ What's the best strategy to prevent this situation?


__Options:__  

* A Workspace group member can only categorize objects into the Workspace category if s/he created the object.
** What if a legacy document ''needs'' to be categorized into the Workspace category?  Ask a Wiki admin to do it?

* A Workspace group member can only categorize objects into the Workspace category ''at the time of object creation''.
** What if the Workspace group member forgets to categorize it until his/her third edit?  Ask a Wiki admin to do it?

* Don't try to prevent it with permissions.  It's a wiki - anything bad that's done can be undone by admins, including an undesirable categorization.

- ))MacLeod((]]></description>
      <pubDate>Tue, 08 Dec 2009 19:10:58 +0000</pubDate>
      <link>https://edu.tiki.org/tiki-view_forum_thread.php?forumId=2&amp;comments_parentId=330</link>
      <guid>https://edu.tiki.org/tiki-view_forum_thread.php?forumId=2&amp;comments_parentId=330</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?forumId=1&amp;comments_parentId=318</link>
      <guid>https://edu.tiki.org/tiki-view_forum_thread.php?forumId=1&amp;comments_parentId=318</guid>
      <slash:comments>0</slash:comments>
    </item>
  </channel>
</rss>
