Open lin-d-hop opened 1 month ago
@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.
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.
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)
@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:
read
the edit options aren't availableThis is def a scope explosion from the original estimate (sorry!). Do you have any alterations to the above? Can you estimate the work?
Thanks!
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
In the front end, we'll need a couple of tweaks:
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.
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.
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.
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
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) withuser_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