Anyone with access to my machine can read the password as it is saved in plain text. There should be an option for the program to prompt for the password if the user does not save his/her password in welearnrc

Why?

Given that this is to be used as a script. One should be able to run it from anywhere and store the files in a predefined path. As of now, it downloads them in the directory from where the script is run.

Possible features:

• A prefix setting in preference section in .welearnrc
• A -p flag while running the script to save to a custom path. This should overwrite the prefix if already set in .welearnrc

PS: I was about to implement this but @sahasatvik is working on switching to using moodle API. This would change the details of the implementation. I would start after all such major changes are done.

Feature for TAs

This PR adds the capability for TAs to fetch assignment submissions from welearn.

Notable features

• The assignments for each subject are downloaded into it's own submissions folder.
• Each student has it's own folder for each assignment.
• If the assignment are in archived form (compressed), they are automatically uncompressed.

Config changes

The users will have to add a [submissions] section to their config with the appropriate information (as shown below)

[submissions]
CS1103 = ALL
CS1101 = 21MS020, ... , 21MS120
CS1102 = 21MS120,  21MS121,  21MS122,  21MS123,  21MS124,  21MS125,  21MS126
CS1101 = 20MS011,  19MS112, 21MS020, ... , 21MS120

Note that you have to add key value pairs of courseid and the roll numbers for which to fetch the submissions The roll numbers can be entered in the following form:

• ALL to fetch all submissions
• a range of roll numbers
• a explicit list of roll numbes
• a mix of range and explicit roll numbers

CLI arguments

• An additional action, s (submissions) has been exposed to the users for using this feature
• The users can also specify list of roll numbers from the cli using -r (--rolls) option
• CLI arguments override the config settings

Misc

A new cache for course information is also added. The users can update the cache using the -u flag

Refactoring welearnbot.py

This refactor separates the logic being handled into functions using the functional programming approach. This will give the script a pipeline like behaviour while keeping it extendable.

The following refactors were done.

• move the parser setup to a separate function
• move constants(like config location, etc.) into separate files so that they are accessible everywhere
• create (resolver) functions for getting information from config , input, server, etc
• isolate code for handling each action into handler functions (handle_action)

Feature

This introduces the --gcalendar flag with the assignments action, which will add due assignments to the user's Google Calendar of choice. You can run

welearn_bot -dc assignments ALL

to add all due assignments to your Google Calendar, after appropriate configuration.

The duration of the created event extends one hour before the deadline, up to the deadline. This choice was made so that the user gets some level of notification before the deadline, and because logically the event ought to end when the deadline is reached.

The user can also choose a "sub calendar" within their Google Calendar account to push events. This gives an additional layer of control, whereby calendarwide preferences such as event colour, notification settings, visibility/sharing, etc can be configured directly from Google Calendar.

Thanks to @AK6263 for contributing the base code for connecting the the Google Calendar API and pushing events.

Caveats

Using this feature requires a fairly complicated process of authentication, which includes the creation of tokens from the Google Developer Console. Complete details are present in the updated README.md. In addition, the program triggers an OAuth login page which opens in the browser if the refresh token expires, which happens roughly every 7 days.

Since this particular feature cannot be automated to the same level as the other actions, Google Calendar integration has been kept as unintrusive and optional as possible.

Changes

• The --gcalendar flag has been added, along with functionality for using the Google Calendar API via OAuth 2.0.
• The [gcal] section has been added to the config file, which must have the client_id and client_secret keys for authenticating with the Google Calendar API.
• The optional calendar_id key specifies the particular calendar within Google Calendar to which events are to be added.

The core server functions, such as authentication and fetching of JSON records, have been encapsulated into a moodlews.service module. This is to streamline the flow of the code, and emphasize that WeLearn is one of many Moodle services that our script can potentially work with.

A typical usecase is as follows.

from moodlews.service import MoodleClient
from moodlews.service import ServerFunctions as sf

# Create the client and authenticate
moodle = MoodleClient("https://welearn.iiserkol.ac.in/")
token = moodle.authenticate("username", "password")

# Empty token if login failed
if not token:
    ....

