@nvyush Please use __DEPLOY_VERSION__ in @since tags instead of 3.8.

@wojsmol Is OK now?

Tested with 3.8 staging. Error under Contents > Articles:

filter[checked_out] has invalid value of the sql_from attribute.

Greetings. Tested with 3.8 beta and once applied if one goes to Content -> Articles we get:

An error has occurred.

0 filter[checked_out] has invalid value of the sql_from attribute. <hr /><sub>This comment was created with the <a href="https://github.com/joomla/jissues">J!Tracker Application</a> at <a href="https://issues.joomla.org/tracker/joomla-cms/17491">issues.joomla.org/tracker/joomla-cms/17491</a>.</sub>

I have tested this item ? unsuccessfully on 8868a8f

In the backend, the Article Manager gives this error with the patch installed:
filter[checked_out] has invalid value of the sql_from attribute.

Uninstalling the patch clears the error.

Oops, at the first variant sql_from had default value "#__content c", later I decided to do it required, but xml for articles leaved as was.
It must be OK now.

I have tested this item ✅ successfully on 8868a8f

The issue with the article manager error is now resolved. Tested the filtering by Checked Out. Works well.

@bayareajenn thanks for testing. I believe you made a mistake with the commit number, the last patched commit is ceb166d.

@nvyush really? I just went to this issue number in patch tester (17491) and applied the patch and it worked. Forgive me, I'm not the best at this testing thing but I'm getting better.

Is applying the patch from patch tester not sufficient? Or is there a different patch/issue number I should test? Cuz what I did gave me a successful test. Let me know and forgive delays, I'm in California and behind almost the entire rest of the world.

@bayareajenn On github.com this PR has last commit of ceb166d. May be this has not matter.

No, it's the same and I did test and it was successful. It matters not whatever that six digit number is. The patch tester is pulling the new PR for us to test. (I think I said that right.)

So as for me, your new PR works and I tested successfully.

FWIW the commit thing is done by the issue tracker, has nothing to do with patch tester. Could just mean the data for this issue fell out of sync on the tracker. Either way it's generally not a big deal.

@mbabker it's worth a lot. The more I learn the more I understand making me a more valuable tester that needs less lame guidance. So thank you very much.

Regardless, I tested the fix and it works as does the filtering by checked out now.

@mbabker Thanks a lot. I thought that only approved commit will be merged.
@crleathers Could you recheck last patch?

I suggest a small improvement.

add in getOptions()

			foreach ($options as $option)
			{
				$option->text = \JText::sprintf('JBY', $option->text);
			}

and in en-GB.ini
JBY="by %s"

to obtain

What do you think?

it would read better without the "by Super User" and instead changed the

• Select Checked Out -
  to
• Select Checked Out By -

Agree

It was corrected as suggested by brianteeman. Please, recheck.

Why is there a "none" in the select? I dont understand that option

Having tested this PR I really dont see the value

I was thinking something similar to @brianteeman earlier. Here's how my thought process went:

Check-in from the article manager can be handy indeed. But the only reason I see to have this filter there is so that a Super Admin or Administrator doesn't have to go to System -> Global Check in.

I then thought, well maybe if there's some UG/ACL that doesn't allow someone to get to System.

But, if a user that is in the Manager User Group tries to check in an Article that is checked out by a Super, they can't check it in anyways. And they shouldn't be able to.

When I train people, one of the things I tell them is that if they need to get into an article that is locked, the first thing they need to do is check to see if anyone is logged in before they "check-in" an article. That way they don't blow someone's work away by checking in an article if someone else is working on it.

This filter might be handy to save 5 clicks for a Super, but not really. And for those that can't check in anyways due to permissions, it's just going to frustrate them that they can't do anything to check in anyways.

PS I didn't realise I could question something that was to test. I was just "testing." Am I allowed to do that?

@bayareajenn of course you can. We dont merge code just because it works ;)

Thanks, @brianteeman I appreciate that. I'll allow myself to express myself in the future.

"None" selects all items, that are not "checked out".
I add it because it can be useful to someone and it is effortless to implement. If the community believes this choice is harmful, I'll delete it.

Well none is the same them as having nothing selected?

I'm not saying it's "harmful", I just don't know that there's a good reason for it.

@brianteeman No, if there are "checked out" items, then empty filter selects all items, but "None" selects all "not checked out" items.
About of the value of the filter. If we have many authors that work simultaneously and we need check-in some articles, we cannot use System -> Global Check in otherwise we drop work all users. In my case the same for contacts.

Can you train them to not use the "back" button in the browser when they finish working on a contact or article? That would keep them from staying checked out in the first place? @nvyush

@bayareajenn All users are trained and know how to end the work with articles and contacts, but sometimes this happens.

@nvyush I know it does. I'm just trying to sort out why you would need more than the individual items where you check the box and then click the "Check-in" button from the Top Toolbar in those cases. If it happens so often that isn't sufficient, then maybe a refreshing training is in order. ;)

For me just reading this conversation, the All/None filters aren't necessarily bad, but they could be better labeled (All Users and Not Checked Out as an example).

For practica use, I can't say I have a case where the None filter adds value, but I also don't do enough work with users/clients who aren't trained in working with Joomla where I'd see a value in either adding it or excluding it from the filter. So I guess I'm not picky either way if it exists.

I tested the commit 10c5731 and see the new label "Select Checked Out By" fine.

@bayareajenn If you have more than 10000 articles and more than 1000 contacts, it is difficult to find needed items, isn't it?
@mbabker I used the available translations and found them quite informative. I did not want to overload the translation file with additional translations. Maybe I was wrong.

I totally get it. But not all of them are checked out (I hope). If someone goes to one they need into and it is checked out, then they can check that one in (if no one else is logged in and editing it). But all good. I did test and it does work. :)

You do know there is an extension available that will check everything in after a set time?

For me just reading this conversation, the All/None filters aren't necessarily bad, but they could be better labeled (All Users and Not Checked Out as an example).

Imho, All Users if fine.
But as we have now Select Checked Out By, Not Checked Out reads a bit weird.

@brianteeman We have the command button "Check In" in Joomla! already without any extensions. Using of it without filtering by "checked out" field is inconvenient. We either need to add filtering, or remove the button. I suggest to add filtering.
@infograf768 My English is not very good to offer acceptable translations. Tell me, please, how to fix it and I will do it. If "None" is superfluous, let's just take it away.

I vote for "None" being removed.

I replace "All" with "All Users" and remove "None". Is it OK now?

I have tested this item ✅ successfully on 8868a8f

I've just tested the latest but the item isn't showing it very well. The new labels of All Users and Super User are working fine.

@infograf768 Could you tell me please, why continuous-integration/drone/pr check is not OK after I removed the found error?

Conflicts with branch 'staging' after merging PR #17668 have been resolved.

Looks OK here.
@mbabker can go or not in 3.8.0 ?

Conflicts with branch 'staging' after merging PR #17748 have been resolved.

as a new feature this should be rebased on the 4.0 branch

Does anyone except me need this feature? If yes, I will rebase it on branch 4.0.

I don't need it. But I can imagine that on a large site with multiple folks logged in all the time that are editing it might be helpful.

@nvyush it would be great if you can rebase it for j4.

I'm closing this, thx for the work and I hope you can rebase it soon.