Ma quando provo a rivelare il loro indirizzo email, non mi mostra nulla. Inoltre, il loro profilo pubblico restituisce un errore 404.
Per quanto riesco a vedere, tutti questi utenti sono quasi inattivi (sono attivi in termini di attivazione dell’account, ma inattivi per quanto riguarda l’attività nel forum). Quindi penso che possa essere stato causato da una rimozione automatica degli utenti inattivi non funzionante molto tempo fa.
Se un utente è inattivo per un certo periodo di tempo (730 giorni di default), viene automaticamente disattivato. L’impostazione si trova nella tua dashboard sotto Settings/Users, scorri quasi fino in fondo. È lì che lo vedrai. Tuttavia, non è necessario apportare modifiche solo per il gusto di farlo. Se quegli utenti non hanno effettuato l’accesso da 2 anni, non ha senso riattivarli a meno che non ricomincino a comparire.
Sembra simile al problema che sto riscontrando. Potresti verificare se i nomi interessati presentano duplicati o ‘corrispondenze molto simili’ nel tuo database? Ad esempio user.user e useruser.
Sì, gli utenti interessati sono tra quelli con nomi utente molto popolari. Quindi Discourse suggerisce un nome utente simile. Io creo gli utenti tramite l’API. Quindi ricevo un nome utente dall’utente, lo verifico contro l’API di Discourse e, se è già occupato, uso automaticamente quello suggerito da Discourse.
Per aggiungere qualcosa, il problema che sta riscontrando @hosna è chiaramente a livello di database. Sembra esserci una certa corruzione nella tabella degli utenti. Copiare i contenuti in una nuova tabella risolve questi problemi.
Detto questo, ho notato due occorrenze del problema di @bartv nel database di @hosna (erano i due duplicati precedenti al 22 settembre e entrambi avevano un punto nel nome utente), ma non sono sicuro che questi due problemi siano correlati. Presentano semplicemente gli stessi sintomi.
Tranne il fatto che ciò è impossibile poiché l’indice è rotto.
Questo fa al caso nostro:
# crea una tabella temporanea senza vincoli e copia i contenuti al suo interno
create table users_test (like users);
insert into users_test select * from users;
# rimuovi i nomi utente duplicati con distinzione tra maiuscole e minuscole, i duplicati sono dopo il 22 settembre
delete from users_test where username in (
select username
from users_test
group by username
having count(username)>1
) and created_at>'2019-09-22' ;
# rimuovi i nomi utente duplicati senza distinzione tra maiuscole e minuscole, i duplicati sono dopo il 22 settembre
delete from users_test where lower(username) in (
select lower(username)
from users_test
group by lower(username)
having count(lower(username))>1
) and created_at > '2019-09-22' ;
# restano altri due problemi, eliminali singolarmente
delete from users_test where id in (184534,130826);
# crea una nuova tabella con i vincoli e copia gli utenti
create table users_clean (like users including indexes);
insert into users_clean select * from users_test;
quindi rinomina users in users_old e users_clean in users.
Vorrei intervenire qui per dire che questo potrebbe danneggiare il tuo database ancora più di quanto abbiano fatto gli utenti danneggiati!
Ora siamo bloccati a metà strada tra gli aggiornamenti, poiché molti vincoli fanno ancora riferimento a users_old dopo aver rinominato la tabella. Questo problema è emerso solo alcuni giorni dopo aver applicato questa apparentemente incompleta correzione. Inoltre, like users including indexesnon è sufficiente (ad esempio, ignorerà la sequenza id).
Hai assolutamente ragione, ricordo infatti di aver dovuto ricreare i vincoli dopo aver rinominato le tabelle.
Mi scuso per questa importante omissione.
Dai miei appunti:
alter table poll_votes drop constraint fk_rails_b64de9b025;
alter table poll_votes add constraint fk_rails_b64de9b025 FOREIGN KEY (user_id) REFERENCES users(id);
alter table user_security_keys drop constraint fk_rails_90999b0454;
alter table user_security_keys add constraint fk_rails_90999b0454 FOREIGN KEY (user_id) REFERENCES users(id);
E oggi anche:
alter table bookmarks drop constraint fk_rails_c1ff6fa4ac;
alter table bookmarks add constraint fk_rails_c1ff6fa4ac FOREIGN KEY (user_id) REFERENCES users(id);
E come importante disclaimer: utilizza questo solo quando sei assolutamente sicuro di ciò che stai facendo!
