Thank you for all of the contributions - gave me some good ideas on how to propose to resolve this for our implementation (this may work for others as well). My apologies for the number of unformatted screen captures.
I have set up our users has having access to the Roles:
- ROLE_ADHOC_DESIGNER,
- ROLE_REPORT_DESIGNER,
- ROLE_USER, plus for example
- CSK_ROLE_PROJECT_MANAGEMENT
This grants a given user with the ability to see but not update OOTB (or centrally administered) reporting objects that are stored in the directory that the System Administrator has rights over - for example, 'cppm* -> CA PPM -> Reports -> Project Management'. This protects the integrity of the reports that everyone has rights to (and needs to rely upon).
This doesn't mean that users cannot create replicas of these reports from this directory, paste them into directories that they do have Write permissions over, and modify the replica, and then save that Report+Parameter combination.
1. Copy:
2. Move to write-enabled directory:
3. Paste:
The permissions on the replica of the original item use the permissions of the directory it resides in, so the replica can be opened, new pameters set and applied, and then saved.
The name given to the Report+Parameter combination now appears under the Report Options.
Viewing the reports available to this user...
... you will see 1) the original, OOTB report, 2) an (artificial) replica of the original report copies to the user's directory, then 3) the replica plus the saved parameter combination.
It is possible for the user to modify the Name and Description properties of the replica, and potentially advisible to avoid having them wonder whether the replication of names in this list isn't a system glitch.
From this point onwards, it would then be the user's responsibility to verify that their saved reports continue to function properly after application upgrades
Hope that this helps someone (else).
Cheers,
Will Lloyd