Moodle
  1. Moodle
  2. MDL-28557

Group event does not appear to teacher, manager and administrator

    Details

    • Type: Bug Bug
    • Status: Closed
    • Priority: Blocker Blocker
    • Resolution: Fixed
    • Affects Version/s: 2.1.1, 2.2.2
    • Fix Version/s: 2.1.7, 2.2.4
    • Component/s: Calendar
    • Labels:
    • Testing Instructions:
      Hide
      • In an empty course, enrol two students (A, B) and one editing teacher (C)
      • Create two groups (Group 1, Group 2) and enrol A in Group 1, B in Group 2, C in no group
      • Log in as C
      • Go to the course and create a group event for Group 1 and another one for Group 2.

      VERIFY: After clicking "Save changes" in the event edit screen, the teacher is redirected to a calendar view where they can see the event that was just created.

      • Still logged in as C, go to the course, then to the calendar; switch to monthly view

      VERIFY: Both events for Group 1 and Group 2 appear in the calendar.

      • Now log in as A. Go to the course, then to the calendar.

      VERIFY: Only the event for Group 1 appears in the calendar.

      Show
      In an empty course, enrol two students (A, B) and one editing teacher (C) Create two groups (Group 1, Group 2) and enrol A in Group 1, B in Group 2, C in no group Log in as C Go to the course and create a group event for Group 1 and another one for Group 2. VERIFY: After clicking "Save changes" in the event edit screen, the teacher is redirected to a calendar view where they can see the event that was just created. Still logged in as C, go to the course, then to the calendar; switch to monthly view VERIFY: Both events for Group 1 and Group 2 appear in the calendar. Now log in as A. Go to the course, then to the calendar. VERIFY: Only the event for Group 1 appears in the calendar.
    • Workaround:
      Hide

      Add the teacher to the group

      Show
      Add the teacher to the group
    • Affected Branches:
      MOODLE_21_STABLE, MOODLE_22_STABLE
    • Fixed Branches:
      MOODLE_21_STABLE, MOODLE_22_STABLE
    • Pull from Repository:
    • Pull Master Branch:
    • Rank:
      18242

      Description

      There is a course with 2 groups and users enrolled in them.

      A teacher adds a news Group event choosing one of the two groups. After having saved changes, the teacher is redirected to the selected date page but no event appears.

      Only the users from the chosen group can see the event. So the administrator, manager or teacher have no way to edit the event.

      1. groupselection.jpg
        121 kB
      2. New event.png
        31 kB
      3. No events.png
        9 kB

        Issue Links

          Activity

          Hide
          Michael de Raadt added a comment -

          Thanks for reporting this.

          I've put it on our backlog and we'll try to get to it as soon as we can.

          In the meantime adding more information, such as screenshots, replication instructions, fix test instructions, a workaround or even a code solution, will help us and other users.

          Show
          Michael de Raadt added a comment - Thanks for reporting this. I've put it on our backlog and we'll try to get to it as soon as we can. In the meantime adding more information, such as screenshots, replication instructions, fix test instructions, a workaround or even a code solution, will help us and other users.
          Hide
          Philippe Siwinski added a comment - - edited

          A teacher who does not belong to the group, adds a new event for the group.

          After having saved the changes, the teacher is redirected to the page displaying events for the selected day. The event does not appear for the teacher but appears for members of the group.

          Not sure if it is related but the event information refresh after logout-login. I guess this deserves another ticket.

          Show
          Philippe Siwinski added a comment - - edited A teacher who does not belong to the group, adds a new event for the group. After having saved the changes, the teacher is redirected to the page displaying events for the selected day. The event does not appear for the teacher but appears for members of the group. Not sure if it is related but the event information refresh after logout-login. I guess this deserves another ticket.
          Hide
          Philippe Siwinski added a comment -

          Any news about how to fix this issue ? Thanks

          Show
          Philippe Siwinski added a comment - Any news about how to fix this issue ? Thanks
          Hide
          Annemarie Merow added a comment -

          Can we please raise the priority of this item? Our teachers are stuck creating Course events and labeling them with the Group name.

          Show
          Annemarie Merow added a comment - Can we please raise the priority of this item? Our teachers are stuck creating Course events and labeling them with the Group name.
          Hide
          Debi Krulak added a comment -

          I would echo my colleague below in her request to raise the priority of this item. I work with 3rd - 5th graders and it is really confusing for them to have to sort through items that do not apply to them. The ability to show homework by group was one of the reasons we decided to post homework to Moodle rather than some other system.

          Show
          Debi Krulak added a comment - I would echo my colleague below in her request to raise the priority of this item. I work with 3rd - 5th graders and it is really confusing for them to have to sort through items that do not apply to them. The ability to show homework by group was one of the reasons we decided to post homework to Moodle rather than some other system.
          Hide
          Anne Kellerman added a comment -

          Please raise the priority of this item. We have ~100 faculty actively using Moodle to post homework assignments and share course documents and various other electronic course resources who currently cannot post assignments to groups because they are lost/disappear. We have ~600 students and ~1400 parents who depend on this system for this information. The issue with group assignments not showing is a MAJOR inconvenience. Thanks for any and all help in elevating the work on a solution to this problem,

          Show
          Anne Kellerman added a comment - Please raise the priority of this item. We have ~100 faculty actively using Moodle to post homework assignments and share course documents and various other electronic course resources who currently cannot post assignments to groups because they are lost/disappear. We have ~600 students and ~1400 parents who depend on this system for this information. The issue with group assignments not showing is a MAJOR inconvenience. Thanks for any and all help in elevating the work on a solution to this problem,
          Hide
          Petr Škoda added a comment - - edited

          Confirming the problem, there is no trivial fix for this because of performance. In general the internal design is very old and bad...

          Possible solution:

          • remove the "All courses option" in full calendar view for standard teachers (performance)
          • add "My course" option that lists only enrolled courses of the current user - already used on the frontpage (performance)
          • force enrolled courses list on the frontpage
          • redefine the $calendar->group - the problem is we need to specify somehow "all course groups" for people with accessallgroups and manageentries capability (this actually fixes the problem and improves perf)
          • do not rely on list of groups in $USER->groupmember, instead join the tables when searching for the entries - groups change, we can not rely on caches like this
          • display group event no matter if group mode selected in course settings

          We should also clearly define how the calendar works for different group modes and groupings...

          Thanks for the report! I am going to bring forward this issue next week during the dev meeting.

          Show
          Petr Škoda added a comment - - edited Confirming the problem, there is no trivial fix for this because of performance. In general the internal design is very old and bad... Possible solution: remove the "All courses option" in full calendar view for standard teachers (performance) add "My course" option that lists only enrolled courses of the current user - already used on the frontpage (performance) force enrolled courses list on the frontpage redefine the $calendar->group - the problem is we need to specify somehow "all course groups" for people with accessallgroups and manageentries capability (this actually fixes the problem and improves perf) do not rely on list of groups in $USER->groupmember, instead join the tables when searching for the entries - groups change, we can not rely on caches like this display group event no matter if group mode selected in course settings We should also clearly define how the calendar works for different group modes and groupings... Thanks for the report! I am going to bring forward this issue next week during the dev meeting.
          Hide
          Petr Škoda added a comment -

          Raising priority, we need to address this issue asap.

          Show
          Petr Škoda added a comment - Raising priority, we need to address this issue asap.
          Hide
          Petr Škoda added a comment -

          Technically it is easy to fix this with a brute force hack, but this hacky solution would add many DB queries on each page which is imo not acceptable.

          Show
          Petr Škoda added a comment - Technically it is easy to fix this with a brute force hack, but this hacky solution would add many DB queries on each page which is imo not acceptable.
          Hide
          Robin de Vries added a comment -

          This bug has to be solved quickly, our teachers are blocked in planning tests by this bug..

          Show
          Robin de Vries added a comment - This bug has to be solved quickly, our teachers are blocked in planning tests by this bug..
          Hide
          Henning Bostelmann added a comment -

          I've linked a fix for master. This is in a sense a partial solution: It shows all group events to the teacher only if the calendar view is filtered for one course. (This seems to be the main use case.)

          This limited approach should have the advantage that it can be implemented without refactoring the entire code, and that it is not too resource intensive (2 additional DB queries).

          Note that this fixes another related bug: When the configuration setting "calendar_adminseesall" was switched on, and the calendar for one course was shown to an admin, it listed all group events for all courses (not only the current course).

          Show
          Henning Bostelmann added a comment - I've linked a fix for master. This is in a sense a partial solution: It shows all group events to the teacher only if the calendar view is filtered for one course. (This seems to be the main use case.) This limited approach should have the advantage that it can be implemented without refactoring the entire code, and that it is not too resource intensive (2 additional DB queries). Note that this fixes another related bug: When the configuration setting "calendar_adminseesall" was switched on, and the calendar for one course was shown to an admin, it listed all group events for all courses (not only the current course).
          Hide
          Henning Bostelmann added a comment -

          Petr, you raised the priority for this bug; can you review this patch? It might not be perfect, but should solve the problem at hand.

          Show
          Henning Bostelmann added a comment - Petr, you raised the priority for this bug; can you review this patch? It might not be perfect, but should solve the problem at hand.
          Hide
          Johan Myny added a comment -

          A simple filter making it possible to select only events from one group would be a great help. It only takes an extra dropdown-list, showing only the groups of the current course and the option "Show all groups." When "Show all groups" has been selected, the calender behaves as it does today. When one group is selected, all group-specific events related to other groups should be omitted.
          I'm not an expert, but it looks like a minor change of the sql-query selecting the calendar records, adding an extra criterion about the group-id.

          Show
          Johan Myny added a comment - A simple filter making it possible to select only events from one group would be a great help. It only takes an extra dropdown-list, showing only the groups of the current course and the option "Show all groups." When "Show all groups" has been selected, the calender behaves as it does today. When one group is selected, all group-specific events related to other groups should be omitted. I'm not an expert, but it looks like a minor change of the sql-query selecting the calendar records, adding an extra criterion about the group-id.
          Hide
          Johan Myny added a comment - - edited

          One extra dropdown list would make a world of difference: either select "Show all groups", or select one specific group. After that, all group-related calendar events belonging to other groups are omitted.
          (see attachment groupselection.png)

          Show
          Johan Myny added a comment - - edited One extra dropdown list would make a world of difference: either select "Show all groups", or select one specific group. After that, all group-related calendar events belonging to other groups are omitted. (see attachment groupselection.png)
          Hide
          Alo Peets added a comment - - edited

          There is a easy not technical workaround, Add yourself to all groups as a member. Worked for me now I can still create, view and edit group events. Nevertheless there is no way to tell which group event it is and you cannot change group to which event is belonging to after creation neither. So I cannot call it solution, but it might help person like me who has only two groups.

          Show
          Alo Peets added a comment - - edited There is a easy not technical workaround, Add yourself to all groups as a member. Worked for me now I can still create, view and edit group events. Nevertheless there is no way to tell which group event it is and you cannot change group to which event is belonging to after creation neither. So I cannot call it solution, but it might help person like me who has only two groups.
          Hide
          Dan Poltawski added a comment -

          Pinging Petr - what do you think of this approach?

          Show
          Dan Poltawski added a comment - Pinging Petr - what do you think of this approach?
          Hide
          Dan Poltawski added a comment -

          Hi Henning,

          Sorry for the delay in peer review for this. I think your approach is sensible pragmatism which at least solve this problem in the short term.

          If you could rebase this for integration I will push it for integration. Note in master we have a new course_context class.

          I will also try and see if Petr can offer any insight.

          Show
          Dan Poltawski added a comment - Hi Henning, Sorry for the delay in peer review for this. I think your approach is sensible pragmatism which at least solve this problem in the short term. If you could rebase this for integration I will push it for integration. Note in master we have a new course_context class. I will also try and see if Petr can offer any insight.
          Hide
          Henning Bostelmann added a comment -

          Hi Dan,

          sorry for the delay - I was busy with other tasks. I have rebased the fix and re-tested. Backports to 2.2 and 2.1 are provided as well.

          Note that this is just a rebase of the previous fix. If refactoring is needed in master (due to the API change you mentioned), this should likely be done in a different tracker entry.

          Cheers
          Henning

          Show
          Henning Bostelmann added a comment - Hi Dan, sorry for the delay - I was busy with other tasks. I have rebased the fix and re-tested. Backports to 2.2 and 2.1 are provided as well. Note that this is just a rebase of the previous fix. If refactoring is needed in master (due to the API change you mentioned), this should likely be done in a different tracker entry. Cheers Henning
          Hide
          Dan Poltawski added a comment -

          The main moodle.git repository has just been updated with latest weekly modifications. You may wish to rebase your PULL branches to simplify history and avoid any possible merge conflicts. This would also make integrator's life easier next week.

          TIA and ciao

          Show
          Dan Poltawski added a comment - The main moodle.git repository has just been updated with latest weekly modifications. You may wish to rebase your PULL branches to simplify history and avoid any possible merge conflicts. This would also make integrator's life easier next week. TIA and ciao
          Hide
          Tim Hunt added a comment -

          Sorry, I don't know the code well enough to review this patch, but I just want to make sure that before this is integrated, people have thought about big courses with 1000 groups, and that a teacher or admin trying to view the calendar on such a course won't crash the server. Thanks.

          Show
          Tim Hunt added a comment - Sorry, I don't know the code well enough to review this patch, but I just want to make sure that before this is integrated, people have thought about big courses with 1000 groups, and that a teacher or admin trying to view the calendar on such a course won't crash the server. Thanks.
          Hide
          Johan Myny added a comment -

          That's why a teacher should be able to select the group or groups he is interested in. If there are a lot of groups, all managed by different colleagues, the output will be overwhelming and not useful at all.
          On monday, you might only be interested in your group(s) attending school on monday (and not the other groups). At this point, there is no easy way to filter group-related calendar items. An extra dropdownlist showing all groups is an easy way to focus on one group and would be a tremendous help to our team. (as I mentioned in a previous post)

          Show
          Johan Myny added a comment - That's why a teacher should be able to select the group or groups he is interested in. If there are a lot of groups, all managed by different colleagues, the output will be overwhelming and not useful at all. On monday, you might only be interested in your group(s) attending school on monday (and not the other groups). At this point, there is no easy way to filter group-related calendar items. An extra dropdownlist showing all groups is an easy way to focus on one group and would be a tremendous help to our team. (as I mentioned in a previous post)
          Hide
          Eloy Lafuente (stronk7) added a comment -

          The integration of this issue has been delayed to next week because the integration period is over (Monday, Tuesday) and testing must happen on Wednesday.

          This change to a more rigid timeframe on each integration/testing cycle aims to produce a better and clear separation and organization of tasks for everybody.

          This is a bulk-automated message, so if you want to blame somebody/thing/where, don't do it here (use git instead) :-D :-P

          Apologizes for the inconvenient, this will be integrated next week. Thanks for your collaboration & ciao

          Show
          Eloy Lafuente (stronk7) added a comment - The integration of this issue has been delayed to next week because the integration period is over (Monday, Tuesday) and testing must happen on Wednesday. This change to a more rigid timeframe on each integration/testing cycle aims to produce a better and clear separation and organization of tasks for everybody. This is a bulk-automated message, so if you want to blame somebody/thing/where, don't do it here (use git instead) :-D :-P Apologizes for the inconvenient, this will be integrated next week. Thanks for your collaboration & ciao
          Hide
          Eloy Lafuente (stronk7) added a comment -

          The main moodle.git repository has just been updated with latest weekly modifications. You may wish to rebase your PULL branches to simplify history and avoid any possible merge conflicts. This would also make integrator's life easier next week.

          TIA and ciao

          Show
          Eloy Lafuente (stronk7) added a comment - The main moodle.git repository has just been updated with latest weekly modifications. You may wish to rebase your PULL branches to simplify history and avoid any possible merge conflicts. This would also make integrator's life easier next week. TIA and ciao
          Hide
          Henning Bostelmann added a comment -

          Rebased, and a whitespace problem corrected.

          Tim, regarding performance, I'm not sure what test scenario you would accept. On a (low spec) development machine , I just created a course with 5000 users, 1000 groups, and 1000 events (one per group, all on the same day). Calendar browsing as a teacher or admin worked in this scenario, and Apache / MySql certainly did not crash. Some additional load was noticeable (subjectively) but mostly generated by the browser process. I'm sorry, I don't have a load test environment so I can't get more detailed results at this time.

          Johan, I agree that an additional "filter by group" dropdown box might be helpful in some situations; but this seems a feature request rather than a bugfix, and it should likely go into a separate issue, and probably to the master branch only. It would also need a better specification. (For example, what exactly is supposed to happen in the "Upcoming events" block?)

          Show
          Henning Bostelmann added a comment - Rebased, and a whitespace problem corrected. Tim, regarding performance, I'm not sure what test scenario you would accept. On a (low spec) development machine , I just created a course with 5000 users, 1000 groups, and 1000 events (one per group, all on the same day). Calendar browsing as a teacher or admin worked in this scenario, and Apache / MySql certainly did not crash. Some additional load was noticeable (subjectively) but mostly generated by the browser process. I'm sorry, I don't have a load test environment so I can't get more detailed results at this time. Johan, I agree that an additional "filter by group" dropdown box might be helpful in some situations; but this seems a feature request rather than a bugfix, and it should likely go into a separate issue, and probably to the master branch only. It would also need a better specification. (For example, what exactly is supposed to happen in the "Upcoming events" block?)
          Hide
          Sam Hemelryk added a comment -

          Hmm after looking at this for some time, and deliberating on it I find myself undecided about it and out of time. I'm assigning Eloy as integrator for this issue. No doubt he has a better understanding of groups than me and will be able to come to a conclusion.

          Show
          Sam Hemelryk added a comment - Hmm after looking at this for some time, and deliberating on it I find myself undecided about it and out of time. I'm assigning Eloy as integrator for this issue. No doubt he has a better understanding of groups than me and will be able to come to a conclusion.
          Hide
          Eloy Lafuente (stronk7) added a comment -

          Some reflexion about this:

          1) The change only affects to requests to show events from 1 course, leaving the requests for multiple courses unmodified. So I don't expect any really performance problem at all. That's nice. More if it's the most common use case.

          2) Important: But I don't get why the 'moodle/calendar:manageentries' is used in the logic at all. IMO it should be the 'moodle/site:accessallgroups' the one controlling if we allow user to see events for all groups. Sounds obvious in my mind. The former does not enable access to all groups at all, only the rights to edit entries at a given context.

          3) Minor: There is some annoyance about the use of the $group variable. It varies from boolean (both true and false) to contain one array. And there is the $groupids variable that seems to be the proper place to store one array. In other words... surely i would replace:

          if ($group === false) {
          

          by one simple

          } else {
          

          4) For sure the Calendar (PFF)API requires a big rework. But it cannot be done now, grrr.

          So, in summary:

          a) With the points 2 & 3 above considered and fixed.
          b) With old behavior 100% observed for all the rest of cases (no matter of the wrong cap being used or anything else).
          c) This has +1

          So I'm reopening this for clarifying the points above, thanks and ciao

          PS: Surely I'd add some followup about the 4) above and also to reconsider 2) to be applied for any groups-calculation.

          Show
          Eloy Lafuente (stronk7) added a comment - Some reflexion about this: 1) The change only affects to requests to show events from 1 course, leaving the requests for multiple courses unmodified. So I don't expect any really performance problem at all. That's nice. More if it's the most common use case. 2) Important: But I don't get why the 'moodle/calendar:manageentries' is used in the logic at all. IMO it should be the 'moodle/site:accessallgroups' the one controlling if we allow user to see events for all groups. Sounds obvious in my mind. The former does not enable access to all groups at all, only the rights to edit entries at a given context. 3) Minor: There is some annoyance about the use of the $group variable. It varies from boolean (both true and false) to contain one array. And there is the $groupids variable that seems to be the proper place to store one array. In other words... surely i would replace: if ($group === false ) { by one simple } else { 4) For sure the Calendar (PFF)API requires a big rework. But it cannot be done now, grrr. So, in summary: a) With the points 2 & 3 above considered and fixed. b) With old behavior 100% observed for all the rest of cases (no matter of the wrong cap being used or anything else). c) This has +1 So I'm reopening this for clarifying the points above, thanks and ciao PS: Surely I'd add some followup about the 4) above and also to reconsider 2) to be applied for any groups-calculation.
          Hide
          Henning Bostelmann added a comment -

          Hi Eloy, thanks for reviewing. Before changing the code, let me comment (and ask for your views):

          Re 2): Part of the bug is that some users are allowed to create group events, but are unable to edit them afterwards since they can't find them in the calendar. Editing all group events is controlled by 'moodle/calendar:manageentries' (see calendar_edit_event_allowed()). I take your point about 'moodle/site:accessallgroups' though. Maybe, events should be shown if the user has any of the two capabilities?

          Re 3): I agree with the "else". Otherwise, the variable type may be an annoyance but it is actually imposed by the parameter format of calendar_get_events() and similar routines.

          Let me know what you think.

          Cheers,
          Henning

          Show
          Henning Bostelmann added a comment - Hi Eloy, thanks for reviewing. Before changing the code, let me comment (and ask for your views): Re 2): Part of the bug is that some users are allowed to create group events, but are unable to edit them afterwards since they can't find them in the calendar. Editing all group events is controlled by 'moodle/calendar:manageentries' (see calendar_edit_event_allowed()). I take your point about 'moodle/site:accessallgroups' though. Maybe, events should be shown if the user has any of the two capabilities? Re 3): I agree with the "else". Otherwise, the variable type may be an annoyance but it is actually imposed by the parameter format of calendar_get_events() and similar routines. Let me know what you think. Cheers, Henning
          Hide
          Eloy Lafuente (stronk7) added a comment - - edited

          Hi Henning,

          2) for sure we need to revisit the calendar seriously and verify how all those checks are working, because the logic should be, IMO, something like:

          a) Allow the edition of group events to all users having correct both "managing" and "group" access. So it's not only a matter of booleans but of allowing the creation and later restrict to the correct groups or so, with correct groups being the ones "viewable" by the user (or member or accessallgroups at the context).

          b) Allow the view of group events to all users having "group" access. I mean, I don't see the point about to have any "managing" access in order to allow to view events. Imagine I want one tutor or helper-teacher to be able to view all the group events, but I don't want him to be able to edit group events. Sounds like a possible use-case here.

          c) But a) and b) cannot be done properly now. So, for the time being... surely the alternative of having any of them is ok. And will cover the the helper-teacher use-case above too (not having "managing" access). Although I would recommend to add one TODO, pointing to this issue, and the need to revisit the calendar edition/view permission checks in the future. I just looked to calendar_edit_event_allowed() and immediately closed the window after reading the first 10-20 lines, lol.

          So +1 for "any" for viewing perms (keeping edition perms unmodified for now).

          Thanks and ciao

          Show
          Eloy Lafuente (stronk7) added a comment - - edited Hi Henning, 2) for sure we need to revisit the calendar seriously and verify how all those checks are working, because the logic should be, IMO, something like: a) Allow the edition of group events to all users having correct both "managing" and "group" access. So it's not only a matter of booleans but of allowing the creation and later restrict to the correct groups or so, with correct groups being the ones "viewable" by the user (or member or accessallgroups at the context). b) Allow the view of group events to all users having "group" access. I mean, I don't see the point about to have any "managing" access in order to allow to view events. Imagine I want one tutor or helper-teacher to be able to view all the group events, but I don't want him to be able to edit group events. Sounds like a possible use-case here. c) But a) and b) cannot be done properly now. So, for the time being... surely the alternative of having any of them is ok. And will cover the the helper-teacher use-case above too (not having "managing" access). Although I would recommend to add one TODO, pointing to this issue, and the need to revisit the calendar edition/view permission checks in the future. I just looked to calendar_edit_event_allowed() and immediately closed the window after reading the first 10-20 lines, lol. So +1 for "any" for viewing perms (keeping edition perms unmodified for now). Thanks and ciao
          Hide
          Henning Bostelmann added a comment -

          Change b) made as discussed.

          Change c) not made after all. Eloy, your suggestion doesn't work out. If I make the change, then users without the "accessallgroups" etc. capability don't see any group events anymore, not even in their own group; and it's easy to see why. (I agree that the whole logic here might use a bit of refactoring, but maybe that's too much for the moment.)

          Show
          Henning Bostelmann added a comment - Change b) made as discussed. Change c) not made after all. Eloy, your suggestion doesn't work out. If I make the change, then users without the "accessallgroups" etc. capability don't see any group events anymore, not even in their own group; and it's easy to see why. (I agree that the whole logic here might use a bit of refactoring, but maybe that's too much for the moment.)
          Hide
          Eloy Lafuente (stronk7) added a comment -

          Ah, yesyes, or I explained myself wrongly or you didn't get it ok.

          b) was the ideal situation where only group access is checked for viewing group entries. But we cannot do that now but as a part of a big reorganization.

          c) the was the one explaining that both a) and b) are impossible now and about to grant access (in 1-course calendars) to users having any of manage or group access.

          So, in my mind, you've implemented c). Perfect.

          Ciao

          PS: About 3) I've seen you have not changed it to simpler "else". Didn't we agree about that?

          Show
          Eloy Lafuente (stronk7) added a comment - Ah, yesyes, or I explained myself wrongly or you didn't get it ok. b) was the ideal situation where only group access is checked for viewing group entries. But we cannot do that now but as a part of a big reorganization. c) the was the one explaining that both a) and b) are impossible now and about to grant access (in 1-course calendars) to users having any of manage or group access. So, in my mind, you've implemented c). Perfect. Ciao PS: About 3) I've seen you have not changed it to simpler "else". Didn't we agree about that?
          Hide
          Henning Bostelmann added a comment -

          Hi Eloy, I think we only disagree about the numbering. What I actually meant was:

          Change 3) not made after all. Eloy, your suggestion doesn't work out. If I make the change, then users without the "accessallgroups" etc. capability don't see any group events anymore, not even in their own group; and it's easy to see why. (I agree that the whole logic here might use a bit of refactoring, but maybe that's too much for the moment.)

          Show
          Henning Bostelmann added a comment - Hi Eloy, I think we only disagree about the numbering. What I actually meant was: Change 3) not made after all. Eloy, your suggestion doesn't work out. If I make the change, then users without the "accessallgroups" etc. capability don't see any group events anymore, not even in their own group; and it's easy to see why. (I agree that the whole logic here might use a bit of refactoring, but maybe that's too much for the moment.)
          Hide
          Eloy Lafuente (stronk7) added a comment -

          Ah, lol, got confused with "c" and "3". So you have not implemented "3" but you've implemented "2c".

          Show
          Eloy Lafuente (stronk7) added a comment - Ah, lol, got confused with "c" and "3". So you have not implemented "3" but you've implemented "2c".
          Hide
          Eloy Lafuente (stronk7) added a comment -

          I think, if I'm not wrong with the Cs and 3s above, that this can be sent to integration as far as fixes the display of group events for 1-course (the most common use case).

          The whole thing continues being imperfect, but this is a good step in the correct direction.

          So sending... ciao

          Show
          Eloy Lafuente (stronk7) added a comment - I think, if I'm not wrong with the Cs and 3s above, that this can be sent to integration as far as fixes the display of group events for 1-course (the most common use case). The whole thing continues being imperfect, but this is a good step in the correct direction. So sending... ciao
          Hide
          Dan Poltawski added a comment -

          I've integrated this, thanks!

          Show
          Dan Poltawski added a comment - I've integrated this, thanks!
          Hide
          Dan Poltawski added a comment -

          Tested and passed.

          Thanks everyone!

          Show
          Dan Poltawski added a comment - Tested and passed. Thanks everyone!
          Hide
          Eloy Lafuente (stronk7) added a comment -

          This issue has been integrated upstream and is now available both via git and cvs (and in some hours, via mirrors and downloads).

          Thanks!

          Show
          Eloy Lafuente (stronk7) added a comment - This issue has been integrated upstream and is now available both via git and cvs (and in some hours, via mirrors and downloads). Thanks!

            People

            • Votes:
              6 Vote for this issue
              Watchers:
              7 Start watching this issue

              Dates

              • Created:
                Updated:
                Resolved: