CN113065106A - Account management method and device - Google Patents

Abstract

The invention discloses an account management method and device, and relates to the technical field of computers. One embodiment of the method comprises: according to the method, the operation authority of a target account on a menu item is determined according to the corresponding relation between the states of the menu items and the account, the target account is the currently logged-in account, the operable menu item of the target account is displayed, and the operable menu item is operated under the target account after the operation instruction of the corresponding operable menu item is received.

Description

Account management method and device

Technical Field

The invention relates to the technical field of computers, in particular to an account management method and device.

Background

The general chain sales enterprise organizational structure comprises a chain headquarter, chain branch companies and chain stores, wherein the headquarter has management authority for the branch companies, the branch companies have management authority for the stores, company employees have different roles according to different posts, the different roles need different authorities, an upper level needs to have authority for monitoring and checking data of the lower level, the lower level needs to inherit partial authority of the upper level, and the requirement for the account management is met due to the fact that the complex relation exists and a complete and clear account management scheme is lacked at present.

In the process of implementing the invention, the inventor finds that at least the following problems exist in the prior art:

account authority control cannot be effectively carried out, so that the account management requirement of a complex account system cannot be met.

Disclosure of Invention

In view of this, embodiments of the present invention provide an account management method and apparatus, which can effectively perform account authority control and meet the account management needs of a complex account system.

To achieve the above object, according to an aspect of an embodiment of the present invention, there is provided an account management method.

An account management method, comprising: determining the operation authority of a target account on the menu item according to the corresponding relation between the menu item state and the account, wherein the target account is a currently logged account; displaying the operable menu items of the target account, and operating the operable menu items in the target account after receiving the operating instructions corresponding to the operable menu items.

Optionally, the method further comprises: when creating menu items, for each type of account, setting the menu items to be in a visible or hidden state of the account type, and recording the corresponding relation between the menu item state and the account type.

Optionally, the level of the target account is a highest level; the determining the operation authority of the target account to the menu item according to the corresponding relation between the menu item state and the account comprises the following steps: and determining the operation authority of the target account on the menu item according to the corresponding relation record between the menu item state and the account type, wherein the menu item visible to the type of the target account is the menu item operable by the target account.

Optionally, the level of the target account is a non-highest level; the method further comprises the following steps: and creating the target account by logging in the previous level account of the target account, and storing a relation table between the target account and the previous level account of the target account.

Optionally, after the creating the target account, the method further includes: the method comprises the steps of inquiring a menu item visible to the type of a target account and a menu item visible to the type of an upper level account of the target account according to a corresponding relation record between the menu item state and the account type by logging in the upper level account of the target account, and configuring the corresponding relation between the target account and the menu item state according to the menu item visible to the type of the target account and the type of the upper level account of the target account at the same time.

Optionally, the determining, according to the correspondence between the states of the menu items and the accounts, the operation permission of the target account for the menu items includes: and determining the operation authority of the target account on the menu item according to the configured corresponding relation between the target account and the state of the menu item.

Optionally, the method further comprises: when a role is created, for each role, the menu item is set to be in a visible or hidden state, and the corresponding relation between the menu item state and the role is recorded.

Optionally, the determining, according to the correspondence between the states of the menu items and the accounts, the operation permission of the target account for the menu items includes: and determining the operation authority of the target account on the menu item according to the corresponding relation record between the menu item state and the account type and the corresponding relation record between the menu item state and the role, wherein the menu item visible to both the type and the role of the target account is the menu item operable by the target account.

Optionally, the account types include a person account and an institution account, each person account has an institution account to which the person account belongs, the account type of the role to be created is the person account, and the institution account to which the person account belongs creates the role for the person account.

Optionally, the type of the target account is a member account; the method further comprises the following steps: and when the target account is logged in, acquiring the state information of the target account, and determining that the target account is in an enabled state according to the state information, wherein the state information of the target account is set by logging in an institution account to which the target account belongs.

According to another aspect of the embodiments of the present invention, an account management apparatus is provided.

An account management apparatus comprising: the authority determining module is used for determining the operation authority of a target account to the menu item according to the corresponding relation between the menu item state and the account, wherein the target account is a currently logged account; and the account operation module is used for displaying the operable menu items of the target account so as to operate the operable menu items in the target account after receiving the operation instruction corresponding to the operable menu items.

Optionally, the system further comprises a menu item creation module, configured to: when creating menu items, for each type of account, setting the menu items to be in a visible or hidden state of the account type, and recording the corresponding relation between the menu item state and the account type.

Optionally, the level of the target account is a highest level; the permission determination module is further configured to: and determining the operation authority of the target account on the menu item according to the corresponding relation record between the menu item state and the account type, wherein the menu item visible to the type of the target account is the menu item operable by the target account.

Optionally, the level of the target account is a non-highest level; further comprising an account creation module for: and creating the target account by logging in the previous level account of the target account, and storing a relation table between the target account and the previous level account of the target account.

