[DONE] Issue selecting related items from a large list of numerically sorted ID's

We are using one app called ‘Equipment’ to store a long list of items such as Drones, Batteries, Charging Equipment, etc.

In a second app called ‘Cases’ we need to curate a group of all the pieces of equipment which are components of each unique Case in a warehouse.

There’s over 150 Batteries, labeled and sorted numerically.
Using labels like B1, B2, B3…yielded poor results when trying to type it in a relationship field selector. So did changing the format to Battery 1, Battery 2, etc.

We then even tried to combine the labels into a category field that looks like “B1 - Battery 1 - Serial# 001011”

The relationship field selector doesn’t seem to recognize a space after the typed characters as typing ‘B1 - Battery1’ returned results of B150, B149, B148 etc.
and because there are so many, the scrolling window wouldn’t scroll far enough to get down to the actual option of Battery 1 which was needed.

We’ve tried sorting the view from Equipment app in various ways to improve the ability to select in the Cases app…but still no success.

3 Likes

@CarsonRedCliffLabs we had a similar experience with material, for example:
J-219 jeklo okroglo
J-220 jeklo cinkano…
The “-“ and empty space between seems to not working properly.
So we did J219, J220 and it worked.
Also I think the best option would be if we could use record ID for example: M0001, M0002… this way it worked nicely from testing, but users are used to Internal naming so we just removed “-“.
Sometimes still a little bit of and need to search for different fields of relation recod.

2 Likes

I agree the sorting on results both in the main search and the relationship field currently leaves a lot to be desired to say the least :frowning: and often makes finding the result you are after in a large list of similar items next to impossible.

3 Likes

@CarsonRedCliffLabs @tomaz @jason many thanks for the report and the detailed description of the problem based on real use cases.

The issue with the record title logic has been annoying us and you guys for quite some time and affects several features. As a background, in our first modeling we mistakenly decided to calculate the title implicitly and in place and not to store it in the database. The reason for this was the requirement that users get different titles depending on the user setting of the formatting and language when, for example, a date field or a number field is used as a title. This has certain advantages but also many disadvantages such as not being able to weight the title higher in the global search (which @Jason mentions), not being able to sort by relation fields, the relation search that @CarsonRedCliffLabs and @tomaz mention just to name a few.

However, I have very good news for you! :100:
We’ve been putting off this topic for a while because the refactor is very time-consuming and other features were more important. However, by coincidence, we already started working on it at the beginning of last week as groundwork for the planned major record upgrade (where you will be able to pick the title field and it will no longer be determined by position due to a multi column approach).

In any case, the refactor should fix all these problems! We are currently rolling out a solution that combines all advantages. If there are any issues left, they will be small fixes in the search logic of the overlay.

The rollout should be completed this week. Then we can doublecheck directly with your real live use cases that you can now find the results as expected without the need of any workarounds.

Thanks again for the feedback and your patience :pray:

Best regards
Leo

4 Likes

Would that also solve the situation, where relationships don’t show titles, although they are calculated just fine in the referenced app? Not happening for all relationship fields though.

Leo

This sounds like great news and I am looking forward to the new record it is starting to sound like it will bring a good number of improvements with it.

Thanks for the update

1 Like

Hi Dirk

I think that is more of a caching issue (Leo will know more) a little like:

I normally find the No Title and the This app does not exist sort themselves out fairly quickly do you?

Don’t get me wrong I am not trying to say either is great :wink:

1 Like

I’m not sure if the updates @Leo mentioned are 100% applied yet…but I can confirm that this issue has been significantly improved for me. Today I was able to go back and complete the task that originally caused this bug report and I had zero issues.
THANK YOU Tape Team!

3 Likes

Hi @CarsonRedCliffLabs, thanks for your update! I’m very happy to hear that the problem has already been fixed. The refactor is not quite finished yet, but modules are being improved and updates released daily, so I wanted to wait until the work was finished to make sure before writing to you, but all the better that the problem has already been fixed on the way.

Thank you very much for your patience and support
Leo

@Leo I am also seeing issues when searching for related items, but it seems a bit different from Carson’s issue here. In my case, many items in the related app can’t be found by searching and I can’t find any pattern to it. I’m searching by the item title, which is just a single line text field, nothing fancy. Do you think this is something the record refactor might fix?

The only way I’ve found I can link these items is by searching the app item ID.

1 Like

Hi @jacquelynmay,

thanks for the report. The description of your issue sounds very much like the title logic. But I’m not entirely sure though, we are rolling out the new pattern day by day for the existing feature modules and should be through with it soon.
Then we can double check if it works for you or you could send us an example of which term you cannot find in which context and we will check directly?

Sorry for the issue and best regards
Leo

1 Like

No worries! I just sent details to your email. The search term is an organization name and I don’t want to post my client’s data publicly. Thank you!

1 Like

Great, thanks @jacquelynmay! Of course the client data should not be public, we will check in detail and get back to you here.

Many thanks and best regards
Leo

1 Like