[SF&G] Create option for data groups to be public

[lin-d-hop]

• Track under Social Farms & Gardens project on Clockify *

Description

We want to be able to make user generated data layers public.

To do this let's add a user_group_membership for the user group we want to make public (e.g. Community Gardens Cymru) with user_id = -1, which represents the "public user" has access. Then we'll make a code change that displays groups that the public user can access to all users.

Acceptance Criteria

• Enable any user groups linked to the -1 public user_id to be shown to every user
• Don't worry about changing any layers on production - I can do that once its live.
• Unit tests to support this change

[rogup]

@lin-d-hop Currently the RGS layers appear like this in the left pane

The user group name is 'Community Growing Cymru' so this appears as the section heading.

For public layers, how do you want this to appear i.e. what should the title be for the "public" user group with ID -1 (e.g. "Community data")? And would each of the datagroups need to be renamed accordingly?

e.g. "Allotments" -> "Community Growing Cymru Allotments"?

or would the front end need an enhancement to allow more division into subsections? i.e a "Community Growing Cymru" subsection within a "Community data" section, which contains "Allotments", etc. This would require a change to the data structures to the BE too.

[lin-d-hop]

I had imagined it would look exactly as it does now. Another section: Community Gardens Cymru And the subsections that exist: Allotments, Orchards etc.

Apologies that I was not clearer on that point.

Eventually these sections will need some additional UI so that people can turn them on and off etc. But for now I feel like just making the list longer is okay. Perhaps it will inspire others to ask questions about these layers, which might lead to further collaborations.

[rogup]

Okay, in that case I'll tweak the design a bit, since we need to maintain the 'user group' (Allotments, Orchards etc.). Rather than having a single public user group with -1 ID that the data groups (Allotments, Orchards etc.) are linked to, we will just add a user_group_membership that links the Community Gardens Cymru user group to the publicuser_id -1. And add some logic in the code that lets all users access data that this public user can access.

Another note: There isn't currently a way to specify the access level for user groups, so any user within the user group can edit datagroup objects or copy objects to the datagroup. I'm guessing we don't want to allow all users to have write permission for these RGS datagroups @lin-d-hop ? So there's a bit more work to do to add this functionality in the backend (but most of it can be copied from how we handle map permissions)

[lin-d-hop]

@rogup Good point! I remember doing some thinking around this a while ago. I'm sorry it slipped from my mind on this spec!

So is the right solution to add a user_group_member.level? With read and write. Then we need to ensure that:

• if read the edit options aren't available
• if a user has two permissions then the 'higher' one trumps? So should we rank them eg read = 1, write =2

This is def a scope explosion from the original estimate (sorry!). Do you have any alterations to the above? Can you estimate the work?

Thanks!

[rogup]

All the work for this ticket is done now apart from this permissions stuff.

Yes, I think we just need to add an access column to the user_group_memberships table, with different integer levels, like the access column in the user_map table. And some logic to

• return the 'higher' permission as you said
• check for permissions in the edit datagroup APIs

In the front end, we'll need a couple of tweaks:

• hide the 'Edit' button in the popups for a datagroup that is read-only.
• ensure the 'copy to data layer' tab doesn't show read-only datagroups

My estimate for the backend changes is 2-3 hours, then 2 hours for the front-end changes. So overall, with code review and merging, 1 day.

[lin-d-hop]

Thanks @rogup. Let's go for it. Would it make sense to pair with @ms0ur1s to get this out? We'll need to do a release as well once this is done.

[rogup]

I'll be away for a while after tomorrow, so I think the best way to do it is if I finish it off and then send to Marcel for reviewing async.

[rogup]

Hey @ms0ur1s , I've sent you PRs for the FE and BE to review.

Since we're probably going to be passing each other code reviews more often in the next few months, it would be good to have a chat to agree as a team on how to do them, and maybe make a Wiki. I usually look for these kind of things https://google.github.io/eng-practices/review/reviewer/looking-for.html#summary