Two issues using the "Public update" section

[Jon Kristensen]

Hi!

I have stumbled upon two issues using the “Public update” textarea (the update section used by body users).

1. The “Default to creating reports/updates as the council” role seems to be ignored when making updates. The name is publicly visible on the site for users that are not signed in.
2. Updates can be created, but when the form is submitted I'm getting a “Page Not Found” page. It says “Unknown problem ID” and “The requested URL 'https://hylte.fixamingata.se/report/update' was not found on this server”.

As a workaround, can the “Public update” section be hidden, so that body users must use the update flow used by regular users?

We're using FixMyStreet 5.0.

Thanks!

All the best,

Jon

[Jon Kristensen]

Hi, again!

While we could work around the second issue below by disabling the public update section, it turns out that the first issue is bigger than we thought.

Unfortunately, changing category and/or status via the inspect area is not respecting the “Default to creating reports/updates as the council” role either. It doesn't seem to matter if updating as the body has been selected under Provide update as.

This is causing problems for us, since names are displayed publicly even if the user has requested this not to be the case.

We have disabled category and status changes in templates/web/<cobrand>/report/_inspect.html for now.

Any hints on how to make the inspect area respect the “Default to creating reports/updates as the council” role would be greatly appreciated.

Thanks!

All the best,
Jon

[Matthew Somerville]

Hi,

The "Default to creating reports/updates as the council" permission only changes the default "Report as" / "Provide update as" dropdown selection in the normal reporting/updating flow/form, it doesn't at present have any effect on the 'inspect area' form. It certainly could do, do raise a ticket about it.

I don't understand the "names are displayed publicly" aspect, though - the update created by filling in the inspect area form does not supply a name to use, and the default code for updates is for any staff user to use the associated body's name on that update, not the user's name. I've just tested this and indeed, the update I made used the body's name on it. Are you seeing the names because you have the view permission to see the actual user name on updates?

ATB,
Matthew

[Jon Kristensen]

fredag 1 december 2023 kl. 14:00:21 UTC+1 skrev matthew:

The "Default to creating reports/updates as the council" permission only changes the default "Report as" / "Provide update as" dropdown selection in the normal reporting/updating flow/form, it doesn't at present have any effect on the 'inspect area' form. It certainly could do, do raise a ticket about it.

Thanks for the quick reply!

I created https://github.com/mysociety/fixmystreet/issues/4749.

 

I don't understand the "names are displayed publicly" aspect, though - the update created by filling in the inspect area form does not supply a name to use, and the default code for updates is for any staff user to use the associated body's name on that update, not the user's name. I've just tested this and indeed, the update I made used the body's name on it. Are you seeing the names because you have the view permission to see the actual user name on updates?

How strange! The name is visible publicly as you can see here:

https://beta.fixamingata.se/report/1068

The first update made a status change and the second update made a category change. In both cases, the extra data is {"is_body_user": 148}.

The corresponding extra data in production (not our beta site) was "A1:1,T12:is_body_user,I2:68,", since we use FixMyStreet 5.0 in production.

 

All the best,

Jon

[Matthew Somerville]

I don't understand the "names are displayed publicly" aspect, though - the update created by filling in the inspect area form does not supply a name to use, and the default code for updates is for any staff user to use the associated body's name on that update, not the user's name. I've just tested this and indeed, the update I made used the body's name on it. Are you seeing the names because you have the view permission to see the actual user name on updates?

How strange! The name is visible publicly as you can see here:

https://beta.fixamingata.se/report/1068

Okay, so the comment name field is being set correctly to the body, not the user - the issue here is the `always_view_body_contribute_details` function that you added back in 2018, then adjusted in 2021 with the commit: `Hides staff user's name if update is made "as body"`. If you didn't want to do that any more (show staff name if they report as themselves), you could remove that function and it would go back to only showing the name to people with the relevant permission. If you did still want the behaviour, then that could probably be fixed as part of the ticket you've just opened, or perhaps there's a way to change your hook I haven't considered.

ATB,

Matthew

[Jon Kristensen]

Hi, again!

Thank you so much! 🙏 This helped us resolve the problem quickly.

It's been a while so I've forgotten the details around always_view_body_contribute_details. Perhaps we should try to find a way to remove it. 🤔

I just tried to disable always_view_body_contribute_details and posting an update “as myself”, but only the body name showed up when I looked at the “public” update. I was expecting to see the user's name. The “Show my name publicly” checkbox was ticked when making the update.

So the “as myself” updates look the same as the “as body” updates when not signed in, even though the extra data is different:

• {"is_body_user": 148, "contributed_by": 116} (“as myself”)
• {"is_body_user": 148, "contributed_as": "body", "contributed_by": 116} (“as body”)

Any insights into what's going on here would be appreciated!

Have a nice weekend! 😊

All the best,
Jon

[Matthew Somerville]

In the default code, staff users, whatever they are posting as, themselves or body, have the body name shown in a comment, not their name.

That's why I said if you removed/disabled that function, it would go back to "only showing the name to [staff] with the relevant permission".

It's also why you added `always_view_body_contribute_details` in the first place, to try and change this behaviour.

But the inspect form does not set/use `contributed_as` at present, so it has no way of resolving the issue, there's no way of telling an update from the inspector form is one you don't want to show the name for, without it being changed to set `contributed_as: body`, as the normal form does.

ATB,

Matthew