Dealer data authority management method, business system, electronic equipment and medium

Abstract

The invention discloses a dealer data authority management method, a business system, electronic equipment and a medium, and relates to the technical field of information management, and the method comprises the steps: receiving a data access request initiated by a dealer user, and determining a dealer organization identifier bound with the dealer user according to a set relation mapping table; the dealer organization identifier represents a unique organization identifier allocated to each dealer in a unified business system; querying a vehicle identifier bound with the dealer organization identifier in the set relation mapping table based on the dealer organization identifier; and based on the vehicle identifier, dynamically filtering and displaying the vehicle business data allowed to be accessed by the dealer user. By adopting the method, vehicle data-based authority isolation can be realized in a unified service system, and the data management cost is reduced.

Description

Technical Field

[0001] The present invention relates to the field of information management technology, and in particular to a dealer data authority management method, business system, electronic equipment and medium. Background Art

[0002] As automakers' digital management capabilities continue to improve, more and more business systems are being opened up to dealers for online, platform-based management of business processes such as sales, inventory, and transfers. In this context, dealer users need to access relevant vehicle data, such as inventory and status information corresponding to the Vehicle Identification Number (VIN), through a unified business system to support daily business operations. However, since OEMs typically serve a large number of dealers, effectively controlling the scope of data each dealer can access in the system, ensuring that dealer A cannot view dealer B's vehicle data, has become a key issue that must be addressed in business system design.

[0003] A commonly adopted solution in related technologies is to deploy a separate business system or configure a separate database instance for each dealer. Through physical isolation, each dealer's data exists only in its own dedicated system or database, ensuring that data cannot be accessed by other dealers from the moment the system is deployed. This approach provides a high level of data isolation and improved security, effectively preventing the risk of data leakage across dealerships. In practice, automobile manufacturers typically only import brand, business, and vehicle data related to a particular dealer into its corresponding system. The systems used by each dealer are independent of each other, forming a data access structure with the dealer as the smallest unit.

[0004] While the aforementioned approach performs well in terms of data security, it suffers from significant deficiencies in system deployment and operations. On the one hand, as the number of dealerships connected to automakers continues to grow, deploying a separate system or database for each dealership will result in a significant waste of system resources, increasing deployment costs and complicating and inefficient subsequent operations and maintenance tasks such as version updates, data synchronization, and troubleshooting. On the other hand, running multiple systems in parallel hinders automakers' centralized management of their entire dealer network, lacking unified data management and permission control mechanisms. Traditional deployment models struggle to meet increasingly complex business needs, especially in scenarios requiring cross-organizational analysis or resource scheduling.

[0005] To sum up, while relevant technologies ensure data isolation between dealers, they also have problems such as high deployment costs, complex operation and maintenance, and low system utilization, making it difficult to adapt to the development trend of unified platform management of multiple dealers by automobile manufacturers. Summary of the Invention

[0006] The present invention aims to at least partially address one of the technical problems in the related art. To this end, the present invention provides a dealer data rights management method, business system, electronic device, and medium to implement vehicle data rights isolation within a unified business system, thereby reducing system deployment costs and improving data management efficiency.

[0007] To achieve the above objectives, a first embodiment of the present invention provides a dealer data rights management method, comprising:

[0008] Receive a data access request initiated by a dealer user, and determine the dealer organization identifier bound to the dealer user based on a set relationship mapping table; the dealer organization identifier represents a unique organization identifier assigned to each dealer in a unified business system;

[0009] Based on the dealer organization identifier, searching the setting relationship mapping table for a vehicle identifier bound to the dealer organization identifier;

[0010] Based on the vehicle identifier, the vehicle business data that the dealer user is allowed to access is dynamically filtered and displayed.

[0011] In addition, the dealer data rights management method of the above embodiment of the present invention may also have the following additional technical features:

[0012] According to an embodiment of the present invention, the relationship mapping table includes: a mapping relationship between a dealer user account and a dealer organization identifier, and a mapping relationship between a vehicle identifier and a dealer organization identifier.

