I’ve been playing with the function of sharing an app with another user in a group. I think it’s a great feature, but I think a few things are amiss when it comes to sharing apps and allowing those users to interact with relationship fields.
Imagine if you will a workspace with two apps, App A and App B, and I’m a user who’s only had App A shared with them.
The share user can interact with a relationship field, but it won’t allow them to add any items (all search results are null) and even though it takes the user to a creation form for that app, any attempts to create items just do nothing, and won’t return to the previous app. The only thing the user can do is remove the value of a relation field, but then they are not capable of putting the value back.
Please see the below image. When the share user is looking at the revision history and the history items have to do with a relationship field, they can’t see anything, it looks very funny where there’s obviously something there but it’s all blank.
Perhaps this is the only way relationship fields can work, but maybe share users should just not be able to touch them in any way? That way, they can’t accidentally clear the field and then not be able to put it back?
I can see that if you try to click to a related item you don’t have access to, you get the error message. So maybe you just need to get rid of the X so users can’t remove the relationship, and disable to “add relation” link so they can’t otherwise interact with the field. Of course, it would be great if these options DID exist if the related app was indeed shared with the user.
The revision history is still weird, though. Not sure what the answer is there.
thanks a lot for your report and the detailed analysis of the issue. I’m going to recreate the problem myself, but I’m already very sure that you’re absolutely right!
We extended the permissions to app and record level about nine months ago, which presented some challenges. Now that we have permissions at record level, it’s very easy and quick to make individual records or apps accessible to just a few people. With Podio, you often had to create workspaces twice.
In our opinion, nothing is worse than a privacy leak, since even the title of a record can be a secret or contain sensitive content, we have decided to display these records in the relation field only if you have at least can edit permission on these records. However, we also know that there are use cases where it is valuable if you do not have access to the app or the records, but can search for and link them in the relation field. We will offer a setting in the relation field for this in the future.
But what you reported is definitely a bug, here we have to deactivate the create button and filter out the activities.
I will get back to you as soon as we have fixed the problem.
Thanks again for the great description of the problem
Leo
Thanks for your response. I think in Podio, the situation where the user can still see the “title” of the item (the top field or whatever the layout says) seems unavoidable and I think this would be fine. I’ve built systems where even the title might have revealed something important, and we just use automations to fill that field with something that provides no information at all (such as just the ID of the item). I personally think this would be preferable than just seeing nothing in the relationship field title, and even having this show up in the activity history would be fine too (again, just in my opinion).
Hi @Leo, is there an update on the reported bug because as of today we can still see the same (weird) behaviour (it looks like you can create a new record but nothing happens after you try).
In addition I have the related question why we have to set the app permissions to “can edit” to make the possible relations visible. In my opinion the “can comment” and “can view” setting should be enough to be able to set a relation for a user that is not a member of the workspace where the records are coming from. I mean “can view” literally says it: user can view the records but is not able to set it as a relation in an app where the user has the rights to create and edit records.
And here is one more thing. Is there a reason why we’re not able to change the “Field type setting” from single to multi or the other way around after we initially saved the setting? I don’t see an advantage for anyone to limit this to a one-time-decision. Correct me I’m wrong.
really a coincidence that you just commented on this issue. We will roll out several permission features this weekend which will solve these problems:
First of all, the create button will only be displayed if you have permission level can edit on at least one related app. Then there will be a permission level for all Org members in the share menu that you can only display the title, which enables the use cases in the relation field as they were implemented in Podio. With the big advantage that you can remove the can show title permission at record level if the content is sensitive.
In addition, we will also release a feature that allows you to easily display individually shared records for users in the app instead of in the share space in the sidebar. This was a highly requested feature from our former Podio users as it allows people to use all the features of the views to work with the shared records.
@Kollaborateur, this is indeed a missing feature at the moment. In Tape, this triggers a field conversion, as we have to clean up all values and all fields where multiple relations are set.
So far there has not been enough demand to prioritize this high enough.
In the course of the new record, however, it is already firmly planned on the roadmap.
Hi @Leo, a question my coworker @timbe just came up with. When you have the right “can edit” in an app of a workspace that you’re not a member off and you’re doing an excel import in another existing app that references the app that you have “can edit” rights, the whole import fails, no matter what setting in the import you choose (create/update/skip).
Why is that and will it be any different after you’ll have rolled out the new update?
Edit: it works with “Full access” level, but it should work from “can edit” level on instead.
I don’t know if you have already seen that we have also solved this issue / request with the permission upgrade.
You can now choose whether the members of the organization (with or without guests) can see the title of records. This can be very useful for some use cases using the relation field.
At the same time, you can remove this access for sensitive records so that the title is not displayed for them. You can find a dedicated article on this here.
In addition, we have fixed the issue with the create button, which is now only displayed if you have “Can edit” permission level on at least one related app.
@Kollaborateur@timbe, no this will not be changed with the update.
We have decided to require the “Full access” permission level when importing because it is possible to create missing category options with an import in a bulk operation, which is only possible with “Full access” in Tape. Of course we could also reduce the required permission levels depending on the settings in the import. However, this makes it more complicated to understand when which level is required and so far no requests have been made in the practice.
If the first requests come from customers or potential customers who need this for the implementation of their use cases, we could change this at any time.