Optionally, the system further comprises a configuration module, configured to: the method comprises the steps of inquiring a menu item visible to the type of a target account and a menu item visible to the type of an upper level account of the target account according to a corresponding relation record between the menu item state and the account type by logging in the upper level account of the target account, and configuring the corresponding relation between the target account and the menu item state according to the menu item visible to the type of the target account and the type of the upper level account of the target account at the same time.

Optionally, the permission determination module is further configured to: and determining the operation authority of the target account on the menu item according to the configured corresponding relation between the target account and the state of the menu item.

Optionally, the system further comprises a role creation module, configured to: when a role is created, for each role, the menu item is set to be in a visible or hidden state, and the corresponding relation between the menu item state and the role is recorded.

Optionally, the permission determination module is further configured to: and determining the operation authority of the target account on the menu item according to the corresponding relation record between the menu item state and the account type and the corresponding relation record between the menu item state and the role, wherein the menu item visible to both the type and the role of the target account is the menu item operable by the target account.

Optionally, the account types include a person account and an institution account, each person account has an institution account to which the person account belongs, the account type of the role to be created is the person account, and the institution account to which the person account belongs creates the role for the person account.

Optionally, the type of the target account is a member account; further comprising an account status verification module for: and when the target account is logged in, acquiring the state information of the target account, and determining that the target account is in an enabled state according to the state information, wherein the state information of the target account is set by logging in an institution account to which the target account belongs.

According to yet another aspect of an embodiment of the present invention, an electronic device is provided.

An electronic device, comprising: one or more processors; a memory for storing one or more programs that, when executed by the one or more processors, cause the one or more processors to implement the account management methods provided by embodiments of the present invention.

According to yet another aspect of an embodiment of the present invention, a computer-readable medium is provided.

A computer-readable medium, on which a computer program is stored, which, when executed by a processor, implements an account management method provided by an embodiment of the present invention.

One embodiment of the above invention has the following advantages or benefits: according to the corresponding relation between the states of the menu items and the accounts, the operation authority of the target account on the menu items is determined, the target account is the currently logged-in account, the operable menu items of the target account are displayed, and after the operation instruction of the corresponding operable menu items is received, the operable menu items are operated under the target account, so that the operation authority of the account can be determined according to the corresponding relation between the states of the menu items and the accounts for all levels of accounts of a complex account system, the account authority is effectively controlled, the account management requirement of the complex account system is met, and a one-to-many management mode is realized.

Further effects of the above-mentioned non-conventional alternatives will be described below in connection with the embodiments.

Drawings

The drawings are included to provide a better understanding of the invention and are not to be construed as unduly limiting the invention. Wherein:

FIG. 1 is a schematic diagram of the main steps of an account management method according to one embodiment of the present invention;

FIG. 2 is a schematic view of an account management flow according to one embodiment of the present invention;

FIG. 3 is a schematic view of an account management flow according to another embodiment of the present invention;

FIG. 4 is a schematic view of an account management flow according to yet another embodiment of the invention;

FIG. 5 is a schematic view of an account management flow according to yet another embodiment of the invention;

FIG. 6 is a schematic diagram of the main modules of an account management apparatus according to one embodiment of the present invention;

FIG. 7 is an exemplary system architecture diagram in which embodiments of the present invention may be employed;

fig. 8 is a schematic structural diagram of a computer system suitable for implementing a terminal device or a server according to an embodiment of the present invention.

Detailed Description

Exemplary embodiments of the present invention are described below with reference to the accompanying drawings, in which various details of embodiments of the invention are included to assist understanding, and which are to be considered as merely exemplary. Accordingly, those of ordinary skill in the art will recognize that various changes and modifications of the embodiments described herein can be made without departing from the scope and spirit of the invention. Also, descriptions of well-known functions and constructions are omitted in the following description for clarity and conciseness.

Fig. 1 is a schematic diagram of the main steps of an account management method according to one embodiment of the present invention.

As shown in fig. 1, the account management method according to an embodiment of the present invention mainly includes the following steps S101 to S102.

Step S101: determining the operation authority of a target account on the menu item according to the corresponding relation between the menu item state and the account, wherein the target account is the currently logged account;

step S102: and displaying the operable menu items of the target account so as to operate the operable menu items in the target account after receiving the operation instructions corresponding to the operable menu items.

The menu items are operable menus in the page.

When creating the menu item, for each type of account, the menu item is set to be in a visible or hidden state with respect to the account type, and the corresponding relationship between the menu item state and the account type is recorded.

In one embodiment, the level of the target account is the highest level. Determining the operation authority of the target account on the menu item according to the corresponding relation between the menu item state and the account, which may specifically include: and determining the operation authority of the target account to the menu item according to the corresponding relation record between the menu item state and the account type, wherein the menu item visible to the type of the target account is the menu item operable by the target account.

In one embodiment, the level of the target account is a non-top level. The target account may be created by logging in to a previous level account of the target account, and storing a table of relationships between the target account and the previous level account of the target account.

After the target account is created, the corresponding relation between the target account and the states of the menu items can be configured by logging in the upper level account of the target account, inquiring the menu items visible to the types of the target account according to the corresponding relation records between the states of the menu items and the types of the accounts, inquiring the menu items visible to the types of the upper level account of the target account, and simultaneously visible to the types of the upper level account of the target account.