[0013] According to an embodiment of the present invention, the mapping relationship between the vehicle identifier and the dealer organization identifier supports a one-to-one or one-to-many mapping configuration.

[0014] According to one embodiment of the present invention, the process of constructing the relationship mapping table includes:

[0015] A vehicle identifier list is obtained, and a mapping relationship is established between at least one vehicle identifier in the vehicle identifier list and a target dealer organization identifier.

[0016] According to one embodiment of the present invention, the method further includes:

[0017] The mapping relationship between the vehicle identifier and the target dealer organization identifier is dynamically adjusted according to the vehicle life cycle status.

[0018] According to one embodiment of the present invention, the method further includes:

[0019] receiving a data operation request initiated by the dealer user for the vehicle business data that is allowed to be accessed;

[0020] Determining the data operation authority of the dealer user based on the dealer organization identifier bound to the dealer user;

[0021] According to the data operation permission, it is determined whether the data operation request is allowed to be executed.

[0022] According to one embodiment of the present invention, the dealer organization identifier includes hierarchical structure information, and querying the vehicle identifier bound to the dealer organization identifier in the set relationship mapping table based on the dealer organization identifier includes:

[0023] Determine the hierarchical information of the dealer organization identifier to which the dealer user belongs in the organizational hierarchy;

[0024] Based on the hierarchical information, the vehicle identifier bound to the dealer organization identifier and the lower-level dealer organization identifier is searched in the relationship mapping table.

[0025] To achieve the above objectives, a second embodiment of the present invention provides a business system, including:

[0026] A request receiving module is used to receive data access requests initiated by dealer users;

[0027] An account management module, configured to determine the dealer organization identifier bound to the dealer user according to a set relationship mapping table; the dealer organization identifier represents a unique organization identifier assigned to each dealer in a unified business system;

[0028] A vehicle resource management module, configured to query the vehicle identifier bound to the dealer organization identifier in the set relationship mapping table based on the dealer organization identifier;

[0029] The data permission control module is used to dynamically filter and display the vehicle business data that the dealer user is allowed to access based on the vehicle identifier.

[0030] To achieve the above objectives, a third embodiment of the present invention provides an electronic device including a memory and a processor, wherein the memory stores a computer program, and the processor implements the steps of the above dealer data authority management method when executing the computer program.

[0031] To achieve the above-mentioned objectives, a fourth embodiment of the present invention provides a computer-readable storage medium having a computer program stored thereon, which implements the steps of the above-mentioned dealer data rights management method when the computer program is executed.

[0032] The dealer data rights management method, business system, electronic device, and media of the present invention utilize the binding relationship between dealer users and dealer organization identifiers, combined with a relationship mapping table that maps vehicle identifiers to organization identifiers. This allows for dynamic filtering and control of dealer data access rights within a unified business system, ensuring that dealer users can access only the vehicle business data corresponding to their organization, thus avoiding the risks of cross-organizational data access. This method eliminates the need to deploy a separate system or database for each dealer, effectively reducing system deployment and maintenance costs, while improving the flexibility of data isolation and the efficiency of system resource utilization. BRIEF DESCRIPTION OF THE DRAWINGS

[0033] Figure 1 A flowchart of a dealer data rights management method according to an embodiment;

[0034] Figure 2 A schematic diagram of a process for managing data operation rights in one embodiment;

[0035] Figure 3 A schematic diagram of a process for querying a vehicle identifier in one embodiment;

[0036] Figure 4 This is a structural diagram of a business system under implementation. DETAILED DESCRIPTION

[0037] In order to make the purpose, technical solutions and advantages of this application more clear, the following further describes this application in detail with reference to the accompanying drawings and embodiments. It should be understood that the specific embodiments described herein are only used to explain this application and are not intended to limit this application.

[0038] The following describes in detail the implementation details of the technical solutions of the embodiments of the present application.

