NEWLY FOUND INFO:
I just noticed that this issue happens when I'm not logged in (as a superadmin) in the frontend. Whenever I'm logged in the frontend, then I can execute anything in the backend.
And this happens for any superadmins. In my previous test, I must have been logged in the frontend with the new superadmin I had created and that's why it was working in the backend.

This is an odd behavior but at least there's a workaround. There were other things not working in the backend for the hwdvideoshare component that were due to this same problem. For example, if when I'm not logged in the frontend, I can't watch videos in the backend.

Although there is this workaround, what worries me is that there may be some "automatic" tasks that hwdvideoshare does from time to time that might get blocked by CBSubs. For example, hwdvideoshare automatically regenerates from time to time the "Most Viewed" playlist. It is currently not working on my site but other users (not using CBSubs) have this working.
I wonder now if CBSubs is causing this, what do you think? Is it possible that CBSubs might be blocking some functionality that gets done automatically from time to time?

Now to your questions/suggestions:

You may want to inspect your database if this is the case. It looks like something went wrong with a plan.

I'd be happy to do it but I need some guidance. What would I be looking for?

Did you delete a plan or subscription by chance? Have you tried deleting all information pertaining to this users plans/subscriptions?

I might have already done all this. Let me explain.
Before I made my site live, I had done tons of testing with CBSubs. For every test, I would create a new "test" user and subscribe to a plan.
When I was satisfied, I deleted about 45 "test" users. After doing that, the "Subscriptions" table was empty. However, I noticed that there were lots of entries in the History Logs, Notifications and (if I remember correctly) the Baskets. Since you can't delete any of these entries from the backend I used phpMyAdmin to empty those tables.
I did this to ensure I would make my site live with everything being clean (clean tables and no unexistent users pointing to any subscription plans or notifications).

I never created a subscription for my superadmin account though. So, I'm still surprised there was recently a notification about my superadmin's subscription being expired.

I just re-read your post and you mention:
[code:1]
CBSubs -> Settings -> Integration -> Content/Extension -> Full Access granted for = Administrator
[/code:1]
Did you make sure to select Administrato AND Super Administrator? It doesn't auto assign to higher up access. You need to hold ctrl and multi-select all usertypes that ignore protection. This could be the problem.

Indeed the super administrator was Not selected. However, I was able to login with my super admin account through the frontend without any problem and I have access to the hwdvideoshare component (protected by my plans). So, there might not be need to select the Super Administrator.
Regardless, I just selected both, the "Administrator" and "Super Administrator" in this setting but it made No difference.

Regards,

Carlos

Due to your large amount of testing and deleting you likely corrupted your installation.

This sounds odd to me. In the life of a live website, there will be lots of users subscribed and deleted among many other things. I certainly wouldn't expect these typical actions to corrupt the database and have to start from scratch.
My tests were simply real scenarios, but only fictitious users.

I suggest starting over as it could be any number of things, but likely database corruption

Well, my site is now live and has some subscribers. I can't simply delete those users' subscriptions.
Or maybe I'm misunderstanding, what do you mean by "starting over"?
Also, what from what I mentioned could have corrupted the database?

Thanks,

Carlos

krileon wrote:

I suggest making a new install in a subfolder to see if issue is able to be duplicated. If not then it is the installation, if so there it's likely a host related issue. This is the best test to perform in order to help narrow it down for further troubleshooting.

Ok. I'll try this. Before I do this though, what is it that we are trying to prove with this?

Do we agree that it's odd I should login in the frontend to be able to access some of hwdvideoshare's functionality in the backend?
Or is this "expected" for those tasks that hwdvideoshare executes "frontend code" in the backend?
Or is it that being a superadmin, I shouldn't run into this (i.e. being asked to login in the backend when I'm not logged in into the frontend)?

Because if I am able to reproduce it and the answer will be that all of the above is "expected", then I would have simply wasted my time performing a brand new installation.

Thanks,

Carlos