Determining the operation authority of the target account on the menu item according to the corresponding relation between the menu item state and the account, which may specifically include: and determining the operation authority of the target account on the menu item according to the configured corresponding relation between the target account and the state of the menu item.

In one embodiment, when creating roles, for each role, the menu item may be set to a state visible or hidden to the role, and the correspondence between the menu item state and the role may be recorded. A plurality of roles, for example, an account system of a chain sales enterprise, may be created in advance according to business needs, and the roles may include a sales role, a logistics role, a delivery role, and the like, and may be further subdivided according to needs. Roles may be assigned to an account after the account is created.

Determining the operation authority of the target account on the menu item according to the corresponding relation between the menu item state and the account, which may specifically include: and determining the operation authority of the target account on the menu item according to the corresponding relation record between the menu item state and the account type and the corresponding relation record between the menu item state and the role, wherein the menu item visible to both the type and the role of the target account is an operable menu item of the target account.

The account types can comprise a personnel account and an institution account, each personnel account has an institution account, the account type of the role to be created is the personnel account, and the institution account to which the personnel account belongs creates the role for the personnel account.

In one embodiment, the type of target account is a member account. The method comprises the steps of obtaining state information of a target account when the target account is logged in, and determining that the target account is in an enabled state according to the state information, wherein the state information of the target account is set by logging in an institution account to which the target account belongs. The status information of the target account may specifically include statuses of activation, deactivation, and the like.

Taking a complex account system composed of a headquarter account, a branch account and a store account as an example, for example, an account system of a chain sales enterprise, an enterprise organization architecture is a chain headquarter, a chain branch company and a chain store, and institution accounts of the chain headquarter, the chain branch company and the chain store are respectively a headquarter account, a branch company account and a store account, wherein the headquarter account is a highest-level institution account, and the branch company account and the store account are non-highest-level institution accounts. The sub-accounts under each institution account are member accounts, the account types can be divided into institution accounts and member accounts, and the institution accounts can be further divided into three specific account types of headquarter accounts, branch company accounts and store accounts.

By the account management method, the headquarter account can be used for creating an account for the branch company, namely creating an account of the branch company; the branch company can create an account for the store, namely, create an account of the store; the headquarter account, the branch account and the store account can all create sub-accounts for respective employees, namely create a personnel account, the authority of the sub-accounts is set through a main account (namely an institution account to which the sub-accounts belong), the functions of part of the main accounts can be inherited, the institution account can assign roles to the sub-accounts (namely the personnel accounts) created by the institution, and the role authority is set. The chain headquarters account has the largest authority, and can view data under the branch account and the store account, the branch account can view data under the store account, all the primary accounts can inquire data under the secondary accounts, and meanwhile, the superior account can set state information, such as a deactivation state or an activation state, on the subordinate accounts.

The following describes the account management process according to the embodiment of the present invention in detail in various embodiments.

FIG. 2 is a schematic view of an account management process according to one embodiment of the invention. As shown in fig. 2, the currently registered account is a headquarters account, which represents the highest-ranked institution account. After logging in the headquarter account, a sub-account under the headquarter account, that is, a staff account of a headquarter staff, may be created, and may also assign roles and set role permissions for the created sub-accounts, and set state information (activation and deactivation) for the created sub-accounts, and may also create and set branch accounts, and each sub-process is introduced below respectively.

The sub-process of creating sub-accounts under the headquarters account includes: and logging in the headquarter account, creating the sub-account according to the sub-account creating command, judging whether the sub-account is created successfully, if so, storing the corresponding relation between the created sub-account and the headquarter account, and if not, ending the process.

The sub-process of setting status information for the created sub-account includes: logging in the headquarter account, setting the state information of the created sub-account of the headquarter account into a disabled state or an enabled state, and recording the set state information through Redis so as to verify whether the sub-account is in the enabled state or not through the state information recorded by the Redis when logging in the sub-account, wherein if yes, the sub-account is logged in successfully, otherwise, the sub-account is logged in unsuccessfully.

The sub-process of assigning roles to the created sub-accounts and setting role permissions includes: logging in a headquarter account, according to a sub-account permission setting command, allocating a role to the sub-account, for example, the role is a delivery role, reading a corresponding relation record between a menu item state and a personnel account type and a corresponding relation record between the menu item state and the role from a database to determine a menu item visible to the type of the sub-account and a menu item visible to the role, according to the menu item visible to both the type and the role of the sub-account, setting role permissions to the sub-account, for example, the menu items visible to the personnel account type in the database are a 1-a 5, the menu items visible to the delivery role in the database are a 3-a 6, then according to the corresponding relation record between the menu item state and the account type and the corresponding relation record between the menu item state and the role, determining that the permissions are set to visible menu items a 3-a 5, that is, the sub-account is operable with menu items a 3-a 5, and the menu items that are not operable with respect to the sub-account are set to be hidden (i.e., invisible) with respect to the sub-account. The database stores the menu items visible under each role, and the sub-accounts are bound with the set roles by setting the roles of the sub-accounts, so that the control of the operation authority of the sub-accounts is realized. When the role authority of the sub-account is set, the role authority of the headquarter account can be inquired, the sub-account of the headquarter account can inherit the authority of the headquarter account, but the authority of the sub-account is smaller than or equal to the authority of the headquarter account.