[0039] In one embodiment, Figure 1 As shown, a flow chart of a dealer data rights management method is provided, which may include the following steps:

[0040] Step S101: receiving a data access request initiated by a dealer user, and determining the dealer organization identifier bound to the dealer user according to a set relationship mapping table.

[0041] During operation, the OEM's uniformly deployed business system receives various data access requests from dealer users, including but not limited to clicking on system menus, loading business pages, and calling interfaces. Each access request typically carries the account information of the currently logged-in user, through which the system can identify the identity of the user initiating the request. A dealer user is an end user who has registered and assigned permissions in the OEM's uniform business system and represents a staff member of a specific dealer unit, such as a sales consultant, vehicle manager, or after-sales service personnel. Such users possess legitimate system access credentials and permissions, and can perform data operations related to their dealership within the system.

[0042] To ensure data access isolation between different dealers within the same business system, this implementation utilizes a dealer organization ID mechanism to define data permission boundaries. During dealer user account creation or permission configuration, the system binds each dealer user account to its assigned dealer organization ID. This dealer organization ID is a logical identifier that uniquely identifies a dealer unit within the system. It can be a string, numeric code, or other form, and is used to logically distinguish data access boundaries between different dealer organizations within the platform.

[0043] Upon receiving a data access request from a dealer user, the business system performs identity resolution based on the dealer user's current login account information and queries a pre-set relationship mapping table to determine the dealer organization ID corresponding to the dealer account. In practice, this relationship mapping table can be stored in a database's permission control table or loaded into a system cache to improve query efficiency. This resolution process enables the business system to quickly identify the dealer organization unit corresponding to the current dealer user based on the dealer user's affiliation.

[0044] Step S102: Based on the dealer organization identifier, a vehicle identifier bound to the dealer organization identifier is searched in a set relationship mapping table.

[0045] Based on the parsed dealer organization ID, the business system searches a pre-set relationship mapping table for the set of vehicle identifiers corresponding to that dealer organization ID. Vehicle identifiers uniquely identify vehicle resources, specifically the Vehicle Identification Number (VIN). This code is a globally unique number associated with each vehicle and serves as the primary key field for vehicle data in the system, clarifying ownership of vehicle data and defining the data boundaries accessible to each dealer organization.

[0046] In practical applications, a relationship mapping table records the correspondence between each dealer organization ID and vehicle identifier. This relationship mapping table can be used as a logical authorization control table in the database. To improve query efficiency, an index structure based on dealer organization ID can be established on the relationship mapping table, allowing dealer users to efficiently complete vehicle identifier queries when access requests arrive.

[0047] During the query process, a database query condition is constructed based on the dealer user's organizational ID. By executing the search statement, all vehicle identifiers matching the dealer's organizational ID are retrieved from the relationship mapping table. The obtained vehicle identifier set can be cached in memory as a list, array, or other data structure.

[0048] In one embodiment, the relationship mapping table is used to carry key mapping information required for dealer data authority control in the system, wherein the relationship mapping table includes at least the following two types of mapping relationships:

[0049] (1) Mapping information between dealer user accounts and dealer organization identifiers. This mapping relationship is used to associate dealer users in the business system with their respective organizations. Each dealer user account has a unique identifier in the system, and this field can be used to accurately locate the dealer organization to which it belongs. When a user logs in or initiates a data access request, the system can determine the user's organizational affiliation based on this mapping relationship.

[0050] (2) The relationship between the vehicle identifier and the dealer organization. This mapping relationship is used to clarify the organizational ownership of vehicle resources. Each vehicle identifier (such as the vehicle identification number (VIN)) uniquely corresponds to a vehicle in the system. Through this mapping relationship, a binding relationship can be established between the vehicle and the corresponding dealer organization, which serves as the basis for subsequent data filtering and permission judgment.

