我们有一个旅行请求应用程序。用户提交一个请求，在获得最终批准之前，该请求应进入审批流程的两个阶段。
现在我们做了以下操作：-
-
创建包含这些字段的SharePoint列表；标题、说明、起始日期、结束日期、首次批准(请求者直接经理(、第二次批准(请求方区域批准(、状态(使用这些选项生成的系统；打开、首次批准、第二批准、最终批准(。
-
Power Apps，它向第一批和第二批用户发送电子邮件，并显示隐藏Approved&根据项目状态拒绝按钮。
-
Power Automate，用于设置项目级别的权限，例如，当项目需要首次审批时，只有审批的直接经理可以编辑该项目，而所有利益相关者都可以只读。
现在流程不是100%安全的，因为使用API调用或使用SharePoint内置表单的请求者可以轻松创建新请求并将其状态定义为Final-Approved。因此换句话说，请求者可以绕过Power Apps业务逻辑。那么我们如何确保我们的流程安全呢？因此，如果一个项目具有状态＝"0"；最终批准"；，那么我们可以100%确定它真的通过了2个审批用户？
我正在考虑的一种方法如下：-
-
若要创建其他SharePoint列表>gt；其存储ItemID+ItemStatus。
-
在授予服务帐户Contribute的同时，授予此新列表上的所有用户只读权限。
-
从"仅自动供电"更新此新列表。因此，例如，仅当提交者的直接经理进行了批准，将新列表中的状态更改为"首次批准"，依此类推。此外，仅当该提交者的区域经理批准了该请求+直接经理已经批准将状态从"第一次批准"更改为"第二次批准"。。因此，无论新的lit内部的状态如何，我都可以确定它没有被黑客入侵，因为最终用户在这个新列表上是只读的。。有人能给我建议吗？
感谢
我相信这个问题并不是你独有的，许多SharePoint开发人员需要进行特定的配置或使用一些技巧来确保在SharePoint中开发特定的流程。
例如，在列表中使用独占/自定义权限控制，并使用PowerAutomate层仅将列表项权限控制给审批者，将确保Rest API的某些更新。
如果你想阻止PowerApps的新插入项目和/或更新项目；OnEdit"；和/或"；OnNew"；使用ResetForm(SharePointForm1);; RequestHide();;并在这些事件中包含此说明的事件会阻止某些用户创建或更新SharePoint项目。
在SharePoint列表设置中，在高级设置中，您可以禁用附件，禁用列表项中的注释，禁用搜索，禁用快速编辑，禁用对话框中的启动表单。
我想仅此而已。