The sub-process of creating and setting up the branch account includes: and logging in a headquarter account, and creating a branch account according to a lower-level account creating command, wherein the lower-level account creating command is used for creating a lower-level account of the current account. Judging whether the branch account is successfully established, if so, storing the corresponding relation between the headquarter account and the branch account, namely: establishing a relation table of a headquarter account and a branch company account and writing the relation table into a database; if not, the process ends. Under the condition that the branch account is successfully created, according to the corresponding relation record between the state of the menu item and the type of the account, a menu item visible for the type of the branch account and a menu item visible for the type of the headquarter account are inquired (checked) from a database, and according to the menu item visible for the type of the branch account and the type of the headquarter account at the same time, the corresponding relation between the branch account and the state of the menu item is configured. Wherein, the menu item which can be seen from the type of the branch company account can be inquired from the database, and for the inquired menu, the database can be respectively checked to check whether the menu can be seen from the branch company account, then searching a corresponding relation record between the states of the menu items and the types of the headquarter accounts from a database, checking whether the menu item visible to the type of the corporate account is visible to the headquarter account according to the corresponding relation record between the searched menu item state and the type of the headquarter account, to determine the menu item that is visible to both the type of corporate account and the type of headquarters account, and if the menu item that is visible to the type of corporate account is also visible to the headquarters account, the authority to operate the menu item (i.e., menu) may be set to the corporate account, and if not, the authority for operating the menu item by the branch account cannot be set.

The correspondence between the menu item status and the account type is set and recorded when the menu item is created. Specifically, when a menu item is created, whether the menu item is visible for a headquarter account, a branch company account, a store account, a staff account, and the like may be set to control the use range of the menu item, and the operation authority for controlling the headquarter account, the branch company account, the store account, the staff account, and the like is realized by recording the corresponding relationship between the state of each menu item and the account type.

The corresponding relation between the menu item state and the role is set and recorded when the role is created. Specifically, when a role is created, whether each menu item is visible for the role can be set to control the use range of the menu item, the operation authority of each role is controlled by recording the corresponding relation between the states of the menu items and the roles, and then the operation authority control of each account is realized after the role is allocated to an account such as a headquarter account, a branch company account, a store account, a personnel account and the like.

FIG. 3 is a schematic view of an account management process according to one embodiment of the invention. As shown in fig. 3, the currently registered account is a subsidiary account, which represents an institution account of one level other than the top-level and bottom-level accounts, i.e., an institution account of an intermediate level. After logging in the account of the branch company, a sub-account under the account of the branch company, namely a staff account of an employee of the branch company, may also assign roles to the created sub-accounts and set role permissions, set state information (enable, disable) for the created sub-accounts, and may also create and set store accounts. The sub-processes for creating a sub-account under the branch account, setting status information for the created sub-account, assigning a role to the created sub-account and setting a role right, and creating and setting a store account are similar to the above sub-processes for creating a sub-account under the head office account, setting status information for the created sub-account, assigning a role to the created sub-account of the head office account and setting a role right, and creating and setting a sub-process for the branch account, and may be specifically referred to the above related descriptions, and are not described herein again.

FIG. 4 is a schematic view of an account management flow according to one embodiment of the present invention. As shown in fig. 4, the currently registered account is a store account, which represents the lowest level institution account. After logging in the store account, a sub-account under the store account, that is, a staff account of a store employee, may be created, and a role may be assigned and a role authority may be set for the created sub-account, and status information may be set for the created sub-account (activation, deactivation). The sub-processes of creating a sub-account under the store account, setting status information for the created sub-account, and assigning a role to the created sub-account and setting a role right may refer to the above introduction of the sub-processes of creating a sub-account under the headquarters account, setting status information for the created sub-account of the headquarters account, and assigning a role to the created sub-account of the headquarters account and setting a role right.

FIG. 5 is a schematic view of an account management process according to yet another embodiment of the present invention.

As shown in fig. 5, for a complex account system including a headquarters account, a branch account, and a store account, an account can be created for a branch by registering the headquarters account, and if the branch account is not created, the creation process is terminated. The embodiment of the invention carries out account management under the headquarter account by logging in the headquarter account, and the account management flow under the headquarter account comprises the following steps: the method comprises the steps of creating a sub-process of a sub-account under a headquarter account, setting status information of the created sub-account, assigning roles to the created sub-accounts and setting role authority, and creating and setting a sub-process of a branch account. The account management process under the headquarter account specifically refers to the description of the embodiment corresponding to fig. 2. For the branch account successfully created, an account can be created for the store by logging in the branch account, and if the store account is not created, the creation process is ended. The embodiment of the invention carries out account management under the branch account by logging in the branch account, and the account management process under the branch account comprises the following steps: creating a sub-process of a sub-account under the branch account, setting a sub-process of state information for the created sub-account of the branch account, allocating roles for the created sub-account of the branch account and setting a sub-process of role authority, and creating and setting a sub-process of a store account. The account management process under the branch account is specifically described with reference to the embodiment corresponding to fig. 3. For the store account successfully created, account management under the store account can be performed by logging in the store account, and the account management process under the store account comprises the following steps: the method comprises the steps of creating a sub-process of a sub-account under a store account, setting a sub-process of state information for the created sub-account of the store account, and assigning roles to the created sub-account of the store account and setting a role authority. The account management process under the store account is specifically described with reference to the embodiment corresponding to fig. 4. And after the branch account is successfully created, establishing a relation table between the headquarter account and the created branch account through a data writing database, wherein the corresponding relation between the headquarter account and the created branch account is stored. And after the store account is successfully created, establishing a relation table between the branch account and the created store account through the data writing database, wherein the corresponding relation between the branch account and the created store account is stored.

