[Citadel Development] Re: Merge Request: Support_IMAP_Flagged_Deleted_Draft_Recent_flags
>I just realized that a Seen message set of *:2099348686 means all messages >have been seen. Were all your messages unseen before the upgrade? I do A seen message set of *:2099348686 means all messages have been seen up to and including 2099348686. We are using what RFC 3501 (IMAP) refers to as a sequence set. If you dig through the RFC's you can read all of the BNF notation, after which you will give up and throw things at your screen. But it's pretty simple to read (maybe not to manipulate, but definitely to read) once you understand it. A sequence set is basically zero or more atoms separated by commas. Each atom can be one of five things: m (a message number) - describes exactly one message. For example: 1,2,3,10,11,12 That means exactly those six messages, and no others, existing or future. m:n (a range) - describes all messages from m to n inclusive, including any new messages that may appear inside that range in the future. For example: 1,2,3,10-12 The above example means messages 1, 2, 3, and everything from 10 to 12 inclusive. If message 11 exists it is included. If message 11 does not exist but appears later on (for example, someone moved it in to the mailbox/room from elsewhere) it is included. *:n - a range from zero to n, inclusive. You'll see this a lot in Citadel; it means "all messages up to and including n" m:* - a range from m to infinity. You'll almost never see this because it excludes any new messages that are added in the future, which isn't exactly desirable. * - all messages, any number, current or future. Again, you'll almost never see this because it excludes any new messages that are added in the future. So if someone picks through a mailbox selecting and deselecting messages, you might see something like: *:124,160,199,200-207,315 Clear as mud, right? ;) To answer your question: when I tested it I had unread messages in quite a lot of rooms. After the conversion they were all marked as read even though I had not read them.
[Citadel Development] Re: Merge Request: Support_IMAP_Flagged_Deleted_Draft_Recent_flags
Duh. Button next to Comment button. I closed.
[Citadel Development] Re: Merge Request: Support_IMAP_Flagged_Deleted_Draft_Recent_flags
>I was trying to figure out how to reject the request myself. Does not look Do you have the button "Close merge request" on the bottom of the screen?
[Citadel Development] Re: Merge Request: Support_IMAP_Flagged_Deleted_Draft_Recent_flags
I just realized that a Seen message set of *:2099348686 means all messages have been seen. Were all your messages unseen before the upgrade? I do ignore Visit records when upgrading that look bad. If they got skipped, the message set would be blank and all messages would show as unseen after the upgrade. Can you check in the log to see what the message says about the conversion. Should show a count of any records were invalid/skipped. > Wed Jul 05 2023 01:48:13 PM EDT from HarlowSolutions Subject: Re: Merge >Request: Support_IMAP_Flagged_Deleted_Draft_Recent_flags > > > >I was trying to figure out how to reject the request myself. Does not look >like you can. I Googled and others were talking about how GitLab was >lacking that option. If you can figure out how to reject or delete it, I >will not be offended unless you don't tell me how :-) Otherwise I will just >update the branch and I think the request will get updated. > >Thanks for the string. I will play with it. In my testing, the upgrade >worked on Seen, but not very extensive examples. > > > >
[Citadel Development] Re: Merge Request: Support_IMAP_Flagged_Deleted_Draft_Recent_flags
I was trying to figure out how to reject the request myself. Does not look like you can. I Googled and others were talking about how GitLab was lacking that option. If you can figure out how to reject or delete it, I will not be offended unless you don't tell me how :-) Otherwise I will just update the branch and I think the request will get updated. Thanks for the string. I will play with it. In my testing, the upgrade worked on Seen, but not very extensive examples.
[Citadel Development] Re: Merge Request: Support_IMAP_Flagged_Deleted_Draft_Recent_flags
Ok then, I think the proper workflow is to cancel the merge request and start a new one? I could reject it but that seems rude :) It isn't just "a seen message set" -- it was ALL of them, across all rooms, at least for me. But if you want an example, my current seen-set for this room (Citadel Development) is: *:2099348686 Are we processing the asterisk? We're using IMAP-compatible syntax, so that one means "every message up to and including 2099348686"
[Citadel Development] Re: Merge Request: Support_IMAP_Flagged_Deleted_Draft_Recent_flags
Thanks for the feedback. My testing only had a small database, so 10 min is rather bad. I think switching to doing the conversion when accessed is the best idea. It is simple since that is how I did it before I switched to the upgrade. I only have to add some code to one function. I am going to look into why the conversion did not work to make sure it is not an error that will occur when I do it on demand. I would be interested in the Seen message set string that caused it to fail. May be the pattern that is not being processed correctly. I will update the branch and submit a new request when I am ready.
[Citadel Development] Re: Merge Request: Support_IMAP_Flagged_Deleted_Draft_Recent_flags
Ok, I tried out the proposed merge. Here are the results. 1. I made a copy of the Uncensored database and ran it on the main line code to verify that the copy is functioning identically to the production database. 2. I switched over to the merged branch and built everything from scratch, and ran it on the same database. 3. The table conversion job took approximately ten minutes to complete. This might cause some server operators to believe the server has stalled and they might take action to interrupt the process. We can talk about options for that later -- perhaps we can wait until an individual record is accessed before converting it, or at the very least we can put progress messages into the log. 4. I logged in to the converted system using my normal account. There were zero (0) messages in all rooms. Prior to the upgrade, I had about 20 rooms with various numbers of new messages in them. 5. I went to a room that is gated by access level and performed a "Who knows room" operation. The results were correct. 6. I verified the following hidden rooms: Room "the test room" with password "thepasswd" Room "Grrr" with no password Room "Citadel Development" with no password In all case, I performed a "Who knows room" operation, and the results appear correct. So it looks like the visit record mapping is correct, the access control bits are perfect, the table conversion completes (albeit slowly), and there were no server crashes or loss of records. The biggest problem is that the conversion of "messages seen" data appears to zero the field out and marks all messages in all rooms as "seen". I did try creating a new message in a room, and then kipped out of the room instead of otoing, leaving that message unmarked. When I returned to the room, it correctly showed as "1 new message". So the ongoing operation appears correct, it's just the conversion that has an issue. I love how you cleaned up the API. Bravo on that.
[Citadel Development] Re: Merge Request: Support_IMAP_Flagged_Deleted_Draft_Recent_flags
No rush on the review. I had to put the code aside for a while (pesky day job :-) and had to write some tests to try to hit most code paths. I tried not to change too much existing code since the change is pretty big to begin with. I only tried to rewrite things that affected performance or optimize using the new functions. I tried to use the profiler (-pg) but was not able to get citserver to output the profile file, so I really have not tested before/after. If you know how to get the profiler working, I would be interest in seeing where we can optimize things for the biggest bang for the buck.
[Citadel Development] Re: Merge Request: Support_IMAP_Flagged_Deleted_Draft_Recent_flags
I'm away on vacation right now and casually browsing the changes. I'll give it a good thorough testing when I'm back at my desk after the weekend, but so far I'm quite impressed. It looks like the changes really follow not just the coding style, but the *design* style of the existing Citadel system. Some things -- like CtdlUserGoto() -- look even cleaner. Unless something comes up that needs an emergency fix, we will stay at version 980 until this merge request has been accepted and tested. When I am back at my desk after the weekend I will try it out with a copy of the production database from Uncensored and see how it goes. It's basically the acid test because after 35 years of nonstop operation there's a little of everything in there. No one else is actively working on the server core right now so there shouldn't be a lot of merge conflicts, if any. As I sit here on the balcony overlooking the ocean and sipping a tasty beverage, I am poking around on WebCit-NG, so I have a lot of commits this week but nothing on the server core. But for now I am signing off because it's time to go out and do something fun. Thanks for your help!
