Merge branch 'memgraph-3-1' into tzdata_warning

Author: katarinasupe

next-env.d.ts

@@ -2,4 +2,4 @@
 /// <reference types="next/image-types/global" />
 
 // NOTE: This file should not be edited
-// see https://nextjs.org/docs/pages/api-reference/config/typescript for more information.
+// see https://nextjs.org/docs/basic-features/typescript for more information.

pages/client-libraries/python.mdx

@@ -11,8 +11,8 @@ import CodeSnippet from '/components/code-snippet/CodeSnippet'
 
 Learn how to create a Python application that connects to the Memgraph database and executes simple queries.
 
-Both [Neo4j Python client](https://neo4j.com/docs/python-manual/current/) and [GQLAlchemy](https://github.com/memgraph/gqlalchemy) can be used to connect to Memgraph with Python. 
-This guide will show how to use Neo4j Python client and for more information on GQLAlchemy, check out its [documentation](https://memgraph.github.io/gqlalchemy/). 
+Both [Neo4j Python client](https://neo4j.com/docs/python-manual/current/) and [GQLAlchemy](https://github.com/memgraph/gqlalchemy) can be used to connect to Memgraph with Python.
+This guide will show how to use Neo4j Python client and for more information on GQLAlchemy, check out its [documentation](https://memgraph.github.io/gqlalchemy/).
 
 Memgraph and Neo4j both support Bolt protocol and Cypher queries, which means that same client can be used to connect to both databases.
 This is very convenient if switching between the two databases is needed. This guide is based on the client version v5 and above. Some examples may
@@ -29,7 +29,7 @@ Necessary prerequisites that should be installed in your local environment are:
 
 <Steps>
 
-### Run Memgraph 
+### Run Memgraph
 
 If you're new to Memgraph or you're in a developing stage, we
 recommend using the Memgraph Platform. Besides the database, it also
@@ -60,7 +60,7 @@ communicate with the client using the exposed 7687 port. Memgraph Lab is a web
 application you can use to visualize the data. It's accessible at
 [http://localhost:3000](http://localhost:3000) if Memgraph Platform is running
 correctly. The 7444 port enables Memgraph Lab to access and preview the logs,
-which is why both of these ports need to be exposed. 
+which is why both of these ports need to be exposed.
 
 For more information visit the getting started guide on [how to run Memgraph
 with Docker](/getting-started/install-memgraph/docker).
@@ -178,6 +178,7 @@ Once the database is running and the client is installed or available in Python,
 - [Connect with authentication](#connect-with-authentication)
 - [Connect with self-signed certificate](#encrypted-database-connection-with-self-signed-certificate)
 - [Connect with Single sign-on (SSO)](#connect-with-single-sign-on-sso)
+- [Impersonate a user](#impersonate-a-user)
 
 #### Connect without authentication (default)
 
@@ -295,6 +296,22 @@ with neo4j.GraphDatabase.driver(
 ) as driver:
 ```
 
+#### Impersonate a user
+
+<Callout type="info">
+[User impersonation](/database-management/authentication-and-authorization/impersonate-user) is an Enterprise feature.
+</Callout>
+
+Once logged in, a user with the correct permissions can impersonate a different
+users during a session. This means that any query executing during that session
+will be executed as if the impersonated user executed it. The target user can be
+defined during session creation as in the following snippet:
+
+```python
+with driver.session(impersonated_user="user1") as session:
+    # queries here will be executed as if user1 executed them
+```
+
 ### Query the database
 
 After connecting your client to Memgraph, you can start running queries. The simplest way to run queries is by using the `execute_query()` method which has an automatic transaction management.
@@ -424,8 +441,8 @@ Path will contain [Nodes](#process-the-node-result) and [Relationships[#process-
 
 Transaction is a unit of work that is executed on the database, it could be some basic read, write or complex set of steps in form of series of queries. There can be multiple ways to mange transaction, but usually, they are managed automatically by the client or manually by the explicit code steps. Transaction management defines how to handle the transaction, when to commit, rollback, or terminate it.
 
-On the driver side, if a transaction fails because of a transient error, the transaction is retried automatically. 
-The transient error will occur during write conflicts or network failures. The driver will retry the transaction function with an exponentially increasing delay. 
+On the driver side, if a transaction fails because of a transient error, the transaction is retried automatically.
+The transient error will occur during write conflicts or network failures. The driver will retry the transaction function with an exponentially increasing delay.
 
 #### Automatic transaction management
 
@@ -671,9 +688,9 @@ The `Session.run()` method is most commonly used for `LOAD CSV` clause to preven
 
 #### Concurrent transactions
 
-It is possible to run concurrent transactions with Python's client by leveraging threads or processes. 
-Using threads could cause your code to be partially locked because of [Global interpreter lock (GIL)](https://wiki.python.org/moin/GlobalInterpreterLock), 
-resulting in slow execution. Hence, it is always better to run your workloads in separate processes, 
+It is possible to run concurrent transactions with Python's client by leveraging threads or processes.
+Using threads could cause your code to be partially locked because of [Global interpreter lock (GIL)](https://wiki.python.org/moin/GlobalInterpreterLock),
+resulting in slow execution. Hence, it is always better to run your workloads in separate processes,
 where each process will have its own interpreter and memory space, avoiding GIL issues. To leverage multiple concurrent processes, you can use Python's `multiprocessing` module.
 
 Here is an example of how to run concurrent transactions with `multiprocessing` module:
@@ -685,7 +702,7 @@ from neo4j import GraphDatabase
 HOST_PORT = "bolt://localhost:7687"
 
 def process_chunk(query, create_list):
-    try: 
+    try:
         driver = GraphDatabase.driver(HOST_PORT, auth=("", ""))
         with driver.session() as session:
             session.run(query, {"batch": create_list})
@@ -706,7 +723,7 @@ with multiprocessing.Pool(10) as pool:
     pool.starmap(process_chunk, [(query, chunk) for chunk in chunks])
 ```
 
-Each process will execute a query that contains a chunk of nodes.  
+Each process will execute a query that contains a chunk of nodes.
 You can control the number of concurrent transactions and processes by
 specifying the number of processes in the `multiprocessing.Pool` constructor.
 Each transaction will be a separate connection to the database and will be
@@ -719,7 +736,7 @@ conflicting transactions. The typical scenario is when two transactions try to
 update the same node simultaneously, or add a relationship to the same node. It
 is a write-write conflict between transactions. In this case, the first
 transaction will pass, and one of the transactions will fail, and you will need
-to handle the error and retry the transaction. 
+to handle the error and retry the transaction.
 
 If you are running transactions in parallel, you should avoid [implicit
 transactions](#implicit-transactions) because you can't control the execution
@@ -728,7 +745,7 @@ process, and there are no retries.
 You can use the [managed transactions](#managed-transactions) or [explicit
 transactions](#explicit-transactions) to handle the conflicting transactions.
 Explicit API provides full control of the process, and it is recommended for
-production use and handling conflicts. 
+production use and handling conflicts.
 
 Here is an example of how to handle conflicting transactions in explicit API:
 
@@ -742,7 +759,7 @@ def process_chunk(query, create_list, max_retries=100, initial_wait_time=0.200,
                 tx.commit()
                 break
         except TransientError as te:
-            jitter = random.uniform(0, jitter) * initial_wait_time 
+            jitter = random.uniform(0, jitter) * initial_wait_time
             wait_time = initial_wait_time * (backoff_factor ** attempt) + jitter
             print(f"Commit failed on attempt {attempt+1}. Retrying in {wait_time} seconds...")
             time.sleep(wait_time)
@@ -756,9 +773,9 @@ In the example above, we are using the `begin_transaction()` method to start a
 transaction, and then we are running the query inside the transaction. If the
 transaction fails with a `TransientError,` the transaction will be retried using
 the retry strategy. Otherwise, another error occurred, and the transaction
-should be aborted. 
+should be aborted.
 
-The essential aspects of the retry strategy are the following arguments: 
+The essential aspects of the retry strategy are the following arguments:
 
 - `max_retries` - the maximum number of retries before the transaction will be
 aborted with a timeout error. This number should be set based on the expected
@@ -776,7 +793,7 @@ for 2 minutes + waiting time.
   retry. If there are a lot of transactions running in parallel, it is
   recommended to use `jitter` to avoid the thundering herd problem.
 
-If you use managed transactions, you can configure the retry scenario to use the `session` configuration. Here is an example: 
+If you use managed transactions, you can configure the retry scenario to use the `session` configuration. Here is an example:
 
 ```python
 import multiprocessing
@@ -807,18 +824,18 @@ In this case, the `TransientError` will be retried using the retry strategy that
 The essential configuration arguments are the following:
 
 - `max_transaction_retry_time` - the maximum time the transaction will be
-  retried; after that, it will be aborted with a timeout error. 
+  retried; after that, it will be aborted with a timeout error.
 - `initial_retry_delay` - the time that the transaction will wait before the
-  first retry. 
+  first retry.
 - `retry_delay_multiplier` - the factor by which the retry delay will be
   multiplied after each retry.
 - `retry_delay_jitter_factor` - the factor by which the retry delay will be
-  randomized after each retry. 
+  randomized after each retry.
 
 <Callout type="info">
 
 If you are still struggling with conflicts and serialization errors while using a Python client, we recommend
 referring to our [Serialization errors](/help-center/errors/serialization) page
-for detailed guidance on troubleshooting and best practices. 
+for detailed guidance on troubleshooting and best practices.
 
 </Callout>

pages/data-migration/csv.mdx

@@ -230,12 +230,12 @@ There are also two variations of the files: files with a header and files withou
   - [`people_relationships_wh.csv`](https://public-assets.memgraph.com/import-data/load-csv-cypher/one-type-nodes/people_relationships_wh.csv)<br/>
     The file contains the following data:
       ```plaintext
-      id_from,id_to
-      100,101
-      100,102
-      100,103
-      101,103
-      102,104
+      id_from,id_to,type
+      100,101,IS_FRIENDS_WITH
+      100,102,IS_FRIENDS_WITH
+      100,103,IS_FRIENDS_WITH
+      101,103,IS_FRIENDS_WITH
+      102,104,IS_FRIENDS_WITH
       ```
   </Tabs.Tab>
   <Tabs.Tab>
@@ -285,13 +285,7 @@ There are also two variations of the files: files with a header and files withou
     ```
 
     If successful, you should receive an `Empty set (0.014 sec)` message.
-
-    You can also create, set, or remove labels using property values, here is an example:
-
-    ```cypher
-    LOAD CSV FROM "/path-to/people_nodes_wh.csv" WITH HEADER AS row
-    CREATE (p:row.label {id: row.id, name: row.name});
-    ```
+    Notice how **node labels can be dynamically created* from the CSV file.
 
   </Tabs.Tab>
   <Tabs.Tab>
@@ -335,10 +329,11 @@ There are also two variations of the files: files with a header and files withou
     ```cypher
     LOAD CSV FROM "/path-to/people_relationships_wh.csv" WITH HEADER AS row
     MATCH (p1:Person {id: row.id_from}), (p2:Person {id: row.id_to})
-    CREATE (p1)-[:IS_FRIENDS_WITH]->(p2);
+    CREATE (p1)-[:row.type]->(p2);
     ```
 
     If successful, you should receive an `Empty set (0.014 sec)` message.
+    Notice how **relationship types can be dynamically created** from the CSV file.
 
   </Tabs.Tab>
   <Tabs.Tab>

pages/data-modeling/graph-data-model/lpg-vs-rdf.mdx

@@ -102,6 +102,8 @@ format.
 
 ## Key differences between LPG and RDF
 
+![rdf-vs-lpg](/pages/data-modeling/graph-modeling/rdf-vs-lpg.png)
+
 | **Feature** | **LPG** | **RDF** |
 | --- | --- | --- |
 | **Data Structure** | Labeled nodes and edges with properties | Triples: subject-predicate-object |

pages/database-management/authentication-and-authorization.mdx

@@ -21,3 +21,8 @@ Learn how to manage roles, set up their privileges and fine-grained access contr
 
 Learn how to integrate with third-party auth systems and manage user
 authentication and access control using Memgraph's auth module. 
+
+## [Impersonate user](/database-management/authentication-and-authorization/impersonate-user) (Enterprise)
+
+Learn how the impersonate user feature enables authorized users to execute
+queries with the full permissions and context of another user.

pages/database-management/authentication-and-authorization/_meta.ts

@@ -1,6 +1,6 @@
 export default {
     "users": "Users",
     "role-based-access-control": "Role-based access control",
-    "auth-system-integrations": "Auth system integrations"
+    "auth-system-integrations": "Auth system integrations",
+    "impersonate-user": "Impersonate user"
 }
-  

pages/database-management/authentication-and-authorization/impersonate-user.mdx

@@ -0,0 +1,132 @@
+---
+title: Impersonate user
+description: Learn how the impersonate user feature enables authorized users to execute queries with the full permissions and context of another user.
+---
+
+import { Callout } from 'nextra/components'
+import {CommunityLinks} from '/components/social-card/CommunityLinks'
+
+
+# Impersonate user (Enterprise)
+
+
+
+The **impersonate user** feature lets authorized users run queries on behalf of
+another user. When using impersonation, the permitted user adopts the full
+permissions and context of the impersonated user. This means they can execute
+queries and perform actions exactly as the impersonated user, with all
+associated privileges.
+
+This feature provides a powerful tool for managing user permissions, debugging,
+and performing administrative tasks. By leveraging the ability to impersonate
+other users, you can ensure more efficient management of users and roles while
+maintaining robust security and access control within your graph database.
+
+<Callout type="info">
+
+**Enterprise**: Impersonate user feature requires a Memgraph Enterprise license to
+function. For more information on Memgraph Enterprise and instructions
+on how to enable it, refer to the
+[enabling Memgraph Enterprise documentation](/database-management/enabling-memgraph-enterprise).
+
+</Callout>
+
+## Targeting impersonation
+
+The impersonated user is defined at the session start, as shown in the example
+using the Neo4j Python driver:
+
+```python
+with driver.session(impersonated_user="user1") as session:
+    # queries here will be executed as if user1 executed them
+```
+
+During this session, all queries will be executed with the privileges and
+context of the impersonated user (`user1` in this case), effectively "switching"
+the identity for the duration of the session.
+
+## Permissions for impersonation
+
+Only certain users or roles have the ability to impersonate other users. These permissions are managed with three key queries:
+- [`GRANT IMPERSONATE_USER`](#grant-impersonate-user)
+- [`DENY IMPERSONATE_USER`](#deny-impersonate-user)
+- [`REVOKE IMPERSONATE_USER`](#revoke-impersonate-user)
+
+### Grant impersonate user
+
+The `GRANT IMPERSONATE_USER` query allows a user or role to impersonate specific users or all users. The syntax and behavior are as follows:
+
+```cypher
+GRANT IMPERSONATE_USER [*] [list of users] TO user/role;
+```
+
+Here is the explanation of arguments:
+- `*`: Grants permission to impersonate all users.
+- `list of users`: Grants permission to impersonate specific users (comma-separated list).
+- `user/role`: The user or role receiving the impersonation permission.
+
+Here is an example of granting the `admin` role permission to impersonate `user1` and `user2`:
+```cypher
+GRANT IMPERSONATE_USER user1,user2 TO admin;
+```
+
+Here is an example of granting the `admin_user` user permission to impersonate all users:
+```cypher
+GRANT IMPERSONATE_USER * TO admin_user;
+```
+
+### Deny impersonate user
+
+The `DENY IMPERSONATE_USER` denies impersonation rights to specific users or roles, allowing you to restrict who can impersonate whom.
+The syntax and behavior are as follows:
+
+```cypher
+DENY IMPERSONATE_USER list of users TO user/role;
+```
+
+Here is the explanation of arguments:
+- `list of users`: Deny impersonation for specific users (comma-separated list).
+- `user/role`: The user or role being restricted from impersonating others.
+
+Here is an example of denying the `admin` role the ability to impersonate `user1` and `user2`:
+```cypher
+DENY IMPERSONATE_USER user1,user2 TO admin;
+```
+
+### Revoke impersonate user
+
+The `REVOKE IMPERSONATE_USER` removes the impersonation rights for a given user or role. It revokes all impersonation permissions for the specified user/role.
+The syntax and behavior are as follows:
+
+```cypher
+REVOKE IMPERSONATE_USER FROM user/role;
+```
+
+Here is the explanation of arguments:
+- `user/role`: The user or role whose impersonation permissions are being revoked.
+
+Here is an example of revoking all impersonation permissions for the `admin` role:
+```cypher
+REVOKE IMPERSONATE_USER FROM admin;
+```
+
+<Callout type="info">
+**Important things to note**
+
+When using the `GRANT` or `DENY` commands, you must provide exhaustive lists of users. This means that the existing configuration will be replaced by the new list provided.
+For example:
+- First command:
+  ```cypher
+  GRANT IMPERSONATE_USER user1,user2 TO admin;
+  ```
+- Second command (this overrides the first one):
+  ```cypher
+  GRANT IMPERSONATE_USER user3 TO admin;
+  ```
+  After the second command, the `admin` role will only be able to impersonate `user3`, even though the first command allowed impersonation of `user1` and `user2`.
+
+Permissions can be granted or denied to individual users or roles. For example, an `admin` role might have impersonation privileges that individual users do not have.
+The `REVOKE` command removes any impersonation permissions for the specified user or role, ensuring that they cannot impersonate any user unless granted explicitly again.
+</Callout>
+
+<CommunityLinks/>