It should be noted that the headquarter account, the branch company account, and the store account are only accounts divided into three levels from high to low in a complex account system, the account hierarchy division in the embodiment of the present invention is not limited to the headquarter account, the branch company account, and the store account, and the account hierarchy in the embodiment of the present invention is not limited to three levels, that is, the middle level may be a plurality of levels.

The account management method/process of the embodiments of the present invention can be implemented by using Java, which is an object-oriented programming language, has two features of powerful function and simplicity, and is used as a representative of a static object-oriented programming language, thereby perfectly implementing an object-oriented theory and allowing a program to perform complex programming in an elegant thinking manner. In addition, Redis and MySQL are used for storing data, the MySQL is a relational database management system, the Redis is a key-value storage system, the Redis supports relatively more stored value types, including string, list, set, zset, ordered set and hash, the data types support push/pop, add/remove, intersection union, difference and richer operations, and the operations are atomic, on the basis, the Redis supports various different manners of sorting, in order to ensure efficiency, the data is cached in an internal memory, the Redis periodically writes updated data into a disk or writes modification operations into a record file, and master-slave synchronization is realized on the basis.

For each level of account, in the embodiment of the present invention, account registration is performed when an account is created, an input user name, a password, a mobile phone number, relevant basic information, and the like are received when the account is registered, the relevant basic information may be an input item added according to a requirement, and then whether the input user name already exists is checked, specifically, whether the user name exists in a Redis or MySQL database may be queried, if so, the user name exists, otherwise, the user name does not exist. Preferably, Redis can be queried first, and in case the user name does not exist in Redis, the MySQL database is queried. In addition, whether the length, the character type and the like of the user name meet requirements or not and whether the length of the password and the password are the supported character types or not are verified, the mobile phone number is verified according to a regular expression of the mobile phone number, and whether the mobile phone number is registered or not is verified at the same time (the user name verification method can be referred to, namely, a Redis or MySQL database is inquired to judge whether the mobile phone number is registered or not, one mobile phone can be allowed to register a plurality of accounts or only one unique account can be supported to be registered, and the registration is allowed according to requirements specifically).

For an account with successful creation, the account management apparatus of the embodiment of the present invention (the account management apparatus is configured to perform an account management method of the embodiment of the present invention, which will be further described in the following embodiments) reads a user name and a password from the Redis to perform login verification, and after it is determined that the login verification passes, the account login is successful, where in the login verification, information of the account may be first found in the Redis, and the information of the account includes the user name and the password, if the information of the account is not found in the Redis, the information of the account is found in the MySQL database, and if the information of the account exists in the MySQL database, the reds data is rewritten from the database to write the information of the account into the Redis, and the account login is successful. If the information of the account does not exist in the Redis database and the MySQL database, the account does not exist, and the account login fails.

The embodiment of the invention can set whether each menu item (for example, one menu item can correspond to one menu) is visible for different types of accounts, for example, whether each menu item is visible for a headquarter account, a branch company account, a store account or sub-accounts (namely, personnel accounts) of all levels of accounts, thereby realizing the use range of the control menu, and the setting about which type of account a certain menu is visible can be stored in the MySQL database or Redis. When setting the corresponding relationship between the account and the menu item states (the menu item states include a visible state and a hidden (i.e. invisible) state), the menu item that can be set corresponding to the account type can be obtained by querying the MySQL database or the Redis according to the account type, and the menu item that can be set corresponding to the account type is the menu item that is stored in the MySQL database or the Redis and is visible to the account of the type. Meanwhile, the menu data of the superior account of the account needs to be inquired to judge whether the menu item visible for the type of account is visible or not, and the corresponding relation between the account and the menu item can be set only if the menu item visible for the type of account and the type of the superior account is visible.

The account management device of the embodiment of the invention can also set menu items for the roles, and for each role, the menu items are set to be visible or invisible for the role.

By means of which the lower level account can be set with its status information, e.g. account status disabled or enabled, settings regarding the status of the account can be saved in the Redis. When logging in the account, the state of the account can be verified, if the account is in a disabled state, the account logs in the identification, and if the account is in an enabled state, the account can log in normally.