[0051] In actual applications, the relationship mapping table can exist in the system database as a logical authorization table. The table structure includes at least three key fields, corresponding to the dealer user account, dealer organization ID, and vehicle identifier. The fields are logically associated through preset business rules, enabling the business system to quickly determine dealer permissions and filter and control vehicle data through single or joint table query operations.

[0052] In one embodiment, the relationship mapping table for recording vehicle ownership relationships in the business system supports flexible configuration, allowing a one-to-one or one-to-many mapping relationship to be established between vehicle identifiers and dealer organization identifiers.

[0053] Specifically, in a one-to-one configuration scenario, each vehicle identifier corresponds only to a unique dealer organization identifier, which is used to clarify the unique ownership of vehicle resources, thereby ensuring absolute isolation of data permissions. This is suitable for business needs where vehicle resources are clearly allocated to a single dealer for management. In a one-to-many configuration scenario, multiple vehicle identifiers can be simultaneously associated with the same dealer organization identifier, which is used to indicate that the dealer organization uniformly manages multiple vehicle resources under its name.

[0054] By supporting the above-mentioned multiple mapping modes, the business system has good scalability and adaptability in data permission configuration, and can meet the differentiated needs of different types of dealer organizations in vehicle resource division and management strategies, thereby maintaining the security boundaries of permissions while improving the flexibility and business adaptability of the permission management mechanism.

[0055] In one embodiment, the process of constructing a relationship mapping table by the business system includes obtaining a list of vehicle identifiers and establishing a mapping relationship between at least one vehicle identifier in the list and a target dealer organization identifier. Specifically, the business system first obtains a set of vehicle identifiers to be allocated. The vehicle identifier is typically a vehicle identification number (VIN), which uniquely identifies each vehicle. Subsequently, based on business needs, at least one of the obtained vehicle identifiers is bound to the target dealer organization identifier, and the mapping relationship between the vehicle identifier and the dealer organization identifier is recorded in the relationship mapping table, thereby establishing a logical association between vehicle resources and dealer organizations. This mapping relationship can be established through an insert or update operation in the database, and the system permission control logic is simultaneously updated so that the bound vehicle identifier is accurately reflected within the data access scope of the dealer organization. Through this binding process, the business system effectively binds the vehicle identifier to the dealer organization identifier, providing a foundation for subsequent data permission management and ensuring that dealer users can only access the business data corresponding to the bound vehicle.

[0056] In one embodiment, the business system dynamically adjusts the mapping relationship between the vehicle identifier and the target dealer organization identifier according to the life cycle status of the vehicle.

[0057] The lifecycle status of a vehicle changes continuously as business processes progress, including production completion, sale to dealers, transfers between dealers, recycling, and scrapping. These status changes directly impact vehicle ownership and management responsibilities. Therefore, the mapping between vehicle identifiers and target dealer organization identifiers needs to be dynamically adjusted to ensure the accuracy and timeliness of data permissions.

[0058] The business system monitors and obtains information on changes in the vehicle's life cycle status in real time. When the vehicle's status changes, it automatically triggers the corresponding mapping relationship update mechanism. Specifically, when a vehicle is just produced, it may not yet be bound to any dealer organization. As the vehicle sales process progresses, the vehicle identifier needs to be mapped to the sales dealer's organizational identifier so that the dealer can access the corresponding vehicle's data. If the vehicle is allocated to other dealers in subsequent business, the system needs to update the mapping relationship in a timely manner, unbinding the vehicle identifier from the original dealer organization identifier and rebinding it to the new dealer organization identifier to prevent the original dealer from continuing to access vehicle data that is no longer under its jurisdiction. When a vehicle enters the recycling or scrapping stage, the corresponding mapping relationship also needs to be adjusted or cleared to avoid invalid or erroneous data access.

[0059] Based on this, the business system promptly modifies the binding between the vehicle identifier and the dealer organization ID in the relationship mapping table, enabling dynamic adjustment of vehicle data access permissions. This dynamic adjustment of the mapping ensures that dealer organizations' access to vehicle data remains synchronized with the actual ownership of the vehicle, preventing data permission lags or confusion, thereby effectively maintaining the accuracy and security of platform data. This mechanism also enhances the automation and flexibility of data permission management, meeting the diverse and dynamic needs of vehicle business processes.

