I have tested this item ✅ successfully on e7418a0

@zero-24 I think the testing instructions are incomplete. It is not sufficient to check if creating a new request still works after this PR has been applied, it needs also to test if status changes like invalidating or confirming still work.

I've tested all that with success.

In addition, I've verified that it's not possible to create a new privacy request with a different status than 0 (Pending) when modifying and sending again the "POST" with modified data with this PR applied, while that is possible without the PR.

Can you please provide more detailed testing instructions?

If it is only a super user who could have done this then so what.

Can you please provide more detailed testing instructions?

What kind of detail do you need? @Ankur-Khandelwal

See here for the docs arround the privacy requests: https://docs.joomla.org/J3.x:Information_Request_Workflow_in_Privacy_Component

@Ankur-Khandelwal You can find some hints on what to test in the comment with my test result #34251 (comment) . The "In addition, I've verified that ..." in the last sentence you can consider an optional test which is not necessary.

@zero-24 Your testing instructions should at least include the test if changes of the status still work, not only if creating a new request works, as I noted in my test result.

You're a super user and its only for your own account - what does it matter

You're a super user and its only for your own account - what does it matter

It's not "only for your own account" as admins can start requests for any email address, but you are right it is a very minimal issue, but equally a disabled field on the form should not be allowed to be manipulated into a non-disabled field and have its hacked value saved in the db.

Im not sure the proposed solution is the correct one - looks more like a quick fix, surely there is something that can be done with filtering/validating the form correctly when an item is new. IF the form is built and rendered with this field disabled, then the submitted data should be validated against that form configuration (i.e that field was disabled, therefore reject input for that field)

It's not "only for your own account"

Thank you for answering and not ignoring the question

I'm not sure the proposed solution is the correct one - looks more like a quick fix, surely there is something that can be done with filtering/validating the form correctly when an item is new. IF the form is built and rendered with this field disabled, then the submitted data should be validated against that form configuration (i.e that field was disabled, therefore reject input for that field)

We have unset filter which could be used for the purpose. To me, instead of hardcode the value of status like this, the right solution would be change https://github.com/joomla/joomla-cms/blob/staging/administrator/components/com_privacy/models/forms/request.xml#L19 to filter="unset"

@joomdonation can unset be used dynamically? I mean, that you only want to unset the value IF you are creating a NEW item, because if you are editing an existing item, then you dont want it to be unset as the value is coming from a valid dropdown

@PhilETaylor Yes, we always use in dynamically if required like I do on this PR #34303

However, look like for privacy request, there is no editing privacy request available, so maybe hardcode the status value like in the current code is fine, too.

So if there is no edit, and you cannot set this value through a form - why is there a form field for status and not just a plain text label, thus by adding a form field we are introducing a security issue that needs fixing by hard coding statuses ?‍♂️

I have tested this item ✅ successfully on e7418a0

Not very nice. But since we only use this for creating new privacy request (no edit), this is OK.

RTC

I have tested this item ✅ successfully on e7418a0

?

Thanks.