I already have a python script processing mails received in the Calendar folder to get the ical event and push it to radicale. It has several drawbacks:

  • It doesn't detect appointment changes (pretty easy to fix as each event has a unique ID)
  • It doesn't detect deleted appointments. This would need to change the script to loop over the mails and already existing events in radicale to sync them.
  • It's a one way script only: from GroupWise to Radicale, the other way still needs to be done.

For this project there are two ways to go and I am still unsure which one would be the best:

  • Use the GroupWise SOAP API: that's what evolution connector used to do and it's only activated on some post offices.
  • Continue the IMAP way: that would require to loop over the whole content of the Calendar folder regularly... is that slower than looping over the events via the SOAP API?

The code of the hackweek project is on github. The project has progressed a lot, but is still not finished. I ended up with:

  • Reading the ical events from IMAP: less parsing work than SOAP and easy to get working
  • Diffing iCalendar files
  • Listing on the changes on a iCalendar file using pyinotify
  • Writing a simple SOAP client in python to access the events to update / remove them (adding could work easily through SMTP)
  • Attachments files are downloaded and properly linked from the events

What is missing:

  • Getting the event ID in a not too time-consuming way using SOAP
  • Convert from iCAL representation to the XML description used by the SOAP API
  • Actually delete / update events
  • Actually add events (may not got the SOAP way)

Looking for hackers with the skills:

python calendar groupwise ical

This project is part of:

Hack Week 10