[0060] Step S103 : Based on the vehicle identifier, dynamically filter and display the vehicle business data that the dealer user is allowed to access.

[0061] Based on the acquired vehicle identifier set, the business system uses the vehicle identifier set as the data access boundary for the current dealer user and embeds the determined vehicle identifier as a filtering condition into the back-end data query logic, thereby limiting dealer users to access only vehicle data that matches their dealer organization identifier.

[0062] After completing data filtering, the business system returns the filtered query results to the front-end page for dealer users to review or process. The vehicle business data displayed on the page is limited to the data corresponding to the vehicles included in the vehicle identifier set. This allows dealer users to control the visibility of their vehicle data, prevent them from accessing unauthorized dealer data, and ensure data isolation and permission security.

[0063] In practical applications, to improve data processing efficiency, the vehicle identifier set can be cached in the user session context after the user logs in and reused throughout the access cycle to avoid the performance overhead caused by repeated queries of the relationship mapping table.

[0064] It should be noted that this filtering logic can be uniformly implemented at the business interface layer or the database access layer. Users do not need to explicitly select any filtering items. Instead, the system automatically completes the filtering based on the user's identity, ensuring that when different dealer users access the same function page, the data results they receive are always limited to their authority scope, thereby ensuring the minimum granularity isolation of data access.

[0065] Through the above-mentioned filtering mechanism, the system realizes dynamic control of data permissions of multiple dealer users under a unified platform architecture, effectively avoiding cross-organizational data access problems and improving the platform's data security and business management efficiency.

[0066] In one embodiment, Figure 2 The following is a flow chart showing the management of data operation rights, which may include the following steps:

[0067] Step S201: receiving a data operation request initiated by a dealer user for vehicle business data that is allowed to be accessed.

[0068] The business system receives data operation requests from dealer users for vehicle business data they are permitted to access. These requests include, but are not limited to, querying, modifying, deleting, or adding new data. Dealer users submit data operation requests through the business system's functional interfaces, API calls, or other interactive methods. The system receives and processes these requests based on the user's identity and the content of the request.

[0069] In practice, the business system first performs a preliminary verification of the legitimacy of the request, ensuring that the request originates from a legitimate user who has logged in and successfully authenticated, and that the request content format complies with specifications. The system then fully records the relevant information about the operation request, providing a data foundation for subsequent permission verification and auditing. This process ensures that all operations originate from legitimately authorized dealer users and that the operations are performed on objects within their authorized scope.

[0070] Step S202: determining the data operation authority of the dealer user based on the dealer organization identifier bound to the dealer user.

[0071] The business system determines the data operation permissions that a user has for the target vehicle business data in the current business scenario based on the unique dealer organization identifier bound to the dealer user, combined with pre-set permission configuration rules. In specific implementation, the permission rule library in the system's access permission management module queries the corresponding permission policy to obtain the type and scope of operations that dealer users are allowed to perform in specific business scenarios, including but not limited to permissions to view, edit, delete, or add new data. Permission configuration is usually refined based on factors such as the user's job responsibilities, organizational hierarchy, and historical behavior. For example, some users may only have viewing permissions, while other users are allowed to perform data editing or management operations. This data operation permission determination ensures the compliance and security of data operations.

[0072] Step S203: judging whether the data operation request is allowed to be executed according to the data operation authority.

[0073] After the business system obtains the dealer user's data operation permissions, it determines whether to allow the data operation request initiated by the current dealer user to be executed based on the dealer user's data operation permissions.

[0074] If the operation type requested by the dealer user is within the scope of his or her authority, the business system will authorize the data operation and feedback the operation results to the dealer user; if the dealer user's operation authority is insufficient to perform the requested operation, the business system will reject the operation request and promptly display the corresponding insufficient authority prompt to the dealer user to guide the dealer user to understand the reason for the restriction.

