I imported users using a JSON file that I made. I set all the users as active, but when I import them, they are all locked. Is it possible to import users and have the status “active”? Or is it possible to make an inactive user active without having the suspend and un-suspend? I am importing 350 authors so it becomes very tedious to have to unlock them all.
When you import a user, they have a random password set. They are locked until the password reset flow is used to set a non-random password.
Why are you concerned that your users are locked? This shouldn’t affect any behaviour other than the user’s ability to log in.
It prevents the Author’s page from working on the front end of the site. The posts for the author still work, but when I go to the /author/mike/ url for example, I get a 404 but if I make mike active instead of locked, his articles show.
I found some comments in the code in the “Importers” but I am not sure what to do with the information.
* - by default all imported users are locked and get a random password
* - they have to follow the password forgotten flow * - we add the role by name [supported by the user model, see User.add] * - background: if you import roles, but they exist already, the related user roles reference to an old model id * * If importOptions object is supplied with a property of importPersistUser then the user status is not locked
If this is the case, then it is a bug. However, I’m not able to reproduce the issue with locked users, only suspended users (which is also a bug).
What version of Ghost are you on, what version of the API is your theme using (look up via the
engines.ghost-api field in your theme’s package.json), and can you please link me to the page for an author that is incorrectly 404ing?
I’d like to get to the bottom of this.
I am working on my localhost. I will change my theme back to Casper, maybe it is just the way the theme is written. If it continues, I will move to my Digital Ocean install and let you have a look. In case it is not obvious, I am new to Ghost so I am still learning my way through the structure.
“node”: “^6.9.0 || ^8.9.0 || ^10.13.0”,
Sorry - I meant the theme’s package.json - it is the theme that defines what version of the API is in active use to render your frontend.
Another quick question - does the user in question have any posts associated with them?
I realized what you meant after I posted, so I went into the theme package.json looking and could not find engines in the theme I was using. I switched to Casper and the still have the issue. Casper shows:
Here is the other side of the coin for me… I really don’t mind unlocking the users one at a time now that I think about it. We are going to move all the stories over one at a time anyhow so its not much more work. If you want to chase this, I am happy to help. If you would rather just move on with your day, that works for me too.
Yes, I assigned three or four posts to that author. All the posts show in the homepage feed, but if I go to that author, I get a 404. If I unlock the author, it works fine.
This is a fairly critical bug and a regression (we’ve accidentally broken this before).
Users that are locked or inactive in some way are meant to not be able to login, they should still be returned from the public facing APIs. I already raised a bug here and linked this topic:
It sounds like you’re seeing locked users not appearing in either version of the API, which is definitely weird and unexpected. They should be returned from both APIs, with the exception that the v2 API will only return authors or tags that have published posts associated with them.
I will set you up on my DO install. I am not very far into it yet.
I just realized, it is the link at the bottom of the post to go to the Author’s posts that is pointing at the 404. If I type in the URL, it works fine.
For example, this works:
But if you click on either of the posts for that author and go to bottom, you will see the Author link goes to 404
Oooooooooh that is really interesting and makes some sense. Thank you for taking the time to share!
We tend to tackle bugs like this on Mondays, ready for releases on Tuesday - this is def high priority.
This topic was automatically closed 14 days after the last reply. New replies are no longer allowed.