2024年8月30日
1、当鉴定师审批通过时，系统会首先检测页面是否已打开鉴定师详情页，通过锁定特定元素（page-content.identify_expert_detail_content.7）来进行判断页面状态。如果页面已经处于显示状态，则执行相应的回调钩子，对审核详情容器的内容进行更新处理。具体步骤包括：首先，将页面中显示的xc_empty提示信息移除，确保用户界面干净明了；接着，移除页面上原有的两个菜单按钮，以简化操作界面；最后，在页面移除原有按钮后，加入一个明显的长按钮，显示提示信息【鉴定师已入驻成功】，以确认操作的顺利完成并且提供直观的反馈给用户。
2、鉴定师成功入驻后，系统还会检测审核员页面是否已打开【入驻管理列表页面】。如果页面已打开，系统会通过id来锁定对应的审核记录，具体元素位置为【review_identify_expert_li_7】，其中的“7”表示id的具体位置。接着，系统将通过选择器find进一步向下选择到元素“jinsom-mark”，并将原本显示为“待审核”的状态更改为“已通过”，同时将菜单颜色标记为红色，以此高亮提示审核员此项操作已完成。
3、如果鉴定师的申请记录状态不等于1，则说明该鉴定师已通过审核。在这种情况下，审核详情页会展示具体的审核信息，包括【审核员：xxxxx，此字段显示当时的审核工作人员姓名，方便溯源和后续操作。审核定价：xx元，此字段记录初次审核时设定的定价，便于溯源操作。审核时间：Y-m-d H:i:s，此字段记录审核的具体时间】。需要注意的是，审核详情仅固定展示两个状态：1、待审核状态；2、审核通过状态。
4、在鉴定师申请页面上，新增一个名为【info：鉴定师资料】的box容器。该容器将展示用户的基础信息，包括但不限于：鉴定师认证的文字描述、鉴定师的从业经历介绍、公开的鉴定师图片，以及鉴定师授权使用的图片。通过这个容器，用户可以快速掌握当前的审核信息。此外，需要注意的是，info中的鉴定师资料图片大部分来自于申请人，由官方进行收录和核查，以确保信息的真实性和准确性。
5、新增页面：鉴定师管理页面（/module/xc_identify/expert_manage.php），页面唯一标识：identify_expert_manage。通过这个页面，管理员可以对鉴定师进行各种管理操作，包括添加、编辑、删除鉴定师信息，以及分配权限等。鉴定师本人也可以通过该页面查看自己的鉴定资料和统计记录。访问该页面时需要通过GET方法传递固定变量author_id。由于该页面涉及权限指派和复杂的数据处理，页面构造可能较为复杂。
6、鉴定师管理页面通过ajax_page执行页面访问拦截机制，以防止非法请求的发生。这些非法请求包括机器人访问、短时间内请求过高以及非法客户端访问（例如通过UA检测判定）。一旦触发了通用拦截规则，将启动相应的事件处理机制，主要有以下三种情形：1、强制跳转到拦截页面，并提示用户存在非法请求。2、触发阿里云验证码系统，通过人机交互行为验证，用户需完成人机验证后方可继续访问。3、在用户未登录的状态下，访问行为将被强制重定向到登录页面以确保安全。
7、鉴定师资料管理页面现已支持 xc_order_access 访问权限拦截设置，识别标识为 identify_expert_manage。备用变量参数为 $_GET['author_id']。当用户尝试进入此页面时，系统会进行身份验证。如果访问者不是鉴定师本人，则必须具备官方管理员 xc_is_admin_x 权限。若访问者既不是鉴定师本人又不具备管理员权限，系统将强制跳转到403页面并视为非法请求。此外，审核客服页面禁止访问鉴定师资料管理页面，因为该管理页面涉及敏感参数重新设置，只有管理员才有权限执行此操作。
8、鉴定师管理页面为了方便用户访问，是通过传递author_id（即用户对象ID）来实现的。当用户进入页面后，系统会使用wpdb构建一条SQL查询语句，以检索xc_expert数据表中是否存在对应的记录。如果存在相应的记录，系统将获取该记录的id，并使用xc_get_sql来获取整个表的缓存记录（expert）。反之，如果不存在对应的记录，页面将进行拦截处理，以防止非法请求进入系统。
9、在鉴定师申请记录页面中，审核详情容器新增了一个名为【管理查看鉴定师资料】的按钮，通过触发 xc_mobile_url 事件，指向特定代码段【[xc_module type=xc_identify]/expert_manage.php?author_id=' . $expert['user_id']】。该按钮的功能是允许审核员直接打开并查看鉴定师的管理页面。需要注意的是，该按钮只有在鉴定师申请已通过审核的状态下才会显示，并且仅在当前用户具备前台管理员权限的情况下才会展示这一按钮。
10、鉴定师信息页面，第一个容器显示内容为【identify_expert_info：鉴定师基本信息】，具体展示内容如下：1、所属类目：指鉴定师所属的鉴定栏目，例如瓷器、玉器、古玩。原则上，每位鉴定师仅支持一个鉴定栏目，如需后期扩展至多个栏目需做单独适配。2、收费标准：每次鉴定服务的收费标准。3、入驻时间：鉴定师申请成为平台认证专家的时间。4、当前状态：目前鉴定师的状态分为五种，分别是待审核、可接单、暂停接单、封禁状态及其它。
11、鉴定师资料现在通过xc_get_avatar来读取缓存，以避免大量输入get_user_meta来单独提取字段。同时，identify_expert_info容器内会额外展示以下内容：1、鉴定师昵称及UID，这使得用户可以方便地知晓查看信息的来源。2、鉴定师的联系信息，包括姓名和电话。这里的电话是读取用户绑定账户的手机号，而非申请时填写的联系电话。3、累计鉴定次数（xxx次），确保用户了解鉴定师的经验丰富程度。4、鉴定收入（xxxx元），透明展示鉴定师的收入情况。
12、鉴定师信息页面不会过多展示鉴定师的详细信息（不会通过组件直接输出用户信息），但在页面的右上角会显示鉴定师的头像。点击该头像后，用户可以进入鉴定师的主页以查看详细信息。需要注意的是，为了防止重复打开鉴定师主页，前端事件会进行检测，如果系统发现该主页已经打开，会触发拦截提示，提示用户该页面已打开，请返回上一级页面查看，避免重复加载。
13、鉴定师信息页面新增第二个box容器【material：鉴定师资料】，该容器将展示以下内容：1、认证描述内容，详细介绍鉴定师在某一领域的专业认证情况。2、从业经历介绍，内容可理解为专家介绍，展示鉴定师的职业背景和工作经验，增强权威性和可信度。3、鉴定师的公开图片，该部分将展示鉴定师的个人形象照片，有助于用户对鉴定师产生直观的认识。4、鉴定师的授权协议图片，通过展示授权协议图片，确保信息的合法性和真实性。这些资料均在鉴定师入驻时由其提供，并经过审核员的审核和验证。在页面上只是做基础展示，如果管理员需要调整资料内容，可以根据具体情况进行修改。鉴定师如需对资料进行修改，需联系对接审核员，并提交相关材料，审核员则会根据新提交的内容进行相应的修订和更新。