[0075] In actual applications, the permission determination process is usually implemented uniformly at the business logic layer or data access layer to ensure that the permission control mechanism of the entire system is strict and reliable. At the same time, in conjunction with the logging function, full monitoring and auditing of the operation process can be achieved to ensure data security and compliance management.

[0076] In one embodiment, Figure 3 A flowchart for querying a vehicle identifier is shown, which may include the following steps:

[0077] Step S301: Determine the hierarchical information of the dealer organization identifier to which the dealer user belongs in the organizational hierarchy.

[0078] The business system first identifies and determines the specific hierarchical position of the dealer organization ID associated with the dealer user within the dealer organizational hierarchy. The dealer organization ID is not only a unique identifier but also contains hierarchical structure information, reflecting the dealer's affiliation and hierarchical relationships within the organizational system. This hierarchy can be represented as a tree or multi-branch structure, with each node representing a dealer organizational unit. The system retrieves the organizational hierarchy data stored in the organization management module to obtain the hierarchical information of the current dealer organization ID, including a list of parent organizations, peer organizations, and subordinate organizations.

[0079] Step S302 : Based on the hierarchical information, the relationship mapping table is searched for the vehicle identifier bound to the dealer organization identifier and the lower-level dealer organization identifier.

[0080] Based on the acquired hierarchical information, the business system further performs query operations in the relationship mapping table. This query not only retrieves the vehicle identifiers directly bound to the current dealer organization ID, but also includes the vehicle identifiers bound to the dealer organization IDs of all subordinate levels of the current dealer organization ID, thereby forming a complete set of identifiers that includes the vehicles of the target organization and its subordinate organizations. In specific implementation, the business system constructs query conditions that include the current organization ID and all its subordinate organization IDs, and performs multi-condition searches on the relationship mapping table. In this way, the business system can support multi-level data access control, allowing dealer users to access the vehicle data of their organization and its subordinate organizations, meeting complex business management needs. At the same time, to ensure query efficiency, the business system can establish corresponding index structures for the relationship mapping table and organizational hierarchy data to optimize the performance of multi-level joint queries.

[0081] In the above-described embodiment, the dealer data permissions management method receives data access requests from dealer users, accurately determines the dealer organization identifier associated with the user based on a pre-defined relationship mapping table, and further queries the vehicle identifier corresponding to that organization identifier, thereby achieving precise binding and permission division for vehicle data. Dynamic filtering and display of vehicle business data based on vehicle identifiers ensures that dealer users can only access vehicle information within their authorized scope, effectively preventing cross-organizational data access risks. This method not only enhances the security and isolation of data access, but also improves the data management efficiency and flexibility of business systems. It meets the need for fine-grained control of data permissions in multi-organization, multi-user scenarios, and promotes the rational utilization and standardized management of dealer resources within a unified platform.

[0082] In one embodiment, a business system is provided, referring to Figure 4As shown, the business system 400 may include: a request receiving module 401, an account management module 402, a vehicle resource management module 403, a data authority control module 404 and a mapping table management module 405.

[0083] Request receiving module 401, for receiving a data access request initiated by a dealer user;

[0084] The account management module 402 is used to determine the dealer organization identifier bound to the dealer user according to the set relationship mapping table; the dealer organization identifier represents the unique organization identifier assigned to each dealer in the unified business system;

[0085] The vehicle resource management module 403 is used to query the vehicle identifier bound to the dealer organization identifier in the set relationship mapping table based on the dealer organization identifier;

[0086] The data permission control module 404 is used to dynamically filter and display the vehicle business data that the dealer user is allowed to access based on the vehicle identifier.

[0087] In one embodiment, the relationship mapping table includes: a mapping relationship between a dealer user account and a dealer organization identifier, and a mapping relationship between a vehicle identifier and a dealer organization identifier.

