This was considered when reviewing
Whenever the calendar page is shown, the month/upcoming... views are dynamically loaded. Same happens when you change / filter... that's nice.
But there are some elements in the UI that never are refreshed, unless you reload the page. The more obvious are the buttons ("new event", "subscriptions" and "export").
Because of that, we have very complex permissions evaluation code that looks for perms sitewide. Also, it's not very intuitive sometimes (if perms change for a given context / course), some of the buttons should become unavailable / dimmed. And they just don't behave that way now.
So this is an issue about consider when those currently "static" elements could be dynamically calculated based on current filters. That way surely:
1) We should not calculate perms site-wide, but just for the context/filter enabled.
2) The UI would dynamically enable/disable elements that are not available, making the calendar page UI 100% consistent (not only some parts).
1) An analysis about the impact of this (new WS calls, more fragments maybe, changes on permissions evaluation, ideally to a lighter approach...)
2) Implement the new behaviors if agreed, completely covered.
Note this may have some relation / dependency with MDL-67422 where the calendar permissions evaluation is being cleaned up.