This is a major release because it fixes https://artemisappfire.atlassian.net/browse/SVM-86 to add a user picker in the macro editors for restricting the macros using lists of voters, viewers, and managers.
...
To search for the pages where this macro is present please see Atlassian’s document for using the REST API for CQL searches: Search Your Site for Pages Containing a Certain Macro - Server You will want to do separate searches for you can use the “Macro Usage” tool in the Confluence administration tool. Search for survey, vote, survey-wikistyle, and vote-wikistyle. You probably don't have any survey-wikistyle or vote-wikistyle macros but should search for them to verify that. Those are old obsolete macros.
You can also do a more specific search to find ONLY pages that contain a survey/vote macro that is using one of the parameters for restricting access to the macro. Those are the only pages you will need to edit (but ONLY if the restriction parameters mix both usernames and groupnames in the same parameter). This would require the use of an plugin that allows full searching of the Storage Format markup for your entire site. We have been able to use the Search and Replace app for this. We are not affiliated with the publish of that app but it works for this use-case.
You can do the following 3 searches to find all of the pages that have either a survey or a vote macro that uses restriction parameters:
<ac:parameter ac:name="managers">
<ac:parameter ac:name="voters">
<ac:parameter ac:name="viewers">
If there are usernames in those parameters then they need to be moved to the new “managerUsers”, “voterUsers”, and “viewerUsers” parameters. The original parameters are now use only for group names.
...
See https://artemisappfire.atlassian.net/wiki/spaces/SUP/pages/410780125147360241/Survey+Vote+Server+-+User+Guide#Survey&VoteServer-UserGuide-SurveyEditorFields
for documentation of the macro parameters for restricting lists of voters, viewers, and groups:
List of voter groups (parameter name in the Storage format is “voters”)
List of voters (“voterUsers”)
List of viewer groups (“viewers”)
List of viewers (“viewerUsers”)
List of manager groups (“managers”)
List of managers (“managerUsers”)
EXAMPLE:
For "List of managers" (Survey macro only. Does not exist in Vote macro)
...
Similarly for "List of voter groups" and "List of result viewer groups" (for both the Survey and Vote macros).
DO YOU REALLY NEED TO FIND AND EDIT ALL OF YOUR SURVEY/VOTE MACROS?
Not really. The most complete solution would be to find them all and to move usernames out of the groupname parameters to the new username parameters, as described earlier (again, only necessary if the macro is combining usernames and groupnames in the parameters which is rare in practice). The other alternative is to ignore the issue, do the upgrade, and see if any users are denied access to a survey/vote that they need access to. That might not sound like a great solution but it is not a dangerous solution.
For a huge site where you have many page authors and you don’t really know how many of the survey/vote macros are combining usernames and groupnames in the parameters you could do the searches to find them all but do you really need to do that?
If you choose to ignore it, do the upgrade, and wait to see what happens: It is safe to do it that way because any survey/vote macro that is currently combining usernames and groupnames in a restriction parameter will start to deny access to the users whose usernames are listed in the groupname parameters. They will no longer be able to participate in the vote/survey. That is not ideal, but it is not a security problem, it does not open up any survey/vote to anyone who should not have access. If a user can't vote or can’t manage a survey then that is something that is easy to detect because the user will know right away and the page owners will probably find out quickly after that.