Podio Solutions Podcast

S1E11 - Solving Podio Gaps 2: "Filter Views via Text Fields & Sharing Just an App"

March 25, 2019 Brick Bridge Consulting Season 1 Episode 11
Podio Solutions Podcast
S1E11 - Solving Podio Gaps 2: "Filter Views via Text Fields & Sharing Just an App"
Chapters
Podio Solutions Podcast
S1E11 - Solving Podio Gaps 2: "Filter Views via Text Fields & Sharing Just an App"
Mar 25, 2019 Season 1 Episode 11
Brick Bridge Consulting

Podcast Outline – Season 1 – Episode 11 – Solving Podio Gaps #2

Discussion Outline:

  1. Introduction – SUBSCRIBE (please)
  2. Single AWS Lambda for the community, a payoff from Episode 10
  3. 1st Discussion: Filter View with Text Fields
    1. Problem: Why Cannot Filter w/Searchable Text
    2. Issue: Indexing - Who & Why
    3. 3 Possible Solutions/Work around
    4. Bonus: Searchable Null Dates
  4. 2nd Discussion: Sharing just an App but not a Workspace
    1. Problem: Giving access to a full App but not the whole Workspace
    2. Issue: Business Case & Podio Entitlements
    3. 4 Possible Solutions/Work around
  5. Audience Engagement: Solving Podio Gaps – Podio Developers and Power users – Submit your gaps!
  6. Outro: SUBSCRIBE and Thank you.

Follow us on social media (@PodcastPodio) to stay up to date on all Podio Podcast news.

