Loading...
 
Skip to main content
[edu.t.o] Development

[edu.t.o] Development

Forum List Topic List

Forums » [edu.t.o] Development » Follow up on current developments for Aulawiki Mod
 
Thread actions

    • Follow up on current developments for Aulawiki Mod

    Posted by Xavi posts: 158 ☆ ☆ ☆ ☆ ☆
    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 Tiki3, the current Long Term Support (LTS) version of Tikiwiki, once Tiki4.0 was released and support for 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. 😉

    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

    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


    Reads: 22722
    Link to this comment
    Posted by Xavi posts: 158 ☆ ☆ ☆ ☆ ☆
    Hi Pingus:

    Following up with this thread, I have several questions/comments



    How a user joins the workspace

    How does a user join a certain workspace as a member?
    With former code, a user could self-join a workspace (following the instructions in edu.tw.o homepage, for instance. But this doesn't work anymore (reported by MacLeod here in edu.tw.o, and confirmed by me in
    http://workspaces.altervista.org/tiki-workspaces_desktop.php?workspaceId=6&zoneId=19
    as user xavi (user without admin perms)

    What type of perms or configuration is needed to allow new users to join a workspace as members?

    Objects cannot be created from Admin Tab at edu.tw.o

    objects cannot be created from Admin Tab here at edu.tw.o, you click on create object button and nothing happens (tried with survey, blog, wiki page). No change.
    Example:
    http://edu.tikiwiki.org/tiki-workspaces_desktop.php?workspaceId=2&zoneId=7
    Click on module "Resources" at "New Object", etc.

    However, from your altervista site:
    http://workspaces.altervista.org/tiki-workspaces_desktop.php?workspaceId=6&zoneId=19
    as user admin I could create objects successfully (example: http://workspaces.altervista.org/tiki-take_survey.php?surveyId=1 )

    I wonder what's the difference.

    1.1.3. mod_calendar_new

    Thanks for reusing Tiki code for the calendar to avoid having to maintain old and duplicated code. However, a few things are gone with that change, and one important is still missing for my point of view (to avoid having users lost)

    mod_calendar_new:
    1. doesn't seem to show the list of next event in the same module box (former ws module did)
    2. doesn't seem to show the "" surrounding the month, in order to allow easily passing months forward and backwards for the calendar view (former ws module did)
    3. it doesn't show any direct link for posting to the calendar (afaik, the former ws module didn't allow that either). Is it difficult to add?

    thanks for your support, as always, pingus!
    Link to this comment
    Posted by pingus posts: 52 ☆ ☆ ☆
    Xavi and everyone!

    By trying to remove php code from smarty I messed up a few things that did work before. Last night I commited fixes for some of them.
    You should apply them here to test, and don't rely on workspaces.altervista.org, because that has not got updated yet.
    Sorry Icouldn't dedicate too much time to testing it, so then this site has become the place to do it 😊

    Changes in yesterday commit:

    -the drop-down select of creatable objects should appear now

    -tiki_p_create_workspace_resour, as a perm on the workspace for a group/role, will now allow *only* creation of new resources. Before it could allow also deleting and changing their perms. But if we don't want a 'own-space resource manager' to be able to delete objects, he shouldn't be able to change his perms on them too, allowing himslef whatever. So this 'intermediate' role should be discussed more in depth. If he can change perms of his ws objects, there should be perms he can, and perms he cannot, modify. So unless he has full deletion power, which carries with it every other perms I think.
    To solve this somehow there could be a constant (like the existing
    Copy to clipboard
    define ("_TIKI_P_CREATE_WORKSPACE_RESOUR_CAN_ADD_USERS_",false)

    in lib/workspaces/userlib.php

    something like
    Copy to clipboard
    define ("_TIKI_P_CREATE_WORKSPACE_RESOUR_CAN_DELETE_RESOURCES_",false)

    wich would also trigger his capacity to modify any objectperms of his ws

    So there remains the tiki_p_admin_workspaces objectpermission
    on a workspace, which grants everything(del/create new sub-ws, del/create objets, change object perms, add groups from the ws and sub-ws, add users) on that workspace and all sub-workspaces

    Now to your questions:

    How a user joins the workspace

    > What type of perms or configuration is needed to allow new users to join a workspace as members?
    >

    I think the way to go is the join-group plugin
    http://doc.tikiwiki.org/PluginSubscribeGroup-PluginSubscribeGroups
    this is done through the plugin tab on the textarea admin page
    /tiki-admin.php?page=textarea

    And then creating a wiki-parsed module with this plugin?
    Can you try it?

    It doesn't make sense that any 'registered' can type any user name in there, just to add himself to the workspace.
    Anyway if one has tiki_p_admin_workspace on the workspace he can still add any user via the 'add user' button on top of resources.

    Objects cannot be created from Admin Tab at edu.tw.o

    > .....

    See before. The one you installed here (and even the latest one) is a work in progress that has to be tested. Latest svn should work now.

    Removing php code with the available restypes array from smarty (and smarty uncapability to define arrays itself) made me do a few base changes, where the available res type for creation are now got from the resourceslib. Much to be done in this area too, like returning only restypes for which there's the feature enabled etc...

    1.1.3. mod_calendar_new

    > Thanks for reusing Tiki code for the calendar to avoid having to maintain old and duplicated code. However, a few things are gone with that change, and one important is still missing for my point of view (to avoid having users lost)
    >
    > mod_calendar_new:
    > # doesn't seem to show the list of next event in the same module box (former ws module did)
    > # doesn't seem to show the "" surrounding the month, in order to allow easily passing months forward and backwards for the calendar view (former ws module did)

    So we should ask these improvements over mod-calendar_new or its template. It makes no sense to maintain another calendar module.

    > # it doesn't show any direct link for posting to the calendar (afaik, the former ws module didn't allow that either). Is it difficult to add?
    >

    On my install mod-calendar_new shows a javascript bubble coming out when the mouse gets over the day, with appointment description, modify it, delete. To add you must click on the month and manage the calendar as usual, but there could be an add-new-item button in the js bubble.

    > thanks for your support, as always, pingus!

    Great job also in transferring everything here!

    Can you add possibility to keep a watch on the whole forum, not only on single threads?
    Giancarlo
    Link to this comment
    Posted by Xavi posts: 158 ☆ ☆ ☆ ☆ ☆
    > Xavi and everyone!
    >
    > By trying to remove php code from smarty I messed up a few things that did work before. Last night I commited fixes for some of them.
    > You should apply them here to test, and don't rely on workspaces.altervista.org, because that has not got updated yet.
    > Sorry Icouldn't dedicate too much time to testing it, so then this site has become the place to do it 😊

    Ok, I don't have access through ftp to the current server behind edu.tw.o (the same which is hosting tw.o). But I could install your files through packaging them from svn into a new tar.gz and put them available somewhere else (mods.tw.o is slow re-packing and re-publishing new changes):
    http://xavidp.pangea.org/tiki/mods/Dist/features-aulawiki-1.7.3.tgz

    So I upgraded aulawiki in edu.tw.o to this version of 1.7.3 from svn mods (r23696).
    However, I attempted to create a new object in a workspace like this one:
    http://edu.tikiwiki.org/tiki-workspaces_desktop.php?workspaceId=2&zoneId=7

    Through "resources" module, new object, and select sheet or wiki page, and they were not created.

    Am I doing something wrong?
    Maybe permissions on that workspace are not the right ones???
    I've granted you, pingus, admin perms on edu.tw.o so that you can also have a look at the whole configuration, if needed.

    >
    > Changes in yesterday commit:
    >
    > -the drop-down select of creatable objects should appear now

    Well, it was appearing before, but didn't create the objects.

    > -tiki_p_create_workspace_resour, as a perm on the workspace for a group/role, will now allow *only* creation of new resources. Before it could allow also deleting and changing their perms. But if we don't want a 'own-space resource manager' to be able to delete objects, he shouldn't be able to change his perms on them too, allowing himself whatever. So this 'intermediate' role should be discussed more in depth. If he can change perms of his ws objects, there should be perms he can, and perms he cannot, modify. So unless he has full deletion power, which carries with it every other perms I think.
    > To solve this somehow there could be a constant (like the existing
    >
    Copy to clipboard
    > define ("_TIKI_P_CREATE_WORKSPACE_RESOUR_CAN_ADD_USERS_",false)
>

    > in lib/workspaces/userlib.php
    >
    > something like
    >
    Copy to clipboard
    > define ("_TIKI_P_CREATE_WORKSPACE_RESOUR_CAN_DELETE_RESOURCES_",false)
>

    > wich would also trigger his capacity to modify any objectperms of his ws
    >
    > So there remains the tiki_p_admin_workspaces objectpermission
    > on a workspace, which grants everything(del/create new sub-ws, del/create objets, change object perms, add groups from the ws and sub-ws, add users) on that workspace and all sub-workspaces

    Ok, I guess, that if this has been applied, the documentation should be updated to reflect that (and avoid having key information lost in forums but out of sync with documentation...).

    > Now to your questions:
    >
    > !!!# How a user joins the workspace
    > > What type of perms or configuration is needed to allow new users to join a workspace as members?
    > >
    >
    > I think the way to go is the join-group plugin
    > http://doc.tikiwiki.org/PluginSubscribeGroup-PluginSubscribeGroups
    > this is done through the plugin tab on the textarea admin page
    > /tiki-admin.php?page=textarea
    >
    > And then creating a wiki-parsed module with this plugin?
    > Can you try it?

    Yes, I?ve tried this with other tiki sites and it works. But it seems to me too much work for any/all new workspaces created. I wish some automatic process could be recovered, as before (using the module for user and group administration from a new Tab for Administration of the workspace.

    > It doesn't make sense that any 'registered' can type any user name in there, just to add himself to the workspace.

    Yes, I agree. But any user (provided that the group is open for new and free memberships) should be able to join the workspace by at least writing his/her name on that box, or clicking some "Add me" button somewhere there... Maybe an easy hack can be coded for that?

    > Anyway if one has tiki_p_admin_workspace on the workspace he can still add any user via the 'add user' button on top of resources.

    Ok, great.

    > !!!# Objects cannot be created from Admin Tab at edu.tw.o
    > > .....
    >
    > See before. The one you installed here (and even the latest one) is a work in progress that has to be tested. Latest svn should work now.

    It didn't for me, see above.

    > Removing php code with the available restypes array from smarty (and smarty uncapability to define arrays itself) made me do a few base changes, where the available res type for creation are now got from the resourceslib. Much to be done in this area too, like returning only restypes for which there's the feature enabled etc...

    Ok. But still basic behavior is missing for me. Create a new wiki page fails.
    Can you duplicate with the 1.7.3 tar.gz that I produced with laatest svn code?

    > !!!# mod_calendar_new
    > > Thanks for reusing Tiki code for the calendar to avoid having to maintain old and duplicated code. However, a few things are gone with that change, and one important is still missing for my point of view (to avoid having users lost)
    > >
    > > mod_calendar_new:
    > > # doesn't seem to show the list of next event in the same module box (former ws module did)
    > > # doesn't seem to show the "" surrounding the month, in order to allow easily passing months forward and backwards for the calendar view (former ws module did)
    >
    > So we should ask these improvements over mod-calendar_new or its template. It makes no sense to maintain another calendar module.

    Ok, I agree.

    >
    > > # it doesn't show any direct link for posting to the calendar (afaik, the former ws module didn't allow that either). Is it difficult to add?
    > >
    >
    > On my install mod-calendar_new shows a javascript bubble coming out when the mouse gets over the day, with appointment description, modify it, delete. To add you must click on the month and manage the calendar as usual, but there could be an add-new-item button in the js bubble.

    Did it work for you here in edu.tw.o? What do we have missing here for that to work?
    (I didn't see how to add a new event from the workspace desktop)

    >
    > > thanks for your support, as always, pingus!
    >
    > Great job also in transferring everything here!
    >
    > Can you add possibility to keep a watch on the whole forum, not only on single threads?
    > Giancarlo

    Mmmm, you should be able to do that. It's been always possible, afaik.
    Don't you see the pair of eye icons at the topic list from each forum?
    Link to this comment
    Posted by pingus posts: 52 ☆ ☆ ☆
    > But I could install your files through packaging them from svn into a new tar.gz and put them available somewhere else (mods.tw.o is slow re-packing and re-publishing new changes):
    > http://xavidp.pangea.org/tiki/mods/Dist/features-aulawiki-1.7.3.tgz
    >
    > So I upgraded aulawiki in edu.tw.o to this version of 1.7.3 from svn mods (r23696).
    > However, I attempted to create a new object in a workspace like this one:
    > http://edu.tikiwiki.org/tiki-workspaces_desktop.php?workspaceId=2&zoneId=7
    >
    > Through "resources" module, new object, and select sheet or wiki page, and they were not created.
    >
    > Am I doing something wrong?

    I am replying to your problems one by one... This is the first and looks more important

    I logged in this site and tried to create a new resource in three ways:
    1) TEST page trough the resources module accessed alone-> OK http://edu.tikiwiki.org/tiki-workspaces_view_module.php?module=workspaces_resources&workspaceId=2
    2) TEST2 page through the same module inside the desktop (your example) -> KO
    3) TEST3 page from the admin workspace->WSDOC->resources (spanner icon, brings to same url as 1): OK

    so there's definetly a clash among variables passed to smarty, probably used by other modules in the same destop..
    Also because I installed your 1.7.3 locally, created a desktop with just the resources and calendar modules, and creation works.
    Will hammer it down...
    Link to this comment
    Posted by pingus posts: 52 ☆ ☆ ☆
    > > But I could install your files through packaging them from svn into a new tar.gz and put them available somewhere else (mods.tw.o is slow re-packing and re-publishing new changes):
    > > http://xavidp.pangea.org/tiki/mods/Dist/features-aulawiki-1.7.3.tgz

    Thanks for that, and for having admin rights here.
    I wouldn't have solved this.

    I could reproduce it because I noticed that the fact happened when the specific workspace did't have any desktop zones (like on edu.tw.o), and defaulted on getting the zones copied up from its ws type...
    It was OK when the workspace had its specific zones redefined, like at my local copy.
    The cause is a widespread error that may come back again, because the ubiquous command ususlly at start of every script:
    $workspace=$workspacelib->get_current_workspace()

    would load the $workspace[type] field with the full wstype object array, while all other wslib functions (get_ws_by_id() etc..), these also often called, return the workspaces' table record as it is, with its 'type' field containing a numeric id, not the full object array, in it.
    So there are still a few places where
    $workspace[type] contains an id,
    others (most) where it contains the full ws' wstype array, while the ids found in
    $workspace[type][wsypeId]

    Hope its solved now.
    Link to this comment
    Posted by Xavi (as xavidp - admin) posts: 15 ☆ ☆ ☆
    > > > But I could install your files through packaging them from svn into a new tar.gz and put them available somewhere else (mods.tw.o is slow re-packing and re-publishing new changes):
    > > > http://xavidp.pangea.org/tiki/mods/Dist/features-aulawiki-1.7.3.tgz
    >
    > Thanks for that, and for having admin rights here.
    > I wouldn't have solved this.
    >
    > I could reproduce it because I noticed that the fact happened when the specific workspace did't have any desktop zones (like on edu.tw.o), and defaulted on getting the zones copied up from its ws type...
    > It was OK when the workspace had its specific zones redefined, like at my local copy.
    > The cause is a widespread error that may come back again, because the ubiquous command ususlly at start of every script:
    > $workspace=$workspacelib->get_current_workspace()
    >
    > would load the $workspace[type] field with the full wstype object array, while all other wslib functions (get_ws_by_id() etc..), these also often called, return the workspaces' table record as it is, with its 'type' field containing a numeric id, not the full object array, in it.
    > So there are still a few places where
    > $workspace[type] contains an id,
    > others (most) where it contains the full ws' wstype array, while the ids found in
    > $workspace[type][wsypeId]
    >
    > Hope its solved now.
    Hi pingus:

    Oh well, might it be that I'm doing something wrong?
    I re-packed the tar.gz with your latest changes (from now onwards I'll append the revision number (r23713, in this case):
    http://xavidp.pangea.org/tiki/mods/Dist/features-aulawiki-1.7.3.23713.tar.gz

    And installed it in local and in edu.tw.o, but no way: I can't create a new wiki page from the workspace desktop 😕

    And while attempting to create a new workspace of type "Documentation group", I get this error:
    Copy to clipboard
    Fatal error: Call to a member function get_watches() on a non-object in [path_to_tiki]/lib/notifications/notificationemaillib.php on line 488


    About group membership:
    (1) I tried with plugin susbscribegroup(s), but It dowsn't work either inside the ws desktop: plugins In general) seem to be non-parsed while shown through the ws desktop.
    http://edu.tikiwiki.org/tiki-workspaces_desktop.php?workspaceId=2

    See the last view page module.
    However, if you visit the page directly, the plugins div and subscribegroup work fine.
    http://edu.tikiwiki.org/WSDOC-Home

    (2) I tried also using the plugin subscribegroups, and it would be wise if it allowed wildcards at filtering level. This way, we could have a single module on a side column to allow any user to join any of the groups which are free to join, by adding this simple code:
    Copy to clipboard
    {SUBSCRIBEGROUPS(groups="WSGRP*",subscribe="Join")}{SUBSCRIBEGROUPS}


    What do you think?
    Link to this comment
    Posted by pingus posts: 52 ☆ ☆ ☆
    > I re-packed the tar.gz with your latest changes (from now onwards I'll append the revision number (r23713, in this case):
    > http://xavidp.pangea.org/tiki/mods/Dist/features-aulawiki-1.7.3.23713.tar.gz
    >
    > And installed it in local and in edu.tw.o, but no way: I can't create a new wiki page from the workspace desktop 😕

    Strange that if you try to create it by accessing the module outside the desktop it works:
    http://edu.tikiwiki.org/tiki-workspaces_view_module.php?module=workspaces_resources&workspaceId=2
    I could create WSDOC-Test Page.
    Strange also that on creating a new ws of anytype (eg docgroup) there is no ws destop defined to it (ws DOCTEST2). Creation of the desktop, at ws creation, fails
    http://edu.tikiwiki.org/tiki-workspaces_assigned_modules.php?wstypeId=11&wsmodtype=workspace
    while the wstype model for DOCGROUP has:
    http://edu.tikiwiki.org/tiki-workspaces_assigned_modules.php?wstypeId=6&wsmodtype=workspace%20type

    Not having his own destop, the ws relies on inheriting the one of his ws type. And by some way it misses to pass something that avoid creation of objects.

    If you try to define the same zones and modules inside the specific WSDOC ws desktop, from here:
    http://edu.tikiwiki.org/tiki-workspaces_assigned_modules.php?wstypeId=2&wsmodtype=workspace
    I am pretty sure obj creation works.

    This is the point I am trying to smash: when there's no desktop for the ws, and thus it gets inherited frm wstype definition, things don't work. And why a desktop for each new ws doesn't gets created in the first instance.

    Please confirm me that this is the problem, I am close to solving it.

    >
    > And while attempting to create a new workspace of type "Documentation group", I get this error:
    >
    Copy to clipboard
    > Fatal error: Call to a member function get_watches() on a non-object in [path_to_tiki]/lib/notifications/notificationemaillib.php on line 488
>

    >

    Line 488 is related to setting notifications (watches) on structures.
    And in fact it seems that the ws gets created, with resources up to a point where it tried to create a structure, then no more.
    These are the reources a docgroup ws type is suppose to create for a new ws:
    http://edu.tikiwiki.org/tiki-workspaces_types_resources.php?wstypeId=6
    These are the only ones that get created after successfully creating the ws DOCTEST2:
    http://edu.tikiwiki.org/tiki-workspaces_view_module.php?module=workspaces_resources&workspaceId=11

    So there's definetly an error in creating structures, something might have changed since. Will look to it after.

    > About group membership:

    > (1) I tried with plugin susbscribegroup(s), but It dowsn't work either inside the ws desktop: plugins In general) seem to be non-parsed while shown through the ws desktop.

    Well the ws desktop isn't always assured to be visible anyway.
    Does it work outside, eg on a side bar or in a wiki page? It does for me.


    > http://edu.tikiwiki.org/tiki-workspaces_desktop.php?workspaceId=2
    >
    > See the last view page module.
    > However, if you visit the page directly, the plugins div and subscribegroup work fine.
    > http://edu.tikiwiki.org/WSDOC-Home
    >
    > (2) I tried also using the plugin subscribegroups, and it would be wise if it allowed wildcards at filtering level. This way, we could have a single module on a side column to allow any user to join any of the groups which are free to join, by adding this simple code:
    >
    Copy to clipboard
    > {SUBSCRIBEGROUPS(groups="WSGRP*",subscribe="Join")}{SUBSCRIBEGROUPS}
>

    >
    > What do you think?

    That sounds great and easy to modify. But first I want to solve the previous.
    If these plugin work in a module on a sidebar it's OK for now.
    Link to this comment
    Posted by pingus posts: 52 ☆ ☆ ☆
    > > I re-packed the tar.gz with your latest changes (from now onwards I'll append the revision number (r23713, in this case):
    > > http://xavidp.pangea.org/tiki/mods/Dist/features-aulawiki-1.7.3.23713.tar.gz
    > >
    > > And installed it in local and in edu.tw.o, but no way: I can't create a new wiki page from the workspace desktop 😕

    I don't want to risk to update a mod here from a site of mine.
    How do you provide mods in the proper way? What triggers the 'Update' of an already installed mod?

    Anyway I commited revision 23721. Definetly hope it will solve.

    And I checked: I was wrong when I said that a dektop with its zones is copied from the ws_type model at every new ws creation.
    The ne ws simply gets it desktop from the wstype if none specific desktop for it workspace is defined.
    Link to this comment
    Posted by Xavi posts: 158 ☆ ☆ ☆ ☆ ☆
    I re-packed the tar.gz with your latest changes (from now onwards I'll append the revision number (r23713, in this case):
    http://xavidp.pangea.org/tiki/mods/Dist/features-aulawiki-1.7.3.23713.tar.gz

    And installed it in local and in edu.tw.o, but no way: I can't create a new wiki page from the workspace desktop 😕

    I don't want to risk to update a mod here from a site of mine.
    How do you provide mods in the proper way? What triggers the 'Update' of an already installed mod?

    Anyway I commited revision 23721. Definetly hope it will solve.

    And I checked: I was wrong when I said that a dektop with its zones is copied from the ws_type model at every new ws creation.
    The ne ws simply gets it desktop from the wstype if none specific desktop for it workspace is defined.

    Hi pingus:
    No success. I packed a new mod with your latest changes (from r23877, which included yours) and no change. You can test that your self from here:
    http://xavidp.pangea.org/tiki/mods/Dist/features-aulawiki-1.7.3.23877.tar.gz

    I'll send you (off forum) the db dump from the former edu.tw.o so that you can play in local with some real data of ws from edu.tw.o
    Link to this comment
    Posted by pingus posts: 52 ☆ ☆ ☆
    > And while attempting to create a new workspace of type "Documentation group", I get this error:
    >
    Copy to clipboard
    > Fatal error: Call to a member function get_watches() on a non-object in [path_to_tiki]/lib/notifications/notificationemaillib.php on line 488
>


    I commited rev 24006, updated the mod at edu.two with the new tgz
    provided from
    http://workspaces.altervista.org/mods
    and now the error is gone, structures, and new ws with structures, in them are created and categorized with no errors.

    There has been a new function about notifications for structures that wanted some 'global $structlib' in calling.
    Thanks to sylvieg for the suggestion on tiki-devel!
    Link to this comment
    Posted by Xavi posts: 158 ☆ ☆ ☆ ☆ ☆
    > > And while attempting to create a new workspace of type "Documentation group", I get this error:
    > >
    Copy to clipboard
    > > Fatal error: Call to a member function get_watches() on a non-object in [path_to_tiki]/lib/notifications/notificationemaillib.php on line 488
> >

    >
    > I commited rev 24006, updated the mod at edu.two with the new tgz
    > provided from
    > http://workspaces.altervista.org/mods
    > and now the error is gone, structures, and new ws with structures, in them are created and categorized with no errors.
    >
    > There has been a new function about notifications for structures that wanted some 'global $structlib' in calling.
    > Thanks to sylvieg for the suggestion on tiki-devel!

    Wohoo, congratullations, pingus!

    So, since many things seem to be working fine again, I would suggest that we invest some time to improve (update) current documentation on how to use aulawiki. We are missing a simple step-by-step tutorial on how to set up a workspace:
    1) for projects (not related to education), for instance, and
    2) for educational scenarios.

    What do you think?

    And I would suggest to do that on a new WS created in edu.tw.o from scratch, with the appropriate settings since the beginning. So that even the process of creating this workspace can be used as a demo on how to setup a third workspace, the new one here on edu.tw.o for documentation. 😊
    What do you think about using some Screen recorder while you define the new ws from scratch? (xvidcap, gtk-recordmydesktop, etc.; with or without audio)

    (right now you are the one with the clear mind on how the new ws should be set up).

    A quick & dirty screenrecording would be enough (at least for me and other tiki experienced users), so that we can help later on on the step by step tutorial or documentation for completely new users of AulaWiki.

    So, opinions?
    Link to this comment
    Posted by pingus posts: 52 ☆ ☆ ☆
    > > !!!# How a user joins the workspace

    > > I think the way to go is the join-group plugin
    > > http://doc.tikiwiki.org/PluginSubscribeGroup-PluginSubscribeGroups
    ...
    > Yes, I?ve tried this with other tiki sites and it works. But it seems to me too much work for any/all new workspaces created. I wish some automatic process could be recovered, as before (using the module for user and group administration from a new Tab for Administration of the workspace.
    >
    > > It doesn't make sense that any 'registered' can type any user name in there, just to add himself to the workspace.
    >
    > Yes, I agree. But any user (provided that the group is open for new and free memberships) should be able to join the workspace by at least writing his/her name on that box, or clicking some "Add me" button somewhere there... Maybe an easy hack can be coded for that?

    At this site, the WSDOC workspace is of workspace_type DOCGRUOP (Documentation Group)
    http://edu.tikiwiki.org/tiki-workspaces_admin.php?viewWS=0&edit=2
    When a ws of DOCGROUP ws type is first created, has defined roles:
    Owner
    In practice it has these groups created:
    • WSDOC (common group with 0 perms that includes members of, useful for assigning eg modules to everyone in the ws )
      • WSDOC-Owner
    http://edu.tikiwiki.org/tiki-workspaces_types_roles.php?wstypeId=6

    Here the WDSOC ws, although itwould have only Owner from its ws_type roles, it has actually 3 roles (and relative groups):
    Owner, Teacher, Student

    So in practice it has these groups created:
    • WSDOC (that contains)
      • WSDOC-Owner
      • WSDOC-Teacher
      • WSDOC-Student
    http://edu.tikiwiki.org/tiki-workspaces_view_module.php?module=workspaces_user_groups&workspaceId=2#

    When you showed the add_user module
    http://edu.tikiwiki.org/tiki-workspaces_view_module.php?module=workspaces_user_groups&workspaceId=2#
    any Registered was able to add any username , by typing it, to any of these groups: WSDOC, WSDOC-Owner, WSDOC-Teacher, WSDOC-Student.

    Very unsensitive. A student could make his mate join the 'Teacher' group of his workspace!

    How can the program decide automatically to which of the groups of this ws, a registered user is allowed to subscribe? Surely not because its name contains the string student!
    -With ))PluginSubscribeGroup(( you can specify in the plugin code a single group name one can join .
    -With ))PluginSubscribeGroups(( you can specify in the plugin code multiple group names one can join.

    To be done automatically, ))PluginSubscribeGroups(( may comes to help.
    Both these plugins are smart enough: they will discover if the provided group/groups are not defined 'user_can_join', and, in case they are not, they will not show that group/anything among the groups you can join.
    So by feeding ))PluginSubscribeGroups(( with all the 1st level groups that belong to the workspace (eg excluded the container WSDOC), it will automatically show only those that are 'allow_join'. If none is, it will show nothing.

    There remains the problem of how to define these groups 'allow_join', especially by a non-admin like someone whose role has been delegated with tiki_p_admin_workspace objectperm only on a single workspace.
    It could be done in redefining the workspace roles tables, so the groups for the roles defined as such will be created as such. Or afterwards (mark/unmark it at anytime after creation). Again this is group-administration by non-admins.
    Will think about it.

    Meanwhile a module with an hand-filled wikiplugin PluginSubscribeGroup(s) can do to fill the missing possibility of joining WSDOC at this site
    Link to this comment
    Posted by Xavi (as xavidp - admin) posts: 15 ☆ ☆ ☆
    > > > !!!# How a user joins the workspace
    >
    > > > I think the way to go is the join-group plugin
    > > > http://doc.tikiwiki.org/PluginSubscribeGroup-PluginSubscribeGroups
    > ...
    > > Yes, I?ve tried this with other tiki sites and it works. But it seems to me too much work for any/all new workspaces created. I wish some automatic process could be recovered, as before (using the module for user and group administration from a new Tab for Administration of the workspace.
    > >
    > > > It doesn't make sense that any 'registered' can type any user name in there, just to add himself to the workspace.
    > >
    > > Yes, I agree. But any user (provided that the group is open for new and free memberships) should be able to join the workspace by at least writing his/her name on that box, or clicking some "Add me" button somewhere there... Maybe an easy hack can be coded for that?
    >
    > At this site, the WSDOC workspace is of workspace_type DOCGRUOP (Documentation Group)
    > http://edu.tikiwiki.org/tiki-workspaces_admin.php?viewWS=0&edit=2
    > When a ws of DOCGROUP ws type is first created, has defined roles:
    > Owner
    > In practice it has these groups created:
    > *WSDOC (common group with 0 perms that includes members of, useful for assigning eg modules to everyone in the ws )
    > **WSDOC-Owner
    > http://edu.tikiwiki.org/tiki-workspaces_types_roles.php?wstypeId=6
    >
    > Here the WDSOC ws, although itwould have only Owner from its ws_type roles, it has actually 3 roles (and relative groups):
    > Owner, Teacher, Student
    >
    > So in practice it has these groups created:
    > *WSDOC (that contains)
    > **WSDOC-Owner
    > **WSDOC-Teacher
    > **WSDOC-Student
    > http://edu.tikiwiki.org/tiki-workspaces_view_module.php?module=workspaces_user_groups&workspaceId=2#
    >
    > When you showed the add_user module
    > http://edu.tikiwiki.org/tiki-workspaces_view_module.php?module=workspaces_user_groups&workspaceId=2#
    > any Registered was able to add any username , by typing it, to any of these groups: WSDOC, WSDOC-Owner, WSDOC-Teacher, WSDOC-Student.
    >
    > Very unsensitive. A student could make his mate join the 'Teacher' group of his workspace!
    >
    > How can the program decide automatically to which of the groups of this ws, a registered user is allowed to subscribe? Surely not because its name contains the string student!
    > -With ))PluginSubscribeGroup(( you can specify in the plugin code a single group name one can join .
    > -With ))PluginSubscribeGroups(( you can specify in the plugin code multiple group names one can join.
    >
    > To be done automatically, ))PluginSubscribeGroups(( may comes to help.
    > Both these plugins are smart enough: they will discover if the provided group/groups are not defined 'user_can_join', and, in case they are not, they will not show that group/anything among the groups you can join.
    > So by feeding ))PluginSubscribeGroups(( with all the 1st level groups that belong to the workspace (eg excluded the container WSDOC), it will automatically show only those that are 'allow_join'. If none is, it will show nothing.
    >
    > There remains the problem of how to define these groups 'allow_join', especially by a non-admin like someone whose role has been delegated with tiki_p_admin_workspace objectperm only on a single workspace.
    > It could be done in redefining the workspace roles tables, so the groups for the roles defined as such will be created as such. Or afterwards (mark/unmark it at anytime after creation). Again this is group-administration by non-admins.
    > Will think about it.
    >
    > Meanwhile a module with an hand-filled wikiplugin PluginSubscribeGroup(s) can do to fill the missing possibility of joining WSDOC at this site

    Thanks pingus. I replied to this also on my previous reply
    Link to this comment

    Switch Language