Ticket #538 (closed Enhancement: fixed)

Opened 7 years ago

Last modified 7 years ago

Advancing the moodle case

Reported by: Malte Owned by: jri
Priority: Blocker Milestone:
Component: DeepaMehta Standard Distribution Version: 4.1.2
Keywords: Cc: malte, dgf
Complexity: 3 Area: GUI / Usability
Module: deepamehta-accesscontrol

Description (last modified by jri) (diff)

The moodle moodle plugin for DM is already functional but feels a bit too rattly to use to hand it out to end users. By now the communication between these two systems need to be triggered by a user on a specific topic via a topic commands like "Ask for my moodle courses" and "Load course contents". I see the need to connect these two systems somehow more magically.

The communication of DM with a remote moodle installation is made of 3 more or less "technical requests" on behalf of each user. I see that there is the necessity to trigger these calls automatically, triggered by hooks of the DM framework.

For example, I could imagine that it makes sense that the mapping-moodle-plugin reacts on a DeepaMehta users login in terms of: Whenever a user logs into DeepaMehta (and has a moodle security key set), the DeepaMehta plugin issues 2 requests on behalf of the user:

# getMoodleCourses() - to check if there are any (new) courses the user is participating in, and for any of these course call subsequently
# getCourseContents() - to check if there are any (new) course materials to index for DM

In this scenario a plugin would have the need to be able to react upon an event (like "user authenticated" for example) fired by the dm4-accesscontrol module.

I just wanted to ask what are your thoughts on this and is there already a way to realize this with the current DM?

Change History

comment:1 Changed 7 years ago by Malte

Here is a working link to the mapping-moodle module: https://github.com/mukil/mapping-moodle - trac makes somehow fun out of link-labels. Furthermore here you find a working snapshot of your this moodle plugin compatible with DM 4.1.2:

http://download.deepamehta.de/nightly/moodle-plugin-1.1.2-SNAPSHOT.jar

To setup a compatible web service definition for this checkout the README in the github repo.

comment:2 Changed 7 years ago by jri

  • Description modified (diff)

comment:3 Changed 7 years ago by jri

Yes, a server-side DM "ON_LOGIN" event definitely makes sense with your Moodle scenario, and would be useful for other DM applications as well. Currently there is no such server-side event and it would require some Core extension first.

But there is a "logged_in" event at client-side already, which you could probably use:

dm4c.add_listener("logged_in", function(username) {
    ...
})

There you would issue a request against your DM Moodle REST service, which in turn would perform the getMoodleCourses() and other calls against the Moodle installation.

comment:4 Changed 7 years ago by jri

For the technical background about why a server-side ON_LOGIN event would require a Core extension see #290 (reopened). The point is the ON_LOGIN event is *not* fired by the Core but, as you said, by a plugin, namely Access Control.

comment:5 Changed 7 years ago by jri

Meanwhile we have a server-side event extension facility. See #290.

comment:6 Changed 7 years ago by Jörg Richter

Access Control: LOGIN and LOGOUT events (#538).

The Access Control module fires custom events once a user logs in or out.

Your plugin can listen to these events analogous to core events:

import de.deepamehta.plugins.accesscontrol.event.PostLoginUserListener;
import de.deepamehta.plugins.accesscontrol.event.PostLogoutUserListener;

public class TimePlugin extends PluginActivator implements PostLoginUserListener,
                                                           PostLogoutUserListener {
    @Override
    public void postLoginUser(String username) {
        ...
    }

    @Override
    public void postLogoutUser(String username) {
        ...
    }
}

Don't forget to put Access Control in your plugin's dependencies (pom.xml):

<dependency>
    <groupId>de.deepamehta</groupId>
    <artifactId>deepamehta-accesscontrol</artifactId>
    <version>4.2-SNAPSHOT</version>
</dependency>

See #538.
See #290.

comment:7 Changed 7 years ago by Malte

Great news, I have just implemented such a listener and it works for the first time.

Just one thing: The ACL-Plugin seems to be waiting until my (or even any) observer which is implementing this listener has done its business.

Cause now:

  • My update logic (querying a remote service for the particular user) blocks the login dialog (initially) for quite some time
  • If something goes wrong in any of the observers implementing this listeners, e.g. a RuntimeException? is thrown, login fails though it actually succeeded.

Furthermore: When my plugins consumes this type of listener, wouldn't it be nice to render some sort of information to the just logging in user? Imagine something like: "Login successfull. The Moodle Plugin just started to check all your courses for new materials".

So, is there a way to change this and what do you think about such possible extension?

comment:8 Changed 7 years ago by Malte

One other thing: In the listener implementation I may want to create (or update) some topics, isn't it crucial to have a users ClientState? available then? If so, is there a way I can construct a proper one given just the "username"? Thanks for your help.

Edited: "to create (OR UPDATE) some topics" - It looks like I can't do that without a ClientState?, at least I get a NullPointerException? if I pass "null" as ClientState?. Can you confirm this?

Last edited 7 years ago by Malte (previous) (diff)

comment:9 Changed 7 years ago by Malte

  • Status changed from new to closed
  • Resolution set to fixed

To clarify:

  • A ClientState?-Object is just needed for automatic Workspace-Assignment of topic (can be done manually)
  • I imlpemented a Thread() so my Worker does not block the login process (this way the listener can return to ACL-Plugin firing the postLoginEvent() before my sync-job is done)

I have updated my /wiki/Malted/PluginDevelopmentNotes accordingly.
Details are also to find in https://github.com/mukil/mapping-moodle/commit/63707cca92f14f9dd37416f3db06ab965b3881e9

Next up: #539 - At best through employing the new dm4-websockets-modules :)

Thanks for your support, this worked fine for me.

Note: See TracTickets for help on using tickets.