[#31130] - [4.0] Core API - Delete
- Closed
- 13 Dec 2020
- Medium
- Build: master
- # 31130
Steps to reproduce the issue
Use Joomla 4 COre API - Banner (this example can help you: https://documenter.getpostman.com/view/9617873/Szzj9yJy#f8b4dece-cb75-44a5-bf6b-b5d5f9b9d75b)
- With POST create a banner
- Check the ID with GET request
- Try to delete the banner with DELETE
Expected result
No response and the Banner is deleted
Actual result
Error 500
And if you enable the debugger a response like:
{
"errors": [
{
"code": 500,
"title": "Internal server error",
"detail": "RuntimeException: There was an error deleting the item. in /var/www/vhosts/jugmi.it/subdomains/j4/httpdocs/libraries/src/MVC/Controller/ApiController.php:319\nStack trace:\n#0 /var/www/vhosts/jugmi.it/subdomains/j4/httpdocs/libraries/src/MVC/Controller/BaseController.php(729): Joomla\\CMS\\MVC\\Controller\\ApiController->delete()\n#1 /var/www/vhosts/jugmi.it/subdomains/j4/httpdocs/libraries/src/Dispatcher/ApiDispatcher.php(59): Joomla\\CMS\\MVC\\Controller\\BaseController->execute('delete')\n#2 /var/www/vhosts/jugmi.it/subdomains/j4/httpdocs/libraries/src/Component/ComponentHelper.php(389): Joomla\\CMS\\Dispatcher\\ApiDispatcher->dispatch()\n#3 /var/www/vhosts/jugmi.it/subdomains/j4/httpdocs/libraries/src/Application/ApiApplication.php(344): Joomla\\CMS\\Component\\ComponentHelper::renderComponent('com_banners')\n#4 /var/www/vhosts/jugmi.it/subdomains/j4/httpdocs/libraries/src/Application/ApiApplication.php(110): Joomla\\CMS\\Application\\ApiApplication->dispatch()\n#5 /var/www/vhosts/jugmi.it/subdomains/j4/httpdocs/libraries/src/Application/CMSApplication.php(233): Joomla\\CMS\\Application\\ApiApplication->doExecute()\n#6 /var/www/vhosts/jugmi.it/subdomains/j4/httpdocs/api/includes/app.php(54): Joomla\\CMS\\Application\\CMSApplication->execute()\n#7 /var/www/vhosts/jugmi.it/subdomains/j4/httpdocs/api/index.php(35): require_once('/var/www/vhosts...')\n#8 {main}"
}
]
}
System information (as much as possible)
Joomla 4.0 nightly build Saturday, 17 October 2020 02:01:01 UTC
Additional comments
Same problem of many other DELETE API. Not on Article
joomla-cms-bot
- | Labels |
Added:
?
|
||
the reason is here https://github.com/joomla/joomla-cms/blob/4.0-dev/administrator/components/com_content/src/Model/ArticleModel.php#L301
if this is correct see #31134
I originally deliberately allowed you to skip. But I'm not 100% - wondering - especially with workflows - I guess we can't have it insta deleting?
so content & workflow apart.... the other DELETE should be allowed to skip trash ??
Im not sure. Generally that’s how api’s work. I’d be open to hear more people’s opinions though
I would say removing something fully that is published is not a good idea even over an api. So delete should move it into trash and when you delete again then it should be removed fully. Same as the application does it.
Hum, i'll probably would like to see a coupl of more entrypoint to move to
trash and for delete from trash, plus the actual one.....just thinking.....
On Tue, Oct 27, 2020 at 3:39 PM Luca Racchetti notifications@github.com
wrote:
So, can we add a text to the error message like "You can not DELETE a not
trashed item" ?@alikon https://github.com/alikon we need to change the DELETE of
Articles (now directly delete). @rdeutz https://github.com/rdeutz
correct?—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
#31130 (comment),
or unsubscribe
https://github.com/notifications/unsubscribe-auth/AABMLMKQ7K422EVHWESEDHDSM3LQJANCNFSM4SUKPOJA
.
OK let's remove the exceptions for the API from com_content...
if we do it in this way .... then you can only delete a trashed content item.... we don't have an entrypoint for "move to trash"...
....i dislike this choice.
API should follow the constrains a user has normally also plugin triggers that expect a trash before delete could have unexpected behavior
No, not in my view
we don't have an entrypoint for "move to trash"
We do - in the standard PATCH request to update an article you change the article state to trashed (or the appropriate workflow if you have workflows enabled)
API should follow the constrains a user has normally also plugin triggers that expect a trash before delete could have unexpected behavior
APIs definitely can shortcut some things in the UI. There's lots of precedents for that in public APIs. Having said that I dunno if it's in the best interests of the CMS to do that or whether it's better for people to follow the same process. Given workflows should enforce some of this anyhow - it's probably safer to do things the same way as the UI.
ok but in this way you need to call the Api 2 times ....
| Status | New | ⇒ | Closed |
| Closed_Date | 0000-00-00 00:00:00 | ⇒ | 2020-12-13 06:49:30 |
| Closed_By | ⇒ | alikon |
it seems that for DELete a banner the banner item should be setted before to status -2 ie trashed then it works
the strange thing is that for articles you can delete it without transition to Trashed status before @wilsonge any opinion ?