Differentiating between working copy and groups permissions.

[ianwallen]

Is your feature request related to a problem? Please describe. Our application has several groups. Some groups are used for metadata records and some are used for granting access to users. i.e. We have a group call MyData with some metadata records in that group. But we wish to get help from another group of users -i.e. TranslationGroup so we will select a record where we need translation, and we will grant edit to the TranslationGroup. The translation group will review and apply translation as needed. Then once complete we will remove edit permissions from the TranslationGroup. This generally works fine.

The issue is that we have some editors who are part of TranslationGroup and MyData and sometimes create metadata records in the TranslationGroup. We told the users not to put data in that group and their response is that it was an accident and that the system should not allow data creation in that group in the first place.

We have many similar types of groups and in some cases, the default group selected during record creation seems to default to one of these groups making it more likely that users will forget to change it and put data in that group.

Describe the solution you'd like It seems like the problem is that groups are currently used for 2 purposes without any separation. They are used for storing metadata records similar to a workspace. And they are also used for permissions mangement.

I currently see 2 ways to fix this issue. (Option 2 is the preferred easier option to implement) 1 - Create a new table called workspace that would be used to identify where data should reside. This would be a big change and it would require migrating data from groups to workspaces. This may be the cleaner approach as it would clearly separate the data from the permissions. Due to the amount of work required for this, it is probably not feasible.

2 - Add a new workspace flag to the group table to indicate if the group is used as a workspace or not. (Default would be true as that is the current behavior) This would be a simpler approach it would require the following changes.

• Update group interface to allow setting the workspace flag.
• Update the create/update metadata api so that they only allow data to be assigned to groups which have the workspace flag.
• Update create metadata front end ui so that the selection box for picking the group only allows groups with workspace flag set.

Feedback Looking for feedback to identify potential other alternatives. Also looking for feedback on option #2 - We can work on some PR's to apply these changes to the existing code but we want to know if this enhancement would be accepted by the community.

[josegar74]

About option 1, it is not very clear to me what the workspace table would contain? just a reference to the groups where metadata can be created?

For option 2, at least some additional cases should be considered:

• Metadata import: show only workspaces.
• Metadata editor: in the option to select group owner, show only workspaces.
• Transfer ownership: show only workspaces.
• Privileges dialog: should not display the Edit privilege for non-workspace groups.
• User management: show only workspaces in Editor / Reviewer profile sections. To consider also that removing the workspace flag in a group can affect existing users.

As I don't have clear option 1, option 2 seems good to me, but can be quite impactful also.

Let's check for additional feedback from @fxprunayre

[ianwallen]

For Option 1, it was mostly separation of concern. By separating the workspace from the group, it would avoid cases in the future where fields are added to the group table that are specific to a workspace. Also, by separating the objects it recudes the potential confusion - i.e. groups are generally for security purposes while workspace would be for data. We can always go with option 2 initially and refactor the code later to align with option 1 if we decide that it is better to separate the objects.