Survey & Vote Upgrade to Version 3.0.0

This is a major release because it fixes https://appfire.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.

In prior versions the inputs for the lists of restricted voters, viewers, and managers combined usernames and group names together.

In the new version we have split the usernames and group names into separate lists to allow for the use of a user picker to auto-populate for usernames in the macro editor.

Upon upgrading to version 3.0.0 from an earlier version you will need to edit all of your Survey and Vote macros that restrict lists of voters, viewers, or managers if (and only if) you have included usernames in those lists along with group names. If you only used the lists for group names and they do NOT contain usernames or if you do not restrict your macros at all then there is no action necessary upon upgrading to version 3.0.0.

To search for the pages where this macro is present 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.

Open

See https://appfire.atlassian.net/wiki/spaces/SUP/pages/147360241/Survey+Vote+Server+-+User+Guide#Survey&VoteServer-UserGuide-SurveyEditorFields
for documentation of the macro parameters for restricting lists of voters, viewers, and groups:

EXAMPLE:

For "List of managers" (Survey macro only. Does not exist in Vote macro)

After the upgrade all of the users/groups that you previously had listed in "List of managers" will now be in the "List of manager groups" input in the macro editor.

• in page edit mode, edit your Survey macro

• Move all usernames from "List of manager groups" to "List of managers"

  • remove usernames from "List of manager groups", leave only group names in that input

  • The "List of managers" parameter is of type "username" so it requires you to start typing in the username for a user so that it can find the user and auto-populate the input for that user.

  • You will need to enter each user manually into "List of managers" so that the auto-populate works to find the user and enter them correctly.

  • The use of a username input fixes the problem of needing to know exactly what the case is for a username (eg. john.doe vs John.Doe). You no longer need to know exactly how the username is spelled in the user store as long as you know enough of the username for the username picker to find them.

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.