Forum Discussion

SystemsBVI's avatar
SystemsBVI
Qrew Assistant Captain
7 years ago

Set record level access

Hi,

I have an issue i am grappling with on how to implement within Quickbase. The App is a high level project management app with multiple tasks. 
Project record is the base record that contains details about the project. A project can have multiple tasks and each task can be performed by a different outsourced partner. They are not the ones creating these tasks. Tasks are pre-created and assgined to the respective partner company (assumption is there's max of one of two people from each partner company that'll have quickbase logins). 

So far so good. I have been able to create template records that determine the partner companies the project tasks will be assigned to. With that logic i can easily control which partner company sees which task record using custom rule on the role. 
Now my issue is with the parent project record itself. What method can i employ to limit the view of the project record to only the partner companies assigned in the task. At any given point in time there could be 10-12 partner companies working on any given project. Reverse relationship is really not an option as a partner company could be working on more than one task. Moreover not all tasks have pre-determined assgined company. Sometimes someone can manually assign a task or re-assign it. 

Basically what i really need i think is a way for me to concatenate all partner ids and make it visible to the project record. I havent seen any native way of making this happen. Any ideas/thoughts on how i can make this happen ?

Thanks!

7 Replies

  • There is a limitation which may make this simpler for you.

    In my experience you cannot control permission access to Parent records by information in the children.  That has never worked for me.

    I suggest that you allow the Outside vendors to see all Projects in terms of their permission settings, but put up reports for them to view which have filters to limit the projects.  Then block that Role's ability to modify reports. 

    If you have the Permissions such that users can only see their own Company's Tasks, then you can filter the Projects report where the # of Tasks is > 0. 
  • SystemsBVI's avatar
    SystemsBVI
    Qrew Assistant Captain
    Yeah. But this causes data security issue. We wouldn't want the partners to know anything about the projects they are not supposed to know about. 

    I am certain someone has definitely come up with this issue. I know i can fix this using custom scripting / API but i am trying to see if there's a way to deal with this without having to go through that. It appears like Quickbase has tied our hands behind our backs in these type of scenarios.

    I would have thought this is project management 101 issue.
  • How about adding also a form rule that says if the # of task is zero to hide all the tabs.  Or if you don't have tabs then make at least 1 tab.

    Then then if they guess their way into a valid URL to view a project, it will be a blank form.

    and disable Grid Edit for that Role.
  • tl;dr

    Without even reading your question I can assure you there is a Service Worker solution.
  • SystemsBVI's avatar
    SystemsBVI
    Qrew Assistant Captain
    Hi Mark, that option sounds interesting. Basically you are saying that if i can create "# of tasks" assigned to the current user, then hide everything. let me think through that. Again it feels like it's obscurity but i guess it probably will work :-) 
  • SystemsBVI's avatar
    SystemsBVI
    Qrew Assistant Captain
    Actually Mark, your recommendation worked quite well for me with a slight variation with which i was able to apply to Role based record visibility rules. Basically i created a summary field "# of Open Tasks For Current User". The rule was to simply check this to be greater than 0. This rule only applies to roles that are serviced by external vendors. 
    Thanks for getting me pointed towards the right direction. 
  • I�m very surprised that that worked. Are you saying that you managed to get Role security working based in that Rule. Have you properly tested? In my experience that approach has never worked.