Adding new fields to Private Messages

It is possible, see #342733: Create upgrade path from privatemsg_attachments to filefield. In that issue is a sub module that does exactly the same as the Upload module for Nodes.. it adds a file field to messages.

We will maybe add Fields support for D7 that might make this easier.

Setting this to postponed, we will think about this again with Drupal 7 where it should be easy.

Don't think it would be a huge problem to add a couple more of fields to messages using the privatemsg module and custom coding. What could be nice is an admin screen for all that...

Big no until drupal 7. Unless of course some one wants to sponsor specific fields development. But i think it will be waste of time and effort until we build it for d7 because fields are in core already in d7.

This is a first, not very well tested patch.

To be fieldable, $message needs to be an object instead of an array. That's why the patch is so huge. Additionally, the patch implements the necessary hooks and makes the required field_attach_* calls. The that some parts are far from being perfect, for example is the content of the fields simply appended to the existing message body.

There are also a few other changes and bugfixes which I might also split up into other patches. One of them is that I removed the privatemsg fieldset in the privatemsg_new form. Not sure about that yet, but with it, there are issues with the weight of the added fields.

There is also a pager bug, which is fixed by the patch. I will most certainly split that into another patch.

subscribing

Triggering a test of the patch, it will most certainly not apply...

Re-roll of the patch, fixed the tests...

Very cool... subscribing.

#11: privatemsg_fieldable2.patch queued for re-testing.

If this passes, probably best to commit without waiting.

Otherwise, two patches would be more easily grockable - the background cleanup to use objects everywhere and then a smaller one just focussing on the fields. but this would only work well if someone had more time to take part in reviewing currently. I would just commit.

Yeah, probably.

I'm not sure about the message body part, that is currently quite a hack. Aka, the fields are simply appended to the message body instead of making the whole thing into a renderable array.

That can be fixed through iterating over what you have written in later commits - as long as there are big fat warnings that the current release is dev only and not 100% supported, I see no problem with that.

Simple re-roll of the patch.

Still not sure about commiting, I'd like to see a some testing before doing so but that might be hard to get so I will probably simply commit it.

Fixed the failing tests...

Fixed the last fail and also added a very basic test case for fields (and have found a bug while doing so).

Final re-roll due to a conflict. Will probably commit this if it still passes the tests.

Berdir,

Just saw that you posted a new patch... was going to test this over the weekend. Would you rather commit and then have me test the entire 7.x-1.x-dev branch? Or are you planning to post another patch that passes the tests?

Let me know how I can be most helpful...

--Ben

I will commit it once it passes the tests again.

Since nobody is (hopefully ;)) using 7.x-1.x-dev in production, it shouldn't be a big problem if there are a few bugs in the -dev release for a while.

Ok, this should now pass.

Okay, sounds good. I'll wait until you commit this to the -dev branch and then start a thorough testing of all features.

By the way, I also was planning to test your recent token patch (http://drupal.org/node/511796) over the weekend. Will that still apply cleanly to the 7.x -dev branch after this commit? I'm assuming there's not any overlap...

Thanks,
Ben

Uhm, good that I wrote a small tests, I forgot an important field function when re-rolling.

@BenK: the token patch will most probably not apply anymore but that's easy to re-roll.

Commited to 7.x-1.x-dev!

@BenK

When testing, please open separate issues for different bugs unless they obviously belong together. That makes it easier to address them separatly with smaller patches.

Suppose entity_uri was lost in this patch

Yeah, must there be one?

The thing is, a single message does not have a entity_url, only threads do.

Sorry, my mistake.