You have been redirected from an outdated version of the article.
Below is the content available on this topic. To view the old article click here.
link
The link
keyword references the linked node of an element.
Only works for <a>
, <link>
, <script>
or <img>
nodes. See Filesystem and Pages Tree View for more info.
The link
keyword can only be accessed if a node of the above types is actually linked to a filesystem element. It can be linked via the link icon which is displayed when hovering over a node.
Search results for "link"
link
The link
keyword references the linked node of an element.
Only works in a
, link
, script
or img
tags/nodes. See Filesystem and Pages Tree View for more info.
The link
keyword can only be accessed if a node of the above types is actually linked to a filesystem element. It can be linked via the link icon which is displayed when hovering over a node.
LinkedIn
oauth.linkedin.authorization_location | URL of the authorization endpoint. |
oauth.linkedin.token_location | URL of the token endpoint. |
oauth.linkedin.client_id | Client ID used for oauth. |
oauth.linkedin.client_secret | Client secret used for oauth. |
oauth.linkedin.redirect_uri | Structr endpoint for the service oauth authorization. |
oauth.linkedin.user_details_resource_uri | Points to the user details endpoint of the service provider. |
oauth.linkedin.user_profile_resource_uri | Points to the user profile endpoint of the service provider. |
oauth.linkedin.error_uri | Structr redirects to this URI on unsuccessful authentication. |
oauth.linkedin.return_uri | Structr redirects to this URI on successful authentification. |
oauth.linkedin.scope | Specifies the scope of the authentifcation. |
User self-registration
Instead of creating users in the Structr backend manually in the Users and Groups section of Structr’s admin UI, you can allow users to sign-up/self-register. The registration process uses double-opt in by default. All you need is a simple page where new users can enter their e-mail address so Structr can send them an e-mail with a confirmation link.
The following pre-defined MailTemplate keys can be used to configure the self-registration process. In version 4.0 they have been renamed to have a more uniform structure.
Note: The Mail Configuration Settings have to be done for self-registration mails to be sent.
Name | Old Name (removed as of v4.1) | Used as | Default |
CONFIRM_REGISTRATION_SENDER_ADDRESS | SENDER_ADDRESS | The sender address of the registration mail | structr-mail-daemon@localhost |
CONFIRM_REGISTRATION_SENDER_NAME | SENDER_NAME | The sender name of the registration mail | Structr Mail Daemon |
CONFIRM_REGISTRATION_SUBJECT | SUBJECT | The subject of the registration mail | Welcome to Structr, please finalize registration |
CONFIRM_REGISTRATION_TEXT_BODY | TEXT_BODY | The plaintext body of the registration mail | Go to ${link} to finalize registration. |
CONFIRM_REGISTRATION_HTML_BODY | HTML_BODY | The HTML body of the registration mail | <div>Click <a href='${link}'>here</a> to finalize registration.</div> |
CONFIRM_REGISTRATION_BASE_URL | BASE_URL | Used to build the link variable | ${base_url} |
CONFIRM_REGISTRATION_TARGET_PAGE | TARGET_PAGE | the target parameter value for the redirection target page name | register_thanks |
CONFIRM_REGISTRATION_ERROR_PAGE | ERROR_PAGE | the error parameter value for the error redirection target page name | register_error |
Notes:
- The visibility flags of these MailTemplates are ignored because the self-registration mail is created as a privileged user.
- A special
link
variable is provided for the TEXT_BODY
and HTML_BODY
templates and can be output with the usual syntax: ${link}
- Example
link
: https://support.structr.com/confirm_registration?key=<CONFIRM_KEY>&target=/dashboard&onerror=/register-error
- From v4.1 scripting is enabled in two templates:
CONFIRM_REGISTRATION_TEXT_BODY
and CONFIRM_REGISTRATION_TEXT_BODY
. The script is being run in the context of the user (me keyword points to the user).
- In any version prior to 4.1 scripting can not be used and simple text replacement is done
Password Reset
To allow users to regain access to their account when they forgot their password we need to enable them to reset their password.
Note: The Mail Configuration has to be done for password retrieval mails to be sent.
Name | Used as | Default |
RESET_PASSWORD_SENDER_ADDRESS | Sender address | structr-mail-daemon@localhost |
RESET_PASSWORD_SENDER_NAME | Sender name | Structr Mail Daemon |
RESET_PASSWORD_SUBJECT | Subject line | Request to reset your Structr password |
RESET_PASSWORD_TEXT_BODY | Plaintext mail body | Go to ${link} to reset your password. |
RESET_PASSWORD_HTML_BODY | HTML mail body | <div>Click <a href='${link}'>here</a> to reset your password.</div> |
RESET_PASSWORD_BASE_URL | Used to build the link variable | ${base_url} |
RESET_PASSWORD_TARGET_PAGE | target parameter value in the link variable. Specifies the redirect page after successful login. | /reset-password |
Notes:
- The visibility flags of these MailTemplates are ignored because the self-registration mail is created as a privileged user.
- A special
link
variable is provided for the TEXT_BODY
and HTML_BODY
templates and can be output with the usual syntax: ${link}
- Example
link
: https://support.structr.com/reset-password?key=<PASSWORD-RESET-KEY>&target=/reset-password
- From v4.1 scripting is two templates:
RESET_PASSWORD_TEXT_BODY
and RESET_PASSWORD_HTML_BODY
. The script is being run in the context of the user (me keyword points to the user).
- In any version prior to 4.1 scripting can not be used and simple text replacement is done.
Changelog
{"time":1455195862431,"userId":"f02e59a47d[...]","userName":"admin","verb":"change","key":"name","prev":null,"val":"My new name"}
{"time":1455195903852,"userId":"f02e59a47d[...]","userName":"admin","verb":"change","key":"name","prev":"My new name","val":"New Name"}
{"time":1455196049579,"userId":"f02e59a47d[...]","userName":"admin","verb":"link","rel":"has","relId":"97d26b5778[...]026eb615e","relDir":"out","target":"4e32a9f6eb[...]bd7a6a"}
{"time":1455195961348,"userId":"f02e59a47d[...]","userName":"admin","verb":"unlink","rel":"has","relId":"97d26b5778[...]026eb615e","relDir":"out","target":"4e32a9f6eb[...]bd7a6a"}
{"time":1455196115875,"userId":"00000000000000000000000000000000","userName":"superadmin","verb":"unlink","rel":"OWNS","relId":"b29e98329fb[...]864aa038","relDir":"out","target":"f02e59a47d[...]"}
Relationship Details Dialog
The Cascading Delete
settings allow configuration of what happens when either end of the relationship is deleted. The possible values are explained in-depth in the help popup in the dialog.
Automatic Creation of Related Nodes
configures if it is allowed to include nested nodes in a REST POST request for this relationship. A node with the given property set is automatically created and linked to the node. If the nested node contains an id
attribute (or another property marked as unique) a node is searched for that property and linked if found.
Permission Resolution
allows configuration of rights propagation in the graph. If NONE
is selected, no rights propagation is applied for this relationship. If SOURCE_TO_TARGET
is selected the rights are propagated along the relationship direction to the next node. For TARGET_TO_SOURCE
the rights propagation is works against the relationship direction. For ALWAYS
the direction of the relationship does not matter and rights propagation is always applied.
Specific rights (Read
, Write
, Delete
, AccessControl
) can be added, kept or removed according to the propagation configuration. If a user has read rights to the previous node and Read
is configured to Keep
, the user also has read rights for the next node. (Specific User/Group rights are applied before using permission propagation - i.e. if a user has specific rights configured for a node, permission resolution is not evaluated as user rights are more specific).
Along the way of permission propagation, properties can be hidden in order to hide sensitive information from users who get rights from permission propagation. The property names can be separated by comma ,
or space
character.
There are 3 tabs where the functionality of the type can be configured:
Local Attributes
A Custom Type can be extended with dynamic properties to provide the data model for the intended use-case. This list contains all local properties (meaning they are defined on this type directly).
Views
The properties of a type can be combined into named Views, which are accessible under an individual REST URL. Access to these URLs can be configured independently for each HTTP method using Resource Access Grants, which makes them an ideal tool to create specialised endpoints for different client applications (e.g. mobile clients etc.).
Methods
There are different kinds of methods - callback methods and entity methods. Callback methods are automatically executed by the framework upon certain lifecycle events and have a strict naming convention. Entity methods are called by the user/programmer.
Entity methods are not automatically run by the framework and must be called manually. This either means making a POST request to /structr/rest/(Type)/(<a data-id="7c9c8218bced42bab66868373e64d885" class="mention">UUID</a>)/(methodName)
or in serverside JavaScript as node.methodName();
This type-awareness is also available for the remote properties of the entities in the graph database. Entities (or nodes in the graph database) can be linked in the table by clicking on the “+” icon in the cells and selecting the node that should be linked.
Buttons
Icon | Action |
| Clone element and all its children |
| Open Properties dialog |
| Delete element and all its children |
| Remove element and all its children |
| Open Access Control and Visibility Dialog |
| Open Edit Content Dialog |
| Open Edit Link Dialog |
Data Model
You can define directed edges between node types and annotate then with a name and cardinality (1:1, 1:n, n:m). Structr uses the structure defined by nodes and relationships as a blueprint for the datastructures in the database. It also takes care that the data is consistent by preventing the creation of invalid structures. In a 1:1 relationship for example, an object can only ever be linked to exactly one other object. If another object is assigned, the previous relationship will be removed. Structr also maintains the type safety of related objects by allowing only those types to be linked to each other that match the schema.
Permission Grants
The SECURITY
relationship can have different combinations of permissions in its allowed
attribute:
read | The user has access to the node and can read the node from the database. |
write | The user can alter the node in the database. This permission is also necessary for linking or unlinking the node to other nodes in the graph. |
delete | The user can delete the node from the database. If a node has relationships to other nodes in the database, the user has to have write permissions on those connected nodes, because delete one node in the graph will affect all neighboring nodes. |
accessControl | The user can grant access to other users and user groups. |
Changelog
Key | Content |
verb | type of changelog event (One of create , change , delete , link , unlink ) |
time | Timestamp of the change (ms since epoch) |
userId | id of the user, 00000000000000000000000000000000 for SuperUser, null for anonymous |
userName | name of the user who triggered the modification |
target | id of the target node of the new or deleted relationship |
relId | id created/deleted relationship |
rel | relationship type of the created/deleted relationship |
relDir | relationship direction of the created/deleted relationship (in/out) |
key | Property key of the modified property |
prev | Previous value of the modified property |
val | New value of the modified property |
Step 3: Create MQTTClient and MessageSubscriber
In our structr instance we navigate to the data section and select the type MQTTClient
.
We create a new object with the following attributes (the default settings for RabbitMQ)
mainBrokerURL = 'ws://localhost:15675/ws'
username = 'guest'
password = 'guest'
Afterwards we check the isEnabled
checkbox which triggers the client to connect to the server. If everything is configured properly it will blink green - otherwise it will blink red and result in an error.
Then we select the type MessageSubscriber
and create a new MessageSubscriber with the following attributes:
topic = '*'
callback = "{ $.log($.topic, ': ', $.message) }"
This instructs the subscriber to listen to any topic and simply log the messages to the server log. We could also forward the messages to any global schema method - for example handleIncomingMQTTMessage
like this:
{
$.call('handleIncomingMQTTMessage', { topic: $.topic, message: $.message });
}
Type Details Dialog
There are 5 tabs where the functionality of the type can be configured:
-
Local Attributes
A Custom Type can be extended with dynamic properties to provide the data model for the intended use-case. This list contains all local properties (meaning they are defined on this type directly).
-
Views
The properties of a type can be combined into named Views, which are accessible under an individual REST URL. Access to these URLs can be configured independently for each HTTP method using Resource Access Grants, which makes them an ideal tool to create specialised endpoints for different client applications (e.g. mobile clients etc.).
-
Methods
There are different kinds of methods - callback methods and entity methods. Callback methods are automatically executed by the framework upon certain lifecycle events and have a strict naming convention. Entity methods are called by the user/programmer.
Entity methods are not automatically run by the framework and must be called manually. This either means making a POST request to /structr/rest/<Type>/<UUID>/<methodName>
or in serverside JavaScript as <node>.<methodName>();
-
Remote Attributes
Custom types can be linked to other types, including base types. Structr will automatically create Remote Attributes on either side of the link, which can then be used to create, update or remove the relationships between instances of the two types. In this tab the configuration of the remote attributes can be viewed and edited. The names configured here are used throughout the application to refer to the other side of the relationship(s).
-
Inherited Attributes
The content of this tab is of informative character. All inherited attributes are shown with an information from where it was inherited.
Changelog
Verb | Event type | Keys in changeset |
create | Creation of an object | verb ,time ,userId ,userName ,target |
delete | Deletion of an object | verb ,time ,userId ,userName ,target |
link | A relationship to/from another object has been created | verb ,time ,userId ,userName ,target , rel |
unlink | A relationship to/from another object has been removed | verb ,time ,userId ,userName ,target , rel |
change | One of the properties of the object has been changed | verb ,time ,userId ,userName ,key , prev , val |
Password Reset Resource
The reset password process should be done via the reset password resource. It is available under /structr/rest/reset-password
.
An un-authenticated user can issue a HTTP POST to that resource to begin the registration process. The accepted input attributes are configured in the configuration registration.customuserattributes
. eMail
is always supported and often used as a single attribute for registration.
The reset password process is then started by the user by making a HTTP POST request to /structr/rest/reset-password
with the following body:
fetch("http://localhost:8082/structr/rest/reset-password", {
method: "POST",
body: JSON.stringify({
eMail: "user.name@mail.com"
})
})
The reset password process would then send a mail using the above templates.
Notes:
- A resource access grant must be configured for public users to allow the POST method to the grant with signature
_resetPassword
- the configuration setting
JsonRestServlet.user.autologin
must be set to true to enable auto-login with the link in the email
- the link in the mail is only valid once