UserList filterBy magic methods not working on custom attributes

Developing with Concrete
1

version: concrete5 5.6.4.0

The built in member search and programmatically searching using new UserList doesn’t work consistently when using custom attributes as search queries.

For example, I have a custom attribute api_key for each user. I can search for these values in the member search but some users can not be found, whilst others can.

The same issue occurs when I search programmatically using magic methods for example

Loader::model('user_list');
$ul = new UserList();
$ul->filterByApiKey('key-here');

If I manually edit any attribute of a user who can not be found, then this starts to work again for that user?

Has anyone else encountered a similar issue?

2

That sounds like the search index is out of date.
You could try running the rebuild search index all job. I am not sure if that covers the user index on c5.6 (it may just be pages it reindexes)

3

Thanks John. yeah it does sound like it’s possible the indexing has gone out of date.

I’ll look in to how I rebuild this is 5.6.

What seems odd, is that one day a user is searchable, then for no reason they can’t be located but only on custom attributes.

Very strange.

4

Do you know whether the UserList class and in particular the magic filter methods uses the UserSearchIndexAttributes table as oppose to the raw users table.

It’s interesting because my UserSearchIndexAttributes table has 1,192 records and my users table has 1,198 which may account for the inconsistency of the search methods.

5

AFAIK it uses a join of user, user info, and the search index. The actual attribute tables are too complicated to search directly, hence they are merged into the search index.

6

Great thanks.

If I update any member then they are added to the search index, which manually solves my problem.

I’m struggling to understand what actually removes a user from the search index in the first place.

Do you know of any action that rebuild the search index?

I noticed that some affected users where sequential in the system which does not seem like coincidence.

7

On current cores, all the search indexes are rebuilt by the search index all job. I do not know if older cores do that, or perhaps older cores only re-index pages with the job.

Any change to a user or their attributes, including deletion, should be reflected with an appropriate update of the user search index. From what you are describing, at some point such an update to the index has been missed for some of your users and their index data is skewed.

8

I don’t believe there is a re-index job for users in 5.6.

It does seem that there are sync issues between the tables. It’s just so odd that is appears to randomly affected different users at different times.

I have some other automated jobs running so I’ll take a look there to see if there are any issues.

Thanks John.

9

The only other idea I have is to export all users, then import them again. You would need export/import addons from the legacy marketplace to do that.

Or you could write a queued job to index all users based on the page reindex job.

1 Like
10

That does sound like an option.

I’m going to spend some time debugging the app first to see if I can locate any issues.

Then I may have to look at a way to automate the re-indexing from a job.