Activity

  • about 11 years ago: aspiers liked this project.
  • about 11 years ago: rhafer liked this project.
  • about 11 years ago: abonilla liked this project.
  • about 11 years ago: wpreston2 liked this project.
  • about 11 years ago: Nijel liked this project.
  • about 11 years ago: cbosdonnat liked this project.
  • about 11 years ago: cbosdonnat started this project.
  • about 11 years ago: cbosdonnat left this project.
  • about 11 years ago: cbosdonnat started this project.
  • about 11 years ago: cbosdonnat joined this project.
  • about 11 years ago: cbosdonnat added keyword "python" to this project.
  • about 11 years ago: cbosdonnat added keyword "calendar" to this project.
  • about 11 years ago: cbosdonnat added keyword "groupwise" to this project.
  • about 11 years ago: cbosdonnat added keyword "ical" to this project.
  • about 11 years ago: cbosdonnat originated this project.

  • Comments

    • Thnielsen
      about 11 years ago by Thnielsen | Reply

      ehh pragmatic comment on the choice of imap or soap - not knowing the complexity of neither the one nor the other, but Groupwise components rather use soap between them (webaccess to postOffice)(datasynchroniser to postOffice) The knowledge in the GroupWise team - should you need help, may be more ready available on SOAP. Bear in mind that Datasynchroniser conains a number of connectors if there are other ways to pass in and out of groupwise: http://www.novell.com/documentation/datasync_connectors1/ (hmm i think they stripped a few connectors in the latest doc - not a good sign . . .

    • vuntz
      about 11 years ago by vuntz | Reply

      As mentioned a few weeks ago on research@, I wrote http://w3.suse.de/~vuntz/tmp/maildir-to-ics which is similar to your existing python script, but writes to a .ics file instead of caldav. It's also lacking true synchronization, though.

    Similar Projects

    Make more sense of openQA test results using AI by livdywan

    Description

    AI has the potential to help with something many of us spend a lot of time doing which is making sense of openQA logs when a job fails.

    User Story

    Allison Average has a puzzled look on their face while staring at log files that seem to make little sense. Is this a known issue, something completely new or maybe related to infrastructure changes?

    Goals

    • Leverage a chat interface to help Allison
    • Create a model from scratch based on data from openQA
    • Proof of concept for automated analysis of openQA test results

    Bonus

    • Use AI to suggest solutions to merge conflicts
      • This would need a merge conflict editor that can suggest solving the conflict
    • Use image recognition for needles

    Resources

    Timeline

    Day 1

    • Conversing with open-webui to teach me how to create a model based on openQA test results

    Day 2

    Highlights

    • I briefly tested compared models to see if they would make me more productive. Between llama, gemma and mistral there was no amazing difference in the results for my case.
    • Convincing the chat interface to produce code specific to my use case required very explicit instructions.
    • Asking for advice on how to use open-webui itself better was frustratingly unfruitful both in trivial and more advanced regards.
    • Documentation on source materials used by LLM's and tools for this purpose seems virtually non-existent - specifically if a logo can be generated based on particular licenses

    Outcomes

    • Chat interface-supported development is providing good starting points and open-webui being open source is more flexible than Gemini. Although currently some fancy features such as grounding and generated podcasts are missing.
    • Allison still has to be very experienced with openQA to use a chat interface for test review. Publicly available system prompts would make that easier, though.


    Run local LLMs with Ollama and explore possible integrations with Uyuni by PSuarezHernandez

    Description

    Using Ollama you can easily run different LLM models in your local computer. This project is about exploring Ollama, testing different LLMs and try to fine tune them. Also, explore potential ways of integration with Uyuni.

    Goals

    • Explore Ollama
    • Test different models
    • Fine tuning
    • Explore possible integration in Uyuni

    Resources

    • https://ollama.com/
    • https://huggingface.co/
    • https://apeatling.com/articles/part-2-building-your-training-data-for-fine-tuning/


    Saline (state deployment control and monitoring tool for SUSE Manager/Uyuni) by vizhestkov

    Project Description

    Saline is an addition for salt used in SUSE Manager/Uyuni aimed to provide better control and visibility for states deploymend in the large scale environments.

    In current state the published version can be used only as a Prometheus exporter and missing some of the key features implemented in PoC (not published). Now it can provide metrics related to salt events and state apply process on the minions. But there is no control on this process implemented yet.

    Continue with implementation of the missing features and improve the existing implementation:

    • authentication (need to decide how it should be/or not related to salt auth)

    • web service providing the control of states deployment

    Goal for this Hackweek

    • Implement missing key features

    • Implement the tool for state deployment control with CLI

    Resources

    https://github.com/openSUSE/saline


    Team Hedgehogs' Data Observability Dashboard by gsamardzhiev

    Description

    This project aims to develop a comprehensive Data Observability Dashboard that provides r insights into key aspects of data quality and reliability. The dashboard will track:

    Data Freshness: Monitor when data was last updated and flag potential delays.

    Data Volume: Track table row counts to detect unexpected surges or drops in data.

    Data Distribution: Analyze data for null values, outliers, and anomalies to ensure accuracy.

    Data Schema: Track schema changes over time to prevent breaking changes.

    The dashboard's aim is to support historical tracking to support proactive data management and enhance data trust across the data function.

    Goals

    Although the final goal is to create a power bi dashboard that we are able to monitor, our goals is to 1. Create the necessary tables that track the relevant metadata about our current data 2. Automate the process so it runs in a timely manner

    Resources

    AWS Redshift; AWS Glue, Airflow, Python, SQL

    Why Hedgehogs?

    Because we like them.


    ClusterOps - Easily install and manage your personal kubernetes cluster by andreabenini

    Description

    ClusterOps is a Kubernetes installer and operator designed to streamline the initial configuration and ongoing maintenance of kubernetes clusters. The focus of this project is primarily on personal or local installations. However, the goal is to expand its use to encompass all installations of Kubernetes for local development purposes.
    It simplifies cluster management by automating tasks and providing just one user-friendly YAML-based configuration config.yml.

    Overview

    • Simplified Configuration: Define your desired cluster state in a simple YAML file, and ClusterOps will handle the rest.
    • Automated Setup: Automates initial cluster configuration, including network settings, storage provisioning, special requirements (for example GPUs) and essential components installation.
    • Ongoing Maintenance: Performs routine maintenance tasks such as upgrades, security updates, and resource monitoring.
    • Extensibility: Easily extend functionality with custom plugins and configurations.
    • Self-Healing: Detects and recovers from common cluster issues, ensuring stability, idempotence and reliability. Same operation can be performed multiple times without changing the result.
    • Discreet: It works only on what it knows, if you are manually configuring parts of your kubernetes and this configuration does not interfere with it you can happily continue to work on several parts and use this tool only for what is needed.

    Features

    • distribution and engine independence. Install your favorite kubernetes engine with your package manager, execute one script and you'll have a complete working environment at your disposal.
    • Basic config approach. One single config.yml file with configuration requirements (add/remove features): human readable, plain and simple. All fancy configs managed automatically (ingress, balancers, services, proxy, ...).
    • Local Builtin ContainerHub. The default installation provides a fully configured ContainerHub available locally along with the kubernetes installation. This configuration allows the user to build, upload and deploy custom container images as they were provided from external sources. Internet public sources are still available but local development can be kept in this localhost server. Builtin ClusterOps operator will be fetched from this ContainerHub registry too.
    • Kubernetes official dashboard installed as a plugin, others planned too (k9s for example).
    • Kubevirt plugin installed and properly configured. Unleash the power of classic virtualization (KVM+QEMU) on top of Kubernetes and manage your entire system from there, libvirtd and virsh libs are required.
    • One operator to rule them all. The installation script configures your machine automatically during installation and adds one kubernetes operator to manage your local cluster. From there the operator takes care of the cluster on your behalf.
    • Clean installation and removal. Just test it, when you are done just use the same program to uninstall everything without leaving configs (or pods) behind.

    Planned features (Wishlist / TODOs)

    • Containerized Data Importer (CDI). Persistent storage management add-on for Kubernetes to provide a declarative way of building and importing Virtual Machine Disks on PVCs for