Forum Discussion

AlexWilkinson's avatar
AlexWilkinson
Qrew Assistant Captain
7 years ago

Group's Records: Problems if record-owner changes

Yesterday I posted a related question about what happens when "Group's Records" is set for permission to view or modify records in a table. The question led to a case I opened with QB Support and their concurrence that the online documentation on this topic needed clarification. In sum, the various problems are:
  1. "Group's Records" means that permissions will align with the group of the record-owner, not the original creator of the record.
  2. If the record-owner is subsequently changed, permission to view or modify aligns with the group of the new record-owner. This could change users' access to records if the new record-owner has different group-membership(s) than the previous one.
  3. If the record-owner no longer has access to the app (their role is "none" or their access is "denied") or the record-owner is removed from group membership(s), and the permission setting is still "Group's Records" then no one (except Admins, presumably) has access to the record.
Personally, I'm interpreting this to mean it's best not to use the "Group's Records" setting unless (a) record-owners are never changed, and (b) departed users are set to a Role of "none" not to access "denied", and (c) departed users are kept in the group(s) they belonged to.
Ask about Quickbase functionality
roles and permissions

3 Replies

Sort By
  • QuickBaseCoachD's avatar
    QuickBaseCoachD
    Qrew Captain
    7 years ago
    FWIW I have been developing apps in QB since 2002 and I have never felt that there was a use for that feature.

    I always find a way to set those kind of permissions based on other techniques. 

    A very powerful technique if you need to control which record users see and don't wants to have a zillion Roles - never have a lot of roles !! - is to create a table of users where the key field is the userds.

    Then in your details tables make a formula User field called [Current user] with a formula of user and then make the formula User().  Then make a relationship based on that field to the userid table and look up say a field  for "department".

    Then make a Custom Role Permission rule that regular users may only see / edit records where  [Dept] is equal to [Current User- Dept]

    So then you have one Role called "Users who are limited to their own department".

    So one Role covers off 100 or 1000 departments.
  • AlexWilkinson's avatar
    AlexWilkinson
    Qrew Assistant Captain
    7 years ago
    Clever. Thanks! I think you meant to say (but forgot to mention) that on each record the [Dept] field has to be initialized, perhaps by a form-rule that changes it to [Current User - Dept] if it's null. Or maybe [Dept] is a formula field that depends on other values, or maybe it's just a required field that the creator has to populate.

    Also, FYI, I was initially drawn to Groups because they also help to manage access to multiple apps. My main client has several of them. However, I think your solution could work if the table in App1 having User as a key field is copied by Quick Base Sync to identical tables in App2, etc. That way, there's just one place to manage access. Or do you know a better way?
  • QuickBaseCoachD's avatar
    QuickBaseCoachD
    Qrew Captain
    7 years ago
    Yes a centralize employee table is a great idea, but you would not be able to use Sync.  It would have to be a Cross App Relationship and then a lookup of the dept.

    The reason is that the Sync will not Sync a userid.  It comes across as texts field and then you need a formula to convert that to a userid, but a formula field is not allowed to be used as a key field unless you really know what you are doing.