After an account is successfully logged in, the account management apparatus according to the embodiment of the present invention may acquire a role of the account, query a menu configured under the role through the role, where the menu configured under the role is a menu item whose role is visible, after the configured menu is read, check a state of the menu in the account type, where the menu item is visible to the account type, if the menu is visible, display the menu, and if the menu is hidden, not display the menu to a front end, where, querying whether the menu item is visible to the account type, may read a corresponding relationship between the account type and a menu item state through Redis, or may read the corresponding relationship through a MySQL database, and specifically may be designed according to a data volume, and if the data volume is large (a specific determination criterion may be set as required), may preferentially read the corresponding relationship in Redis, and in the case of no existence in Redis, reading in MySQL database. If the data volume is not large, the corresponding relation can be directly stored in the MySQL database, and the corresponding relation is directly read from the MySQL database during query.

The account management method/process can solve the problem that a superior account (such as a headquarter account) manages subordinate accounts (such as branch account, store account and employee account), the menus can be visible or hidden for different types of accounts, the menus can be visible or hidden for different role accounts, the accounts are bound with roles, the corresponding menus are obtained through reverse check of the roles and the account types after the accounts are logged in, account authority is obtained, one-to-many account management is achieved through account authority control, and data of the subordinate accounts can be checked in real time or subjected to specific intervention operation through the superior account. However, the existing account management cannot meet the complex account relationship, the lower-level account cannot be managed and controlled through the upper-level account, the data condition under the lower-level account cannot be clearly acquired through the upper-level account, the lower-level account cannot inherit part of functions of the upper-level account, and for the complex account relationship, a whole set of account management scheme is not realized in the prior art.

Fig. 6 is a schematic diagram of main blocks of an account management apparatus according to an embodiment of the present invention.

Anaccount management apparatus 600 according to an embodiment of the present invention mainly includes: apermission determination module 601 and anaccount operation module 602. Theaccount management apparatus 600 may be located in a terminal or a server for account management.

Theauthority determining module 601 is configured to determine an operation authority of a target account for a menu item according to a corresponding relationship between a menu item state and an account, where the target account is a currently logged-in account.

Theaccount operating module 602 is configured to display menu items that are operable for the target account, so that after receiving an operating instruction corresponding to the operable menu items, the operable menu items are operated in the target account.

Theaccount management device 600 may further include a menu item creation module to: when creating menu items, for each type of account, setting the menu items to be in a visible or hidden state of the account type, and recording the corresponding relation between the menu item state and the account type.

The level of the target account may be a highest level; thepermission determining module 601 is specifically configured to: and determining the operation authority of the target account to the menu item according to the corresponding relation record between the menu item state and the account type, wherein the menu item visible to the type of the target account is the menu item operable by the target account.

The level of the target account may be a non-top level; theaccount management apparatus 600 may further include an account creation module to: and creating the target account by logging in the previous level account of the target account, and storing a relation table between the target account and the previous level account of the target account.

Theaccount management apparatus 600 may further include a configuration module to: the method comprises the steps of logging in an upper level account of a target account, inquiring a menu item visible to the type of the target account and a menu item visible to the type of the upper level account of the target account according to a corresponding relation record between the state of the menu item and the type of the account, and configuring the corresponding relation between the state of the target account and the state of the menu item according to the menu item visible to the type of the upper level account of the target account and the type of the upper level account of the target account.

Thepermission determining module 601 is further specifically configured to: and determining the operation authority of the target account on the menu item according to the configured corresponding relation between the target account and the state of the menu item.

Theaccount management apparatus 600 may further include a role creation module to: when a role is created, for each role, the menu item is set to be in a visible or hidden state, and the corresponding relation between the menu item state and the role is recorded.

Thepermission determination module 601 is further configured to: and determining the operation authority of the target account on the menu item according to the corresponding relation record between the menu item state and the account type and the corresponding relation record between the menu item state and the role, wherein the menu item visible to both the type and the role of the target account is an operable menu item of the target account.

The account types can comprise a personnel account and an institution account, each personnel account has an institution account, the account type of the role to be created is the personnel account, and the institution account to which the personnel account belongs creates the role for the personnel account.

In one embodiment, the type of target account is a person account; theaccount management apparatus 600 may further include an account status verification module for: when the target account is logged in, state information of the target account is obtained, and the target account is determined to be in the starting state according to the state information, wherein the state information of the target account is set by logging in an institution account to which the target account belongs.

In addition, the specific implementation contents of the account management device in the embodiment of the invention have been described in detail in the above account management method, so that repeated contents are not described again.

Fig. 7 shows anexemplary system architecture 700 to which the account management method or the account management apparatus of the embodiment of the present invention can be applied.

As shown in fig. 7, thesystem architecture 700 may includeterminal devices 701, 702, 703, anetwork 704, and aserver 705. Thenetwork 704 serves to provide a medium for communication links between theterminal devices 701, 702, 703 and theserver 705.Network 704 may include various connection types, such as wired, wireless communication links, or fiber optic cables, to name a few.

