Symphony.

This is a feature request:

I often use a separate section for static content like privacy policies, contact information or general texts about a site. The number of entries in this section is predefined by the static content itself: there should only be one privacy policy and one contact information etc. The user of the site should be able to edit but not to add more entries.

As I think that I'm not the only one using a section this way, I'd like to propose a new option for sections: allow or disallow new entries. Normally this option should be set to allow but if it is set to disallow the create new and delete buttons on the entry overview of a section should just disappear. This way I would have a guaranty that all needed entries exist and the user of the site cannot delete or add new entries by mistake while trying to change parts of the content. Entry Editing should still be allowed.

Nils

I vote for this. While it is technically simple to grab only the intended entries per page, the mechanisms are still difficult to understand for authors. Nils' idea would mean a significant improvement.

I second this, I have been in this situation myself, I simply don't trust my clients not to mess things up.

This seems like a pretty common requirement. Back when we were working on S1.8, we'd planned to separate create/delete access from edit access in the user settings, for precisely the reasons you mention.

The equivalent to this in S2 will be user roles (yet to be implemented), so here's what I propose:

Add 3 options under Restricted Admin Access for each section, like "Articles (Create)", "Articles (Edit)" and "Articles (Delete)". By restricting both create and delete access, all users with this role will only be able to edit articles. With all 3 selected, that section just won't appear in the navigation.

This is exactly how events work too. It requires a bit more setting up than if there were just a toggle on the section form (categorising users into developer and author roles setting their role permissions appropriately), but I think the customisation benefits are worth it.

There will be no ability in S2 to say "allow Fred to only edit entries which he created" (another common requirement) although since each entry stores its creator as metadata, it would be possible to make an extension to add this behaviour.