[0088] In one embodiment, the mapping relationship between the vehicle identifier and the dealer organization identifier supports a one-to-one or one-to-many mapping configuration.

[0089] In one embodiment, the business system 400 further includes a mapping table management module 405 for acquiring a vehicle identifier list and establishing a mapping relationship between at least one vehicle identifier in the vehicle identifier list and a target dealer organization identifier.

[0090] In one embodiment, the mapping table management module 405 is further configured to dynamically adjust the mapping relationship between the vehicle identifier and the target dealer organization identifier according to the vehicle life cycle status.

[0091] In one embodiment, the data permission control module 404 is further configured to receive a data operation request initiated by a dealer user for vehicle business data that is allowed to be accessed; determine the data operation permission of the dealer user based on the dealer organization identifier bound to the dealer user; and determine whether to allow the data operation request to be executed based on the data operation permission.

[0092] In one embodiment, the dealer organization identifier includes hierarchical structure information. The vehicle resource management module 403 is specifically used to determine the hierarchical information of the dealer organization identifier to which the dealer user belongs in the organizational hierarchy; based on the hierarchical information, query the vehicle identifier bound to the dealer organization identifier and the subordinate dealer organization identifier in the relationship mapping table.

[0093] The specific definition of business system 400 can be found in the definition of the dealer data rights management method above and will not be repeated here. Each module in business system 400 can be implemented in whole or in part through software, hardware, or a combination thereof. Each module can be embedded in or independent of a processor in a computer device in hardware form, or stored in a computer device memory in software form, so that the processor can call and execute the corresponding operations of each module.

[0094] In one embodiment, an electronic device is provided, including a memory and a processor. The memory stores a computer program, and the processor implements a dealer data authority management method when executing the computer program.

[0095] In one embodiment, a computer storage medium is provided, on which a computer program is stored. When the computer program is executed by a processor, a dealer data rights management method is implemented.

[0096] It should be noted that the logic and / or steps represented in the flowcharts or otherwise described herein, for example, can be considered as a sequenced list of executable instructions for implementing the logical functions, and can be embodied in any computer-readable medium for use by an instruction execution system, apparatus, or device (such as a computer-based system, a system including a processor, or other system that can fetch and execute instructions from an instruction execution system, apparatus, or device), or in conjunction with such instruction execution system, apparatus, or device. For the purposes of this specification, a "computer-readable medium" can be any device that can contain, store, communicate, propagate, or transmit a program for use by an instruction execution system, apparatus, or device, or in conjunction with such instruction execution system, apparatus, or device. More specific examples (non-exhaustive list) of computer-readable media include the following: an electrical connection portion having one or more wires (electronic device), a portable computer disk cartridge (magnetic device), random access memory (RAM), read-only memory (ROM), erasable and programmable read-only memory (EPROM or flash memory), fiber optic devices, and portable compact disc read-only memory (CDROM). Furthermore, the computer-readable medium may even be paper or other suitable medium on which the program is printed, since the program may be obtained electronically, for example, by optically scanning the paper or other medium and then editing, interpreting or processing it in another suitable manner if necessary, and then storing it in a computer memory.

[0097] It should be understood that various parts of the present invention can be implemented using hardware, software, firmware, or a combination thereof. In the above-described embodiments, multiple steps or methods can be implemented using software or firmware stored in a memory and executed by a suitable instruction execution system. For example, if implemented using hardware, as in another embodiment, any one of the following technologies known in the art or a combination thereof can be used: a discrete logic circuit having a logic gate circuit for implementing a logic function on a data signal, an application-specific integrated circuit having a suitable combination of logic gate circuits, a programmable gate array (PGA), a field programmable gate array (FPGA), etc.

