This PR is not for the article manager as requested in the referenced issue OR it is incomplete and needs updating to add userfacing means to filter by checked out status in the article manager

I have tested this item 🔴 unsuccessfully on 9aaf0f4

As can be seen by the screenshots below it works to show the articles that are checked out BUT the filter option to show articles that are not checked out does not work

I have tested this item ✅ successfully on 72ed6b4

tested the filter in article manager works correctly

Is that a bug fix or a new feature?

Is that a bug fix or a new feature?

Sir it is just a addon in Filter Feature

Anything which is not a bug fix should be made for 5.4-dev (if small feature or improvement) or 6.0-dev (if bigger feature).

@Aashish-Jha-11 As we only accept bug fixes for 5.3, I have rebased your PR to 5.4-dev.

Me and my co-release manager for 5.4 are happy to accept your PR, so I've just rebased it to 5.4-dev.

I've restored @brianteeman 's test result in the issue tracker, so it is still counted, as the change which invalidated the test count was a clean rebase.

So it needs only one more human test to get your PR ready to commit.

However, there is one thing you should know and be careful with:

As you have used your 5.3-dev branch to create this PR and not a dedicated branch, your 5.3-dev branch is now based on our 5.4-dev branch. This might be confusing you.

Furthermore, if you make new PRs, be sure to create branches for these PRs based on the target branch from the upstream repository = this repository here and not on the 5.3-dev branch of your fork because that is already used for this PR here.

You can clean that up when this PR has been merged.

P.S.: I forgot, the PR would also need some documentation, and I think the if conditions could be simplified. For the latter I will make change suggestions when I find the time, if nobody else is faster.

Hi @richard67 Sir ,

Thank you for the rebase and the detailed clarification!

I understand the importance of using a dedicated branch for each PR now. I’ll make sure to create new branches based on the target branch of the upstream repository for future PRs to avoid such confusion.

Once this PR is merged, I’ll clean up the 5.3-dev branch in my fork accordingly.

Also noted about the documentation and potential simplification of the if conditions — feel free to suggest changes whenever you find the time. I’m happy to make those adjustments.

Thanks again for your support!

Best regards,
Aashish

[+] Fetch all articles - ok.
[+] Fetch all checked out articles - 3 count. Ok.
[+] Fetch all articles, but exclude checked out articles - ok. There are no checked out articles in response data.
[-] Fetch all articles checked out by specific user - not working, I got a full articles list.

@sergeytolkachyov Thank you for testing and discovering this critical issue! You were absolutely right - QuyTon's optimization broke the specific user filtering functionality. I've identified and fixed the root cause.

🐛 Problem Analysis
The issue was in the type handling logic. When you select a specific user from the dropdown, the value comes from the HTTP request as a string (e.g., "123"), but QuyTon's optimization was:

Casting to integer too early: $checkedOut = (int) $checkedOut; at the top
Using strict comparison: if ($checkedOut === 1) and elseif ($checkedOut === 0)
This caused string values like "123" to fail both strict comparisons and fall through to the wrong branch.

🔧 Solution Applied
I've reverted to loose comparison with selective type casting:

✅ How This Fixes The Issue
$checkedOut == 1 (loose): Matches both 1 (integer) and "1" (string) ✅
$checkedOut == 0 (loose): Matches both 0 (integer) and "0" (string) ✅
else branch: Only executes for actual user IDs (like "123"), then casts to integer ✅

🧪 Testing Request
@sergeytolkachyov Could you please test again with this fix?

@Aashish-Jha-11

@sergeytolkachyov Sir! You were right to point out the API issue! I discovered the real problem was in the Administrator Model that the API uses, not the API controller.

🎯 Root Cause
The API uses the Administrator Model , which had the same bug as QuyTon's original approach.

I've now fixed both models:

✅ Site Model - For frontend filtering
✅ Administrator Model - For backend & API filtering
Both API calls should now work correctly:

✅ filter[checked_out]="370"
✅ filter[checked_out]=370

Now it's ok. I can submit successful test result if there will not any changes in this pr. Feel free to ping me for this

@sergeytolkachyov Thank you so much Sir for your thorough testing and patience throughout this process! 🙏

I really appreciate you taking the time to verify all the different filtering scenarios - your comprehensive testing was invaluable in ensuring we caught and fixed that critical API filtering bug.

No further changes are planned for this PR, so please feel free to submit your successful test results. The fix is now solid and ready for merge.

I truly value your contributions to the Joomla community and would be more than happy to collaborate with you on future improvements. Your expertise in testing and finding edge cases is exactly what makes Joomla better for everyone.

Thank you again for your excellent work! 🚀

I have tested this item ✅ successfully on 8740f4a

@Aashish-Jha-11 have you used AI for this work? If so, which one?

Hi @sergeytolkachyov Sir, I didn’t use any AI for the actual work — that’s one reason it took a bit more time. I only used my own custom agent at the beginning to help set up the codebase and install dependencies, just to save some setup time. That’s it!

