Amrayu78 That's interesting :) I have some questions:

Max Romanchenko this is only available to paid tiers that I mentioned. Their limits are stated above. Normal users and Swabby can’t request, so it doesn’t make sense to keep a tally of the Raw requests. This is only for staff to fulfill and not the community at large

Amrayu78 Okay, I get it, thank you.

Max Romanchenko no, one request per title only.

We do not need to track these publicly. Most requested widget should only be for subtitles. I guess these should go into a queue for admin to action on. We will only need to track it internally to see how many requests admin has filled

Amrayu78 I'm a little confused, sorry... It's a request, but it's not really a request, right? What will happen in the admin panel, what will the queue be like? Can you give me the full picture? I've already started working on this and want to go in the right direction and make a decision - to make raw requests similar to existing requests or differently.

So far, I've made raw requests in the current request model, please take a look. Thank you.

Max Romanchenko Sorry for confusing you...

I'll explain what the Requests feature is for both Subtitles and RAWs.

The attached modals that you've created look great!

For the Admin Panel, I'm thinking something similar to the Report Issues queue that we currently have. We do not need anything fancy, just an ability to see the requests, fulfill them, and potentially message the user if needed (for clarification)--> for this you can use the built-in Messages on the site or something similar to Report Issues. If you think it's better to merge Requests & Issues, we can do that too. Request would just be an Issue type "Request" and get precedence.

Amrayu78 Thank you very much for the detailed explanation, it helped me understand better.

The current implementation looks good - okay, I can take the visual but change the backend logic.

Unfortunately, the current implementation of subtitle requests is not a pure table, i.e., it is not possible to display it as a table of requests - the data is not stored separately but is cached in the user and in the title. The status of a request does not exist at all, it is a dynamically obtained value depending on the data.

Adding a new type to the Issues table seems like a logical step, so let's try this option (so that it also handles raw requests).

Therefore, I now have two options:

I am leaning towards the second option - to deal only with raw requests and not touch existing subtitle requests, since the code you generated relies on this storage and I don't want to do something that is not necessary yet.

Do you agree?

Max Romanchenko I agree, lets go with option 2. I don't think there's any need to refactor requests.

Amrayu78 I've added support for raw requests to the Issues table, updated the relevant templates, and tested it. I've also simplified the admin's response a bit in case the issue type is Request. Please check it out.

Max Romanchenko This looks great!

Can we change the statuses for the RAW Requests though?

Amrayu78 Sure, I've changed the statuses for the RAW Requests.

Max Romanchenko This is ready to test now?

Amrayu78 Yes, it's ready and can be tested.

Max Romanchenko Can you show me the screen where everything starts for this?

I want to show what the flow looks like on the site, so I can get someone to test.

Max Romanchenko for example from here? Can you make this flow viewable for Admins as well?

Amrayu78 The flow begins with the request form. It is best to log in incognito as a test user with the necessary role (Matey, Captain, or Moby) to fully test this process (creating a request, email notifications).

I can make it visible to the admin, but what about the limits? To fully test the limits, a test account is required (or I can set the same limit for administrators as for Moby, for example. What do you think?)

Max Romanchenko Yes, please set the limits as Moby for Admin.

Amrayu78 Sure, I added the same limits for admins as for Moby. Now you can test it as an admin.

Max Romanchenko I can't select RAWs. It shows 0/0 and is not selectable (grayed out)

Amrayu78 It was an interesting bug that occurred specifically with your account.

I've searched the database and cleaned up the junk left over from Toolset (it was preventing your admin role from being checked correctly in this case).

Here's what was in your account (wpcf_ and ddl_ are Toolset prefixes):

array (

‘wpcf_custom_post_type_view’ => true,

‘wpcf_custom_post_type_edit’ => true,

‘wpcf_custom_post_type_edit_others’ => true,

‘wpcf_custom_taxonomy_view’ => true,

‘wpcf_custom_taxonomy_edit’ => true,

'wpcf_custom_taxonomy_edit_others' => true,

‘wpcf_custom_field_view’ => true,

‘wpcf_custom_field_edit’ => true,

‘wpcf_custom_field_edit_others’ => true,

‘wpcf_user_meta_field_view’ => true,

'wpcf_user_meta_field_edit' => true,

‘wpcf_user_meta_field_edit_others’ => true,

‘ddl_create_layout’ => true,

‘ddl_assign_layout_to_content’ => true,

‘ddl_edit_layout’ => true,

‘ddl_delete_layout’ => true,

'ddl_create_content_layout' => true,

‘ddl_edit_content_layout’ => true,

‘ddl_delete_content_layout’ => true,

‘administrator’ => true,)

________________________

And now it's cleaner:

array (

‘administrator’ => true,)

Now everything will work perfectly.

I will also check other admins/editors to clean up similar garbage.

Max Romanchenko I've been living testing this with a real user, Mamir.

She's subscribed as Matey and successfully requested one title, but she's unable to request more. Can you check?

Here's her message:

Okay so I've sent a request for Simulation ~Showa 16-nen Natsu no Haisen~ and i think it worked.. but then when I tried to send another request on different title, I can't click on the RAWs option... or is it because i can only request one title at once?

Amrayu78 I've checked, and it's expected, because as you wrote:

"Matey gets 1 title request per month."

Or did I understand something wrong?