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

[edu.t.o] Development

Forum List Topic List

 
Thread actions
Print this page
  • Print all pages

    • Reassestment of edu.two

    Posted by pingus posts: 52 ☆ ☆ ☆
    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.
    Reads: 27471
    Link
    Posted by Xavi posts: 158 ☆ ☆ ☆ ☆ ☆
    > 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.


    I have to admit that I'm kind of overwhelmed by the amount of information.
    See my proposal in the reply to the other thread

    Anyway, for the sae of simplicity to follow up on that thread (which became too long and to nested), I copy my reply here, so that we can continue disucssing in this new thread of you:

    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
    Posted by pingus posts: 52 ☆ ☆ ☆
    > 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)

    Yes Xavi. I wanted to get rid of major problems too, and focus on a better documentation and more examples.
    But now comes a busy period, until 6 Jan, with kids and everything you know.
    I would pause until then, and only start some extending of the docu locally
    Link

    Posted by pingus posts: 52 ☆ ☆ ☆
    I am also trying to advocate for fixing an inconsistency (for me) in how deferred inheritance of perms from 'Registered', when defining perms for a new group, cannot be avoided, although one defines the new group without 'including the perms of' Registered.

    That is very annoying, it was not so before.
    Because when you define permission for the RolePerms templates group, you want not to have any deferred inheritance (shaded perms that would be inherited at runtime, if Register still has them):
    if the new group does not 'include the perms of Registered', all the perms marked (shaded or not) must be written in the grouppermissions table for that group.

    This is important for RolePerms-xxx, because these perms will be copied and transformed into objectpermissions granted to that role when any ws objects is created.

    I had to empty temporarily all perms of 'Registered' when defining the RolePerms-xxx templates at edu.two, to get things right.

    That is also not very consistent for normal usage outside workspaces.

    See tikiwiki-devel thread 'tiki-assignpermissions.php'
    Link
    Posted by pingus posts: 52 ☆ ☆ ☆
    > I am also trying to advocate for fixing an inconsistency (for me) in how deferred inheritance of perms from 'Registered'...
    >
    > That is very annoying, it was not so before.
    > ...
    > I had to empty temporarily all perms of 'Registered' when defining the RolePerms-xxx templates at edu.two, to get things right.

    You cannot ask anyone to do that.

    I would add that, without fixing this in 3.3, it becomes very hard, if not impossible, to create Roles properly.
    That would be blocking for workspaces. The only solution would be to install the roles via profiles, which do not have these restrains.

    But this creates also problems for normal use, because this way, when you take away eg tiki_p_forum_post from Registered, you take it away also from Editors. There is no way that Editors can have tiki_p_forum_post indipendently from Registered or Anonymous.
    Link

    Posted by pingus posts: 52 ☆ ☆ ☆
    I also get a bug when trying to remove members from a group, can't remove members from groups.
    eg trying to remove 'pingus' from WSGRPWSDC at (Members tab):
    http://edu.tikiwiki.org/tiki-admingroups.php?group=WSGRPWSDOC

    I get this:
    Parse error: syntax error, unexpected T_ELSE in /var/www/edu.tikiwiki.org/templates_c/it
    %%4E
    4EF^4EF91FAC%%tiki-adminusers.tpl.php on line 609

    This is 3.3 related, it has nothing todo with ws.
    Link

    Switch Language