A user may use theterminal devices 701, 702, 703 to interact with aserver 705 over anetwork 704, to receive or send messages or the like. Theterminal devices 701, 702, 703 may have installed thereon various communication client applications, such as a shopping-like application, a web browser application, a search-like application, an instant messaging tool, a mailbox client, social platform software, etc. (by way of example only).

Theterminal devices 701, 702, 703 may be various electronic devices having a display screen and supporting web browsing, including but not limited to smart phones, tablet computers, laptop portable computers, desktop computers, and the like.

Theserver 705 may be a server providing various services, such as a background management server (for example only) providing support for shopping websites browsed by users using theterminal devices 701, 702, 703. The backend management server may analyze and perform other processing on the received data such as the product information query request, and feed back a processing result (for example, target push information, product information — just an example) to the terminal device.

It should be noted that the account management method provided in the embodiment of the present invention is generally executed by theserver 705, and accordingly, the account management apparatus is generally disposed in theserver 705.

It should be understood that the number of terminal devices, networks, and servers in fig. 7 is merely illustrative. There may be any number of terminal devices, networks, and servers, as desired for implementation.

Referring now to FIG. 8, shown is a block diagram of acomputer system 800 suitable for use in implementing a terminal device or server of an embodiment of the present application. The terminal device or the server shown in fig. 8 is only an example, and should not bring any limitation to the functions and the scope of use of the embodiments of the present application.

As shown in fig. 8, thecomputer system 800 includes a Central Processing Unit (CPU)801 that can perform various appropriate actions and processes in accordance with a program stored in a Read Only Memory (ROM)802 or a program loaded from astorage section 808 into a Random Access Memory (RAM) 803. In theRAM 803, various programs and data necessary for the operation of thesystem 800 are also stored. TheCPU 801,ROM 802, andRAM 803 are connected to each other via abus 804. An input/output (I/O)interface 805 is also connected tobus 804.

The following components are connected to the I/O interface 805: aninput portion 806 including a keyboard, a mouse, and the like; anoutput section 807 including a signal such as a Cathode Ray Tube (CRT), a Liquid Crystal Display (LCD), and the like, and a speaker; astorage portion 808 including a hard disk and the like; and acommunication section 809 including a network interface card such as a LAN card, a modem, or the like. Thecommunication section 809 performs communication processing via a network such as the internet. Adrive 810 is also connected to the I/O interface 805 as necessary. Aremovable medium 811 such as a magnetic disk, an optical disk, a magneto-optical disk, a semiconductor memory, or the like is mounted on thedrive 810 as necessary, so that a computer program read out therefrom is mounted on thestorage section 808 as necessary.

In particular, according to the embodiments of the present disclosure, the processes described above with reference to the flowcharts may be implemented as computer software programs. For example, embodiments of the present disclosure include a computer program product comprising a computer program embodied on a computer readable medium, the computer program comprising program code for performing the method illustrated in the flow chart. In such an embodiment, the computer program can be downloaded and installed from a network through thecommunication section 809 and/or installed from theremovable medium 811. The computer program executes the above-described functions defined in the system of the present application when executed by the Central Processing Unit (CPU) 801.

It should be noted that the computer readable medium shown in the present invention can be a computer readable signal medium or a computer readable storage medium or any combination of the two. A computer readable storage medium may be, for example, but not limited to, an electronic, magnetic, optical, electromagnetic, infrared, or semiconductor system, apparatus, or device, or any combination of the foregoing. More specific examples of the computer readable storage medium may include, but are not limited to: an electrical connection having one or more wires, a portable computer diskette, a hard disk, a Random Access Memory (RAM), a read-only memory (ROM), an erasable programmable read-only memory (EPROM or flash memory), an optical fiber, a portable compact disc read-only memory (CD-ROM), an optical storage device, a magnetic storage device, or any suitable combination of the foregoing. In the present application, a computer readable storage medium may be any tangible medium that can contain, or store a program for use by or in connection with an instruction execution system, apparatus, or device. In this application, however, a computer readable signal medium may include a propagated data signal with computer readable program code embodied therein, for example, in baseband or as part of a carrier wave. Such a propagated data signal may take many forms, including, but not limited to, electro-magnetic, optical, or any suitable combination thereof. A computer readable signal medium may also be any computer readable medium that is not a computer readable storage medium and that can communicate, propagate, or transport a program for use by or in connection with an instruction execution system, apparatus, or device. Program code embodied on a computer readable medium may be transmitted using any appropriate medium, including but not limited to: wireless, wire, fiber optic cable, RF, etc., or any suitable combination of the foregoing.

The flowchart and block diagrams in the figures illustrate the architecture, functionality, and operation of possible implementations of systems, methods and computer program products according to various embodiments of the present application. In this regard, each block in the flowchart or block diagrams may represent a module, segment, or portion of code, which comprises one or more executable instructions for implementing the specified logical function(s). It should also be noted that, in some alternative implementations, the functions noted in the block may occur out of the order noted in the figures. For example, two blocks shown in succession may, in fact, be executed substantially concurrently, or the blocks may sometimes be executed in the reverse order, depending upon the functionality involved. It will also be noted that each block of the block diagrams or flowchart illustration, and combinations of blocks in the block diagrams or flowchart illustration, can be implemented by special purpose hardware-based systems which perform the specified functions or acts, or combinations of special purpose hardware and computer instructions.