# Fetch site info records
site_info = moodle.server(sf.SITE_INFO)
userid = site_info["userid"]

# Fetch user enrolled courses
user_courses = moodle.server(sf.USER_COURSES, userid=userid)
....

Changes

• Altered directory structure, with a src folder.
• Creation of a moodlews.service module, with the MoodleClient and ServerFunctions classes.
• Implementation of the same into welearn_bot

Why?

The welearn-bot client can only perform one action per run, such as fetching files, listing assignments, etc. Thus, it doesn't make sense to allocate fetching files as a default, and leave the others as command line options, of which at most one can be used at a a time. Instead, we can specify a single mode/action to perform, such as files or assignments, which helps make the desired outcome more explicit.

Summary of actions

Following are the implemented actions.

• files: all resources and files from the specified courses will be downloaded.
• assignments: all assignments from the specified courses will be listed, and the attachments will be downloaded.
• urls: all urls from the specified courses will be listed.
• courses: all enrolled courses will be listed
• whoami: this is a command to retrieve the user's name from the server (mostly used to check that the program has been configured properly)

usage: welearn_bot [-h] [-d] [-i [IGNORETYPES ...]] [-f] [-p PATHPREFIX] action [courses ...]

A command line client for interacting with WeLearn.

positional arguments:
  action                choose from
                            files       - downloads files/resources
                            assignments - lists assignments, downloads attachments
                            urls        - lists urls
                            courses     - lists enrolled courses
                            whoami      - shows the user's name and exits
                        Abbreviations such as any one of 'f', 'a', 'u', 'c', 'w' are supported.
  courses               IDs of the courses to download files from. The word ALL selects everything from the [courses] section in .welearnrc or welearn.ini

optional arguments:
  -h, --help            show this help message and exit
  -d, --dueassignments  show only due assignments with the 'assignments' action
  -i [IGNORETYPES ...], --ignoretypes [IGNORETYPES ...]
                        ignores the specified extensions when downloading, overrides .welearnrc
  -f, --forcedownload   force download files even if already downloaded/ignored
  -p PATHPREFIX, --pathprefix PATHPREFIX
                        save the downloads to a custom path, overrides .welearnrc

Some common operations are

./welearn_bot.py files MA1101        # Get files from MA1101
./welearn_bot.py -d assignments ALL  # Show all due assignments
./welearn_bot.py -d a ALL            # Same as above

Please see the updated README.md for a full list of examples.

Why?

The Moodle webservice API is much faster than scraping webpages one by one and parsing HTML. Furthermore, the API returns a complete list of files which solves the problem of nested resources.

Why not?

There are a few details about assigments (submission status) which have not yet been implemented.

Changes

• Restructured all code to work with the webservice API, which gives a significant speed boost
• Restructured the .welearnrc format
• Changed the level of detail of assignment statuses
• The bot now downloads assignment attachments

Why?

When we think of rc files, bashrc or vimrc, etc comes to our mind. They all have some variable-value kind of setup so that the meaning of each setting can be better conveyed to the user. I tried to achieve the same.

How?

Python has a built-in configparser module that can parse .ini config files. So I chose to use .ini formatting for the .welearnrc file. This can then be easily parsed using the aforementioned module.

Changes:

• Updated README.md to convey to the users to use the new format.
• Implemented .welearnrc parsing using the configparser module.

NOTE: Merging this into main will break the code until the user updated the .weleanrc file to use the new format.

Traceback (most recent call last): File "/home/parth/.local/bin/welearn_bot", line 8, in sys.exit(main()) File "/home/parth/.local/lib/python3.8/site-packages/welearnbot/welearnbot.py", line 58, in main handler.handle_files( File "/home/parth/.local/lib/python3.8/site-packages/welearnbot/action_handlers.py", line 185, in handle_files modules = item.get("modules", []) AttributeError: 'str' object has no attribute 'get'

Is your feature request related to a problem? Please describe. A clear and concise description of what the problem is. Ex. I'm always frustrated when [...]

Describe the solution you'd like A clear and concise description of what you want to happen.

Describe alternatives you've considered A clear and concise description of any alternative solutions or features you've considered.

Additional context Add any other context or screenshots about the feature request here.