Support the show (http://www.brickbridgeconsulting.com/podcast)

Show Notes Transcript

Podcast Outline – Season 1 – Episode 11 – Solving Podio Gaps #2

Discussion Outline:

  1. Introduction – SUBSCRIBE (please)
  2. Single AWS Lambda for the community, a payoff from Episode 10
  3. 1st Discussion: Filter View with Text Fields
    1. Problem: Why Cannot Filter w/Searchable Text
    2. Issue: Indexing - Who & Why
    3. 3 Possible Solutions/Work around
    4. Bonus: Searchable Null Dates
  4. 2nd Discussion: Sharing just an App but not a Workspace
    1. Problem: Giving access to a full App but not the whole Workspace
    2. Issue: Business Case & Podio Entitlements
    3. 4 Possible Solutions/Work around
  5. Audience Engagement: Solving Podio Gaps – Podio Developers and Power users – Submit your gaps!
  6. Outro: SUBSCRIBE and Thank you.

Follow us on social media (@PodcastPodio) to stay up to date on all Podio Podcast news.

Support the show (http://www.brickbridgeconsulting.com/podcast)

Gil Roberts:

Welcome to the Podio Solutions Podcast, season one episode eleven. I'm Gil Roberts and with me today is Jarett Duker, our principal consultant and our lead developer Alex Shull. This podcast is about the design and development on a Citrix podio platform. It's Podio, p o d i o.com. We use this podcast to discuss our experiences with podio as well as interesting topics from podio is developer community. If you're a podio designer or developer working at an agency, small business or enterprise, you should immediately hit that subscribe button if you have already. Thank you so much for your support. Lastly, before we dive into today's topic, if you have a topic issues, solution, problem or anything else you'd like us to discuss, we want to know about it . Hit us on our Facebook, linkedin, Twitter, or send us an email or podio message to podcast@brickbridgeconsulting.com today's topic is solving podio gaps are mini series on covering solutions for things inside of the user forms or things that people are asking for us. Uh , we got two gaps today that we're going to dive into a but first, Alex, you had a, on our last song podio gaps episode, you had made it quick promise. So, we want to give the pay off on that. So I'll let you go ahead and get into that.

Alex Shull:

Yeah. And the prior podcast I mentioned that I would put together a little example of a lambda function for AWS lambda that would use javascript to do a basic interaction with a podio application. It's kind of a small scale form of what we do with Sassafras. We run our infrastructure on AWS and we have a whole bunch of functions running on lambda that create and manage data to and from podio. But this is a single lambda function that you can take. You can, if you don't have an AWS account, you can go create an AWS account for free and you can go create a brand new no js eight point 10 , um, function. And those, there are different run times available. So you'll have to select the right run time. You create that function and then you add these files into that function and you add one thing called an API gateway trigger. And that means that you're letting your function be called from the Internet just like podio is, API gets called from the Internet. And so with those few steps in this , um, javascript file that we're going to put out there for people to try out , um , you can then configure your function. You have to put a few configuration things for security purposes. You have to tell the function, your app id, and there's something called an app token that you get from the developer tab in Podio for that application. And then you'll have to have a, your own client id and client secret that comes from your Api keys , um , for your account settings. Once you can figure those things, you're good to go and try this out. Would you like to know what it does gil?

Gil Roberts:

Yes, why don't you tell me?

Alex Shull:

So basically this uses a model of authentication for podio called APP authentication that uses the APP token and you use it, the client ID and secret to create a little access token that can then um , create a web hook in your application. So once you have this out there and you have your new unique URL for the function you just created, you can go back to podio and in that app and you can say add a hook and you can put in that URL and you can say, I want to be a, to be an item created hook. And you add it, it will call out that brand new function. You just put an Amazon web services, it will validate it and it will then have a hook that subsequent calls and we'll be able to respond to. Now I have a preconfigured where if you put an item create in there, then it will drop a comment on your item. And so you could change that comment text. You could, you know, just muck around with that a little bit. And you can also change the code to respond to different events. You can do any of the item create, item delete, item update and you can run whatever a little Java script code you want and check it out. I hope people enjoy it. Let us know what you think.

Gil Roberts:

And you're going to have a, we're going to have this on our blog posts. Coming up once we get a little traction on it and some people, yeah ,

Alex Shull:

yeah. Like to see a little feedbacks. Maybe some, some people just to test it out in a validated for us. And then I'll, we'll throw together a little, a blog post to put it in some pictures or whatever to help people. Uh, try it . If , uh , that's the only reason they're, they're slow to tribal . We'll throw some words material to help people try it out .

Gil Roberts:

That's excellent. And uh , just a , a final summary and clarification on this. I just need to know Java script really to to be able to write your function.

Alex Shull:

You can try this without javascript because it's set up to work. All you need to do is put in the environmental variables that's a configuration specific to your podio application .

Gil Roberts:

So they could use maybe PHP or c sharp or

Alex Shull:

No, no , this is javascript javascript. But all I meant to say is that you can actually run, use this file that I'm just getting out there without knowing javascript . It will, it will work. Just running as is. And then if you want to modify it, yeah, you need to learn a little javascript . It's a no js event handlers.

Gil Roberts:

Excellent. Well for our listeners out there, especially those that might be driving around in that car or something, we'll have a link for this , uh , on the show notes, which will take you out to the resources. And then eventually when we write the blog posts all , I'll add the link to that also in the show of this episode as well. Uh , so you can access that and then , and enjoy hopefully, it's great value too and learning to the community.

Alex Shull:

And we can expand on that, um, and , and let , let it see where, it goes. If people find useful, we don't mind, you know, I'm contributing a free resources to the podio community, I think is a great way to show somebody who's very distributable. Okay ,

Gil Roberts:

fantastic. So , uh , with that, we'll go ahead and jump into our first gap and uh, I'll let you give us just a little history , uh, Alex on how we found this and , and why we think it's a great gap to address up. The first one is filter views. Um, and that came from the podio community forms.

Alex Shull:

Yeah If you go to the help.podio.com you'll see that there's um, some space for people to put in some feature requests and vote on them. And um , there's a that hasn't been cleaned up recently so there's a lot of old activity you but this is a more recent one that was posted by um, Harry Clemetti and um , he's asking for filtering views with keywords. And I'll just read, he says it is very useful to filter views, but I'm missing the possibility to also include a free text search keyword into the filter. That is, I can use the filters to narrow down my views to some tens of lines items. But I would very much like to additionally use the key word search to further select only those items were in my keyword is included in any text. So it's, it's a , um, it's not the first time I've heard things like this. What about you Jarett? Seems like a...

Jarrett Duker:

No. And the tag function that is included on a potentially included on all podio items, girls a fair way because you can create dynamic tags, which I've gotten filterable but very frequently we generate just text fields. Ultimately it's a text field and there's no way to filter on that. Yeah . Um, you know, even if it's a single word text field , um, but you know, potentially has a large number of variables that could go into it. Therefore we didn't make an a category field and you just flat out can't even filter by someone's name or uh , frequently would be an example of that. Just filter on a last name to find all your examples. And you can't do that either unless you turned it into some other form of a text. Now you can filter on a relationship by name, which is nice. So if you're linking to another item that has that name, you can do it, but just flat out filtering by text fields is kind of a no go right now.

Alex Shull:

You can filter by the name of the related items?

Jarrett Duker:

Yup .

Gil Roberts:

Yeah, onto on a related side, but that means you have to go what? Build another APP. Another item, put the name of...

Alex Shull:

The primary field that that item is a text field and there's the name Brian on that item. Then you can actually filter, review related on Brian ,

Jarrett Duker:

I do this all the time. Let's say you wanted to find all the appointments related to x , Y , Z company. I can go into my appointments APP and filter by Xyz company as a relationship and then what I do, that's what I'm doing is I'm pulling a related item and then I'm going to give me, give me everything that's, this is related to this one.

Alex Shull:

That's a little hack, I didn't know. See there , what are the interesting things that this uncovers about podio, which I find interesting from the technical standpoint and it's useful. Understand from a design standpoint is that podio and I , I'm not an architect of Podio, I don't have any inside secrets, but I'm just inferring as a user from the outside what's going on and why you have this split between the , the search features and the, the views and there's actually without indexes are built and what , how you, you know, where it's useful to build indexes and how they perform and if you're doing free text search then the number of indices that you have to build as much greater. And usually I have a lot of volume where with a , within a single page of text, you know, if someone, if you're letting him , especially if people use multiple keywords you have to have um , or you're doing similarity matches and things like that, the complexity just skyrockets for what people expect that of searching . Google makes it look so easy and AI is changing this and there are tools out there like elastic, they'll let people build internal search tools on really strong open source platforms. And I'm sure podio teams looking at all was improving those things, but these are built on a core index technology that makes it very easy to serve out the right pieces of data very effectively. Free text doesn't offer that programmatically and it's kind of a soft area of a business process where you have have to go and be a human and read it and understand it and those aren't computery thing.

Jarrett Duker:

Let me stop just for a second. Just for our audience, can you define what you mean when you say index ? Talk about how podio uses index is right now

Alex Shull:

An index is something that from a computer standpoint is basically like the index in a book where you go through and you say, I want to have find the page on, you know, companies z and it says go to page 13 that's something that where you can flip ahead to page 13 you don't have to scan the book looking for the company. You have an index that tells you where to look in this big book full of data. Certainly there's keywords could find all the pages that mention a certain content . If you build custom indexes, that's what search should text searching is building a bunch of, you know , different styles of insurgencies over all of that text versus a category field. I mean if you have five possible selections in the category field, that index is much more compact. It's as much less data to get that kind of search capability versus you know, having a big multiline text field that could be, who knows what characters set. Changed frequently ended up your rebuild those constantly. When someone pastes in 2000 you know words. It's a lot of work and so I don't, you can't diminish that. It is a different kind of work than indexing on a category. Even the relationship index you're talking about where you can then do that on the name . I'm surprised they even do that cause it's, it can be expensive. I think

Jarrett Duker:

It's a little bit of a hack because you're not actually, you're not actually indexing. In that particular case, what you're doing is you're indexing an item and then you're using texts , search features to find that item you want.

Alex Shull:

Okay . That's that , that's a good point. But still the fact that the views let they give you the capability to filter on that view really speaks to it that , um, you know, there are little features in there that I haven't uncovered. Um, and that's useful to know about.

Jarrett Duker:

So how does podio, how does it build indexes and how does it use them?

Alex Shull:

Yeah, I can't speak to exactly how I build them. I don't want to, you know, step out of my, my area of expertise, you know. Um, but where do you see is , is it in the filtering? The filtering is the primary use of the indexes and um, a lot of the, you know, the Java script that is doing calcs, it's based upon the same , the same kind of indexes. It doesn't, you're not going to do free text in a Java script . You know, when you can build those nice convenient relationships within fields and those are where the index is going to play. Um, and, and obviously it has to do with the fundamental Api accessing items and stuff like that. Those are all, you know, it's , it's a data management system under the hood and the indices drive efficient data access. So it's an , it's an interesting topic but to get back to the actual, you know, post , um, I , I hope you have understood why it's a challenge. I think that I believe that tags are under utilized and you would still need a level of parsing to build these tags out, but then you can solve the problem that you're looking at. Um, I think that there, there are other ways or approached, you know, the, the same thing. Um, if you, if you wanted to be actually search within any of you and then constrained the returned items based upon what you match in there, that would be bespoke development and that we could do that. You know, that's kind of work that we would be happy to do to extend the capabilities of podio. Um, and I don't know if that would be returned as a separate app or you know, how you would actually be returned to, depends on what the use cases, but that's bespoke development and that would, the delay on those searches could be removed by having a different search utility that can be on demand. You know, we wouldn't have to rely upon this aggregate, you know, third. Yeah. My podio skills that out , they have to consider everyone searches. But if we just want to extend the capabilities of this one team, we can pull your textile, you pay a little more for, it'll be spoke search, you know,

Gil Roberts:

basically we can build a , uh , its own index for your application. This is the way that you solve the gap, right ? I mean, there's us, they can do it, but even those that are, that are listeners out there that can work on the API, you basically have to build your our index, a little database.

Alex Shull:

Well, the best way is to somehow convert it to tags and build your index with tags.

Jarrett Duker:

Well , I've , I've worked in this for awhile now and I've never felt that this was flat out stopping me. Well this will work around. It would be nice that , you know , if I could just do it, but I've always found a way to accomplish my mission without having to filter by text .

Alex Shull:

Yeah. Nice. Yeah. But I have had disagreements with people about the usefulness of search in the past. And I think that some of them , it's misapplied because early design decisions forced that to be the only way for you to build the correspondence between two items, what you really want there to be hard links that you can just follow. And if you have to do search, it means you're in this fuzzy territory again. And , and so I think design decisions can prevent the need for search and some of these cases. But if it comes down to it, I , I've had people say, well, you know, I don't get to unmake that decision. Search is the best option. That's true. Maybe you need to bespoke search to get, cause you know you're relying on it and podio and their searches are delayed. They haven't rebuilt a search yet. What are you going to do?

Jarrett Duker:

Yeah . I kind of have a follow on question from this, which is something that has flat out stopped me is as it relates to filter limited uplift filter limitations. Yeah . Which is as a part of the default Ui, you cannot filter on a null date . You can search date ranges, but you cannot ask find me the items in which this date feel has no value. Now this has been a major limitation when I'm doing data, data audits because I'm looking for items that are out of compliance.

Alex Shull:

Yeah, go ahead. I'm sorry.

Jarrett Duker:

but the items I'm trying to find, it don't belong into a range . That's why I'm trying to find that

Alex Shull:

The status of null in computer science is something that puzzles a lot of people and um, it's a, it's a, it's kind of one of the philosophical mysteries of life , Jarett. But null are hard things because in database world. Um, knoll is not it . Like you have a boolean value is true or false, right? Well and databases it can also be know what does that mean. So in this case , um , the s I don't have a good solution for you, but I would suggest that maybe the , the back end solution , um , verging on a hack is to have a hidden date fueled with the default value that is out of the range of possible values in 1970. If you go back to January 1st, 1970, that's the beginning of epic time. You block time in the unix world as a, it has a number of zero cause that's when time started in Unix world. And so if you go back to January 1st, 1970 as a default date , you could test against that and all your other days would be subsequent. You don't want to show that to people because then they'll get the wrong. So that's a hidden field technique is something that you know , um, is , yeah,

Jarrett Duker:

That's a really, that's a good idea. And that's something that I could do. And then just simply put an update hook in which saying with any of these dates that I care about are onset, set this to this specified date, but then I can define as a part of my filter is what I'm trying to do is I'm trying to find items that are out of compliance .... a very important question that I've had quite a few times, which is how do I find the items in my database that are wrong?

Alex Shull:

Those are classic database management issues. There were a lot of like style decisions people make about how to, you know, rely on old and you'll see all these stored procedures. Some of them were saying, if this is an old word, this would go blah, blah, all that kind of stuff. So it's , it's just a, it's a persistent problem. You have to make some decisions about how you're going to regards values.

Gil Roberts:

Uh , I think that , uh , so in summary , uh , basically the reason that we cannot filter in a searchable text field is that there's an intimacy and a little workhorse problem that that's required. Is Alex jumped into, or are you , you're kind of solutions available to you. Obviously there's the relationship field hack Jarett described by you can also do something with tags and automatically updating tags , uh , as well as just building something that's bespoke to what you're working on. Um, and , and have them , we'll side database and assigned to index that kind of does that shuffling for, they'd come returns with the podio in some form or fashion that your solution would require. A and a little too for one, Jarrett. So the null dates or even just some of the null fields, you could have a hidden field that , that that's a checked value. Um, so that, and then you can search by that hidden field if need be. So we'll move to the next one. I think this one's even more interesting.

Alex Shull:

I just want to throw one last thing. If the person posting this message gets a hold of that little javascript lambda, you only need one lamb to go to go out and read your texts field and add tags back to your items. Just a thought.

Gil Roberts:

And it was Harry . Harry , are you listening? Okay, excellent. So , uh , our next Podio gap, that will solve here. I is about just sharing an app, the whole app, but just that, not the workspace, not a single item, kind of that middle layer right now because we can obviously we can invite people to workspaces that sharing workspace. We can share items and we could technically share a whole app , but they'd get a whole bunch of emails and you'd have to share every single item an ad.

Jarrett Duker:

It's not ideal. And I can go into use cases of why that doesn't work very well. Uh , here in a minute. Yeah.

Gil Roberts:

So let's go ahead and , uh , where this originated. Also community forums .

Alex Shull:

Um, yeah, this is on the same , um , help.podio.com and this one is , um , actually originally posted in 2014 but there's been more recent activity. It's people keep coming back around, it's been around and people keep coming back to it. And um, and actually Sarah has Sarah Hague , um, has a , um, official response. They're saying, thank you for continuing to share your feedback and need for this feature . We are looking to conduct customer interviews on this subject and also no TBA or timeline. So , um, to me this is as much as anything, it's probably a UI design problem that they're facing. I don't think it's an actual permission design problem from what I've seen inside of podio because they have their pieces segmented well, but I don't think they have a easy means of saying, here's this app, you know, hosted inside, however they structure their Ui wise with relationships, do a workspace but not the other apps that that's , that's my intuition because I can easily imagine using the existing permission sets and capabilities they have to say, here is this app and this app only and the other ones are disallowed. Um, it , so yeah, it has to do with probably , um, probably just having to organize the Ui or on that is my guess. But I think they're a good work around . So the that are possible .

Jarrett Duker:

I've done a couple of different bills because the business case here is um, I have lower level employees that I want to grant limited access to data. I need them to at workspace. I need them to be able to see things, but I really only want them interacting in specific ways. I'm trying to enforce compliance for various reasons, so I don't want to just give them regular member access to my workspace . Um, I want, I only want them to be working inside of the constraints that I set out. And what I've done in the past is dynamically sharing items based on , uh , various criteria. A great example of this is shift notes for um, workers. They need to fill out a law shift log at the end of their shift. They don't want other people messing with other people's shift flaws. They only want them filling out their own. So I can't really give them just access to an APP and I really can't make a workspace for them cause I'd have to have a different one for every single potential employee. So I end up sharing the specific item with them on the day that they work, you know they log in it all to increase the shift log and it shares it with them they're supposed to fill out. Now there's two major problems with this. One is the way that the sharing interface in Podio is organized, it's just a stream of consciousness based on date. It is impossible to find something if it's not at the very top. So let's say you've been working here for a year and you've got 365 shift log shared with you. It's an absolute mess. You , you don't have all of the tools that you would have if you would actually been inside of the APP. Now, this is a little off topic but it's the same basic idea

Alex Shull:

I wanna say that with a little more structure you could build an app to capture that data and keep it much more organized and they can still involve links to shared items in those, in that other items, so, and I , I'm going to speak just more generally to the ability to wire up item copies. So it depends on what level of access you need. If you need this scenario where I want someone to have full access to this app as a user manipulating data and causing changes, that's one thing. Versus I want to show someone all the data in this app and let them muck around with it, but I don't necessarily need them to update my data. What are the use cases? Because that might be a scenario where you copy items out, you know, into a separate workspace.

Jarrett Duker:

I will say this, I've never encountered a scenario where I was going to show someone data without expecting them to manipulate it in some way and I care about that manipulation. I can, I can visualize some business cases where that would exist, but I think it'd be very rare. And it would mostly just be about displaying dashboards, which I have better ways of doing anyway.

Alex Shull:

Well you can , you can achieve the same thing even if you wanted to be able to manipulate the data. It's just the flows are a little more complicated. You have to link items back and things like that. But I can imagine, again, we're pretty low level of bespoke development, having amping up the sharing capabilities without changing the fundamentals of podio at all. I think the, the, the tools are set , it is there, it just requires a little bit of tweaking for the exact scenario. And that's what I like about putting a podio is it , you don't have to build one shear in model that's super complicated to address all the different variations. You can kind of, you know, hone in on the, the exact sharing level you need. But you know, granted everyone wants to have the one they need built right in . I want a button that says my sharing mode. Click here. But, and that's, and , and granted if the podium went through the , the , the , the measures to build in something that is at the level of Amazon web services, you know , um, access model or Google's access model, then you could get off the granularity you need. But it's a lot of overhead to build it.

Jarrett Duker:

We would really want to do would be to give people both the same workspace in app views. Basically the entire toolset that we get from a shared item except when log into their app, they see the items that are tagged with their permission. So that's the only, that's the only gap here.

Alex Shull:

In the database world that's called like um, row level access where you have a database table and every row you have entitlement to that row or not. And so when you do a query on it, it applies your entitlements and then it'll lead queries that we do the same thing when we aggregate data in our, on our SQL copy, what we do is we record the target deployment for anyone who has a copy of that software in Podio, made it through Sas , suppress , we aggregate it back to a central database and when you query it, you have to tell us what environment you're coming from and you're not going to get access to other people's data. That's the way we can do the multilevel. You can have an aggregate report or did you have a client level report? So I think it's, you know, this , uh,

Jarrett Duker:

this kind of opens up another can of worms since I'm on wishlist mode right now, then that's how this photo , it's a very interesting gap. That's a, that's a natural extension of what we're talking about right now, which is granular permissions inside of the database, which is field level permissions that I could've incited . Or is that just inside Podio as a dropdown ? When I'm selecting that I can say this field, maybe they had manipulated by an admin or regular member or a light member.

Alex Shull:

This speaks to something that we were talking about before we started recording this podcast. Wow. Portal.

Gil Roberts:

Yeah. Wow. Wow . Portal that has somewhat solved. Yeah . The gap. I think in certain instances this is probably going to be your best efforts, especially if you're not as skilled or as highly technical on the API side. Uh, to build a custom solution around this. I think that that , uh , w au portal, u m, I'll link it in the show notes. I don't know the URL o ff the top of my head. You c an also Google it of course, and find that. It creates a proxy Ui I think i s, i s what we were talking about where you can k ind o f have an app over an APP, right?

Alex Shull:

Yeah. I think, I think, I don't know the architecture, but I'm assuming that they're just calling the Podio API for you. That's all they're doing and they're just filling it into a Ui where you get to make more decisions of over what's displayed. So they have a lit filtering layer that doesn't give you everything the podio Ui gives you. It gives you that customization.

Gil Roberts:

from what I've seen in it and I got in and it played around with it a little bit. It has somewhat of an entitlement system based on the person logging into a wow portal. So let's say your business uses podio and your employees have access to that, but you want like , um, I'll wait for your customers to get in and look at a statement, right? I can just display a statement or allowed them to maybe manipulate a profile. Right? So they have real specific business case are , excuse me, access and as business case, so a wild portal does that, I don't , they'll return the items that, that, that person is entitled to based on the wow login. Um , so it helps. I think they , this is one of the reasons why that team put that tool together. Um, it's a little arduous to set up just from my experience. I didn't, I also did a cursory through it, so maybe I didn't get as familiar with it. Um, but it does interject some fields into your podio database that you'll probably need to hide , uh , for like entitlements and who gets access and those types of things. We love the guys over a wound or reach out to us. We'd like to talk about the product. I think it's very interesting idea. Uh , and , and is a solution, a solution to this? Um, so do we have another solution? Another possibility. So we've got wow portal, we got just having a custom system built on top.

Alex Shull:

Yeah. I mean , um , uh , other than having the , um, an alternate space where you can , um, send items. Um, I think that , um, you're just looking at different bespoke solutions, but I wanted to talk back to one initial point about, you know, the design of podio and how this sharing is somewhat of a challenge. When you think about the, the permission structure when you have a, Oh yeah, this isn't going to hold up entirely, but when do you have a access to an item and it has a relationship to an item in another APP. It could be also a relationship to an item in another space. Then the way that podio manages your access to the information available when you have, when you're looking at the item you have access to versus clicking on that you may or may not have access to it and I haven't really dug into how they manage that part of it, but the fact that you can filter on a related items and things tells me that they, they, they bring enough of that in to share the item that the related data that it pulls in, it's going to, it's going to display that so it grants you've limited access to related items and I'm wondering if that might not be a way to grant you access to an item that is related to all the items you want in the in the APP.

Gil Roberts:

I see what you're saying.

Alex Shull:

So you just say here, here's a bunch of related items. I'll let you have access to them.

Jarrett Duker:

You're very curious to show. And I've never tried this to make a field level manipulation through the relationship block to an item that I may or may not have permission.

Alex Shull:

It won't give you access to it cause it's that , that is when you click that link, it's,

Jarrett Duker:

well I'm not clicking the link. The relationship field itself has interactable buttons on it. So let's say I could change a category feel from active to inactive without ever opening that. I can do that right from the relationship So I'm really curious to try this now. I'm seeing if I can manipulate an item that I don't have access to through its relationship block based on what the designer allowed into that relationship.

Gil Roberts:

We'll see. I mean who knows? Um, that's very interesting. Uh, I think so. Basically , um , an unverified solution here . Yeah, so what make you leverage over relationship field? Uh, to do it ?

Alex Shull:

Yeah. We'll follow up on it on a subsequent podcast about researching this and what it tells us about the possibilities.

Jarrett Duker:

I think it's amazing that there is a platform we've been working on for years and we're still discovering potential , um, kind of work arounds hacks and secrets.

Alex Shull:

These edge cases really make you search deeper and it's never disappointed in terms of the kind of software we're trying to build. It's, it's a , it's a lot of fun and it's , um, and I'm glad that it was still a little ways we learn to use it to, it's a creative space.

Gil Roberts:

Always a interesting ever boring. So just to summarize the second gap , uh , sharing just an APP, access to full APP but not the rest of the workspace. Um, we've talked about some of the issues as to why that may not be in there. We talked about entitlements as a, as a background on how people can access things just in general from a database side. Got The solution of obviously always the , the bespoke , uh , custom development , uh , can be applied here via the API. Um... shameless plug. U m, there's also the wow portal. I think that's great for those that are maybe less technically inclined t o, to get into the API or deal with any of that type of stuff, that that's a solution that's out there. U h, and then of course, u m, something that we've had to use before, which isn't the greatest, but it does work a s alternative workspaces with apps in them and moving data back and forth, kind of doing that, y ou k now, that that can quickly run out as an option and depending on the size scan over f rom t ime

Jarrett Duker:

I'm working on a build right now that uses three copies of an identical app that all pushes data back up into the master copy and then reserves it. And it's working very well. But again, it's a v ery limited scale c ause I n o, this is just on globiflow.

Gil Roberts:

Yup . So , um, that, that's a way to attempt to get around. It might, you might have to sit there and play with it to get it to sync stuff back. And I think the key part of that when it's making sure that all the copies stay in sync with the master

Jarrett Duker:

It's not scalable. And this is why Sassafras exists, right? I can do it in a limited scope, but as soon as I needed that like 50th copy I'm calling Alex.

Gil Roberts:

right, right. And then , uh, we got an unverified solution. Maybe somehow leverage the relationship field to make a little control panel for apps and kind of a kind of an APP inside of an item , uh , APP inception there. Uh , got it . Solution, we'll check that out and then report back if anybody else has tried that, go ahead and throw some comments or shoot us a message on that. Well, always a pleasure, gentlemen. Uh, we liked solving these stamps who like seeing what's going on in the user community. Everybody's using the system so much differently and we're still learning even after all these years, we are still looking for gaps for the next episode. We've , we found a lot of good ones and got a lot of suggestions being the community forms. If you have a gap that you'd like us to solve on our next show, we'd like to hear from you about that. Go ahead and hit us up on our Facebook, linkedin, Twitter, or send us an email or podio message to podcast@brickbridgeconsulting.com uh, for , uh, the javascript functions that we talked a bout at the beginning of the show. Make sure you check out our show notes for the link on that, and I guess we'll see you all next week.

Alex Shull:

Thank you.

Jarrett Duker:

Wonderful. Thank you for your time.