Since the same permissions are checked on both sides (getting the list of categories vs accepting the submitted categories), the only ways I can see this happening are:
- The category was not originally protected. The user selected the category in the editor. The category was newly protected. The user submitted their category selection; OR
- The category had admin-level protection. The admin user selected the category in the editor. The user's admin session timed out (but their non-admin session was still active). The user submitted their category selection.
- The user was an admin who had Test Permissions active for a user other than himself. In 4.0.18, the effect of this on wiki functions would be undefined and give unexpected results.
In the first two cases, the behavior you described would be expected.
However, I agree that protection against edits probably shouldn't affect the ability to use the category as a container. Thus, I have changed this to a feature request. In the next release, the behavior of protection on node-types (books, categories, feeds, etc) has changed:
- An additional checkbox appears on the Protect tab asking whether protection should also apply to adding/removing pages inside the container. This checkbox is semi-independent of the protection state. If there is no protection set on the category, but the box is checked, then only users with access to uncheck the box have permission to add/remove pages. If there is protection set on the category, and the box is checked, then only users who satisfy the category's protection state can add/remove pages. Whether there is protection set on the category or not, if the box is not checked, then users can add/remove pages as long as they have generic permission to do so.
If you continue to have an issue with this in the next release, please open a private ticket via the Members area here, as I have not been able to reproduce the problem on my test site.