in the new Find dialog it doesn't seem like its possible to search for ContactId, PersonId, AppointmentId, DocumentId or ProjectId. Only SaleId is available.
I assume this is a bug? Searching for ID's is very useful.
Here is a screenshot with some more context. I've clicked the Find icon at the top of the screen.
We have filtered out all ID fields (primary db key) from search criteria and comluns. The number of fields needed to come down because users were unable to navigate the huge lists. ID fields are not something our end users have any releation to. Actually our reports say that the fields confuse them instead
for columns I see that the ID fields are still there for some of the entities. That is good, because it is very common to include the database ID when exporting a selection to Excel, so that we can use that field as a key when importing again later. Without that it makes it really hard to export/import data.
The naming of the fields however are a bit confusing. For companies it's called "Company ID", for sale "Sale ID", but for persons its called "DB ID".
For projects, appointments and documents, the column is not available.
When it comes to searching for on the field, I still feel like the ID-fields should available. One might think that the database ID's shouldn't be something that anyone has a need to know, but the it's more common than one would think. For what it's worth I believe the searchfields should be put back.
Since all fields are not collapse by default per entity, you dont have to scroll through a huge list anymore.
A few ID's fields should not be a issue then I think?
Note: For OnSite you can now flip a toggle to enable all columns/criteria to be shown. You can do this in the preferces section of the admin when logged in as system user
While it is not my place to counterdict the statistics and/or design, I will stick my neck out this time. After all, at my age, what could possibly happen :-)
From a developper/(partner) p.o.v. the need to get to any field was obvious from the start - when win adopted the netsever providers. So I understand why one may want this.
Why not make it possible to have the best of both worlds?
In win I chose this strategy:
1. When doing a free-text search: show results from everything - even form inside a tooltip!2. Hold-down the ctrl key before clicking the control and the dropdown will show show everything.(Been like this for years!)
Alternatively, use some preference...
Observe that there are 2 ways to hide columns/restriction.
1. The provider meta data can hide.2. The xml .config file can ignore.
For this to work, the provider meta data should not hide too much../conrad
This is from a consultant / partner view.
Removing the Find posibillity for these values makes it more difficult to have reliable way of searching in a number range that does not change in SuperOffice.
These values can be shown in the columns view, but searching is of great help.
Number 1 and Number 2 does change, depending on what that means for the customer.
ERP, Customer number, Social security number etc. or no logic at all. Could be a random counter
When doing imports, exports. Having a unique number field is of great value,
A practical example. eMarketeer applies the DB number on a contact to make a link to SuperOffice.
When looking for duplicates in eMarketeer / SuperOffice. The DB-ID is what makes an entity distinct.
Simply replacing the person ID in the url in browser, to find the correct person is not always a workaround.
Searching for a name/ email search will not show you the correct person easily.
If the wish was to simplify. Rename all naming to DB-ID. So that the uniqe value is more visible.
Sale DB-ID, Project DB-ID, Contact DB- Etc.
We hear you. Loud and clear :-)
We will re-introduce ID's on all major entities into the list of columns and criteria.
Thank you all for your input and feedback.
Have a super day
Thank you, Erik
That`s good news :)
Thank you :)
Someone once said that "It's only statues do not change their minds" and we don't want to be seen as statues :)
Great news. If the goal is to not confuse the standard user, then call them something like Unique ID instead of DB-ID :).
Great News - reenabling the unique IDs in the search/find solution!
StängDenna webbplats använder cookies. Superoffice använder cookies främst för att övervaka trafiken på webbplatsen och för att optimera innehållet. Om du accepterar vår användning av cookies kan du fortsätta använda den här webbplatsen. Läs mer: Integritetspolicy