[0098] Throughout this specification, reference to terms such as "one embodiment," "some embodiments," "examples," "specific examples," or "some examples" means that a specific feature, structure, material, or characteristic described in conjunction with that embodiment or example is included in at least one embodiment or example of the present invention. In this specification, schematic representations of the above terms do not necessarily refer to the same embodiment or example. Furthermore, the specific features, structures, materials, or characteristics described may be combined in any suitable manner in any one or more embodiments or examples.

[0099] Furthermore, the terms "first" and "second" are used for descriptive purposes only and should not be construed as indicating or implying relative importance or implicitly specifying the number of the technical features being referred to. Thus, a feature defined as "first" or "second" may explicitly or implicitly include at least one such feature. In the description of the present invention, "plurality" means at least two, such as two, three, etc., unless otherwise specifically defined.

[0100] Although the embodiments of the present invention have been shown and described above, it will be understood that the above embodiments are illustrative and are not to be construed as limitations on the present invention. A person skilled in the art may change, modify, replace and modify the above embodiments within the scope of the present invention.

Claims

1. A dealer data rights management method, characterized in that: include: Receive a data access request initiated by a dealer user, and determine the dealer organization identifier bound to the dealer user according to a set relationship mapping table; The dealer organization identifier represents a unique organization identifier assigned to each dealer in a unified business system; Based on the dealer organization identifier, searching the setting relationship mapping table for a vehicle identifier bound to the dealer organization identifier; Based on the vehicle identifier, the vehicle business data that the dealer user is allowed to access is dynamically filtered and displayed.

2. The dealer data rights management method according to claim 1, characterized in that: The relationship mapping table includes: a mapping relationship between a dealer user account and a dealer organization identifier, and a mapping relationship between a vehicle identifier and a dealer organization identifier.

3. The dealer data rights management method according to claim 2, characterized in that: The mapping relationship between the vehicle identifier and the dealer organization identifier supports a one-to-one or one-to-many mapping configuration.

4. The dealer data rights management method according to claim 1, characterized in that: The process of constructing the relationship mapping table includes: A vehicle identifier list is obtained, and a mapping relationship is established between at least one vehicle identifier in the vehicle identifier list and a target dealer organization identifier.

5. The dealer data authority management method according to claim 4, characterized in that: The method further comprises: The mapping relationship between the vehicle identifier and the target dealer organization identifier is dynamically adjusted according to the vehicle life cycle status.

6. The dealer data authority management method according to claim 1, characterized in that: The method further comprises: receiving a data operation request initiated by the dealer user for the vehicle business data that is allowed to be accessed; Determining the data operation authority of the dealer user based on the dealer organization identifier bound to the dealer user; According to the data operation permission, it is determined whether the data operation request is allowed to be executed.

7. The dealer data rights management method according to claim 1, characterized in that: The dealer organization identifier includes hierarchical structure information, and searching the set relationship mapping table for a vehicle identifier bound to the dealer organization identifier based on the dealer organization identifier includes: Determine the hierarchical information of the dealer organization identifier to which the dealer user belongs in the organizational hierarchy; Based on the hierarchical information, the vehicle identifier bound to the dealer organization identifier and the lower-level dealer organization identifier is searched in the relationship mapping table.

8. A business system, characterized in that: include: A request receiving module is used to receive data access requests initiated by dealer users; An account management module, configured to determine the dealer organization identifier bound to the dealer user according to a set relationship mapping table; The dealer organization identifier represents a unique organization identifier assigned to each dealer in a unified business system; A vehicle resource management module, configured to query the vehicle identifier bound to the dealer organization identifier in the set relationship mapping table based on the dealer organization identifier; The data permission control module is used to dynamically filter and display the vehicle business data that the dealer user is allowed to access based on the vehicle identifier.

9. An electronic device comprising a memory and a processor, wherein the memory stores a computer program, wherein: When the processor executes the computer program, the steps of the dealer data rights management method according to any one of claims 1 to 7 are implemented.

10. A computer-readable storage medium having a computer program stored thereon, characterized in that: When the computer program is executed by a processor, the dealer data authority management method according to any one of claims 1 to 7 is implemented.

Images