I have tested this item ✅ successfully on 8740f4a

Hi Aashish, I was able to successfully test this! Works great.

Really great work, while I don't use API much at all, very happy that you made this possible! And thanks to everyone who participated to make this great useful result! Congrats to everyone!

Thank you so much for testing and for your kind words Sir, @exlemor!
I'm glad to hear everything works well and that the improvements are useful, even for those who don't use the API much.
Big thanks to everyone who contributed, tested, and reviewed—this was a real team effort! 🚀

@sergeytolkachyov @exlemor Could you do a quick re-test to see if it still works after my suggested changes have been applied? Just to be sure I was not wrong. Thanks in advance.

@sergeytolkachyov @exlemor P.S.: Of possible, don't only test the api as described but also the filter in the articles list in backend like @brianteeman has done before.

@sergeytolkachyov @exlemor P.S.: Of possible, don't only test the api as described but also the filter in the articles list in backend like @brianteeman has done before.

I did it. It had worked)

@sergeytolkachyov @exlemor P.S.: Of possible, don't only test the api as described but also the filter in the articles list in backend like @brianteeman has done before.

I did it. It had worked)

@sergeytolkachyov Could you test again with the latest changes from a few minutes ago? Thanks in advance.

@sergeytolkachyov @exlemor P.S.: Of possible, don't only test the api as described but also the filter in the articles list in backend like @brianteeman has done before.

I did it. It had worked)

@sergeytolkachyov Could you test again with the latest changes from a few minutes ago? Thanks in advance.

I'm afk now, later )))

Hi @sergeytolkachyov @richard67 @brianteeman,

Just following up on this PR 🙂
All checks have passed successfully after the latest changes, and I believe the rebase to 5.4-dev and earlier feedback were addressed.

Please let me know if there's anything else needed from my side, or if it’s good to be merged now.

Appreciate all your help and time!

@Aashish-Jha-11 All good, nothing to be done for you. The PR just needs again 2 successful human tests.

I have tested this item ✅ successfully on 8299936

I have re-tested this successfully (including backend Articles / Filter Options and API)! (thanks again @Aashish-Jha-11

I have tested this item ✅ successfully on 8299936

@Aashish-Jha-11 Isn't it generally a problem if we have a parameter for the checked-out status and the user ID at the same time? What if we want to retrieve the list of checked out items for user ID 1? From my point of view we need a second parameter for the API and @richard67 has the idea of a simplification by using -1 for checked out items.

Background: The user ID for the first root user is created randomly with mt_rand(1, 1000). And therefore has a probability of 0.1% that it is 1. The subsequently created user IDs each increase the max user ID by 1.

@Aashish-Jha-11 @muhme is right, I have completely forgotten that. I think it should work if you change
<option value="1">COM_CONTENT_FILTER_CHECKED_OUT_YES</option>
to <option value="-1">COM_CONTENT_FILTER_CHECKED_OUT_YES</option>
in the administrator/components/com_content/forms/filter_articles.xmlfile, and in the 2 model PHP files check for -1 where you check for 1 now.

Thank you for the clarification @muhme and @richard67 Sir. That makes perfect sense. I'm currently attending college classes, but I’ll make the suggested changes and push the updates by this evening for sure. Appreciate your patience!

Thank you for the clarification @muhme and @richard67 Sir. That makes perfect sense. I'm currently attending college classes, but I’ll make the suggested changes and push the updates by this evening for sure. Appreciate your patience!

@Aashish-Jha-11 Thank you for working on it. No need to hurry. But please make sure to test my suggested changes yourself before submitting. I did my suggestion from scratch and had no time to test it myself. As I'm only a human being, there is always a chance that I am wrong or missed something.

All is ok

I have tested this item ✅ successfully on a376999

Sir @exlemor can you please test again as one more Human test is required for Approval.

I have tested this item ✅ successfully on a376999

I have tested this item ✅ successfully on a376999

I have re-tested this successfully @Aashish-Jha-11 ;)

Great work!

(for the future, it is a good idea to update the testing instructions when there are important changes ( like -1 vs 0/1) so that testing can be faster/most accurate). :) Thanks again.

@Aashish-Jha-11 - I couldn't find you on Mattermost, it would be nice to have you there as well :) Looking forward to testing your next PR :)

Hi @exlemor Sir,
Thank you so much for the re-testing and kind words! I’ll definitely make sure to keep testing instructions more precise next time — that’s a very helpful tip. 😊

Also, I wasn’t aware of Mattermost — I’ll get myself added there shortly so I can stay in the loop and collaborate better with the team. Appreciate the heads-up!

Looking forward to contributing more 🚀

@Aashish-Jha-11 Please adopt the test instruction

Regarding the PHPstan errors in the CI checks: They are not caused by this PR and can not be fixed in 5.4. They will be fixed in 6.0-dev when we update the database framework to v4. I am working on a fix for 5.4-dev to solve that in general. Nothing which can be done with this PR. Just stay tuned.