Help for your Sign-in issues – other than case sensitive username

No you misunderstood. There is but one moment of approval.

You ask for the plugin. Approved. The folder is made, the access is granted. DONE. Nothing else happens. As soon as you have, once, uploaded code, and everything’s fine, we know the approval/creation process was done correctly. After that, if something gets screwey, you must have done it.

No one approves/denies privs after that first moment! The simple fact that you are checking out code you checked in means the privileges were set up just fine.

My local copy doesn’t decides the access

Yes it does. Your local copy tells the server who you are. If THAT info got corrupted, you’d see a problem like this.

Yes it does. Your local copy tells the server who you are. If THAT info got corrupted, you’d see a problem like this.

No, my local copy doesn’t contain the username in any .svn file, and it doesn’t say a thing to nobody. It’s just data in my disk, which worked FINE for another user. It’s the client who sends the login info, in this case rapidSVN, which is a software. This software agrees with DreamWeaver that my login is fine, and that your insinuations that there’s no error on the server side is wrong.

If it’s not wrong in the DB, it’s wrong in some other place you’ll find soon.
I just hope somebody is honest enough to admit it when you/they fix it.

Again, by changing something in my profile, or “Author” name in my plugin, by themselves SHOULD NOT affect that user’s access to TWO plugins, through TWO different clients, while other user CAN access it using the SAME local info. Not if everything were working as you describe it should.

When the description of “how it should be” and “how it actually works” mistmatch, there’s a bug. Even if it’s the description what is wrong, it’s called a bug, since it’s not performing as it is expected (or taken as given it should)

Now, let’s forget you confused local copy with client and move on:
Given:

1. DreamWeaver and rapidSVN tells me WP SERVER throws a 403 error, and
2. DreamWeaver even confirms “You have been successfully accessed the server”, and
3. ANOTHER user and another client use both the same local files, and
4. one of my first tests to fix the 403 issue was actually to create a new local folder and starting from scratch, and didn’t work
5. A new user gained access fine
6. committing was tested and failed right before to grant access to the new user, which means the error didn’t fix itself between 1 and 5

Do you still suggest there’s something wrong with my local copy?

Not your local copy of the plugin, your local install of the SVN client (in your case, RapidSVN).

It’s the client who sends the login info, in this case rapidSVN, which is a software. This software agrees with DreamWeaver that my login is fine, and that your insinuations that there’s no error on the server side is wrong.

Yes, that’s what I think is corrupted.

I use svn via command line, but I have the ability to save my username and password so I don’t enter it every time. Should my password change I get one error, and should the file that stores that info get corrupted, I get a 403. It’s happened before.

RapidSVN takes your username and password to the WordPress SVN repo to commit files. Should it’s information as to who YOU are get corrupted, you’d likely see the same error.

I’d uninstall RapidSVN or wipe out it’s prefs and start over.

I have the ability to save my username and password so I don’t enter it every time

As I said before, the username WAS in the .svn files, but it was just in the url, as you said to use it. That was not causing the issue, since I tested it too. With and without it the error kept going. (I made other tests with and without other usernames as well)

The theory of a corrupt software makes no sense. I DIDN’T install any software when it finally worked from a different user. Again, other plugins were commiting fine. Nothing changed and what did I tested it, reverted it, and tried to replicate it.

RapidSVN takes your username and password to the WordPress SVN repo to commit files

No. The password is not saved in the .svn files. I HAVE to manually log-in/out before to connect and I DID test many usernames, passwords, saved, not saved, etc. No success. Other plugins committed fine with a different user.

The info for each plugin is stored in the files inside .svn and .tmp directories. The ones inside .tmp are deleted in each app restart and the ones inside .svn only affect the directory it is in. I tried other directories etc etc. no success. Forget it. My local files were tested for ANYTHING you can think of, many times, many days.

Yes, a mouse bitting my internet cable under the rain also would explain an error. But that doesn’t explain all the other points I’m repeating in every post.

Should it’s information as to who YOU are get corrupted, you’d likely see the same error.

The information as to who I am is saved in the .svn files, in the url. Nowhere else. AND those files don’t affect other plugins. Anyway I removed, re-created, duplciated, edited, etc all the bookmarks, created new local directories, etc. Nothing worked.

Only logging in from a different user worked, AND fixed another plugin (or matched with the date the block in the server was removed/fixed)

UPDATE:

The plugin graphic-wp-sitemap appears as missing in the plugins directory.
I got an email saying “your plugin is ok” (I was questioned about a back-link in it) and I though someone would eventually put it back live, but it’s been 7 days and the plugin is still not found I can commit, though.

If the normal process is NOT taking it off-line while the doubts are resolved, then it definitely stopped working since I REMOVED the original user from the list of committers.

Why did I remove the original user?
Once I got it back working with the new user and committed all files and made sure the plugin was properly working, I removed the original user to test wether re-adding it would fix it (the user) how precise was the statement of

No one approves/denies privs after that first moment! The simple fact that you are checking out code you checked in means the privileges were set up just fine.

and other similar statements about how nonsense was my questions about the relation between the “Author” line in a plugin or the readme.txt file, the committing privileges and the plugin’s approval process.

As per the happened (the plugin is missing now) It seems the plugin is approved for the ORIGINAL user. That means exactly was I suggested: A change in the “Author:” line in the plugin comments or readme.txt file or, in this case, the committers, would make the plugin-user validation to fail.

Right Now I can commit, but the plugin does NOT appear in wp plugins website. No answer from WP in the last 7 days about that.

No, this is not an SVN issue, nor does it have anything to do with the readme or any other thing like that. There is no ‘validation’ like you’re speaking of. I do know how this thing works, you know. I have the source code.

The plugin appears to have been manually removed from the listings. No idea why, I’ll put in a request for the reasoning.

Thanks Otto.

Well, manual intervention was always one of the possibilities, and even makes more sense for the initial issue. (My user was definitely blocked)

Now that you guess that, I’ll guess something too: My plugin was flagged for moderation but since nobody had the time to take a look at it, some random block was put in place, and when I found the way around it the whole plugin was taken out of the listing.

That would explain why I’ve got questioned about the back-link MONTHS after it was approved (right after I re-gained committing access through the new user)

Good news, it’s not a bug ??
Bad news, when a hand is involved it becomes discrimination, retaliation, personal interest, hidden agendas, or many other nasty words.

The user was not blocked. We don’t even have a way to do that.

The plugin itself “graphic-wp-sitemap” was manually delisted. It’s been re-listed now, and is visible in the plugins repository.