I was planning to use a condition for showing or not a specific button.
All my user have a Field “Role” that can be something like: Engineer, Project Manager, AIT Manager, AIT Engineer, etc.".
Since I have more than one type of manager I was attempting to use a condition that says:
when User’s Role contains “Manager” then show button
But it doesn’t seem to work. It works only when I put the extact type “Project Manager” or “AIT Manager”.
Now, I know that I just create as many condition as I need in order to solve the problem.
But I would like to have more flexibility because is possible that names of roles will change once I ll deploy the app, but the Manager suffix will stay for whatever role I put.
Is there something I didn’t get from the use of contains?
@scott do you assign a item# to a user (I.e. “Name” inside of the Roles thing), or create data types for each Role as a list of users?
I am in a similar situation and have lots of repeating group that my app uses to show things relevant to each role (I.e. Role = engineer). What is the best data setup for roles so that RG results can be easily filtered.
it’s a good solution, but do not cover the possibility that I have more or less manager then before. In that case I need to use a different field for manager (yes/no) and it solves the problem even before, but nevertheless, I am wondering if I misunderstood the usage of the command “contains”…
@sergio.rufini The “contains” filter is for exact matches of a single list item within a list (what you’re seeing) as opposed to partial matches of a single item (what you were expecting). “Contains” is to be used with lists, which your User Role field is not.
[List Field] contains [Single Entry]. You can’t say “User Role contains” because a single value doesn’t contain anything - it’s just the single value. You CAN say “Grocery List contains” because that field would be a list of ingredients. Also, try not to think of “contains” as “partially matches”… it’s more “find exact entry” whether it be a text string of a Thing in your database.
Your manager yes/no field would definitely help to keep the number of conditions down, but Scott’s solution gives you more flexibility so that you can still have role names that you can modify without having to update Users.
In general when renaming roles is not a concern is it better to keep roles as text strings or datatype?
I opted for text strings because in this way whenever I want to specify role I don’t need to:
Role = Do a search for…
Name = manager
Instead I can just type it Role = manager, which might speed up my app a bit by avoiding doing searches and I haven’t had other things than Name to create under Role for this option to be necessary.
Yes, in that case if there isn’t anything else associated with the role and names are more stable, then I agree a text field is way easier and more practical. I’ve used both methods, each the better route due to app context.
Thanks guys.
So contains works with the exact value of an entry. But what about “partial” entries?
Another dead end for example is: I am doing a search field that want to search word or partial word in “Any field” of certain types, exactly what we have on the top of the forum page. It works very nicely, with repeating group on groupfocus, but it works only if I type the exact content of a field, non partial.
Nevethless this forum search works fine with partial words…
@romanmg , thanks for the response. It looks like you are suggesting creating different Things for each role, is this correct? Why not just have a thing called Roles and inside of that Thing have RolenameX, ListofRolenameXUsers, RolenameY, ListofRolenameYUsers, etc? Like this:
The above solution, where you have lists of the special class of User held once, is going to be handy in the long run. A little more effort when creating a user (you have to add the new user to the list) but it will make your searches simpler. And you do more searches than creates (usually).
Having direct “business” data embeded in text fields is generally a bad idea. Be explicit in your data when describing things that matter to your application (like being a manager) rather than deriving it from somewhere else.
You can 100% do this too, but I think the key is more about how the app can most efficiently (fewer steps, faster response) retrieve the data. Just depends on your use case.
I just read @NigelG’s response where (I think) he’s saying your way is simpler, but I’m seeing some areas where it might require more steps to search. For example, to simply identify the user’s role. For the solution of multiple lists in a single record, you’d have to check each list (yes or no value)
This structure doesn’t allow you to retrieve the actual name of the role no matter how you spin it because the name is in the field label only.
Versus…
“Current User’s Role’s Name” where role is a Thing and name is the text to label it.
Versus…
“Current User’s Role” where role is just a text field on the user.
The challenge with your list solution is that there’s no Independence for each role, so you can’t reference each of them on other Things that aren’t Users as easily. Even without making Roles a Thing, at the very least with text fields, you can do text matches between different Things. (Nigel also provided a partial match solution)
I just feel like more often than not, you’ll be creating conditions for each list to do anything role related, that I think it’s worth separate records to cross-referencing with any Thing (not just User) and be done with it.
We don’t want to confuse the DESCRIPTION of the role, with the FUNCTIONS that having that role control.
“Is this User a Manager ?” is something that is functional. We will do certain things depending on the answer.
“What is the name of this user’s role” is something descripitve.
Mashing to two together as “Does this User’s Role description contain the word Manager” as both function and description seems like the wrong thing to do.
Personally I would do both, I would have the Role on the User and a list of Users having that Role on the Role. That way I can do the simplest thing to get the data each time depending on what I am doing. What costs me a little time when I set up the User will hopefully make my life easier in the future.
Interesting, so you suggest both having a text data type inside of User which will contain a list of roles (assuming the user has multiple roles) and then each role has its own Thing, which contains a list of users?
For User (this could contain multiple roles: Teacher and VOLUNTEER):
Any help around managing users with multiple roles would be greatly appreciated. Similar to the OP, I have about 5 different types of roles, and each user could be one or all of them. The app, now big enough, has various custom states, filtered searches, and conditional statements (ex. "when role=“Teacher”)…remembering to update the text conditions on all of these is becoming a documentation challenge.
For multiple role searches, I’ve been using separate searches Do a search for RoleX megedwith Do a search for RoleY merged with , etc. It would be nice if Bubble opened up the recordID (ex. 1458364798130x448803103687777760) for table entries (you can see them in the App Data tab), so that we could reference a Roles Thing that has all possible roles in in it, and update as needed).
Nigel,
thanks for the clarification, makes sense and will be careful in the future to consider that.
As regardin the search in text field, I noticed that works only with whole words.
if I have for exmaple a field “title” with the data “Report of Test” and I start search
“Rep” I have no results until I write the whole word “Report” or any other word.
Is that how is suppose to work? Because the search box of this forum takes any partial word!
The forum is not built on bubble, it’s a platform called Discourse. There are ways to let you do a partial match, but it’s not out of the box bubble functionality.