2024年8月29日
1、对 xc_is_review 函数进行优化处理，解决因 type 变量传递不当而始终返回 false 的问题。目前，即便用户是管理员或审核员，系统也会错误地判断其无权限，导致这些用户在访问鉴定入驻详情页、审核列表页及同意审批页面时，均被拒绝访问。该错误源于 xc_is_config 函数在获取配置信息后，对场景是否存在的判断依赖于 type 变量。由于变量问题，系统错误地认为场景不存在，从而间接造成了 xc_is_review 函数返回 false。通过优化此函数，将确保权限判断的准确性，提高用户访问相关页面的正常性。
2、修复审核员在点击【同意鉴定师入驻请求】菜单按钮时，服务端返回错误信息【审核失败：提交参数缺失】。经过仔细排查，发现是由于参数（agree['id']）缺失所导致的。在前端封装agree数组对象时，通过page_content.attr('id')获取申请表主键值却出现了undefined错误。进一步检查发现，该错误是由于GET参数提取失败引起的，正确的方法应该是通过agree[′id′]）缺失所导致的。在前端封装agree数组对象时，通过pagec​ontent.attr(′id′)获取申请表主键值却出现了undefined错误。进一步检查发现，该错误是由于GET参数提取失败引起的，正确的方法应该是通过_GET['Id']来设定自定义属性，从而确保参数能够正确传递。
3、图片组件进行优化处理。修复多个图片上传组件同时存在时，B组件图片在完成上传后，无法执行排序拖拽的现象。A图组件则不受影响，可以正常进行排序拖拽。具体错误是Sortable.js库的执行逻辑，该库是用于创建可拖拽和排序的列表，为了用户交互体验，项目集成了该库。并在用户图片上传时候，会自动触发初始化。但是因为上传场景组件的重构，没法兼容适配。目前已进行适配处理。在元素选择的时候，会通过type表示，进行元素位置锁定，确保图片场景拖拽功能被解锁。
4、四个图片上传场景均已适配新版本的 Sortable 库，确保所有场景的图片上传行为都能够实现拖拽排序图片的功能。图片元素的锁定方式为使用【xc_publish_image.find('#xc_publish_images_list').get(0)】来定位元素。以下是各场景的具体函数描述：1、h5_upload_image_change：这是一个H5内置上传拦截器，用于处理H5页面中的图片上传并随后实现图片排序。2、plus_gallery：该函数负责打开系统相册，用户可以选择图片或视频进行上传，并在上传后实现排序功能。3、plus_camera：此函数调用系统摄像头，支持拍照或录制视频，完成后同样可以对上传的内容进行拖拽排序。4、xc_upload_image_wx：专门处理微信环境下的图片事件，确保微信中上传的图片也能支持拖拽排序功能。
5、修复并解决【Undefined variable $ua in 】错误，在执行完成所有的业务交互动作后，会触发xc_notify_hook消息通知，通知用户入驻成功。这里会通过push_data传递一些参数，这其中就包含审核员的UA信息，在执行通知的时候，因为UA变量不存在，导致返回结构体被破坏了。目前改为通过$_SERVER['HTTP_USER_AGENT']来获取设备信息。该错误存在多个场景，审核和拒绝鉴定师。
6、鉴定师审批通过通知进行优化：为提高用户体验，在审批通过通知中加入一个字段，明确显示鉴定收费标准【示例：鉴定收费：（98元）】。由于鉴定收费标准是由官方设定的，用户对定价非常敏感，需在通知过程中明确告知。具体调整如下：邮件通知内容应显示（您的鉴定师入住申请已通过，您已成为平台认证的（' . cat_name . '）鉴定师。单次鉴定收费标准为（' .cat n ​ ame. ′ ）鉴定师。单次鉴定收费标准为（ ′ .price . '元））。同时，在服务号菜单中新增字段，以显示'鉴定收费：（' . $price . '元）'，以便用户随时查阅。
7、修复并解决了在同意鉴定师入驻请求时，SQL数据表操作未能成功写入的问题。具体而言，info字段应包含鉴定师的资料信息（包括认证信息、图片资料和个人介绍），而audit字段应记录审核员的信息（包括审核时间、审核员ID和审核设备信息），这些都是用于溯源操作的重要数据。这两个字段都是数组结构，虽然数据表显示有写入尝试的记录，但最终结果为空。经过仔细分析和处理，最终发现问题的根源在于xc_update_sql方法不支持子数组结构。正确的解决方案是提前对这些数组进行序列化处理，确保数据能够正确地写入和存储。
8、关于数据库结构设计的规划，目前宫论对于数组结构内容的存储方案采用了序列化和反序列化的处理方式。在PHP的开发环境下，这种方法运行良好。然而，若将来需要更换开发语言，这种方法将成为一个重大问题。此外，序列化的字符串无法支持索引，从长远考虑，这显然是一个不利因素。因此，需要进行变更。今后在处理涉及数组结构的内容时，将全面禁止使用反序列化字符，而改用JSON结构来存储。这不仅确保了数据的跨语言兼容性，也大大提升了数据库查询的效率和灵活性。注：已有的存储方案，暂不做处理。后续开发需要做json处理
9、修复并解决xc_is_user_id判断用户是否存在方法出现错误的问题，该函数是检测UID是否存在数据库中，存在返回true，不存在返回false。但是实际测试发现，已存在的用户也会返回false。具体错误为，使用username_exists来验证用户是否存在是错误的表现，该方法是检测用户名是否存在，而不是UID。正确的处理是通过get_userdata来判断用户是否存在，如果存在则加入缓存。并返回true。
10、解决通过xc_verify_update_hook方法进行认证时，接口返回【认证失败：后台未配置对应的场景】的错误问题。实际上，这种错误的根源在于xc_is_config方法，即使场景已经配置，系统仍旧无法识别到。具体原因是，当传递的key是整数时，遍历查询process会检测字符串，因此整数形式的key无法通过检测，从而导致场景无法正确返回。这是一个隐形BUG。现在已经修复了这个问题，通过在检查执行过程中，将传递的参数强制转换为字符串类型，保证能够识别并正确处理不同类型的参数。
11、服务端已完成鉴定师审批的全部流程出来，整个执行流程如下。1、用户安全验证：（检测用户是否登录、环境是否安全、是否有权限执行操作）。2、参数效验检测（检测必须参数是否传递、是否存在非法字符、是否长度符合要求、字段是否符合要求）3、数据表相关检测（检测申请记录是否存在、申请记录状态是否待审核）4、封装并提交sql（完成一系列基础检测后，会通过xc_update_sql执行sql更新动作）这个更新动作涉及到子数组对象的二次封装。5、缓存清理动作：将对应的缓存关联清理，确保缓存不会影响正确结果。6、图片收录：通过xc_upload_media_ok钩子执行图片处理，避免本次提交的图片因为过期被删除。7、认证标识处理：通过xc_verify_update_hook钩子执行鉴定师认证处理逻辑。8、执行xc_notify_hook通知，通知申请用户入驻成功。9、触发xc_agree_identify_expert_ok_hook回调钩子，后续业务操作通过这里处理。10、集成动作回调事件，第三方业务可以通过注册函数来接收回调信息。
12、新增前端回调处理钩子：xc_hook_agree_identify_expert_ok(agree)。该钩子将在鉴定师入驻成功时触发，即审核员通过鉴定师入驻请求且服务端完成所有业务处理并返回code=0的情况下。触发后，钩子将负责页面清理和进一步的交互操作。为方便业务元素的操作与锁定，该钩子将继承来自上级方法的agree对象信息，内含所有提交审核的关联字段，包括ID
13、同意鉴定师入驻请求后，菜单按钮将增加一个子类：agree_identify_expert。当服务端返回处理成功时，通过这个元素锁定按钮位置，并执行以下操作：首先，移除菜单按钮的onclick事件，防止用户二次点击或重复提交；其次，将按钮文字更改为“鉴定师已入驻成功”，以通知审核员该操作已完成；最后，将菜单按钮的背景颜色更改为浅黑色，使其高亮提醒审核员注意操作的成功执行。值得注意的是，这些交互行为全部通过xc_hook_agree_identify_expert_ok钩子进行处理。

