blogapi fails with other type of nodes

Still true ... is it by design?

In the meantime, a workaround for who doesn't want to enable blog.module:

1) enable blog.module
2) add 'edit own blog' permission to the desired groups
3) disable blog.module

Maybe blogapi should have a own permission, like "add content with blog api"

Still true.

Has this ever been looked at or addressed?

This isn't a feature request – this is a bug! And it is still applicable in latest CVS!

The attached patch adds a new permission ("add content through blog api") and checks for that instead. I haven't tested it very much, just verified that it meets my most basic needs, so if people would test this to a greater extent, that would be wonderful.

What, then, needs to be tested? Well, permissions! For example: If several content types are allowed to be posted to through BlogAPI, what happens if the posting user doesn't have permission for that particular type of content?
E.g., if BlogAPI is set up to allow for both 'story' and 'page', but a user only has access to post 'story' nodes - are they able to see "$user: page" as an available blog? If so, what happens when they try posting to it? Editing/deleting old entries(/nodes)?

Depending on the outcome of the above mentioned testing, BlogAPI may need a more exhaustive overhaul, making it less blog.module specific (url('blog/'. $user->uid, array('absolute' => TRUE)) (lines 148 and 171, post patch) looks an awful lot like a hardcoded blog path, for one).

D'oh. Forgot to attach the patch. -.-

The handbook page says:

This module also allows site administrators to configure which content types can be posted via the external applications. So, for instance, users can post forum topics as well as blog posts. Where supported, the external applications will display each content type as a separate "blog"

And looking at the code, it seems to check create permissions per node type, so I'm not sure where the "edit own blog" comes in - I don't use this module, but can you reproduce? The hardcoded url and this permission do indeed look like legacy code though.

I can definitely reproduce – I doubt I'd come across this bug if I wasn't actively searching for it. :)

I didn't check how it worked with no permission check on login though, but I thought it makes sense to introduce the one given (hm, on second thought, that might, strictly speaking, have to be put off for D7... ?), as a site maintainer may want to enable himself/some users to post via XML-RPC, while they may want to 'restrict' regular/anonymous with posting access (wiki-like setups, for one), as BlogAPI posting will by-pass any captchas or similar that might be in place to stop/slow spam(mers).

In case the above/previous/former comments aren't clear on how to reproduce:

1. Enable blogapi.module on a fresh install/an install where blog.module was never enabled (or where noone ever had or doesn't currently have 'edit own blog').
2. Set up blogapi.module to be able to post some content types that your testing user has "create $type" permissions for.
3. Try to login with your preferred client. You will get an error saying that your not allowed to post in that blog.

Simply adding one new permission - I don't think that'd be too much an issue if we assume no upgrade path and it seems essential to fix this bug.

Agreed. I also doubt that any currently ported contrib modules rely use BlogAPI and rely on this behaviour... also, there shouldn't be any production sites (ignoring that I'm basing my own, personal site off Drupal CVS :)) running Drupal 6, so people install D6 from scratch would see it straight up. People upgrading from D5 should probably be told that they need to set a new permission when they upgrade to D6 though.

If you have the time, catch, it would be lovely if you would run through the patch. :) I'd love to try and clean blogapi.module up to a greater extent, but this late into the D6 cycle, I feel I would put my sparse resources (= time) to better use working the patch queue and testing for (more serious) bugs. The problem reported here is easily fixed (as demonstrated), so further cleaning, unless absolutely necessary, will be put off for D7 for now (by me, at least). If I can find the time, I think I'll be digging very much into blogapi.module for D7 as things appear right now. :p

This is now merged to the critical issue at http://drupal.org/node/153998#comment-683603 where we needed to fix this issue anyway, while breaking up the blog entry permissions. Otherwise that patch would have been broken as it was. Marking this as duplicate. Thanks for the suggestion Freso, although the permission needed to be renamed to accommodate its broad usage. It is used to check node creation, editing, deletion, file upload, node publishing, categorization, etc. permissions, so it is an all covering permission for blog API. That's where blogapi.module is also lacking, not checking the individual permissions when doing taxonomy, file or node operations (the later depending on node type specific permissions as well). It is not a goal of http://drupal.org/node/153998#comment-683603 however to fix that, so feel free to open another issue for that as well. (I don't think it can be fixed in Drupal 6 comfortably though).

Gábor: As long as it is fixed, it's all good. :) And I do plan on giving BlogAPI a thorough look for Drupal 7. I have a dream of making it more modular, so that it will be easier to add new protocols to it – possibly even from contrib. But let's get D6 out first.