Difference between revisions of "Features/Custom code"

From TempusServa wiki
Jump to navigation Jump to search
 
(3 intermediate revisions by the same user not shown)
Line 28: Line 28:


=== Status actions ===  
=== Status actions ===  
Actions will allow certain code to run as if it where a normal status action: Timed, On enter, On leav
Actions will allow certain code to run as if it where a normal status action: Timed, On enter, On leave


Link via: Designer > Entity > STATUS > STATUS ACTION > Codeunit
Link via: Designer > Entity > STATUS > STATUS ACTION > Codeunit
Line 41: Line 41:


Link via: Designer > Modules > Configuration > dk.p2e.blanket.codeunit.common.PageStaticContent
Link via: Designer > Modules > Configuration > dk.p2e.blanket.codeunit.common.PageStaticContent
== TS NoCode API ==
The TS API will enable access to all relevant things in the system, including your own custome models.
Data can be queried and updated via the object model, that will ensure that all rules og permissions are respected.
See deatils and code examples in [[API_v1.0]] 
All requests will be passed references to
* DB connetion
* User profile
** Session variables
* Server seetings
** Policies
** Cache


== Custom security ==
== Custom security ==
Custom security is an option in Event handlers, that allows you to build custom security schemes.


 
Usecases include
== API ==
* Users profile must be related to some other data
* Users permissions are change over time
* A records attributes defines who may see it
* Access to records are governed by the records relation to other records
You simple write an SQL filter that can be appended to all dayabase queries relating to that enity.

Latest revision as of 11:14, 10 November 2024

Usage

In some cases there will be a need for specialized functionality.

Using codeunits you use all of the existing nocode features, and just do the special features in custom code.

The platform will handle WHEN to execute the code, while you make the code do WHAT you want.

Note that custom extensions are loaded dynamically, so the platform can still be updated independntly of your custom code.

Many extension points

Your custom code can be plugged into various ponts

Pages

A page will display file or HTML content, with or without navigation wrapped around it.

Normal pages will only be served to authenticated users, while the public variant can be served to anyone accessing the URL.

Link via: URL (example: main?command=xxx)

Event handlers

An eventhandler will extend the behavior of an existing entity.

Multiple function handles ensure your code can be executed at the right time: beforeSelect, beforeRender, beforeUpdate etc.

In addition it is also possible control navigation flow after updates or build custom permission schemes (see below).

Link via: Designer > Entity > Advanced > Codeunit

Status actions

Actions will allow certain code to run as if it where a normal status action: Timed, On enter, On leave

Link via: Designer > Entity > STATUS > STATUS ACTION > Codeunit

Scheduled code

This is used for custom code that you need to run without user intervention.

Link via: Designer > Modules > Configuration > serviceRunCustomCodeunitClass

Global content

This codeunit can inject HTML content into all pages on that instance.

Link via: Designer > Modules > Configuration > dk.p2e.blanket.codeunit.common.PageStaticContent

TS NoCode API

The TS API will enable access to all relevant things in the system, including your own custome models.

Data can be queried and updated via the object model, that will ensure that all rules og permissions are respected.

See deatils and code examples in API_v1.0

All requests will be passed references to

  • DB connetion
  • User profile
    • Session variables
  • Server seetings
    • Policies
    • Cache

Custom security

Custom security is an option in Event handlers, that allows you to build custom security schemes.

Usecases include

  • Users profile must be related to some other data
  • Users permissions are change over time
  • A records attributes defines who may see it
  • Access to records are governed by the records relation to other records

You simple write an SQL filter that can be appended to all dayabase queries relating to that enity.