inviteAssignees not working about gitlab-calendar

[PeterDaveHello]

The last change date of calendar_manager.py file is on Apr 28, 2017, on May 22, 2017, GitLab 9.2 released with "Multiple Assignees for Issues" support: https://about.gitlab.com/releases/2017/05/22/gitlab-9-2-released/#multiple-assignees-for-issues, as a result:

Note that as part of this change, the assignee_id parameter in the issues API has been deprecated. The assignee_ids should be used instead. Also, the assignee object in the JSON response has been deprecated. The assignees array should be used instead.

As this issue was opened on Jul 20, 2019, I guess that you're using a newer version of GitLab instance, so that may be the reason why this feature is not working.

[PeterDaveHello]

@summbrooks if you're not using multiple assignee feature on GitLab, a quick patch to make gitlab-calendar could be:

diff --git a/calendar_manager.py b/calendar_manager.py
index f34a486..c59f20f 100644
--- a/calendar_manager.py
+++ b/calendar_manager.py
@@ -121,14 +121,15 @@ def handle_event(data, service, gitlab, calIdMap, config):
         }
         
         # populate assignee field using email from gitlab, if feature is enabled
-        if 'assignee' in data:
+        if 'assignees' in data:
             if gitlab and config['gitlabApi']['inviteAssignees']:
                 body['attendees'].append({
-                    'email': gitlab.users.list(username=data['assignee']['username'])[0].email,
+                    'email': gitlab.users.list(username=data['assignees'][0]['username'])[0].email,
                     'responseStatus': 'accepted'
                 })
             else:
-                body['description'] += "\nAssignee: %s" % data['assignee']['username']
+                body['description'] += "\nAssignee: %s" % data['assignees'][0]['username']
         
         # call api to create issue
         e = service.events().insert(

[tmick0]

Sorry for taking over two years to address this issue, but I have pushed a prospective fix (which handles multiple assignees) to #7 however I am unable to test it. If anyone can confirm this works I will merge the branch.

[PeterDaveHello]

Cool, I also have a local patch that I'm testing it right now, will see if we can just use #7