Auto-publishing and getLoginUserID logic

While investigating a sudden database insert failure one of our users reported, I was trying to follow the logic of the auto-publishing feature.

It does a conditional insert, setting the various fields relevant to a document’s publish status, including the publishedby field. To set this, it uses the getLoginUserID function. I find the logic of this hard to follow. If the visitor is not logged in, what exactly gets returned? Apparently nothing. As you can see from the failed query mentioned above,
the publishedby field is empty. Now we’ve had plenty of problems trying to install on new MySQL databases that have "strict mode" set on this very issue. What would happen if a user’s hosting company upgraded their MySQL database engine?

I’m also puzzled over the logic of the getLoginUserID function. If a web user is logged in his ID gets used as the publishedby value? hm. And if a manger user is logged in and poking around in his site, his user id is never returned by the function (we’re talking front-end here). This looks like an awkward problem to me.

I would think it would be better to automatically use the createdby value in the case of auto-publishing, or don’t update that value at all, and only use the logged-in userID if it’s being manually published. Which of course makes it interesting if the manager user uses QuickEdit, since the getLoginuserID still won’t return his manager ID, since it’s front-end.

Here’s an interesting note that may apply:

You can change the SQL mode at runtime by using a SET [GLOBAL|SESSION] sql_mode=’modes’ statement to set the sql_mode system value. Setting the GLOBAL variable requires the SUPER privilege and affects the operation of all clients that connect from that time on. Setting the SESSION variable affects only the current client. Any client can change its own session sql_mode value at any time.

And one user’s comment:

I migrated from 4.0 to 5.0 and all of a sudden mysql’s sensitivity went through the roof, and queries failed. You can override the features listed on this page by making your first query:

SET @@global.sql_mode=’’;

Which will take away all sql modes. The documentation didn’t seem to be clear on this as far as NEGATING one of these flags but that’s how it’s done.

Maybe we could add something like this to the parser immediately after setting up the db connection?

My tip for the "publishedby" value for auto-publishing is setting it to the loginUser when the publishing date is set, instead of trying to set the field when the auto-publishing actually happens.

Quote from: silent at Aug 21, 2006, 04:10 AM

My tip for the "publishedby" value for auto-publishing is setting it to the loginUser when the publishing date is set, instead of trying to set the field when the auto-publishing actually happens.

A very elegant solution indeed! And just remove that field altogether from the UPDATE query.

Susan, sounds like something that might should be committed to the repository... wanna take a stab at it?

(and if there’s not a bug, we should log this sucker... with suggested code fix)

Susan, looking back at your first post I think that linking the publishedby field - which is a date - to the user who sets it, would not only be a solution (= getting rid of a problem), but a real improvement. You even should not log a user for events that another user has defined. SQL-bug or not: I think it should have worked that way ever since.

regards! (I love your helpful and instructive habits here on the forums as well as your "playground")

Quote from: silent at Aug 21, 2006, 04:12 PM

...linking the publishedby field - which is a date - to the user who sets it...

It’s not a date, it’s the user ID of the logged-in user when the document is published.

Yes, I formulated that wrong. I meant: the user who sets the publishing date should be logged as the publisher (publishedby), he is responsible for the auto-publishing, not a random user who might be logged in at publishing-time.

Yeah, that’s what I thought. But I’ve never claimed to be perfect, and I could have been way off base. Should be easy enough to fix, just need to fix the save_content processor, and remove the offending field in the parser.