Updated: The file manifest carries the checksums of the base data with the Configuration class group

Added: The base data creates an empty content class group Configuration

Group 5, after Setup, in share/db_data.dba and both clean data files. It holds no classes. Loaded into throwaway
SQLite databases from the .dba and from the clean data, where it appears with no classes.

Updated: The file manifest carries the checksums of the role view with policy IDs and sortable headings

Added: The role view shows each policy's ID and sorts its policy list by ID, module, function and limitation, with the same headings as the role editor

Like the editor, it sorts in the database, because the list is paged. The sort is carried as (policy_sort) and (policy_dir) next to (policy_offset), and the pager keeps it. The default is ID ascending, the role's own order. The page only reads, so it has no order buttons. Its other sections, such as the users and groups the role is assigned to, are unchanged. The German translation gains the ID heading in the role view's context.

Updated: The file manifest carries the checksums of the role editor with policy IDs, sorting and order buttons

Added: The role editor shows each policy's ID, sorts its policy list by ID, module, function and limitations, and has up and down buttons that change the order of the policies

The order is kept in the policy ids, so the database schema is unchanged. The editor already works on a temporary version of the role: opening a role for editing copies its policies in list order, Save keeps those copies, and Cancel deletes them. The ids are therefore the order, and they are rewritten on every save anyway. A move swaps the contents of a policy and its neighbour (module, function, limitations and any temporary copy the policy editor holds of either) and leaves both ids where they are. It is made in the temporary version, so Save keeps it and Cancel drops it, like every other change in the editor. A policy id that belongs to another role is refused.

For this to hold, eZRole::policyList() and policyPage() now return policies in id order instead of by module and function. Otherwise the next temporary copy would sort the list back into alphabetical order. The role view shows the same order. The permission system does not depend on the order: each policy grants access by itself. The role's access array, with the policy ids taken out, is identical before and after a reorder and Save.

The sorting is done by the database, as on the role list, because the policy list is paged. It is carried as (policy_sort) and (policy_dir) next to (policy_offset). The form address and the pager keep all three, so a button pressed on page three of a sorted list returns to page three, still sorted. Limitations sort by the first limitation identifier and then by the number of limitations, with a join on SQL engines and in PHP on MongoDB. The order buttons are offered only in the role's own order, which is ID ascending, the default. They also work across a page boundary.

Pressing Enter in the name field would now have pressed the first order button. A hidden button that only keeps the name now comes first in the form.

German translations are added for the new strings.

Updated: The file manifest carries the checksums of the clean data with the Websites root folder