2024年8月28日
1、在全局push通知配置中，新增了一个名为【update_verify】的通知场景，该场景将在账户类型认证成功或更新时触发具体通知。具体而言，当通过xc_verify_update_hook成功变更账户认证状态时，将自动触发该通知场景，主要目的是告知用户其账户已成功完成认证。目前，该通知场景支持两种push消息形式：【APP消息通知】和【站内信服务号通知】。其中，站内信服务号的发送者设定为系统助理（system），消息类型则设定为系统类型通知。
2、认证状态变更成功后，将触发名为xc_notify_hook的消息通知，其通知场景为【update_verify】。由于通知操作是异步下发的，为确保信息的准确性，会同步传递一个名为push_data的数组结构。该结构包含以下内容：（verify_info：认证的描述文字信息，此项不可为空；key：认证的类型标识；ip：操作者的IP地址；ua：操作者的客户端信息；fingerprint：当前设备的指纹信息）。
3、xc_notify_hook 通知钩子已实现账户类型认证成功的提示。当收到通知下发请求时，系统会提取 $push_data['key']，并通过 xc_is_config 来获取对应的认证场景名称。统一的通知标题为：🇻 账户认证通知。统一的通知正文为：您的账户已完成认证，认证类型为： . $is_config['name']。无论是应用服务号还是站内弹窗消息，都会使用这两个变量来构建通知的标题和正文。服务号菜单消息具体内容为：认证类型： . $is_config['name']、认证时间： . date("Y-m-d H:i")、认证描述： . $verify_info。
4、在完成所有业务逻辑处理（包括通知下发）后，xc_verify_update_hook钩子将返回一个包含code=0和msg=认证成功！的结果。同时，为了确保第三方业务能够顺利接收到回调通知，系统内置了xc_do_action动作钩子。如果函数在返回结果时需要调用钩子，可以通过add_action函数来注册相应的钩子，系统会自动将处理结果和传递参数传递给注册函数，实现自动事件接管。
5、至此，宫论账户类型认证钩子的封装工作已经完成。如果需要对用户进行账户认证或者进行账户信息变更，只需执行xc_verify_update_hook方法即可。该方法会通过标准钩子机制来执行相应的业务钩子，确保在认证状态发生变动时，平台能够进行全局监听，并自动更新相应的事件。值得注意的是，所有涉及账户认证的操作都必须通过新版方法来执行。另外，还需密切关注并监听返回的状态码，以确保操作的执行结果是可靠的。
6、工作人员在审批【鉴定师入驻请求】时，如果提交的资料经过核验无误，并且账户操作合规，将在执行SQL语句后，触发认证标识处理。这时会给予用户一个认证状态【鉴定师认证：5】，并通过审核员提交的参数info来显示相关的认证标识文字。当鉴定师入驻成功后，用户会获得一个专门的加V效果，以便于其他用户能够清晰地区分鉴定师的身份。此外，需要特别注意的是，如果用户的鉴定师资质被封禁或者进入禁用状态，也必须同步移除其认证标记，确保系统中的认证状态始终保持准确和有效。
7、在全局推送通知配置中，新增了一个名为【agree_identify_expert_apply】的通知场景（即【鉴定师入驻】平台通过用户入驻请求）。当用户申请成为鉴定师后，平台会对其提交的资料进行审核，并在最终批准其入驻请求时发送该通知。此消息场景非常重要，因此所有的通知接口都将对此消息场景开放，包括【短信通知、APP通知、站内信、邮件通知、服务号通知、公众号通知】在内的六个场景都会配置好相应的渠道，以确保用户能百分之百收到审核通过的通知。
8、delete_identify_expert_apply：【鉴定师入驻】平台拒绝用户入驻通知场景，增加短信通知：短信ID：1298140。短信模版：您提交的鉴定师认证，审核结果为： {1}。短消息每日上限为三条。当审核员拒绝用户入驻请求时，会通过 xc_notify_hook 钩子发送相应的消息给申请用户。需要注意的是，这里的短信通知是发送到用户绑定的平台手机号，如果用户提交了新的联系方式，新的号码不会收到这条短信。完整的短信通知内容为：“您提交的鉴定师认证，审核结果为：入驻请求被驳回，详情请通过站内信查阅。”
9、审核员同意用户入驻成为平台鉴定师后，会通过xc_notify_hook下发消息通知给申请用户。通知的标识为：agree_identify_expert_apply。因为通知大概率是通过异步执行的，为了确保信息给准确传递过去，会通过push_data传递以下内容。1、agree：前端提交的参数信息，包括申请表ID、鉴定费用、认证描述、个人资料介绍、授权书图片、公开图片等内容。2、user_id：审核员的UID，需要注意不是申请人。3、审核员的IP、UA、和指纹信息。
10、鉴定师入驻成功通知已完成基础配置：1、通用标题：鉴定师申请通过。通用正文：恭喜您，已成为平台认证鉴定师。2、邮件标题：鉴定师入驻审核结果。邮件正文：您的鉴定师入住申请通过，你已成为平台认证鉴定师。3、公众号消息模版，第一栏：鉴定师入驻-通过。第二栏：你已成为平台认证鉴定师。4、服务号站内信：title：鉴定师入驻审核。message：您的鉴定师入住申请通过，你已成为平台认证鉴定师。first：鉴定师入驻审核。keyword1：审核结果：通过。keyword2：审核时间：' . date("Y-m-d H:i")。
11、通知优化处理：在push_data中会额外传递一个字段【cat_name：申请入驻的藏品类目，通过is_config方法提取】。每次通知消息下发时，该字段会明确标记申请的栏目。示例，旧文字：“恭喜您，已成为平台认证鉴定师。” 新文字：“您的鉴定师入驻申请已通过，您已成为平台认证（玉器）鉴定师。” 同时，在通知栏中新增一个短信提醒功能，短信模板继续使用1298140。当审批通过时，将会触发以下短信提醒【您提交的鉴定师认证已通过审核，您已成为平台认证( ' . $cat_name . ')鉴定师。】
12、服务端新增了一个回调钩子：xc_agree_identify_expert_ok_hook($agree)，当用户成功成为平台栏目鉴定师时，将会触发此回调钩子。触发时会携带一个名为【agree】的数组，该数组包含了申请材料的详细信息，包括但不限于认证信息、材料图片、申请信息等。通过这个数组变量，可以获取到本次申请的所有材料信息。这个回调钩子是一个预留事件，服务端在用户完成鉴定师入驻申请后，可以通过此回调钩子执行其他业务逻辑。
13、当服务端完成鉴定师入驻审批的处理流程后（确保所有相关业务操作均已执行完毕），将会返回code=0及消息"已同意鉴定师入驻请求"。此时，服务端的处理工作已经圆满结束，申请的用户将正式成为平台认证的鉴定师，并可以根据设定接受指定类目的藏品鉴定请求。鉴于入驻鉴定师的操作具有高度的重要性与核心地位，为了进一步确保业务流程的稳健性，增加了一个名为xc_do_action的回调动作，使得其他业务模块能够通过注册外部方法来接收到入驻成功的结果。

最低多少钱？最低多少钱？

测试看看最低多少钱？

内容测试出