The modules described in the embodiments of the present invention may be implemented by software or hardware. The described modules may also be provided in a processor, which may be described as: a processor comprises a permission determination module and an account operation module. The names of the modules do not form a limitation on the modules themselves under certain conditions, for example, the authority determination module may also be described as a "module for determining the operation authority of the target account for the menu item according to the corresponding relationship between the states of the menu items and the account".

As another aspect, the present invention also provides a computer-readable medium that may be contained in the apparatus described in the above embodiments; or may be separate and not incorporated into the device. The computer readable medium carries one or more programs which, when executed by a device, cause the device to comprise: determining the operation authority of a target account on the menu item according to the corresponding relation between the menu item state and the account, wherein the target account is a currently logged account; displaying the operable menu items of the target account, and operating the operable menu items in the target account after receiving the operating instructions corresponding to the operable menu items.

According to the technical scheme of the embodiment of the invention, the operation authority of the target account for the menu item is determined according to the corresponding relation between the menu item state and the account, the operable menu item of the target account is displayed, and the operable menu item is operated under the target account after the operation instruction of the corresponding operable menu item is received, so that the operation authority of the account can be determined according to the corresponding relation between the menu item state and the account for each level of accounts of a complex account system, the account authority is effectively controlled, the account management requirement of the complex account system is met, and a one-to-many management mode is realized.

The above-described embodiments should not be construed as limiting the scope of the invention. Those skilled in the art will appreciate that various modifications, combinations, sub-combinations, and substitutions can occur, depending on design requirements and other factors. Any modification, equivalent replacement, and improvement made within the spirit and principle of the present invention should be included in the protection scope of the present invention.

Claims (13)

1. An account management method, comprising:

determining the operation authority of a target account on the menu item according to the corresponding relation between the menu item state and the account, wherein the target account is a currently logged account;

displaying the operable menu items of the target account, and operating the operable menu items in the target account after receiving the operating instructions corresponding to the operable menu items.

2. The method of claim 1, further comprising:

when creating menu items, for each type of account, setting the menu items to be in a visible or hidden state of the account type, and recording the corresponding relation between the menu item state and the account type.

3. The method of claim 2, wherein the level of the target account is a highest level;

the determining the operation authority of the target account to the menu item according to the corresponding relation between the menu item state and the account comprises the following steps:

and determining the operation authority of the target account on the menu item according to the corresponding relation record between the menu item state and the account type, wherein the menu item visible to the type of the target account is the menu item operable by the target account.

4. The method of claim 2, wherein the level of the target account is a non-top level;

the method further comprises the following steps: and creating the target account by logging in the previous level account of the target account, and storing a relation table between the target account and the previous level account of the target account.

5. The method of claim 4, wherein after the creating the target account, further comprising:

the method comprises the steps of inquiring a menu item visible to the type of a target account and a menu item visible to the type of an upper level account of the target account according to a corresponding relation record between the menu item state and the account type by logging in the upper level account of the target account, and configuring the corresponding relation between the target account and the menu item state according to the menu item visible to the type of the target account and the type of the upper level account of the target account at the same time.

6. The method according to claim 5, wherein the determining the operation authority of the target account for the menu item according to the corresponding relationship between the menu item state and the account comprises:

and determining the operation authority of the target account on the menu item according to the configured corresponding relation between the target account and the state of the menu item.

7. The method of claim 2, further comprising:

when a role is created, for each role, the menu item is set to be in a visible or hidden state, and the corresponding relation between the menu item state and the role is recorded.

8. The method according to claim 7, wherein the determining the operation authority of the target account for the menu item according to the corresponding relationship between the state of the menu item and the account comprises:

and determining the operation authority of the target account on the menu item according to the corresponding relation record between the menu item state and the account type and the corresponding relation record between the menu item state and the role, wherein the menu item visible to both the type and the role of the target account is the menu item operable by the target account.

9. The method of claim 7, wherein the account types include a human account and an institution account, and each human account has an institution account to which the human account belongs, and the account type of the role to be created is the human account for which the role is created by the institution account to which the human account belongs.

10. The method of claim 9, wherein the type of the target account is a member account;

the method further comprises the following steps:

and when the target account is logged in, acquiring the state information of the target account, and determining that the target account is in an enabled state according to the state information, wherein the state information of the target account is set by logging in an institution account to which the target account belongs.

11. An account management apparatus, comprising:

the authority determining module is used for determining the operation authority of a target account to the menu item according to the corresponding relation between the menu item state and the account, wherein the target account is a currently logged account;

and the account operation module is used for displaying the operable menu items of the target account so as to operate the operable menu items in the target account after receiving the operation instruction corresponding to the operable menu items.

12. An electronic device, comprising:

one or more processors;

a memory for storing one or more programs,

the one or more programs, when executed by the one or more processors, cause the one or more processors to implement the method of any of claims 1-10.

13. A computer-readable medium, on which a computer program is stored which, when being executed by a processor, carries out the method according to any one of claims 1-10.

Images