├── .well-known └── funding-manifest-urls ├── docs ├── Gemfile ├── _config.yml ├── tocbot-3.0.2 │ ├── tocbot.css │ ├── styles.css │ └── tocbot-min.js ├── _layouts │ └── default.html └── coderay-asciidoctor.css ├── old-docs ├── resources │ ├── bw-basic-arch.png │ ├── eventRegAdminForm.png │ └── eventRegRegistered.png ├── development │ ├── development-toc.md │ ├── caldavtester.md │ └── todo.md ├── administrators │ ├── admin-toc.md │ ├── eventRegistration.md │ └── subscriptions.md ├── deployers │ ├── deployer-toc.md │ ├── locations.md │ ├── installing-old.md │ ├── elasticsearch.md │ ├── configure-wildfly.md │ ├── installing.md │ ├── eventRegistration.md │ ├── synch-engine.md │ └── databases.md ├── md-index.md ├── intro │ ├── technologies.md │ ├── history.md │ ├── introduction.md │ ├── standards.md │ ├── system-overview.md │ └── features.md └── schema │ ├── wildfly │ ├── wildfly-request-controller_1_0.xsd │ ├── wildfly-feature-pack-build-1_0.xsd │ ├── wildfly-feature-pack-build-1_1.xsd │ ├── wildfly-core-management_1_0.xsd │ ├── jboss-as-jmx_1_3.xsd │ ├── wildfly-security-manager_1_0.xsd │ ├── jboss-as-deployment-scanner_2_0.xsd │ ├── wildfly-io_3_0.xsd │ └── jboss-as-naming_2_0.xsd │ └── galleon-package-2_0.xsd ├── .gitignore ├── src └── main │ └── asciidoc │ ├── foreword.adoc │ ├── resources │ └── bw-basic-arch.png │ ├── deployers │ ├── eventRegistration.adoc │ ├── locations.adoc │ ├── keycloak-saml.adoc │ ├── installing.adoc │ ├── deploying-servers.adoc │ ├── configure-wildfly.adoc │ ├── opensearch.adoc │ ├── databases.adoc │ └── synch-engine.adoc │ ├── sometime │ └── sometime.adoc │ ├── administrators │ ├── workflow.adoc │ ├── eventRegistration.adoc │ ├── errors.adoc │ ├── aliasStructureOverview.adoc │ ├── authusers.adoc │ ├── reindex.adoc │ ├── addTopicalArea.adoc │ └── subscriptions.adoc │ ├── overview │ ├── issues.adoc │ ├── technologies.adoc │ ├── standards.adoc │ ├── history.adoc │ ├── system-overview.adoc │ ├── xslchanges.adoc │ └── features.adoc │ ├── development │ ├── debugging.adoc │ ├── caldavtester.adoc │ ├── github-actions.adoc │ ├── building.adoc │ └── todo.adoc │ ├── tocbot-3.0.2 │ ├── tocbot.css │ └── styles.css │ ├── docinfo │ ├── docinfo.html │ └── docinfo-footer.html │ ├── introduction.adoc │ └── index.adoc ├── system-links └── installed-systems.txt ├── config └── bedework │ └── calsocket │ └── calsocket.xml ├── data └── addPublicAuth.txt ├── bedework.iml ├── .idea ├── modules.xml ├── inspectionProfiles │ └── Project_Default.xml └── vcs.xml ├── pom.xml └── README.md /.well-known/funding-manifest-urls: -------------------------------------------------------------------------------- 1 | https://www.apereo.org/funding.json -------------------------------------------------------------------------------- /docs/Gemfile: -------------------------------------------------------------------------------- 1 | source "https://rubygems.org" 2 | 3 | gem "github-pages", group: :jekyll_plugins 4 | -------------------------------------------------------------------------------- /old-docs/resources/bw-basic-arch.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/Bedework/bedework/HEAD/old-docs/resources/bw-basic-arch.png -------------------------------------------------------------------------------- /.gitignore: -------------------------------------------------------------------------------- 1 | .settings 2 | .classpath 3 | .project 4 | target 5 | .idea 6 | tmp 7 | /system-links/test* 8 | /system-links/wildfly* 9 | -------------------------------------------------------------------------------- /old-docs/resources/eventRegAdminForm.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/Bedework/bedework/HEAD/old-docs/resources/eventRegAdminForm.png -------------------------------------------------------------------------------- /old-docs/resources/eventRegRegistered.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/Bedework/bedework/HEAD/old-docs/resources/eventRegRegistered.png -------------------------------------------------------------------------------- /src/main/asciidoc/foreword.adoc: -------------------------------------------------------------------------------- 1 | The Bedework system supports both personal and group calendaring and scheduling and public events. 2 | 3 | -------------------------------------------------------------------------------- /src/main/asciidoc/resources/bw-basic-arch.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/Bedework/bedework/HEAD/src/main/asciidoc/resources/bw-basic-arch.png -------------------------------------------------------------------------------- /old-docs/development/development-toc.md: -------------------------------------------------------------------------------- 1 | # Developers pages 2 | * [Todo list](todo.md) 3 | * [Running the caldav tester](caldavtester.md) 4 | -------------------------------------------------------------------------------- /old-docs/administrators/admin-toc.md: -------------------------------------------------------------------------------- 1 | # Administrators table of contents 2 | 3 | [Public Events Registration](eventRegistration.md) 4 | 5 | [Subscribing to external feeds](subscriptions) 6 | -------------------------------------------------------------------------------- /system-links/installed-systems.txt: -------------------------------------------------------------------------------- 1 | This directory is used to hold symlinks to installed systems to make them visible to the IDE. 2 | 3 | Nothing, other than this file and those links, should be added to this directory. -------------------------------------------------------------------------------- /src/main/asciidoc/deployers/eventRegistration.adoc: -------------------------------------------------------------------------------- 1 | [[configure-events-registration]] 2 | === Enabling and Disabling Public Events Registration 3 | 4 | Full documentation is available at https://bedework.github.io/bw-event-registration/[github pages for the event registration project] 5 | -------------------------------------------------------------------------------- /src/main/asciidoc/sometime/sometime.adoc: -------------------------------------------------------------------------------- 1 | == Bedework Sometime 2 | 3 | This is a fork of the Apereo (formerly jasig) scheduling assistant project. It was developed at the University of Wisconsin and provides a way for students to book time with faculty. 4 | 5 | See the bw-sometime documentation at ... 6 | -------------------------------------------------------------------------------- /src/main/asciidoc/administrators/workflow.adoc: -------------------------------------------------------------------------------- 1 | [[workflow]] 2 | === Workflow Support 3 | 4 | Workflow support is enabled by a system property: ... 5 | 6 | ==== Approver users 7 | An approver user is an admin user with approval rights. These may be explicitly added to the user as an *approver* role (see ...). -------------------------------------------------------------------------------- /config/bedework/calsocket/calsocket.xml: -------------------------------------------------------------------------------- 1 | 2 | 3 | 4 | http://localhost:8080/socketws 5 | abcd 6 | 7 | -------------------------------------------------------------------------------- /docs/_config.yml: -------------------------------------------------------------------------------- 1 | theme: jekyll-theme-slate 2 | # remote_theme: "mmistakes/minimal-mistakes@4.14.1" 3 | 4 | github: 5 | repository_name: Bedework 6 | project_tagline: An Enterprise Calendaring and Scheduling Server 7 | 8 | title: Bedework 9 | show_downloads: true 10 | 11 | plugins: 12 | - jekyll-include-cache 13 | -------------------------------------------------------------------------------- /old-docs/deployers/deployer-toc.md: -------------------------------------------------------------------------------- 1 | # Deployers pages 2 | 3 | * [Installing the quickstart](installing.md) 4 | * [Configuring Wildfly](configure-wildfly.md) 5 | * [Setting up databases](databases.md) 6 | * [Configuring and deploying OpenSearch](opensearch.md) 7 | * [Public Events Registration](eventRegistration.md) 8 | * [Deploying the sync engine](synch-engine) 9 | -------------------------------------------------------------------------------- /old-docs/md-index.md: -------------------------------------------------------------------------------- 1 | # Bedework Enterprise Calendar System 2 | 3 | The Bedework system supports both personal and group calendaring and scheduling and public events. 4 | 5 | [Introducing bedework](intro/introduction.md) 6 | 7 | [Pages for administrators](administrators/admin-toc) 8 | 9 | [Pages for deployers](deployers/deployer-toc.md) 10 | 11 | [Pages for developers](development/development-toc.md) 12 | -------------------------------------------------------------------------------- /src/main/asciidoc/overview/issues.adoc: -------------------------------------------------------------------------------- 1 | [[issues]] 2 | === Issues 3 | 4 | * Modifying a recurring event so that it is not recurring will leave instances indexed. 5 | 6 | * CalintfHelper.getCollection returns null - causes failures higher up. 7 | 8 | * Index waits and refresh could be set to only occur on testing if there is any real performance issue. Generally - in real life - the delay isn't a problem. 9 | 10 | * Should I be removing the entity from entity caches in the indexer? 11 | 12 | 13 | -------------------------------------------------------------------------------- /old-docs/intro/technologies.md: -------------------------------------------------------------------------------- 1 | # Underlying technologies 2 | The following lists some of the core technologies used by the Bedework platform: 3 | 4 | * Apache Struts MVC 5 | * CalDAV 6 | * Cascading Style Sheets (CSS) 7 | * iCAL: RFC 5545 8 | * iCal4j 9 | * Java Servlet API 10 | * Java Server Pages (JSP) 11 | * JavaScript (including jcal, jQuery, jQueryUI, Bootstrap, and others) 12 | * Portlet API: JSR-168 13 | * XHTML 14 | * XML 15 | * XPath 16 | * XSLT 17 | 18 | See also [Calendaring Standards](standards.md) 19 | -------------------------------------------------------------------------------- /docs/tocbot-3.0.2/tocbot.css: -------------------------------------------------------------------------------- 1 | .toc{overflow-y:auto}.toc>ul{overflow:hidden;position:relative}.toc>ul li{list-style:none}.toc-list{margin:0;padding-left:10px}a.toc-link{color:currentColor;height:100%}.is-collapsible{max-height:1000px;overflow:hidden;transition:all 300ms ease-in-out}.is-collapsed{max-height:0}.is-position-fixed{position:fixed !important;top:0}.is-active-link{font-weight:700}.toc-link::before{background-color:#EEE;content:' ';display:inline-block;height:inherit;left:0;margin-top:-1px;position:absolute;width:2px}.is-active-link::before{background-color:#54BC4B} -------------------------------------------------------------------------------- /src/main/asciidoc/development/debugging.adoc: -------------------------------------------------------------------------------- 1 | [[Debugging-the-quickstart]] 2 | === Debugging the quickstart 3 | 4 | Need to write a bunch of stuff here - I use intellij. 5 | 6 | === Tracing database interactions 7 | Add the following to the wildfly logging configuration to see generated SQL and the values of the parameters: 8 | 9 | [source,xml] 10 | ---- 11 | 12 | 13 | 14 | 15 | 16 | 17 | ---- 18 | -------------------------------------------------------------------------------- /src/main/asciidoc/tocbot-3.0.2/tocbot.css: -------------------------------------------------------------------------------- 1 | .toc{overflow-y:auto}.toc>ul{overflow:hidden;position:relative}.toc>ul li{list-style:none}.toc-list{margin:0;padding-left:10px}a.toc-link{color:currentColor;height:100%}.is-collapsible{max-height:1000px;overflow:hidden;transition:all 300ms ease-in-out}.is-collapsed{max-height:0}.is-position-fixed{position:fixed !important;top:0}.is-active-link{font-weight:700}.toc-link::before{background-color:#EEE;content:' ';display:inline-block;height:inherit;left:0;margin-top:-1px;position:absolute;width:2px}.is-active-link::before{background-color:#54BC4B} -------------------------------------------------------------------------------- /src/main/asciidoc/overview/technologies.adoc: -------------------------------------------------------------------------------- 1 | [[technologies]] 2 | === Underlying technologies 3 | The following lists some of the core technologies used by the Bedework platform: 4 | 5 | * Apache Struts MVC 6 | * CalDAV 7 | * Cascading Style Sheets (CSS) 8 | * iCAL: RFC 5545 9 | * iCal4j 10 | * Java Servlet API 11 | * Java Server Pages (JSP) 12 | * JavaScript (including jcal, jQuery, jQueryUI, Bootstrap, and others) 13 | * Portlet API: JSR-168 14 | * XHTML 15 | * XML 16 | * XPath 17 | * XSLT 18 | 19 | See also xref::standards.adoc[Calendaring Standards] 20 | -------------------------------------------------------------------------------- /src/main/asciidoc/docinfo/docinfo.html: -------------------------------------------------------------------------------- 1 | -------------------------------------------------------------------------------- /src/main/asciidoc/administrators/eventRegistration.adoc: -------------------------------------------------------------------------------- 1 | [[public-events-registration]] 2 | === Public Events Registration 3 | 4 | Bedework supports a public events registration system that allows authenticated users to register for events. Users may view and modify their registrations, such as unregistering or changing the number of tickets they've requested. When registration is full, users may choose to be placed on a waiting list. Users on waiting lists will automatically be moved up in the queue if space becomes available. 5 | 6 | Full documentation is available at https://bedework.github.io/bw-event-registration/[github pages for the event registration project] 7 | 8 | -------------------------------------------------------------------------------- /src/main/asciidoc/administrators/errors.adoc: -------------------------------------------------------------------------------- 1 | [[Errors]] 2 | === Errors that may occur 3 | 4 | ==== Indexer errors 5 | The following error might be seen when attempting to make changes to any indexed object: 6 | ---- 7 | AuthorizationException(403, 'cluster_block_exception', 'blocked by: [FORBIDDEN/12/index read-only / allow delete (api)];') 8 | ---- 9 | 10 | The indexes have been made read-only - this can happen if, for example, the file system becomes full. 11 | 12 | The indexes may be unlocked by doing the following 13 | 14 | ---- 15 | curl -XPUT -H "Content-Type: application/json" http://localhost:9200/_all/_settings -d '{"index.blocks.read_only_allow_delete": null}' 16 | ---- 17 | -------------------------------------------------------------------------------- /old-docs/intro/history.md: -------------------------------------------------------------------------------- 1 | # Bedework History and Background 2 | 3 | Bedework was established in March 2005 in succession to UW Calendar. In December 2006 Bedework received the Andrew W. Mellon Foundation's Technology Collaboration (MATC) Award. Since then the project has prospered, and in early 2009, Bedework became an incubator project of Jasig (http://www.jasig.org/) now a part of the Apereo Foundation (http://www.apereo.org). 4 | 5 | Bedework is in use by institutions large and small, educational, governmental, commercial, and non-profit. 6 | 7 | Bedework is named after the Venerable Bede, a highly influential monk and scholar from the area of Northumbria in Britain who in 725AD wrote the treatise, "On the Reckoning of Time". Bede is pronounced like “bead”, Bedework is pronounced “bead work”. 8 | -------------------------------------------------------------------------------- /src/main/asciidoc/overview/standards.adoc: -------------------------------------------------------------------------------- 1 | [[calendar-standards-interoperability]] 2 | === Calendaring Standards & Interoperability 3 | The Bedework implementation team participates in the standards process as a member of http://www.calconnect.org/[CalConnect, the Calendaring and Scheduling Consortium], which is "focused on the interoperable exchange of calendaring and scheduling information between dissimilar programs, platforms, and technologies." 4 | 5 | Interoperability with other calendar systems and clients by way of standards compliance is an important design goal of the Bedework system. 6 | 7 | Bedework is designed to conform to existing calendar standards. For more information about calendaring and calendaring standards, please visit https://devguide.calconnect.org/Appendix/Standards/[the CalConnect Devguide]. -------------------------------------------------------------------------------- /src/main/asciidoc/overview/history.adoc: -------------------------------------------------------------------------------- 1 | [[history-background]] 2 | === Bedework History and Background 3 | 4 | Bedework was established in March 2005 in succession to UW Calendar. In December 2006 Bedework received the Andrew W. Mellon Foundation's Technology Collaboration (MATC) Award. Since then the project has prospered, and in early 2009, Bedework became an incubator project of Jasig (http://www.jasig.org/) now a part of the Apereo Foundation (http://www.apereo.org). 5 | 6 | Bedework is in use by institutions large and small, educational, governmental, commercial, and non-profit. 7 | 8 | Bedework is named after the Venerable Bede, a highly influential monk and scholar from the area of Northumbria in Britain who in 725AD wrote the treatise, "On the Reckoning of Time". Bede is pronounced like “bead”, Bedework is pronounced “bead work”. 9 | -------------------------------------------------------------------------------- /old-docs/deployers/locations.md: -------------------------------------------------------------------------------- 1 | # Locations in bedework 2 | 3 | These are stored internally as location entities. They are created withthe admin client for public events or as a result of specifying or receiving locations for user clients. 4 | 5 | ## Searching for public locations 6 | 7 | There is a web service endpoint which can be used to search for public locations. It takes a filter expression as a parameter and will return number 8 | 9 | A search takes the form: 10 | ``` 11 | /locations/all?[params] 12 | ``` 13 | 14 | The params are 15 | * fexpr=expression 16 | * ? 17 | 18 | The expression is a valid filter expression. Of particular interest are the following 19 | 20 | * loc_all=a-string 21 | * geo? 22 | * ? 23 | 24 | For example 25 | ``` 26 | http://localhost:8080/cal/location/all.gdo?fexpr=loc_all=%27some%27 27 | ``` 28 | -------------------------------------------------------------------------------- /src/main/asciidoc/deployers/locations.adoc: -------------------------------------------------------------------------------- 1 | === Locations in bedework 2 | 3 | These are stored internally as location entities. They are created withthe admin client for public events or as a result of specifying or receiving locations for user clients. 4 | 5 | ==== Searching for public locations 6 | 7 | There is a web service endpoint which can be used to search for public locations. It takes a filter expression as a parameter and will return number 8 | 9 | A search takes the form: 10 | [source] 11 | ---- 12 | /locations/all?[params] 13 | ---- 14 | 15 | The params are 16 | * fexpr=expression 17 | * ? 18 | 19 | The expression is a valid filter expression. Of particular interest are the following 20 | 21 | * loc_all=a-string 22 | * geo? 23 | * ? 24 | 25 | For example 26 | [source] 27 | ---- 28 | http://localhost:8080/cal/location/all.gdo?fexpr=loc_all=%27some%27 29 | ---- 30 | -------------------------------------------------------------------------------- /old-docs/development/caldavtester.md: -------------------------------------------------------------------------------- 1 | ## Running the caldav tester 2 | 3 | The tester started as an Apple developed project to test CalDAV servers. It has since been taken over by CalConnect adn is in the process of being modified to make the tests more universally applicable. 4 | 5 | #### Setup 6 | To run some basic tests there is a script bw-caldavTest/src/main/resources/calconnect-tester/testbw/bw-QuickLook-CalDAV.sh 7 | 8 | This script sets up the tester which needs to be cloned from the repository. 9 | 10 | Running the tester requires that a number of users be provisioned in a particular state. 11 | 12 | The quickstart data comes with users user01-user04. Each is setup with 13 | 14 | * cn: 01,test 15 | * objectclass: inetOrgPerson 16 | * objectclass: organizationalPerson 17 | * objectclass: person 18 | * objectclass: top 19 | * sn: user 20 | * givenname: 01 21 | * mail: user01@mysite.org 22 | * uid: user01 23 | * password: bedework 24 | 25 | (Replace 01 with 02-04 for the rest) 26 | 27 | 28 | 29 | 30 | -------------------------------------------------------------------------------- /src/main/asciidoc/development/caldavtester.adoc: -------------------------------------------------------------------------------- 1 | [[running-caldav-tester]] 2 | === Running the caldav tester 3 | 4 | The tester started as an Apple developed project to test CalDAV servers. It has since been taken over by CalConnect and is in the process of being modified to make the tests more universally applicable. 5 | 6 | ==== Setup 7 | To run some basic tests there is a script bw-caldavTest/src/main/resources/calconnect-tester/testbw/bw-QuickLook-CalDAV.sh 8 | 9 | This script sets up the tester which needs to be cloned from the repository. 10 | 11 | Running the tester requires that a number of users be provisioned in a particular state. 12 | 13 | The quickstart data comes with users user01-user04. Each is setup with 14 | 15 | * cn: 01,test 16 | * objectclass: inetOrgPerson 17 | * objectclass: organizationalPerson 18 | * objectclass: person 19 | * objectclass: top 20 | * sn: user 21 | * givenname: 01 22 | * mail: user01@mysite.org 23 | * uid: user01 24 | * password: bedework 25 | 26 | (Replace 01 with 02-04 for the rest) 27 | 28 | 29 | 30 | 31 | -------------------------------------------------------------------------------- /old-docs/intro/introduction.md: -------------------------------------------------------------------------------- 1 | # Introducing Bedework 2 | 3 | Bedework is an open-source enterprise calendar system that supports public, personal, and group calendaring. It is designed to conform to current calendaring standards with a goal of attaining strong interoperability between other calendaring systems and clients. Bedework is built with an emphasis on higher education, though it is used by many commercial enterprises. 4 | 5 | You may choose to deploy Bedework for public events calendaring, personal calendaring and scheduling, or both. Bedework is suitable for embedding in other applications or in portals and has been deployed across a wide range of environments. 6 | 7 | 8 | * [Features of Bedework](features.md) 9 | * [Release Notes](release-notes.md) 10 | * [System Overview](system-overview.md) 11 | * [History and Background](history.md) 12 | * [Calendaring Standards & Interoperability]( 13 | standards.md) 14 | * [Underlying technologies](technologies.md) 15 | 16 | 17 | -------------------------------------------------------------------------------- /src/main/asciidoc/introduction.adoc: -------------------------------------------------------------------------------- 1 | == Introducing Bedework 2 | 3 | Bedework is an open-source enterprise calendar system that supports public, personal, and group calendaring. It is designed to conform to current calendaring standards with a goal of attaining strong interoperability between other calendaring systems and clients. Bedework is built with an emphasis on higher education, though it is used by many commercial enterprises. 4 | 5 | You may choose to deploy Bedework for public events calendaring, personal calendaring and scheduling, or both. Bedework is suitable for embedding in other applications or in portals and has been deployed across a wide range of environments. 6 | 7 | 8 | ++++ 9 |
10 | 11 |
12 | 13 | 14 | 29 | ++++ 30 | -------------------------------------------------------------------------------- /src/main/asciidoc/deployers/keycloak-saml.adoc: -------------------------------------------------------------------------------- 1 | [[keycloak-saml]] 2 | === Configure keycloak saml 3 | 4 | Saml seems to need a certificate for signing. A self-signed cert will do. 5 | 6 | ==== Create a self-signed cert. 7 | 8 | ---- 9 | # Generate private key 10 | openssl genrsa -des3 -out domain.key 2048 11 | 12 | # -des3 generates an encypted key - can remove. 13 | # Will ask for pass phrase if -des3 specified 14 | 15 | # create a certificate signing request (CSR). 16 | openssl req -key domain.key -new -out domain.csr 17 | 18 | # Provide info required 19 | # common name should be the exact Fully Qualified Domain Name (FQDN) of the service 20 | 21 | # Create a self-Signed certificate 22 | openssl x509 -signkey domain.key -in domain.csr -req -days 365000 -out domain.crt 23 | 24 | # Create PKCS12 keystore from private key and public certificate. 25 | openssl pkcs12 -export -name domaincert -in domain.crt -inkey domain.key -out domain.p12 26 | # password is required or the next step fails 27 | 28 | # Import into wildfly application.keystore 29 | # Assumes path below is valid 30 | keytool -importkeystore -destkeystore wildfly/standalone/configuration/application.keystore -srckeystore domain.p12 -srcstoretype pkcs12 -alias domaincert 31 | ---- 32 | -------------------------------------------------------------------------------- /old-docs/deployers/installing-old.md: -------------------------------------------------------------------------------- 1 | # Installing the quickstart (versions previous to 3.12.x) 2 | 3 | These quickstarts are complete and packaged up as downloadable zip files available from [the dev.bedework.org download site](http://dev.bedework.org/downloads). 4 | 5 | Navigate to the desired version and download. 6 | 7 | Once unzipped it's advisable to ensure it is fully up to date. 8 | 9 | ``` 10 | cd 11 | ./bw -updateall 12 | ./bw deploy 13 | ``` 14 | 15 | will update everything then build the main calendar engine, web clients and caldav. 16 | 17 | We have attempted to make the quickstart as close to a production-ready system as possible. To move to deployment, you willneed to move to a production database. You may also choose to use local authentication (against ldap, CAS, Shib, etc), front Bedework with Apache, or make further customizations. In all cases, begin with the Bedework Quickstart. 18 | 19 | For more information about deploying a production system, see Deploying Bedework – but read this chapter first! 20 | 21 | Packaged with the quickstart 22 | 23 | * Bedework: Calendar engine, CalDAV, CardDAV, Timzone servers, and web clients 24 | * Wildfly (or jboss for older versions) 25 | * Apache DS 1.5 (apacheds-1.5.3-fixed) 26 | * HSQL or H2 provides the demonstration database 27 | * Vert.x/web page caching application 28 | 29 | -------------------------------------------------------------------------------- /src/main/asciidoc/docinfo/docinfo-footer.html: -------------------------------------------------------------------------------- 1 | 2 | 34 | -------------------------------------------------------------------------------- /data/addPublicAuth.txt: -------------------------------------------------------------------------------- 1 | # 2 | # bwcli script to add the public/auth folder and some example calendars 3 | # 4 | user admin super 5 | 6 | # What we're creating: 7 | # 8 | # Academic: 9 | # o ARPT (Academic Review Promotion & Tenure) calendar 10 | # o Research Dates 11 | # o XX 12 | # 13 | # Human Resources: 14 | # o Benefits Enrollment Dates 15 | # o Staff Review Dates 16 | # o Compliance - Reporting Dates 17 | # o New Employee Orientation Dates 18 | # o XX 19 | # 20 | # Payroll: 21 | # o Pay Cycle Due Dates 22 | # o Compliance – Reporting Dates (e.g. W2, 1099, ACA, etc.) 23 | # o XX 24 | # 25 | # Admissions: 26 | # o Event Dates 27 | # o Milestone Dates 28 | # o XX 29 | # 30 | # Enrollment Services: 31 | # o Academic Calendar Dates (Registration, Add Drop, etc.) 32 | # o Financial Aid Packaging Dates 33 | # o Bill Dates 34 | # o Graduation Ceremony related Dates 35 | # o XX 36 | # 37 | # Alumni & Development: 38 | # o Alumni Events 39 | # o Gala 40 | # o XX 41 | # 42 | # Other 43 | # o XX 44 | 45 | # create collection... 46 | # folder: parent name summary owner creator [desc=""] [filter=""] [category=""] 47 | # alias/topic: parent name summary alias-path owner creator [desc=""] [filter=""] [category=""] 48 | 49 | # clean up to start 50 | 51 | delete collection "/public/auth" recursive 52 | 53 | 54 | 55 | 56 | -------------------------------------------------------------------------------- /old-docs/intro/standards.md: -------------------------------------------------------------------------------- 1 | # Calendaring Standards & Interoperability 2 | The Bedework implementation team participates in the standards process as a member of [CalConnect, the Calendaring and Scheduling Consortium](http://www.calconnect.org/), which is "focused on the interoperable exchange of calendaring and scheduling information between dissimilar programs, platforms, and technologies." 3 | 4 | Interoperability with other calendar systems and clients by way of standards compliance is an important design goal of the Bedework system. 5 | 6 | Bedework is designed to conform to existing calendar standards. In particular: 7 | 8 | * iCalendar: [RFC 5545](http://tools.ietf.org/html/rfc5545)
9 | Internet Calendaring and Scheduling Core Object Specification 10 | * iTIP: [RFC 5546](http://tools.ietf.org/html/rfc5546)
11 | iCalendar Transport-Independent Interoperability Protocol 12 | * CalDAV: [RFC 4791](http://tools.ietf.org/html/rfc5545)
13 | Calendaring Extensions to WebDAV 14 | * CalDAV scheduling [RFC6638](http://tools.ietf.org/html/rfc6638)
15 | Scheduling Extensions to CalDAV 16 | * CardDAV [RFC6352](http://tools.ietf.org/html/rfc6352)
17 | vCard Extensions to Web Distributed Authoring and Versioning 18 | * [VPOLL](https://tools.ietf.org/html/draft-york-vpoll-04): Consensus Scheduling Component for iCalendar 19 | 20 | For more information about calendaring and calendaring standards, please visit [CalConnect](http://www.calconnect.org). -------------------------------------------------------------------------------- /src/main/asciidoc/deployers/installing.adoc: -------------------------------------------------------------------------------- 1 | [[installing-bedwork]] 2 | === Installing bedework on Ubuntu 3 | . Make sure that apt is up to date 4 | + 5 | ................. 6 | sudo apt-get update 7 | ................. 8 | . Ensure java 17 jdk installed 9 | + 10 | ................. 11 | sudo apt-get install openjdk-17-jdk-headless 12 | sudo update-alternatives --config java 13 | ................. 14 | + 15 | The last command should state there are no alternatives but if another has been installed pick the appropriate version. 16 | . Create a directory in which to install. 17 | + 18 | We'll refer to this directory as 19 | + 20 | ---- 21 | mkdir 22 | cd 23 | ---- 24 | . Install wildfly with bedework using galleon 25 | + 26 | Follow the instructions at <>. 27 | 28 | . Install OpenSearch 1.2.3 29 | + 30 | The deployed wildfly has scripts to install a docker image and start and stop it. See <> for instructions on installing and (re)indexing. 31 | You'll need to start the system before reindexing. 32 | 33 | . Start the system 34 | + 35 | ................. 36 | cd 37 | ./wildfly/bin/bwstarth2.sh 38 | ./wildfly/bin/bwdirstart.sh 39 | ./wildfly/bin/bwstartwildfly.sh 40 | ................. 41 | + 42 | If you need to reindex there will certainly be some errors at startup. 43 | . Reindex 44 | + 45 | Use the cli to run the reindexer 46 | ................. 47 | ./wildfly/bin/bwcli.sh jmxUrl http://localhost:8080/jolokia -id hawtadmin -pw mypw 48 | help 49 | idx list 50 | idx rebuild 51 | idx list 52 | idx makeprod all 53 | exit 54 | ................. 55 | -------------------------------------------------------------------------------- /src/main/asciidoc/administrators/aliasStructureOverview.adoc: -------------------------------------------------------------------------------- 1 | [[Alias-structure-overview]] 2 | === Alias Structure Overview 3 | 4 | The "system" tab provides access to the calendars and folders 5 | view. This looks like a file system structure with a hierarchy 6 | of folders (or collections) rooted under the folder "public". 7 | 8 | There will be at least the following at the next level: 9 | 10 | * *aliases* holds a number of system aliases or folders. 11 | Aliases will generally reference the main calendar collection 12 | with the url "bwcal:///public/cals/MainCal". 13 | 14 | 15 | * *cals* contains the public calendar collections. If your 16 | system has no incoming feeds then only the single collection 17 | "MainCal" may be present. MainCal contains all the public 18 | events created with the admin client. 19 | 20 | * *unbrowsable* is used to hide special calendar collections 21 | used for the workflow feature and the submission client. 22 | 23 | ==== System aliases/subscriptions 24 | These normally have one or more categories applied for 25 | input and output - usually the same category. The categories 26 | are applied when <> are applied when adding 27 | or updating events. 28 | 29 | When an alias/subscription is selected in the public client 30 | (or referenced by a virtual path in feed urls) then the 31 | category is used as a filter. 32 | 33 | [[topical-areas]] 34 | ==== Topical Areas 35 | Calendar suites may have subscriptions to the system aliases. 36 | Typically, those subscriptions have the same name as the 37 | system alias. This added level of indirection helps to ensure 38 | consistency in the categorisation. -------------------------------------------------------------------------------- /bedework.iml: -------------------------------------------------------------------------------- 1 | 2 | 3 | 4 | 5 | 6 | 7 | 8 | 9 | 10 | 11 | 12 | 13 | 14 | 15 | 16 | 17 | 18 | 19 | 20 | 21 | 22 | 23 | 24 | 25 | 26 | 27 | -------------------------------------------------------------------------------- /old-docs/deployers/elasticsearch.md: -------------------------------------------------------------------------------- 1 | # OpenSearch 2 | Bedework uses OpenSearch as the indexer engine. As objects are created destroyed and updated they are indexed through calls to the indexer. The indexer can run as an embedded engine - as it arrives in the quickstart - or as an external service - which will be required for clustering. 3 | 4 | Currently OpenSearch is completely unsecured. For testing and debugging it is possible to enable the http interface but this may expose your index. DO NOT run in production with the ES http interface open. In embedded mode the only access should be through the api. 5 | 6 | Later versions of ES do appear to offer the ability to secure ES. This may be an option when we upgrade. 7 | 8 | In non-embedded mode you can run ES on the same server or preferably a different server. ES - depending on the amount of data and types of search - can use a lot of memory for caching of filters. See the ES site for full instructions on running a non-embedded version. 9 | 10 | In general this is an easy process - ES offers various installation formats of all their versions including the very old 15.2 we are running currently. 11 | 12 | Both embedded and non-embedded require a small number of changes to the configuration. These are already in place for the embedded version and are available in the quickstart in 13 | 14 | bedework/config/bedework/elasticsearch/config/elasticsearch.yml 15 | 16 | Note that the mappings and settings do not need to be installed. They are used when creating a new index. 17 | 18 | The changes made are 19 | 20 | **action.auto_create_index: false** 21 | 22 | Prevent ES from creating indexes implicitly. This can cause issues when reindexing. 23 | 24 | Uncomment the following 25 | 26 | **node.max_local_storage_nodes: 1** 27 | -------------------------------------------------------------------------------- /old-docs/administrators/eventRegistration.md: -------------------------------------------------------------------------------- 1 | # Bedework Public Events Registration System 2 | 3 | Bedework supports a public events registration system that allows authenticated users to register for events. Users may view and modify their registrations, such as unregistering or changing the number of tickets they've requested. When registration is full, users may choose to be placed on a waiting list. Users on waiting lists will automatically be moved up in the queue if space becomes available. 4 | 5 | ![Registered Event]({{ site.baseurl }}/resources/eventRegRegistered.png) 6 | 7 | With the form elements as shown below, administrators can specify how many users may register, how many tickets each registrant may request, and set the opening and closing dates of registration. Administrators can view and modify a registration list and download CSV files of their registrations on-demand. 8 | 9 | ![Register Event Form]({{ site.baseurl }}/resources/eventRegAdminForm.png) 10 | 11 | ### Displaying the current status 12 | Clicking on the "View registrations" button will take you to a screen showing the current registrations for the event. This screen also allows the administrator to hold some tickets and to update or remove registrations. 13 | 14 | ### Custom Fields 15 | Administrators may add custom field elements for use during registration. These custom fields are displayed to the user when they register for the event. These fields can be used to obtain extra information from the user as they register, for example dietary restrictions. 16 | 17 | Currently the results are only visible in the downloaded registrations. 18 | 19 | ### Data elements 20 | Data about the event is maintained in x-properties attached to the event and provides the following information: 21 | 22 | * Booking window start and end 23 | * Number of tickets 24 | * Max number of tickets per person 25 | 26 | -------------------------------------------------------------------------------- /src/main/asciidoc/deployers/deploying-servers.adoc: -------------------------------------------------------------------------------- 1 | [[deploying-servers]] 2 | === Deploying servers 3 | 4 | It is possible to deploy bedework in a number of configurations. There are the following major components to consider: 5 | 6 | * Database 7 | * OpenSearch 8 | * Calendar servers 9 | * Sync Engine 10 | * Event registration 11 | * Load balancer 12 | 13 | The load balancer is only required if more than one calendar server is running. If there is only one instance then it is optional. 14 | 15 | It might still be helpful to run the server behind a load balancer such as haproxy to restrict traffic to known services and allow filtering of bad ip addresses. Apache http server is an alternative. 16 | 17 | All of the rest can be run on a single server, but it will need a generous amount of memory and multiple processors for any significant load. 18 | 19 | Running the database and OpenSearch on a separate instance helps spread the load. For greater reliability both could be run as clustered services and your organization may already provide database support you can use. 20 | 21 | It should be possible to use hosted solutions for both database and OpenSearch. 22 | 23 | Multiple calendar servers can be run to provide greater reliability and to handle higher loads. Bedework is not currently configured to handle session migration etc. If you do run multiple servers you MUST have a single database and OpenSearch service they both use. 24 | 25 | The sync engine and the event registration modules currently need to run on a single server. This is mostly because there is no mechanism to allocate outstanding sync requests between multiple servers. 26 | 27 | Note that the calendar server does not use the database for the public events web presence or feeds. This would allow some different configurations - for example a single smaller server for public events administration and a number of front end servers for web presence and feeds. 28 | -------------------------------------------------------------------------------- /old-docs/deployers/configure-wildfly.md: -------------------------------------------------------------------------------- 1 | == Configuring wildfly 2 | 3 | ==== Adding an admin account 4 | 5 | ``` 6 | cd wildfly 7 | ./bin/add-user.sh -dc standalone 8 | 9 | What type of user do you wish to add? 10 | a) Management User (mgmt-users.properties) 11 | b) Application User (application-users.properties) 12 | (a): b 13 | 14 | Enter the details of the new user to add. 15 | Using realm 'ApplicationRealm' as discovered from the existing property files. 16 | Username : hawtio-admin 17 | Password recommendations are listed below. To modify these restrictions edit the add-user.properties configuration file. 18 | - The password should not be one of the following restricted values {root, admin, administrator} 19 | - The password should contain at least 8 characters, 1 alphabetic character(s), 1 digit(s), 1 non-alphanumeric symbol(s) 20 | - The password should be different from the username 21 | Password : 22 | Re-enter Password : 23 | What groups do you want this user to belong to? (Please enter a comma separated list, or leave blank for none)[ ]: admin 24 | About to add user 'hawtio-admin' for realm 'ApplicationRealm' 25 | Is this correct yes/no? yes 26 | Added user 'hawtio-admin' to file '/Users/xxx/dev/wildfly/standalone/configuration/application-users.properties' 27 | Added user 'hawtio-admin' to file '/Users/xxx/dev/wildfly/standalone/configuration/application-users.properties' 28 | Added user 'hawtio-admin' with groups admin to file '/Users/xxx/dev/wildfly/standalone/configuration/application-roles.properties' 29 | Added user 'hawtio-admin' with groups admin to file '/Users/xxx/dev/wildfly/standalone/configuration/application-roles.properties' 30 | Is this new user going to be used for one AS process to connect to another AS process? 31 | e.g. for a slave host controller connecting to the master or for a Remoting connection for server to server EJB calls. 32 | yes/no? no 33 | ``` 34 | -------------------------------------------------------------------------------- /src/main/asciidoc/deployers/configure-wildfly.adoc: -------------------------------------------------------------------------------- 1 | [[configuring-wildfly]] 2 | === Configuring wildfly 3 | 4 | ==== Adding an admin account 5 | 6 | [source] 7 | ---- 8 | cd 9 | ./wildfly/bin/add-user.sh -a -dc wildfly/standalone/configuration 10 | 11 | What type of user do you wish to add? 12 | a) Management User (mgmt-users.properties) 13 | b) Application User (application-users.properties) 14 | (a): b 15 | 16 | Enter the details of the new user to add. 17 | Using realm 'ApplicationRealm' as discovered from the existing property files. 18 | Username : hawtio-admin 19 | Password recommendations are listed below. To modify these restrictions edit the add-user.properties configuration file. 20 | - The password should not be one of the following restricted values {root, admin, administrator} 21 | - The password should contain at least 8 characters, 1 alphabetic character(s), 1 digit(s), 1 non-alphanumeric symbol(s) 22 | - The password should be different from the username 23 | Password : 24 | Re-enter Password : 25 | What groups do you want this user to belong to? (Please enter a comma separated list, or leave blank for none)[ ]: admin 26 | About to add user 'hawtio-admin' for realm 'ApplicationRealm' 27 | Is this correct yes/no? yes 28 | Added user 'hawtio-admin' to file '/Users/xxx/dev/eap/wildfly-8.1.0.Final/standalone/configuration/application-users.properties' 29 | Added user 'hawtio-admin' to file '/Users/xxx/dev/eap/wildfly-8.1.0.Final/domain/configuration/application-users.properties' 30 | Added user 'hawtio-admin' with groups admin to file '/Users/xxx/dev/eap/wildfly-8.1.0.Final/standalone/configuration/application-roles.properties' 31 | Added user 'hawtio-admin' with groups admin to file '/Users/xxx/dev/eap/wildfly-8.1.0.Final/domain/configuration/application-roles.properties' 32 | Is this new user going to be used for one AS process to connect to another AS process? 33 | e.g. for a slave host controller connecting to the master or for a Remoting connection for server to server EJB calls. 34 | yes/no? no 35 | ---- 36 | -------------------------------------------------------------------------------- /.idea/modules.xml: -------------------------------------------------------------------------------- 1 | 2 | 3 | 4 | 5 | 6 | 7 | 8 | 9 | 10 | 11 | 12 | 13 | 14 | 15 | 16 | 17 | -------------------------------------------------------------------------------- /old-docs/intro/system-overview.md: -------------------------------------------------------------------------------- 1 | # System Overview 2 | Bedework System Architecture 3 | 4 | Bedework has a central server architecture and is modular and extensible. It consists of the following components: 5 | 6 | * Bedework core calendar engine 7 | * Public events web client, called a “Calendar Suite”, for display of public events 8 | * Public events cached feeds and widget builder, supporting ical, json, and XML and for producing embeddable JavaScript widgets for use on other websites. 9 | * Public events administration web client for entering public events, moderating pending events from the submissions client, and configuring calendar suites 10 | * Public events submission web client for authenticated members of your community to suggest public events – these become pending events in the admin client 11 | * Personal and group calendaring web client with a subscription model to Bedework public calendars, user calendars, and external calendar feeds 12 | * CalDAV server for integration with CalDAV capable desktop (and web) clients such as Apple's iCal or Mozilla Lightning 13 | * CardDAV server that supports contacts for scheduling in the personal client. 14 | * A JavaScript-only CardDAV address book web client is available for use with the CardDAV server. The address book comes with the Bedework personal web client, and is suitable for use with other web applications (e.g. webmail). 15 | * TimeZone server for support of timezone information. 16 | * Dump/Restore command-line utilities for database backup, initialization, and upgrades. 17 | 18 | ## Calendar Architecture 19 | 20 | The Bedework system is divided into two main spaces: the public events space, and the personal and group calendaring space which are kept separate by design. Public events are stored below a public calendar root folder and personal calendars are below a user calendar root folder. 21 | 22 | ![Basic Architecture]({{ site.baseurl }}/resources/bw-basic-arch.png) 23 | 24 | Personal calendar users (and other clients) can subscribe to public events, but users may only add public events using the Administrative and Community Submissions web clients. For more information about Bedework's public and personal event calendaring models, see Public Events Calendaring and Personal & Group Calendaring. -------------------------------------------------------------------------------- /old-docs/schema/wildfly/wildfly-request-controller_1_0.xsd: -------------------------------------------------------------------------------- 1 | 2 | 3 | 26 | 27 | 33 | 34 | 35 | 36 | 37 | 38 | 41 | 42 | 43 | 44 | 45 | 46 | 47 | -------------------------------------------------------------------------------- /docs/tocbot-3.0.2/styles.css: -------------------------------------------------------------------------------- 1 | .transition--300{transition:all 300ms ease-in-out}.toc{height:100%;width:280px;transform:translateX(0)}.content h1:first-child,.content h2:first-child{padding-top:0;margin-top:0}.title{font-size:3em}.content{margin-bottom:95vh}.content ul,.content ol{list-style:inherit}.content a{color:#0977c3;text-decoration:none;border-bottom:1px solid #EEE;transition:all 300ms ease}.content a.no-decoration{border-bottom:0}.content a:hover{border-bottom:1px solid #0977c3}.content a:hover.no-decoration{border-bottom:0}a.toc-link{text-decoration:none}.try-it-container{transform:translateY(84%)}.try-it-container.is-open{transform:translateY(0%)}.page-content{display:block !important}.hljs{display:block;background:white;padding:0.5em;color:#333333;overflow-x:auto}.hljs-comment,.hljs-meta{color:#969896}.hljs-string,.hljs-variable,.hljs-template-variable,.hljs-strong,.hljs-emphasis,.hljs-quote{color:#df5000}.hljs-keyword,.hljs-selector-tag,.hljs-type{color:#a71d5d}.hljs-literal,.hljs-symbol,.hljs-bullet,.hljs-attribute{color:#0086b3}.hljs-section,.hljs-name{color:#63a35c}.hljs-tag{color:#333333}.hljs-title,.hljs-attr,.hljs-selector-id,.hljs-selector-class,.hljs-selector-attr,.hljs-selector-pseudo{color:#795da3}.hljs-addition{color:#55a532;background-color:#eaffea}.hljs-deletion{color:#bd2c00;background-color:#ffecec}.hljs-link{text-decoration:underline}.toc-icon{position:fixed;top:0;right:0}#toc:checked ~ .toc{box-shadow:0 0 5px #c8c8c8;transform:translateX(0)}.toc{background-color:rgba(255,255,255,0.9);transform:translateX(-100%)}.toc.toc-right{transform:translateX(100%);right:0}@media (min-width: 52em){.toc{transform:translateX(0)}.toc.toc-right{transform:translateX(0);right:calc((100% - 48rem - 4rem) / 2)}.toc-icon{display:none}.try-it-container{display:block}.content{margin-left:280px}.toc-right ~ .content{margin-left:0;margin-right:280px}}*{box-sizing:border-box}body{font-size:1.2rem;font-family:-apple-system, BlinkMacSystemFont, "Segoe UI", "Roboto", "Oxygen", "Ubuntu", "Cantarell", "Fira Sans", "Droid Sans", "Helvetica Neue", sans-serif}h1,h2,h3,h4,h5,h6{padding-top:0.5em}p{margin-top:0.25rem}pre{display:block;background:#f7f7f7;border-radius:2px;border:1px solid #e0e0e0;padding:2px;line-height:1.2;margin-bottom:10px;overflow:auto;white-space:pre-wrap}code{display:inline;font-size:.8em;max-width:100%} -------------------------------------------------------------------------------- /src/main/asciidoc/overview/system-overview.adoc: -------------------------------------------------------------------------------- 1 | [[system-overview]] 2 | === System Overview 3 | Bedework System Architecture 4 | 5 | Bedework has a central server architecture and is modular and extensible. It consists of the following components: 6 | 7 | * Bedework core calendar engine 8 | * Public events web client, called a “Calendar Suite”, for display of public events 9 | * Public events cached feeds and widget builder, supporting ical, json, and XML and for producing embeddable JavaScript widgets for use on other websites. 10 | * Public events administration web client for entering public events, moderating pending events from the submissions client, and configuring calendar suites 11 | * Public events submission web client for authenticated members of your community to suggest public events – these become pending events in the admin client 12 | * Personal and group calendaring web client with a subscription model to Bedework public calendars, user calendars, and external calendar feeds 13 | * CalDAV server for integration with CalDAV capable desktop (and web) clients such as Apple's iCal or Mozilla Lightning 14 | * CardDAV server that supports contacts for scheduling in the personal client. 15 | * A JavaScript-only CardDAV address book web client is available for use with the CardDAV server. The address book comes with the Bedework personal web client, and is suitable for use with other web applications (e.g. webmail). 16 | * TimeZone server for support of timezone information. 17 | * Dump/Restore command-line utilities for database backup, initialization, and upgrades. 18 | 19 | ==== Calendar Architecture 20 | 21 | The Bedework system is divided into two main spaces: the public events space, and the personal and group calendaring space which are kept separate by design. Public events are stored below a public calendar root folder and personal calendars are below a user calendar root folder. 22 | 23 | image::bw-basic-arch.png[Basic Architecture] 24 | 25 | Personal calendar users (and other clients) can subscribe to public events, but users may only add public events using the Administrative and Community Submissions web clients. For more information about Bedework's public and personal event calendaring models, see Public Events Calendaring and Personal & Group Calendaring. -------------------------------------------------------------------------------- /src/main/asciidoc/tocbot-3.0.2/styles.css: -------------------------------------------------------------------------------- 1 | .transition--300{transition:all 300ms ease-in-out}.toc{height:100%;width:280px;transform:translateX(0)}.content h1:first-child,.content h2:first-child{padding-top:0;margin-top:0}.title{font-size:3em}.content{margin-bottom:95vh}.content ul,.content ol{list-style:inherit}.content a{color:#0977c3;text-decoration:none;border-bottom:1px solid #EEE;transition:all 300ms ease}.content a.no-decoration{border-bottom:0}.content a:hover{border-bottom:1px solid #0977c3}.content a:hover.no-decoration{border-bottom:0}a.toc-link{text-decoration:none}.try-it-container{transform:translateY(84%)}.try-it-container.is-open{transform:translateY(0%)}.page-content{display:block !important}.hljs{display:block;background:white;padding:0.5em;color:#333333;overflow-x:auto}.hljs-comment,.hljs-meta{color:#969896}.hljs-string,.hljs-variable,.hljs-template-variable,.hljs-strong,.hljs-emphasis,.hljs-quote{color:#df5000}.hljs-keyword,.hljs-selector-tag,.hljs-type{color:#a71d5d}.hljs-literal,.hljs-symbol,.hljs-bullet,.hljs-attribute{color:#0086b3}.hljs-section,.hljs-name{color:#63a35c}.hljs-tag{color:#333333}.hljs-title,.hljs-attr,.hljs-selector-id,.hljs-selector-class,.hljs-selector-attr,.hljs-selector-pseudo{color:#795da3}.hljs-addition{color:#55a532;background-color:#eaffea}.hljs-deletion{color:#bd2c00;background-color:#ffecec}.hljs-link{text-decoration:underline}.toc-icon{position:fixed;top:0;right:0}#toc:checked ~ .toc{box-shadow:0 0 5px #c8c8c8;transform:translateX(0)}.toc{background-color:rgba(255,255,255,0.9);transform:translateX(-100%)}.toc.toc-right{transform:translateX(100%);right:0}@media (min-width: 52em){.toc{transform:translateX(0)}.toc.toc-right{transform:translateX(0);right:calc((100% - 48rem - 4rem) / 2)}.toc-icon{display:none}.try-it-container{display:block}.content{margin-left:280px}.toc-right ~ .content{margin-left:0;margin-right:280px}}*{box-sizing:border-box}body{font-size:1.2rem;font-family:-apple-system, BlinkMacSystemFont, "Segoe UI", "Roboto", "Oxygen", "Ubuntu", "Cantarell", "Fira Sans", "Droid Sans", "Helvetica Neue", sans-serif}h1,h2,h3,h4,h5,h6{padding-top:0.5em}p{margin-top:0.25rem}pre{display:block;background:#f7f7f7;border-radius:2px;border:1px solid #e0e0e0;padding:2px;line-height:1.2;margin-bottom:10px;overflow:auto;white-space:pre-wrap}code{display:inline;font-size:.8em;max-width:100%} -------------------------------------------------------------------------------- /src/main/asciidoc/administrators/authusers.adoc: -------------------------------------------------------------------------------- 1 | [[auth-users]] 2 | === Public events authorised users 3 | These are users with rights to create events, perhaps publish them and possibly have access to calendar suite setup. 4 | 5 | A user must have one or more roles and be the member of at least one group to have any administrative capabilities. 6 | 7 | See <> for details on how some of these roles are used. 8 | 9 | ==== Creating a user 10 | Go to the "Users" tab and click on "Manage Admin Roles". 11 | 12 | If the user does not appear in the list then type the account into the box labeled "Edit admin roles by userid" and hit enter. 13 | 14 | All users with the ability to create events must have the "Public Events" flag set. 15 | 16 | The "Content Admin" flag does nothing at present - ignore. 17 | 18 | Users who may create and publish must have the "Approver" flag set. 19 | 20 | ==== Updating a user 21 | Go to the same location, "Users" -> "Manage Admin Roles", locate the user in the list and click on the "edit" link. 22 | 23 | Flags may be set or unset from there. 24 | 25 | ==== Updating group membership. 26 | Until the user is added to a group or groups they cannot create events. Each calendar suite will have one or more groups associated with it. Typically, there is an admin group associated directly with the suite and a submission group which is a member of the admin group. 27 | 28 | Approvers are typically added to the admin group and event creators get added to the submission group. 29 | 30 | To add a user or group click on "Users" then "Manage Admin Groups". 31 | 32 | Find the group to update and click on the "membership" link. 33 | 34 | To add a user enter their account in the "Add member" box, ensure "User" is selected then press the "Add" button. 35 | 36 | To add a group ensure "Group" is selected. 37 | 38 | To remove a group member, click on the trash icon next to the account. 39 | 40 | ==== A problem to be resolved later: 41 | Note that the rights of the users are attached to their auth user entry. So a user is always an approver whatever groups they are in. 42 | 43 | There is no provision for a user being an approver in one group and an event creator in another. At some point we may move the rights to the associated groups so that approval rights will come about because of group membership. 44 | -------------------------------------------------------------------------------- /src/main/asciidoc/index.adoc: -------------------------------------------------------------------------------- 1 | = Bedework Enterprise Calendar System 2 | :title: Bedework Enterprise Calendar System 3 | :safe-mode-unsafe: 4 | :docinfo: shared 5 | :docinfodir: ./docinfo 6 | :docinfo2: 7 | :scriptsdir: ./tocbot-3.0.2 8 | :imagesdir: ./resources/ 9 | :toc: left 10 | :toclevels: 4 11 | :sectnumlevels: 4 12 | // 13 | :overview-dir: overview/ 14 | :admin-dir: administrators/ 15 | :deployer-dir: deployers/ 16 | :dev-dir: development/ 17 | :older-dir: older/ 18 | :sometime-dir: sometime/ 19 | // 20 | :sectnums!: 21 | 22 | include::foreword.adoc[] 23 | include::introduction.adoc[] 24 | 25 | :sectnums: 26 | 27 | [[overview]] 28 | == Overview 29 | 30 | include::{overview-dir}features.adoc[] 31 | include::{overview-dir}release-notes.adoc[] 32 | include::{overview-dir}issues.adoc[] 33 | include::{overview-dir}system-overview.adoc[] 34 | include::{overview-dir}history.adoc[] 35 | include::{overview-dir}standards.adoc[] 36 | include::{overview-dir}technologies.adoc[] 37 | 38 | == General Administration 39 | include::{admin-dir}reindex.adoc[] 40 | include::{admin-dir}errors.adoc[] 41 | 42 | == Public Administrator Features 43 | include::{admin-dir}authusers.adoc[] 44 | include::{admin-dir}workflow.adoc[] 45 | include::{admin-dir}aliasStructureOverview.adoc[] 46 | include::{admin-dir}addTopicalArea.adoc[] 47 | include::{admin-dir}eventRegistration.adoc[] 48 | include::{admin-dir}subscriptions.adoc[] 49 | 50 | == System Components 51 | include::{sometime-dir}sometime.adoc[] 52 | 53 | == Deployers 54 | include::{deployer-dir}featurepack-install.adoc[] 55 | include::{deployer-dir}installing.adoc[] 56 | include::{deployer-dir}deploying-servers.adoc[] 57 | include::{deployer-dir}configure-wildfly.adoc[] 58 | include::{deployer-dir}keycloak-saml.adoc[] 59 | include::{deployer-dir}databases.adoc[] 60 | include::{deployer-dir}opensearch.adoc[] 61 | include::{deployer-dir}eventRegistration.adoc[] 62 | include::{deployer-dir}synch-engine.adoc[] 63 | include::{deployer-dir}locations.adoc[] 64 | 65 | == Development 66 | include::{dev-dir}github-actions.adoc[] 67 | include::{dev-dir}todo.adoc[] 68 | include::{dev-dir}debugging.adoc[] 69 | include::{dev-dir}caldavtester.adoc[] 70 | include::{dev-dir}building.adoc[] 71 | 72 | [[older-releases]] 73 | == Older Bedework Versions (3.10 and Prior) 74 | include::{older-dir}releases.adoc[] 75 | -------------------------------------------------------------------------------- /pom.xml: -------------------------------------------------------------------------------- 1 | 2 | 4.0.0 3 | 4 | 5 | org.bedework 6 | bedework-parent 7 | 238 8 | 9 | 10 | bedework 11 | 5.0.1-SNAPSHOT 12 | pom 13 | Bedework 14 | 15 | Quickstart scripts and resources 16 | https://github.com/Bedework/bedework 17 | 18 | 19 | scm:git:git@github.com:Bedework/bedework.git 20 | scm:git:git@github.com:Bedework/bedework.git 21 | https://github.com/Bedework/bedework 22 | HEAD 23 | 24 | 25 | 26 | 27 | 28 | org.asciidoctor 29 | asciidoctor-maven-plugin 30 | 31 | 32 | 33 | maven-resources-plugin 34 | org.apache.maven.plugins 35 | 36 | 37 | 38 | copy-generated-asciidoc 39 | package 40 | 41 | copy-resources 42 | 43 | 44 | ${project.basedir}/docs/ 45 | 46 | 47 | ${project.build.directory}/generated-docs 48 | false 49 | 50 | index.html 51 | asciidoctor.css 52 | tocbot*/* 53 | docinfo/* 54 | 55 | 56 | 57 | 58 | 59 | 60 | 61 | 62 | 63 | 64 | 65 | -------------------------------------------------------------------------------- /src/main/asciidoc/overview/xslchanges.adoc: -------------------------------------------------------------------------------- 1 | [[xsl-changes]] 2 | 3 | These are changes made to the xsl and associated javascript. These changes often need to be carried over to a site when upgrading. 4 | 5 | Not all changes will be flagged here - only those that should be carried over. 6 | ==== Dev version 7 | 8 | *bedeworkEventForm.js* 9 | 10 | Changed 11 | ---- 12 | if (formObj["xYaleRecurrenceInfo"] && trim(formObj["xYaleRecurrenceInfo"].value) != '') { 13 | bwXProps.update('X-YALE-RECURRENCEINFO',[],trim(formObj["xYaleRecurrenceInfo"].value),true); 14 | } else { 15 | bwXProps.remove('X-YALE-RECURRENCEINFO'); 16 | } 17 | ---- 18 | to 19 | ---- 20 | if (formObj["xRecurrenceInfo"] && trim(formObj["xRecurrenceInfo"].value) != '') { 21 | bwXProps.update('X-BW-RECURRENCEINFO',[],trim(formObj["xRecurrenceInfo"].value),true); 22 | } else { 23 | bwXProps.remove('X-BW-RECURRENCEINFO'); 24 | } 25 | ---- 26 | that is the x-prop and field name changed. (This mat cause some issues for old data) 27 | 28 | *addEventFrom.xsl* 29 | 30 | Calcel button needs to be a submit 31 | 32 | ---- 33 | 34 | ---- 35 | 36 | *eventsForm.xsl, eventForm.xsl, addEventForm.xsl* 37 | 38 | Added guid and recurrenceid as hidden fields to allow checking that we are editing the same event. Multiple browser tabs can cause issues 39 | 40 | Added this 41 | ---- 42 | 43 | 44 | 45 | 46 | 47 | 48 | 49 | ---- 50 | 51 | *timezones.xsl* 52 | 53 | Removed code to update timezones - don't do it that way now we have a tz server. 54 | 55 | *eventsForm.xsl* 56 | 57 | As a result of upgradign struts image uploads are handled a little differently. Need to change 58 | 59 | ---- 60 | 61 | ---- 62 | to 63 | ---- 64 | 65 | ---- 66 | i.e. *name* parameter changed. 67 | -------------------------------------------------------------------------------- /.idea/inspectionProfiles/Project_Default.xml: -------------------------------------------------------------------------------- 1 | 2 | 3 | 30 | -------------------------------------------------------------------------------- /README.md: -------------------------------------------------------------------------------- 1 | # Bedework project 2 | 3 | This project contains configurations and scripts used to build the quickstart and will be used to provide an overall view of changes to the project. At the moment production releases of the calendar engine, client and quickstart are versions 3.x. Other modules are 4.x. 4 | 5 | ## Bedework modules 6 | The bedework system is comprised of a number of modules, most of which support enterprise calendaring. The 4.x modules are already in use. These are the ones that implement the generic caldav and carddav servers and their dependencies. 7 | 8 | These modules include 9 | * Caldav 10 | * Carddav 11 | * Webdav 12 | * access 13 | * util 14 | * util-logging 15 | 16 | ## Installing 17 | Please see the [current (but incomplete) documentation](http://bedework.github.io/bedework/#installing-the-quickstart). 18 | 19 | ## Release Notes 20 | These are in the [github pages documents](http://bedework.github.io/bedework/#release-notes). 21 | 22 | ## Releasing 23 | 24 | Releases of this fork are published to Maven Central via Sonatype. 25 | 26 | To create a release, you must have: 27 | 28 | 1. Permissions to publish to the `org.bedework` groupId. 29 | 2. `gpg` installed with a published key (release artifacts are signed). 30 | 31 | To perform a new release - first commit and push any changes then: 32 | 33 | > mvn release:clean release:prepare 34 | 35 | When prompted, select the desired version; accept the defaults for scm tag and next development version. 36 | When the build completes, and the changes are committed and pushed successfully, execute: 37 | 38 | > mvn release:perform 39 | 40 | For full details, see [Sonatype's documentation for using Maven to publish releases](http://central.sonatype.org/pages/apache-maven.html). 41 | 42 | ## Release Order 43 | Modules need releasing in the order shown below. After each module release, update the dependencies in the remaining modules to refer to the newly released module. 44 | 45 | * bw-xml 46 | * bw-util-logging 47 | * bw-util 48 | * bw-util2 49 | * bw-util-hibernate 50 | * bw-access 51 | * bw-cli (No dependencies to update) 52 | * bw-timezone-server (No dependencies to update) 53 | * bw-self-registration (No dependencies to update) 54 | * bw-synch (No dependencies to update) 55 | * bw-event-registration (No dependencies to update) 56 | * bw-webdav 57 | * bw-carddav (No dependencies to update) 58 | * bw-caldav 59 | * bw-notifier (No dependencies to update) 60 | * bw-calendar-engine 61 | * bw-calendar-client 62 | -------------------------------------------------------------------------------- /src/main/asciidoc/administrators/reindex.adoc: -------------------------------------------------------------------------------- 1 | [[reindex]] 2 | === Reindexing 3 | Opensearch is used for indexing and searching the data. Nearly all complex queries take place against OpenSearch. The public facing web client and feeds use Opensearch exclusively - there are no database interactions. CalDAV read-only methods (e.g. GET, PROPFIND, etc) also interact only with Opensearch. 4 | 5 | The database is used only as a transactional store and only the admin clients and CalDAV write methods (PUT, POST etc) use the database. Changes made to the database result in updates to the Opensearch index, which in some cases can take up to a second to appear. 6 | 7 | Occasionally, the index will get out of step with the database. The database is the authoritative copy of the data. Sometimes - for an individual entity making a trivial change to the data via the admin client can get things back in step. If it's an event which was being destroyed, and it remained in the index a super-user can delete by href from the system tab. 8 | 9 | If things are significantly out of step, or you are restoring data you'll need to reindex. Depending on the amount of data present this can take from a few minutes to some hours. 10 | 11 | During reindexing, the system can continue to run using the previous index. However, any changes to the data may be lost so it is better to suspend any such changes until after reindexing is complete. 12 | 13 | A reindex takes 2 steps: 14 | 15 | . Build a new set of indexes from the data 16 | . If no errors make the new indexes production. 17 | 18 | These are both manually initiated. 19 | 20 | To reindex 21 | 22 | .... 23 | cd bw-cli 24 | ./target/client/bin/client -id -pw 25 | rebuildidx 26 | 27 | makeidxprod all 28 | .... 29 | 30 | Before the last step ensure that all phases of the indexing took place. 31 | If - for some reason - the client loses touch with the server, you can check the status with 32 | 33 | .... 34 | rebuildstatus 35 | .... 36 | 37 | The response should include a section which might look like this (for the quickstart data) 38 | 39 | .... 40 | Statistics for Public 41 | current status: indexCollection(/public/unbrowsable/submissions/submissions) 42 | Statistics for Public 43 | unreachableEntities: 0 44 | principals: 11 45 | preferences: 1 46 | collections: 71 47 | categories: 62 48 | locations: 5 49 | contacts: 4 50 | filters: 0 51 | events: 3 52 | resources: 10 53 | resourceContents: 10 54 | .... 55 | 56 | Note that - other than for filters - there are non-zero counts for everything. If resources for example are 0 check for errors. 57 | -------------------------------------------------------------------------------- /src/main/asciidoc/administrators/addTopicalArea.adoc: -------------------------------------------------------------------------------- 1 | [[Add-topical-area]] 2 | === Adding a topical area. 3 | 4 | ==== First create a category for the topical area. 5 | Or categories if necessary. The normal case is to filter and categorise with the same category. 6 | 7 | Go to *System* -> *Manage-categories* and add any required new category or categories. 8 | 9 | ==== Create a system alias. 10 | Go to *System* -> *Manage calendars & folders* and determine where in the hierarchy you want the topical area to appear. Usually under *aliases*. 11 | 12 | If you want to group aliases together first create a folder then 13 | create the aliases inside that folder 14 | 15 | *Create a new system folder* 16 | 17 | * Click the "+" on the folder in which you want to create the new subscription/alias 18 | * set the system name 19 | * display name 20 | * description 21 | * set the category or categories for auto-tagging and filtering 22 | * select "Subscription". 23 | * Set the url to bwcal:///public/cals/MainCal 24 | * ensure all other fields are blank and add the alias. 25 | 26 | *Create a new system subscription* 27 | 28 | * Click the "+" on the folder in which you want to create the new subscription/alias 29 | * set the system name 30 | * display name 31 | * description 32 | * set the category or categories for auto-tagging and filtering 33 | * select "Subscription". 34 | * Set the url to bwcal:///public/cals/MainCal 35 | * ensure all other fields are blank and add the alias. 36 | 37 | You may need to refresh the display to see the new alias. 38 | 39 | Using system aliases in this way ensures consistency in categorisation. 40 | 41 | ==== Create a calendar suite subscription to the new alias. 42 | Switch to the appropriate group then the *Calendar Suite* tab. 43 | 44 | If the new alias is in a folder it may already be available. 45 | 46 | Otherwise 47 | 48 | * Select *Manage Subscriptions* 49 | * Click *+* on the top level folder (named the same as the suite) 50 | * Set the names - probably the same as the alias 51 | * Add any extra filtering - note a default category will be added for the suite so normally no action is required on categories 52 | * Ensure the type is *Public alias* 53 | * Click *Select a public calendar or folder* 54 | * Click on the new alias 55 | * *Add* 56 | 57 | Now go to *Main Menu* -> *Add Event* and ensure the topical area is visible. 58 | 59 | ==== Add it to the view for the main campus 60 | The above needs to be done for the main campus calendar suite. Then 61 | 62 | * go to the *Calendar Suite* tab. 63 | * Select *Manage views* 64 | * Select the appropriate view 65 | * Add the new topical area 66 | 67 | Currently, it appears a restart is needed for it to appear (or a long wait). I'll try to add a flush to fix this. 68 | 69 | -------------------------------------------------------------------------------- /old-docs/administrators/subscriptions.md: -------------------------------------------------------------------------------- 1 | # Subscribing to a feed for public calendars. 2 | 3 | You probably want the incoming events to all be flagged with a specific category or categories. This can be useful for filtering.It makes it easier to include the calendar collections imported by the sync engine. Before carrying out the following steps ensure these categories are created. 4 | 5 | For public events there are a few more options available when subscribing. 6 | 7 | **Process Locations and Contacts:** This causes locations and contacts to be moved into x-properties **"X-BEDEWORK-LOCATION"** and **"X-BEDEWORK-CONTACT"**. The receiving end (bedework) may carry out further actions to validate the location or contact and as a result may set a preexisting location or contact in the event. The x-property is always available for display but this process allows the system to validate the location/contact. 8 | 9 | **Process categories:** This does the same for categories. 10 | 11 | ### Note: 12 | If you don't select those options then categories and locations will be created in bedework. This is probably not what is wanted as these are uncurated. 13 | 14 | By setting the **Process....** flag you ensure that such locations and categories don't end up in the database. 15 | 16 | **Suppress deletion of events?** This means that if events disappear from the feed they will stay in the database. This effectively turns the feed into a change feed adn can significantly reduce the size of the data. It does mean that events that MUST be deleted will require help from an administrator with sufficient privileges. 17 | 18 | ### Creating a public subscription 19 | 20 | As a super user 21 | * Switch to the System tab and select "Manage calendars and folders". 22 | * Open up "public" and click the "+" on the cals folder. 23 | * Set the name - e.g "Athletics" 24 | * Check off categories for filtering 25 | * Click on "show/hide categories used for filtering" 26 | * Scroll down and select a previously created category or categories 27 | * Check off any categories you want applied on input - 28 | * Click on "show/hide categories for auto-tagging on input" 29 | * Scroll down and select a previously created category or categories 30 | * Mark as a subscription 31 | * Set the URL in the URl field 32 | * Set an id/password if necessary 33 | * Select the "Process Locations and Contacts" and "Process Categories" checkboxes if desired (probably so) 34 | * Set the location key field name for mapping locations 35 | * Set the refresh rate in minutes 36 | * Save 37 | 38 | ### Mapping Locations 39 | 40 | The update process uses a key field set in locations to map the locations. The key field value should be an exact copy of what appears in the events. 41 | 42 | The actual location will be stored in an x-property -------------------------------------------------------------------------------- /docs/_layouts/default.html: -------------------------------------------------------------------------------- 1 | 2 | 3 | 4 | 5 | 6 | 7 | 8 | 9 | 10 | 11 | 12 | {% seo %} 13 | 14 | 15 | 16 | 17 | 18 |
19 |
20 | View on GitHub 21 | 22 |

{{ site.title | default: site.github.repository_name }}

23 |

{{ site.description | default: site.github.project_tagline }}

24 | 25 | {% if site.show_downloads %} 26 |
27 | Download this project as a .zip file 28 | Download this project as a tar.gz file 29 |
30 | {% endif %} 31 |
32 | 33 |
34 | 35 | 36 |
37 |
38 | {{ content }} 39 |
40 |
41 | 42 | 43 | 53 | 54 | {% if site.google_analytics %} 55 | 63 | {% endif %} 64 | 65 | 66 | -------------------------------------------------------------------------------- /src/main/asciidoc/development/github-actions.adoc: -------------------------------------------------------------------------------- 1 | [[github-actions]] 2 | === github actions to run dependency checks and codeql 3 | Sonatype migrated its platform, and at that time the owasp dependency checks stopped being run. In any case, these checks were only run on release — meaning possibly having to release again after fixing vulnerabilities. 4 | 5 | These checks can be run manually, but it is convenient to have them run on push — if you can get them to work. 6 | 7 | ==== Codeql 8 | This was relatively easy — see the action file in each project. 9 | 10 | ==== owasp dependency check. 11 | This seemed easy but turned out to have a number of issues. The desired end result was to: 12 | 13 | * Run the checks on push 14 | * At each run put the resulting report somewhere easy to access. 15 | 16 | === Running the checks 17 | Requires the maven plugin be installed. Configured to put the report into a folder "./target/reports". Perhaps unnecessary but allows other files as well. 18 | 19 | The plugin downloads data from a number of sites - in particular nvd.nist.gov. An api key is really a must to access this site or the requests will be throttled. Go to 20 | 21 | [source] 22 | ----- 23 | https://nvd.nist.gov/developers/request-an-api-key 24 | ----- 25 | 26 | You may want one per project. Add this as a project or organization secret. I used the name "nvdApiKey". 27 | 28 | The owasp data is added to an h2 database which is stored in the maven repository under org/owasp. It can take a long time to build so needs to be cached. The action will restore and save the maven cache. This is also needed to speed up builds. 29 | 30 | In the action, we use the goal aggregate for the maven plugin as they are mostly multi-module projects. 31 | 32 | The resulting report is copied into the "docs" folder. The main AsciiDoc file has a link to the report, so the latest report is available from the GitHub pages site. 33 | 34 | === Suppress on release 35 | The release process pushes to the repo a couple of times: 36 | 37 | 1. After setting the release version 38 | 2. After creating a tag 39 | 3. After setting the snapshot version 40 | 41 | Arguably - none of these should trigger an actions run. However at some point we may depend on an action to make a push work. 42 | 43 | Suppressing steps 1 and 2 is probably appropriate - especially as they generate push requests themselves which may intefere with the process. 44 | 45 | Disabling the actions can be achieved by following the instructions at https://docs.github.com/en/actions/managing-workflow-runs-and-deployments/managing-workflow-runs/skipping-workflow-runs 46 | in our case by adding a string to the commit message. 47 | 48 | === Asciidocs 49 | I decided the easiest way to get at the reports was to upload them to GitHub pages. None of these projects (other than the main bedework project) used GitHub pages. I set it up with a minimal amount of documentation, and the reports are copied in to the /docs folder for the project. -------------------------------------------------------------------------------- /old-docs/deployers/installing.md: -------------------------------------------------------------------------------- 1 | # Installing the quickstart (3.12.x onwards) 2 | 3 | Instructions for older releases are [here.](installing-old.md) 4 | 5 | The current quickstart is installed by executing a script which will create the quickstart directory and then download, clone and build. In the event of a failure part way through, the script may be restarted with the **restart** parameter. 6 | 7 | The script may be downloaded from github [here](https://github.com/Bedework/bedework/raw/master/build/quickstart/linux/installQS.sh). Alternatively clone the [bedework](https://github.com/Bedework/bedework.git) repo and use the script at **bedework/build/quickstart/linux/installQS.sh** 8 | 9 | ### Which version 10 | The script will ask you if you want the development or latest version. 11 | 12 | ### Apacheds 13 | The script will install apacheds. This will install a directory with some initial ids in place for testing. Ultimately you'll want to use your own directory service. 14 | 15 | ### Maven 16 | This is a maven project and as usual you need to set up your maven profile in ~/.m2/settings.xml. The script will display a possible settings.xml file with the paths filled in. 17 | 18 | If you want to merge in the profile to an existing settings.xml ensure you also merge in the **pluginGroups** section. 19 | 20 | The profile does not need to be active by default if you have other profiles. The build process will specify the bedework-3 profile. 21 | 22 | Below is the contents of that settings.xml file. This must be in place before allowing the script to continue on to the builds otherwise they will fail during deployment. 23 | 24 | ``` 25 | 29 | 30 | org.bedework 31 | 32 | 33 | 34 | 35 | bedework-3 36 | 37 | true 38 | 39 | 40 | $qs 41 | 42 | 43 | 44 | 45 | 46 | ``` 47 | 48 | ### Building 49 | In many cases it is possible to simply cd in to the appropriate directory and do a mvn install with the bedework-3 profile. However there is a **bw** script which - while taking longer - does build all projects a module depends upon. This avoids the need to work out the dependency orderings of the independent projects. Thus 50 | 51 | ```./bw deploy``` 52 | 53 | will build a lot of projects eventually building the client project which deploys an ear file. 54 | 55 | ### Deploying 56 | As part of the bedework project there is a maven plugin which handles post-build deployment issues. 57 | 58 | The deployment process may involve inserting filters for CAS, adding property values to web.xml files, cloning entire wars for calendar suites etc. 59 | 60 | When developing your own service the first thing to do is create a repository with your files. 61 | 62 | -------------------------------------------------------------------------------- /old-docs/development/todo.md: -------------------------------------------------------------------------------- 1 | # Todo list 2 | 3 | This is a (moderately) sorted list of features/changes etc for bedework. Could bea set of tickets but this is easier to read. 4 | 5 | ## Imminent changes 6 | Intend to get round to these ones Any Time Now(tm) 7 | * Filter x-properties in public clients/feeds - list of x-props to retain. 8 | 9 | ## Future changes 10 | These are longer term. Will pick away at these as time allows. 11 | 12 | ### Api changes 13 | Change the api to use response objects throughout. No exceptions. Allows for a better networked api. 14 | 15 | ### Notifications 16 | Need to be indexed in ES so that finding a notification for an entity is efficient (need to merge multiple notifications for same entity) 17 | Change notifications for public events is probably not working correctly. We should be using the creator - or the owner of the alias - all public events have the same owner (public-user) and change notifications seem to be ending up in that bucket. 18 | 19 | ### Limit interactions with db for updates. 20 | For this we would do all interactions with ES and connect to and update db only as needed. Use sequence numbers to ensure db and index correctness. Benefits are shorter db interactions - only at point we update. Less complexity in web clients - no need to have conversations stretching across multiple requests. This can build on the work of the previous item. The web client code is already structured ro assume that it will do an explicit update of entities which should facilitate the change. 21 | 22 | ### Move business logic out of webapps into core 23 | Move as much as possible out of the current webapps module into the core APi implementation - this potentially allows a more RESTful style of client - possibly using the new jmap style interface being developed. 24 | 25 | ### Categories 26 | Use a larger category scheme as the basis for categories. Use SKOS based representation so that they are RDF friendly. Will allow for sub-categorization by event submitters. 27 | 28 | ### Locations 29 | Allow for use of external location sources such as geonames. Will allow good locations on external events. 30 | 31 | ### Searching improvements 32 | Search for events near a geo-location (requires locations to have geo) 33 | 34 | ### Caching 35 | Implement caching of feeder data as a built in feature of the quickstart. 36 | 37 | ### Deployment of ears 38 | Finish off the deployment process - it's THAT close (is there an emoticon for 2 fingers very close together?) to allowing deployers to just replace the ears from prebuilt ears on the site. No builds required - server can detect an update is available. 39 | 40 | ### Deployment of wildfly modules 41 | If all - or many - required dependencies are deployed as wildfly modules it should reduce the size of the deployment and allow for even quicker startup. 42 | 43 | ### Networked client api 44 | Subset of svci but can be used for web client interactions. 45 | 46 | ### Groups 47 | Directory interface to directly interact with grouper for user and admin groups. Allow consumer only approach for external management of groups. Use extra ldap attributes to allow admin groups to be maintained in ldap. 48 | 49 | ### Index logs in ES 50 | Use kibana to get metrics etc 51 | 52 | ### Timezones 53 | Update UI to provide a search - possibly based on map. Use tzdist geo feature (being developed) 54 | 55 | ### General work needed 56 | * Upgrade ES to latest - changes the query structure 57 | * Upgrade all libraries to latest 58 | * Preprocess the xsl to build the deployable language specific versions. 59 | 60 | 61 | -------------------------------------------------------------------------------- /src/main/asciidoc/deployers/opensearch.adoc: -------------------------------------------------------------------------------- 1 | [[installing-opensearch]] 2 | === Install and configure OpenSearch 3 | Bedework uses OpenSearch as the indexer engine. As objects are created destroyed and updated they are indexed through calls to the indexer. The indexer can run as a local application, useful for development - or as an external service - which will be required for clustering. The version bedework is using is 2.18.0 4 | 5 | It is safer to NOT run in production with the OpenSearch interfaces open to the outside. OpenSearch now has various configuration options available. Bedework supports basic user authentication. Currently, you can run unauthenticated but OpenSearch will generate a lot of warnings in the log. 6 | 7 | You can run OpenSearch on the same server, but preferably it should be running on a different server. OpenSearch - depending on the amount of data and types of search - can use a lot of memory for caching of filters. See the OpenSearch site for full instructions on running and installing. 8 | 9 | In general this is an easy process - OpenSearch offers various installation formats of all their versions. 10 | 11 | Bedework requires a small number of changes to the configuration. These are available in the deployed wildfly at 12 | 13 | [source] 14 | ---- 15 | wildfly/standalone/configuration/bedework/opensearch/config/opensearch.yml 16 | ---- 17 | 18 | The changes made are 19 | 20 | [source] 21 | ---- 22 | action.auto_create_index: "-bw*,+*" 23 | 24 | # Limit to inline only 25 | script.allowed_types: inline 26 | ---- 27 | 28 | Prevent OpenSearch from creating bedework indexes implicitly. This can cause issues when reindexing. 29 | 30 | [source] 31 | ---- 32 | cluster.name: bedework-2019 33 | ... 34 | node.name: bw2019-1 35 | ... 36 | cluster.initial_master_nodes: ["bw2019-1"] 37 | ---- 38 | 39 | Use specific names for the cluster and nodes. 40 | 41 | [[installing]] 42 | ==== Installing OpenSearch 43 | There are a number of options available. The deployed wildfly demo server has a script to deploy a docker image of OpenSearch. 44 | First ensure docker is installed on your system and running then execute: 45 | 46 | wildfly/bin/bwinstallosch.sh 47 | 48 | To run the image: 49 | 50 | wildfly/bin/bwstartosch.sh 51 | 52 | will start a container with volumes bound to 53 | 54 | * wildfly/standalone/configuration/bedework/opensearch/config 55 | * wildfly/standalone/data/bedework/opensearch/data 56 | * wildfly/standalone/log 57 | 58 | This is only suitable in that form for demonstration but may provide the basis for a production service. 59 | 60 | For more information see https://opensearch.org/docs 61 | 62 | If you're looking to install as a production service you need to install OpenSearch as a service. There are instructions at the OpenSearch site fo installing on various platforms. 63 | 64 | The 2.1.0 release is available at: 65 | ---- 66 | https://artifacts.opensearch.org/releases/bundle/opensearch/2.1.0/opensearch-2.1.0-linux-x64.tar.gz 67 | ---- 68 | 69 | After installing and starting the service you will need to restore and reindex the data. For instructions see <>. 70 | 71 | ==== Installing a runnable OpenSearch 72 | If you wish to install OpenSearch as a runnable service there are instructions on running a minimal version without any security. 73 | You will need to copy the configuration and possibly the data from the deployed demo wildfly. 74 | 75 | In your /.bw file add 76 | 77 | ................. 78 | # 79 | # OpenSearch options 80 | # 81 | bwOschdatadir="//data/" 82 | ................. 83 | 84 | Then you can use the restore script to restore the data and indexes: 85 | 86 | ................. 87 | .wildfly/bin/bwresetQS.sh 88 | ................. 89 | 90 | -------------------------------------------------------------------------------- /.idea/vcs.xml: -------------------------------------------------------------------------------- 1 | 2 | 3 | 4 | 5 | 6 | 7 | 8 | 9 | 10 | 11 | 12 | 13 | 14 | 15 | 16 | 17 | 18 | 19 | 20 | 21 | 22 | 23 | 24 | 25 | 26 | 27 | 28 | 29 | 30 | 31 | 32 | 33 | 34 | 35 | 36 | 37 | 38 | 39 | 40 | 41 | 42 | 43 | 44 | 45 | 46 | 47 | 48 | 49 | 50 | 51 | 52 | 53 | 54 | 55 | 56 | -------------------------------------------------------------------------------- /src/main/asciidoc/development/building.adoc: -------------------------------------------------------------------------------- 1 | [[building-bedwork]] 2 | === Building bedework 3 | 4 | Any examples tend to be ubuntu but bedework can be built on any system that supports java17. 5 | 6 | . Ensure java 17 jdk is installed 7 | + 8 | ................. 9 | sudo apt-get install openjdk-17-jdk-headless 10 | sudo update-alternatives --config java 11 | ................. 12 | + 13 | The last command should state there are no alternatives but if another has been installed pick the appropriate version. 14 | 15 | . Install maven 16 | ................. 17 | sudo apt install maven 18 | ................. 19 | 20 | . Install git 21 | + 22 | ................. 23 | sudo apt install git 24 | ................. 25 | 26 | . Set up maven 27 | + 28 | If you are doing builds of versions before 4.0.0 then set up the maven profile which must be named "bedework-3" 29 | + 30 | ................. 31 | mkdir ~/.m2 32 | emacs ~/.m2/settings.xml 33 | ................. 34 | + 35 | and paste in a modified form of the following (change the paths 36 | "/home/mike/bedework/" to correspond to the directory you're about 37 | to create) 38 | + 39 | ................. 40 | 44 | 45 | org.bedework 46 | 47 | 48 | 49 | 50 | bedework-3 51 | 52 | true 53 | 54 | 55 | 17 56 | 17 57 | /home/mike/bedework/quickstart-dev 58 | /home/mike/bedework/quickstart-dev/bedework/config/wildfly.deploy.properties 59 | 60 | 61 | 62 | 63 | ................. 64 | . Provide a bw settings file. 65 | + 66 | If necessary create a *.bw* file in your home directory and add properties to it. Currently, the only properties allow setting the profile for the *.bw* script used to build and the location of the deployment proeprties used to configure your deployed modules. 67 | + 68 | An example file is 69 | + 70 | ................. 71 | # 72 | # Defaults for bw script 73 | # 74 | echo "Setting defaults from .bw" 75 | bw_mvnProfile="-P bedework_dev" 76 | 77 | bw_deployProps="/home/myhome/bwstuff/myprops.properties" 78 | ................. 79 | 80 | . Create a directory in which to place sources and wildfly. 81 | + 82 | Much of the build assumes a directory in which we have each of the bedework projects and a working wildfly deployment. We'll refer to this directory as . 83 | 84 | . Cd into and install wildfly 85 | + 86 | Follow the instructions in <>. Choose a version which runs your db of choice and installs a copy of opensearch. 87 | + 88 | If you want to use postgres as your db you need to install that yourself. See <> 89 | 90 | . Create wildfly symlink 91 | + 92 | This provides a consistent name for the server. 93 | ---- 94 | ln -s wildfly-26.1.3.Final wildfly 95 | ---- 96 | 97 | . Clone sources 98 | 99 | ---- 100 | cd 101 | git clone https://github.com/Bedework/bedework.git 102 | 103 | ./bedework/build/quickstart/linux/cloneall.sh 104 | ---- 105 | 106 | To build, this should build all 107 | ---- 108 | ./bedework/build/quickstart/linux/util-scripts/deploySnapshots.sh 109 | ---- 110 | 111 | -------------------------------------------------------------------------------- /docs/coderay-asciidoctor.css: -------------------------------------------------------------------------------- 1 | /* Stylesheet for CodeRay to match GitHub theme | MIT License | http://foundation.zurb.com */ 2 | /*pre.CodeRay {background-color:#f7f7f8;}*/ 3 | .CodeRay .line-numbers{border-right:1px solid #d8d8d8;padding:0 0.5em 0 .25em} 4 | .CodeRay span.line-numbers{display:inline-block;margin-right:.5em;color:rgba(0,0,0,.3)} 5 | .CodeRay .line-numbers strong{color:rgba(0,0,0,.4)} 6 | table.CodeRay{border-collapse:separate;border-spacing:0;margin-bottom:0;border:0;background:none} 7 | table.CodeRay td{vertical-align: top;line-height:1.45} 8 | table.CodeRay td.line-numbers{text-align:right} 9 | table.CodeRay td.line-numbers>pre{padding:0;color:rgba(0,0,0,.3)} 10 | table.CodeRay td.code{padding:0 0 0 .5em} 11 | table.CodeRay td.code>pre{padding:0} 12 | .CodeRay .debug{color:#fff !important;background:#000080 !important} 13 | .CodeRay .annotation{color:#007} 14 | .CodeRay .attribute-name{color:#000080} 15 | .CodeRay .attribute-value{color:#700} 16 | .CodeRay .binary{color:#509} 17 | .CodeRay .comment{color:#998;font-style:italic} 18 | .CodeRay .char{color:#04d} 19 | .CodeRay .char .content{color:#04d} 20 | .CodeRay .char .delimiter{color:#039} 21 | .CodeRay .class{color:#458;font-weight:bold} 22 | .CodeRay .complex{color:#a08} 23 | .CodeRay .constant,.CodeRay .predefined-constant{color:#008080} 24 | .CodeRay .color{color:#099} 25 | .CodeRay .class-variable{color:#369} 26 | .CodeRay .decorator{color:#b0b} 27 | .CodeRay .definition{color:#099} 28 | .CodeRay .delimiter{color:#000} 29 | .CodeRay .doc{color:#970} 30 | .CodeRay .doctype{color:#34b} 31 | .CodeRay .doc-string{color:#d42} 32 | .CodeRay .escape{color:#666} 33 | .CodeRay .entity{color:#800} 34 | .CodeRay .error{color:#808} 35 | .CodeRay .exception{color:inherit} 36 | .CodeRay .filename{color:#099} 37 | .CodeRay .function{color:#900;font-weight:bold} 38 | .CodeRay .global-variable{color:#008080} 39 | .CodeRay .hex{color:#058} 40 | .CodeRay .integer,.CodeRay .float{color:#099} 41 | .CodeRay .include{color:#555} 42 | .CodeRay .inline{color:#000} 43 | .CodeRay .inline .inline{background:#ccc} 44 | .CodeRay .inline .inline .inline{background:#bbb} 45 | .CodeRay .inline .inline-delimiter{color:#d14} 46 | .CodeRay .inline-delimiter{color:#d14} 47 | .CodeRay .important{color:#555;font-weight:bold} 48 | .CodeRay .interpreted{color:#b2b} 49 | .CodeRay .instance-variable{color:#008080} 50 | .CodeRay .label{color:#970} 51 | .CodeRay .local-variable{color:#963} 52 | .CodeRay .octal{color:#40e} 53 | .CodeRay .predefined{color:#369} 54 | .CodeRay .preprocessor{color:#579} 55 | .CodeRay .pseudo-class{color:#555} 56 | .CodeRay .directive{font-weight:bold} 57 | .CodeRay .type{font-weight:bold} 58 | .CodeRay .predefined-type{color:inherit} 59 | .CodeRay .reserved,.CodeRay .keyword {color:#000;font-weight:bold} 60 | .CodeRay .key{color:#808} 61 | .CodeRay .key .delimiter{color:#606} 62 | .CodeRay .key .char{color:#80f} 63 | .CodeRay .value{color:#088} 64 | .CodeRay .regexp .delimiter{color:#808} 65 | .CodeRay .regexp .content{color:#808} 66 | .CodeRay .regexp .modifier{color:#808} 67 | .CodeRay .regexp .char{color:#d14} 68 | .CodeRay .regexp .function{color:#404;font-weight:bold} 69 | .CodeRay .string{color:#d20} 70 | .CodeRay .string .string .string{background:#ffd0d0} 71 | .CodeRay .string .content{color:#d14} 72 | .CodeRay .string .char{color:#d14} 73 | .CodeRay .string .delimiter{color:#d14} 74 | .CodeRay .shell{color:#d14} 75 | .CodeRay .shell .delimiter{color:#d14} 76 | .CodeRay .symbol{color:#990073} 77 | .CodeRay .symbol .content{color:#a60} 78 | .CodeRay .symbol .delimiter{color:#630} 79 | .CodeRay .tag{color:#008080} 80 | .CodeRay .tag-special{color:#d70} 81 | .CodeRay .variable{color:#036} 82 | .CodeRay .insert{background:#afa} 83 | .CodeRay .delete{background:#faa} 84 | .CodeRay .change{color:#aaf;background:#007} 85 | .CodeRay .head{color:#f8f;background:#505} 86 | .CodeRay .insert .insert{color:#080} 87 | .CodeRay .delete .delete{color:#800} 88 | .CodeRay .change .change{color:#66f} 89 | .CodeRay .head .head{color:#f4f} -------------------------------------------------------------------------------- /old-docs/deployers/eventRegistration.md: -------------------------------------------------------------------------------- 1 | # Enabling and Disabling Public Events Registration 2 | #### Enabling Public Events Registration 3 | 4 | The public events registration system is enabled by default if you have installed Bedework with the data available in the quickstart. 5 | 6 | #### Disabling Public Events Registration 7 | 8 | If you wish to disable the public events registration system remove the "Eventreg admin token" from the System Preferences in the jmx console: 9 | 10 | * Log into the Bedework jmx console, e.g. http://localhost:8080/hawtio 11 | * Click "org.bedework.bwengine" in the left menu, then "service=System" in the right menu 12 | * Remove the value in the EventRegAdminToken field 13 | * Click "Apply Changes" 14 | * Invoke "saveConfig" to save your changes. 15 | 16 | #### Enabling Public Events Registration (possibly after upgrade from a previous release) 17 | 18 | First ensure that the CalWs interface is available. This is the SOAP service that the event registration service uses o communicate with bedework. In system.xml make sure the element is present and has the same value as the soap:address element in pubcalws-soap/wsdls/wssvc.wsdl (this requires better explanation - it's a file deployed in the bw-xml ear) 19 | 20 | If you have upgraded from an older release, you may not have the data required for event registration in your system yet. Follow these steps to turn on the event registration system: (Please note: the process outlined below is only set up for the default quickstart and postgresql configs at the moment.) 21 | 22 | * Start up jboss and apacheDS 23 | 24 | * Log into the JMX-Console shipped with Bedework's JBoss, e.g. http://localhost:8080/hawtio 25 | * Click "org.bedework.eventreg" in the left menu, then "service=Eventreg" in the right menu 26 | * If no database exists: 27 | * Set “create” and “export” attributes to "True" 28 | * Click "Apply changes" button (at the bottom of the list of attribute values) 29 | * Find the "schema" operation in the lower list, and click the “Invoke” button to export schema and create database 30 | * You should see a successful result; click "Back to MBean" button to return to "service=Eventreg" 31 | * Point at needed systems: 32 | * Set the WsdlUri attribute value to: http://localhost:8080/wsdls/pubcalws-soap/wssvc.wsdl 33 | * Set the TzsUri attribute value to: http://localhost:8080/tzsvr 34 | * Click "Apply changes" button 35 | * Admin token: 36 | * If no admin token exists, click “generateAdminToken” 37 | * You should see a successful result; click "Back to MBean" button to return to "service=Eventreg" 38 | * You should see a string such as "c0e93685-93cd-4bee-bed2-9996b89be28c" in the EventRegAdminToken attribute value. 39 | * Copy the EventRegAdminToken value (for use in the next step) 40 | 41 | * Click "org.bedework.bwengine" in the left menu, then "service=System" in the right menu 42 | 43 | * Paste the value into the EventRegAdminToken field 44 | * Click "Apply Changes" button 45 | * Invoke the "saveConfig" operation to save your changes. 46 | 47 | * Test: 48 | * Add a new public event. You should be able to select the checkbox "Users may register for this event", and make the event registerable. 49 | * Visit the event in public client -- you should be able to register for it. 50 | 51 | ### Notifications from EventReg 52 | 53 | The event registration service will send notifications to the calendar engine when changes take place that might require notifying users. The event registration service calls the calendar engine notification web service (not to be confused with the notification engine). This web service allows the core engine to add notifications to the accounts of subscribed users. It is the job of the notification engine to forward those via email or some other service. 54 | 55 | To configure notifications from eventreg you need to set the BwId, BwToken and BwUri properties in "service=Eventreg"and the NotifierId and NotifierToken values in "org.bedework.bwengine" -> "notifications" 56 | 57 | 58 | -------------------------------------------------------------------------------- /old-docs/deployers/synch-engine.md: -------------------------------------------------------------------------------- 1 | # Synch Engine 2 | The synch engine handles the synchronization of external subscriptions with a bedework calendar - for example a Google web calendar or an ical feed from a department. 3 | 4 | Currently such a synchronization must be carried out to a single calendar collection which only contains data from the external resource. Also only one way synchronization is supported - inbound to bedework. 5 | 6 | These subscriptions are available to personal calendar users and to public events administrators. For personal calendar users the options are limited as it is intended only to mirror the external resource. 7 | 8 | ##Initializing the database - PostgreSQL 9 | 10 | ``` 11 | create database eventregdbstd with owner bw; 12 | ``` 13 | 14 | ##Initializing the database - MySQL 15 | 16 | If running with mysql the built in hibernate schema export doesn't work - mysql jdbc does not support it. 17 | 18 | The schema is simple however - it can be generated via the JMX mbeans or use the examples below - to install it manually, create a database - ensure UTF-8 is enabled 19 | 20 | ``` 21 | CREATE DATABASE `synchdb` DEFAULT CHARACTER SET utf8; 22 | grant all on synchDb.* to ''@'%' identified by ''; 23 | 24 | ``` 25 | and then create the single table: 26 | 27 | 28 | ``` 29 | CREATE TABLE `bwsynch_subs` ( 30 | `bwsyn_id` bigint(20) NOT NULL AUTO_INCREMENT, 31 | `bwsyn_seq` int(11) NOT NULL, 32 | `bwsyn_subid` varchar(250) NOT NULL, 33 | `bwsyn_owner` varchar(500) NOT NULL, 34 | `bwsyn_lrefresh` varchar(20) DEFAULT NULL, 35 | `bwsyn_errorct` int(11) DEFAULT NULL, 36 | `bwsyn_missing` char(1) NOT NULL, 37 | `bwsyn_connectorid_a` varchar(100) DEFAULT NULL, 38 | `bwsyn_conn_props_a` varchar(3000) DEFAULT NULL, 39 | `bwsyn_connectorid_b` varchar(100) DEFAULT NULL, 40 | `bwsyn_conn_props_b` varchar(3000) DEFAULT NULL, 41 | `bwsyn_props` varchar(3000) DEFAULT NULL, 42 | `bwsyn_dir` varchar(25) NOT NULL, 43 | `bwsyn_mstr` varchar(25) NOT NULL, 44 | PRIMARY KEY (`bwsyn_id`), 45 | UNIQUE KEY `UK_qptomm2syatpqumsl1udwk7be` (`bwsyn_subid`), 46 | KEY `bwsynidx_subid` (`bwsyn_subid`), 47 | KEY `bwsynidx_subowner` (`bwsyn_owner`) 48 | ) ENGINE=InnoDB DEFAULT CHARSET=utf8; 49 | 50 | ``` 51 | 52 | ## (Re)build bw-xml 53 | 54 | The synch engine uses an extension of CalWS to communicate with bedework. It requires that the wsdl file contain the location of bedework. This is configured into the deploy.properties file - only one change for the synch engine should be necessary. Set the location of (one of) your application servers in the following. 55 | 56 | 57 | ``` 58 | # ------------------------------------------------------------------------ 59 | # wsdls; ear bw-xml 60 | # These go together - first name the wsdl directories and files... 61 | org.bedework.app.bw-xml.bwwsdls.wsdl.synch=wssvc.wsdl 62 | 63 | # then provide the global properties 64 | org.bedework.global.synch.service.location=http://localhost:8080/synchws/ 65 | 66 | ``` 67 | 68 | If you are running everything on one server then the quickstart setting above will do. Note that at the moment the synch engine can only work against a single bedework server. It can accept requests from any member of the cluster however. 69 | 70 | ##Keys 71 | 72 | This is only necessary if you expect to create subscriptions that require an id and password. Most public event subscriptions don't require this step. 73 | 74 | Generate a set of keys using the cli. 75 | 76 | 77 | ``` 78 | cd bw-cli/target/client/bin 79 | ./client 80 | JMX id: 81 | Password: 82 | cmd:genkeys gen 83 | test with---->A variable of array type holds a reference to an object. 84 | encrypts to-->BaUPfgTjzZxxbbW+lJACxmdo56tldkgfnr7LERkRTVyLQJh0kVt+GJZgJA1k9Wm+ojvpJCYFl34ybTy0vX2PM8Tu0+UsMKeV3HDi24NW6cH+C+QQ6XATLtskiBPhUQufpHBIKCke08PNh24xCoIk9+hllLgQQNCgVB1JQnQA0ak= 85 | decrypts to-->A variable of array type holds a reference to an object. 86 | 87 | Validity check succeeded 88 | 89 | ``` 90 | 91 | If you are using multiple servers copy the resulting key file from //standalone/data/bedework/ on to each server. 92 | Ensure calendar server(s) can locate the synch engine. 93 | 94 | The bwengine/synch settings are configured to use a jvm system property to locate the synch engine. In file //standalone/configuration/bedework/bwengine/synch.xml you should see: 95 | 96 | 97 | ``` 98 | 99 | 100 | 101 | localBedework 102 | http://localhost:8080/synch/manager 103 | http://localhost:8080/wsdls/synch/wssvc.wsdl 104 | 105 | 106 | ``` 107 | If you are using multiple servers change the host in to refer to your sync server. 108 | 109 | ###Validating locations. 110 | When an event arrives at the receiving end with an "X-BEDEWORK-LOCATION" property if the String value of the x-property is ... -------------------------------------------------------------------------------- /old-docs/schema/galleon-package-2_0.xsd: -------------------------------------------------------------------------------- 1 | 2 | 20 | 23 | 24 | 25 | 26 | 27 | 28 | 29 | Describes a feature-pack package which is an atomic unit of content. 30 | 31 | 32 | 33 | 34 | 35 | 36 | 37 | 38 | The name of the package which must be unique inside the feature-pack. 39 | 40 | 41 | 42 | 43 | 44 | 45 | 46 | 47 | Describes a list of package dependencies. 48 | 49 | 50 | 51 | 52 | 53 | 54 | 55 | 56 | 57 | 58 | 59 | Describes a package dependency on another package. 60 | When a package is selected to be installed, all the packages it depends 61 | on will also be installed unless they have been explicitly excluded by 62 | the user. 63 | If a user installs a package which has a required dependency on an 64 | excluded package, the provisioning process will terminate with an error. 65 | If a user installs a package which has an optional dependency on an 66 | excluded package, the provisioning process will proceed installing 67 | the package the user chose to install. 68 | 69 | 70 | 71 | 72 | 73 | Name of a package, the package declaring dependency depends on. 74 | 75 | 76 | 77 | 78 | 79 | 80 | Indicates whether the dependency is optional or required. 81 | 82 | 83 | 84 | 85 | 86 | 87 | Indicates whether the dependency is optional and passive. Passive dependencies 88 | are always optional. Attempt to mark a required dependency as passive should 89 | result in an error. 90 | 91 | 92 | 93 | 94 | 95 | 96 | 97 | 98 | Describes an external package dependency. 99 | I.e a dependency on packages that belong to another feature-pack. 100 | External dependencies are assumed to be required dependencies. 101 | 102 | 103 | 104 | 105 | 106 | 107 | 108 | 109 | Name assigned to a dependency on the feature-pack (in 110 | the feature-pack.xml of the feature-pack this package belongs to) 111 | which will be used as a source for external package dependencies 112 | specified as children of the element of this type. 113 | 114 | 115 | 116 | 117 | 118 | -------------------------------------------------------------------------------- /src/main/asciidoc/deployers/databases.adoc: -------------------------------------------------------------------------------- 1 | [[setting-up-databases]] 2 | === Setting up databases 3 | The quickstart is configured to use h2 for demonstration only. For production, you will need to switch to something like postgresql or mysql. 4 | 5 | Below there is some help on configuring the database. Additionally, there is some information on reconfiguring wildfly. A better approach is to install a configuration specifically for the desired database using galleon. In that case any information on wildfly configuration can be skipped. 6 | 7 | ==== postgresql 8 | We'll describe the process for the main calendar engine. The others are very similar. 9 | 10 | All bedework and wildfly configuration files are in standalone/configuration/ - we'll just refer to the relative path. 11 | 12 | * Name: caldb (you can change that if you wish) 13 | * Configuration: bedework/bwcore/dbconfig.xml 14 | * datasource: CalendarDS 15 | 16 | ===== Configure postgresql 17 | You'll probably need to configure postgres to allow your chosen role access to the server and databases. 18 | 19 | Depending on how you're running the system you may need to modify postgresql.conf and pg_haba.conf - both located by default in the data directory. 20 | 21 | If you're running postgres on a separate system you may need to change the listen_addresses value and port: 22 | 23 | [source] 24 | ---- 25 | listen_addresses = 'localhost' # what IP address(es) to listen on; 26 | # comma-separated list of addresses; 27 | # defaults to 'localhost'; use '*' for all 28 | # (change requires restart) 29 | port = 5432 # (change requires restart) 30 | ---- 31 | 32 | Change "localhost" to "*" or a list of addresses. 33 | 34 | 5432 is the default port. 35 | 36 | To allow your account access you will need to add a line or lines to pg_hba.conf near the end something like: 37 | 38 | [source] 39 | ---- 40 | host all bedework 10.0.0.1/32 md5 41 | ---- 42 | This can be made more restrictive by naming the db. 43 | 44 | 45 | Create a database with a known id/password. Ensure it is accessible from the host you are running bedework on. 46 | 47 | The psql commands are something like: 48 | 49 | [source] 50 | ---- 51 | create role bw with login password 'xxxxxxxxx'; 52 | create database caldb owner bw; 53 | ---- 54 | 55 | Some or all of the following seems to be required. Note it also seems to be important to connect to the database first: 56 | ---- 57 | \c caldb 58 | GRANT ALL PRIVILEGES ON ALL TABLES IN SCHEMA public TO bw; 59 | grant all privileges on database caldb to bw; 60 | ---- 61 | 62 | ===== Check configurations 63 | You MUST install the postgres version for this to work. Most of the configuration is already done for you. You will need to provide the id and password. 64 | 65 | Configuration overrides are found in 66 | ---- 67 | /bin/bwcommon.conf 68 | ---- 69 | 70 | For example: replace 71 | ---- 72 | #JAVA_OPTS="$JAVA_OPTS -Dorg.bedework.site.db.id.calendar=sa 73 | #JAVA_OPTS="$JAVA_OPTS -Dorg.bedework.site.db.pw.calendar=sa 74 | ---- 75 | 76 | with 77 | 78 | ---- 79 | JAVA_OPTS="$JAVA_OPTS -Dorg.bedework.site.db.id.calendar=bw 80 | #JAVA_OPTS="$JAVA_OPTS -Dorg.bedework.site.db.pw.calendar=xxxx 81 | ---- 82 | 83 | Use the psql client application to install the initial schema and data. 84 | 85 | [source] 86 | ---- 87 | psql caldb < /standalone/data/bedework/postgresql/caldb.sql 88 | ---- 89 | 90 | Note this file sets the owner to 'bw'. If you want a different owner then edit the file first. 91 | 92 | ===== Do the same for other databases. 93 | If you are running the notifier do the same for that database: 94 | 95 | ---- 96 | psql 97 | create database notifydb owner bw; 98 | grant all privileges on database notifydb to bw; 99 | \q 100 | psql notifydb < /opt/bedework/wildfly/docs/schema/postgresql/notifyschema-pg.sql 101 | ---- 102 | and update bwcommon.conf. 103 | 104 | ---- 105 | psql 106 | create database synchdb owner bw; 107 | grant all privileges on database synchdb to bw; 108 | \q 109 | psql notifydb < /opt/bedework/wildfly/docs/schema/postgresql/synchschema-pg.sql 110 | ---- 111 | 112 | Similarly for the synch engine: 113 | 114 | 115 | ===== Install opensearch 116 | ===== Start wildfly 117 | There will be a number of erros because of the lack of data 118 | 119 | In the cli enter the command 120 | 121 | [source] 122 | ---- 123 | ./wildfly/bin/bwcli.sh jmxUrl http://localhost:8080/jolokia -id -pw 124 | restoreCal "/full/path/to/initbedework.xml" 125 | ---- 126 | The quotes are required. Some activity should ensue. 127 | 128 | Reindex the data - again use the cli 129 | 130 | [source] 131 | ---- 132 | rebuildidx 133 | ---- 134 | 135 | wait for it to terminate - then enter 136 | 137 | [source] 138 | ---- 139 | listidx 140 | ---- 141 | The alias ***bwuser*** should be pointing at the index before the last one just created. 142 | 143 | In the cli 144 | 145 | [source] 146 | ---- 147 | makeidxprod index-name 148 | ---- 149 | replacing ***index-name*** with that last name - no quotes. 150 | 151 | ==== MySQL 152 | 153 | TBD 154 | 155 | Set the hibernate dialect in the config file: 156 | [source,xml] 157 | ---- 158 | hibernate.dialect=org.hibernate.dialect.MySQL5InnoDBDialect 159 | ---- 160 | -------------------------------------------------------------------------------- /src/main/asciidoc/deployers/synch-engine.adoc: -------------------------------------------------------------------------------- 1 | [[deploying-sync-engine]] 2 | === Deploying the sync engine 3 | The synch engine handles the synchronization of external subscriptions with a bedework calendar - for example a Google web calendar or an ical feed from a department. 4 | 5 | Currently, such a synchronization must be carried out to a single calendar collection which only contains data from the external resource. Also, only one way synchronization is supported - inbound to bedework. 6 | 7 | These subscriptions are available to personal calendar users and to public events administrators. For personal calendar users, the options are limited as it is intended only to mirror the external resource. 8 | 9 | === Initializing the database 10 | If running with mysql, the built-in hibernate schema export doesn't work - mysql jdbc does not support it. 11 | 12 | The schema is simple however, it can be generated via the JMX mbeans or use the examples below - to install it manually, create a database - ensure UTF-8 is enabled 13 | 14 | [source] 15 | ---- 16 | CREATE DATABASE `synchdb` DEFAULT CHARACTER SET utf8; 17 | grant all on synchDb.* to ''@'%' identified by ''; 18 | ---- 19 | 20 | and then create the single table: 21 | 22 | [source] 23 | ---- 24 | CREATE TABLE `bwsynch_subs` ( 25 | `bwsyn_id` bigint(20) NOT NULL AUTO_INCREMENT, 26 | `bwsyn_seq` int(11) NOT NULL, 27 | `bwsyn_subid` varchar(250) NOT NULL, 28 | `bwsyn_owner` varchar(500) NOT NULL, 29 | `bwsyn_lrefresh` varchar(20) DEFAULT NULL, 30 | `bwsyn_errorct` int(11) DEFAULT NULL, 31 | `bwsyn_missing` char(1) NOT NULL, 32 | `bwsyn_connectorid_a` varchar(100) DEFAULT NULL, 33 | `bwsyn_conn_props_a` varchar(3000) DEFAULT NULL, 34 | `bwsyn_connectorid_b` varchar(100) DEFAULT NULL, 35 | `bwsyn_conn_props_b` varchar(3000) DEFAULT NULL, 36 | `bwsyn_props` varchar(3000) DEFAULT NULL, 37 | `bwsyn_dir` varchar(25) NOT NULL, 38 | `bwsyn_mstr` varchar(25) NOT NULL, 39 | PRIMARY KEY (`bwsyn_id`), 40 | UNIQUE KEY `UK_qptomm2syatpqumsl1udwk7be` (`bwsyn_subid`), 41 | KEY `bwsynidx_subid` (`bwsyn_subid`), 42 | KEY `bwsynidx_subowner` (`bwsyn_owner`) 43 | ) ENGINE=InnoDB DEFAULT CHARSET=utf8; 44 | 45 | ---- 46 | 47 | ==== (Re)build bw-xml 48 | 49 | The synch engine uses an extension of CalWS to communicate with bedework. It requires that the wsdl file contain the location of bedework. This is configured into the deploy.properties file - only one change for the synch engine should be necessary. Set the location of (one of) your application servers in the following. 50 | 51 | [source] 52 | ---- 53 | # ------------------------------------------------------------------------ 54 | # wsdls; ear bw-xml 55 | # These go together - first name the wsdl directories and files... 56 | org.bedework.app.bw-xml.bwwsdls.wsdl.synch=wssvc.wsdl 57 | 58 | # then provide the global properties 59 | org.bedework.global.synch.service.location=http://localhost:8080/synchws/ 60 | 61 | ---- 62 | 63 | If you are running everything on one server then the quickstart setting above will do. Note that at the moment the synch engine can only work against a single bedework server. It can accept requests from any member of the cluster however. 64 | Keys 65 | 66 | Generate a set of keys using the cli. 67 | 68 | [source] 69 | ---- 70 | cd bwcli/dist/temp/shellscr/bwcli/ (or wherever your binary is) 71 | ./bwcli.sh 72 | /usr/lib/jvm/java-8-oracle/bin/java -cp .:./classes:./resources:lib/bw-access-3.11.0.jar:lib/bw-annotations-3.11.0.jar:lib/bw-calfacade-3.11.0.jar:lib/bwcli-3.11.0.jar:lib/bw-ical4j-vcard-1.0.5.jar:lib/commons-collections4-4.0.jar:lib/commons-lang-2.3.jar:lib/commons-lang3-3.3.2.jar:lib/commons-logging.jar:lib/httpclient-osgi-4.3.3.jar:lib/ical4j-2.0.6.jar:lib/jackson-annotations-2.1.1.jar:lib/jackson-core-2.1.1.jar:lib/jackson-databind-2.1.1.jar:lib/jolokia-client-java-1.3.1.jar:lib/json-simple-1.1.1.jar:lib/log4j-1.2.8.jar:lib/rpiutil-3.11.0.jar org.bedework.bwcli.BwCli 73 | JMX id: 74 | Password: 75 | cmd:genkeys gen 76 | test with---->A variable of array type holds a reference to an object. 77 | encrypts to-->BaUPfgTjzZxxbbW+lJACxmdo56tldkgfnr7LERkRTVyLQJh0kVt+GJZgJA1k9Wm+ojvpJCYFl34ybTy0vX2PM8Tu0+UsMKeV3HDi24NW6cH+C+QQ6XATLtskiBPhUQufpHBIKCke08PNh24xCoIk9+hllLgQQNCgVB1JQnQA0ak= 78 | decrypts to-->A variable of array type holds a reference to an object. 79 | 80 | Validity check succeeded 81 | ---- 82 | 83 | If you are using multiple servers copy the resulting key file from /wildfly/standalone/data/bedework/ on to each server. 84 | Ensure calendar server(s) can locate the synch engine. 85 | 86 | The bwengine/synch settings are configured to use a jvm system property to locate the synch engine. In file /wildfly/standalone/configuration/bedework/bwengine/synch.xml you should see: 87 | 88 | [source,xml] 89 | ---- 90 | 91 | 92 | 93 | localBedework 94 | http://localhost:8080/synch/manager 95 | http://localhost:8080/wsdls/synch/wssvc.wsdl 96 | 97 | ---- 98 | 99 | If you are using multiple servers change the host in to refer to your sync server. 100 | 101 | ==== Validating locations. 102 | When an event arrives at the receiving end with an "X-BEDEWORK-LOCATION" property if the String value of the x-property is ... -------------------------------------------------------------------------------- /old-docs/schema/wildfly/wildfly-feature-pack-build-1_0.xsd: -------------------------------------------------------------------------------- 1 | 2 | 3 | 18 | 19 | 24 | 25 | 26 | 27 | 28 | 29 | 30 | 31 | 32 | 33 | 34 | 35 | 36 | 37 | 38 | 39 | 40 | 41 | 42 | 43 | 44 | 45 | 46 | 47 | 48 | 49 | 50 | 51 | 52 | 53 | 54 | 55 | 56 | 57 | 58 | 59 | 60 | 61 | 62 | 63 | 64 | 65 | 66 | 67 | 68 | 69 | 70 | 71 | 72 | 73 | 74 | 75 | 76 | 77 | 78 | 79 | 80 | 81 | 82 | 83 | 84 | 85 | 86 | 87 | 88 | 89 | 90 | 91 | 92 | 93 | 94 | 95 | 96 | 97 | 98 | 99 | 100 | 101 | 102 | 103 | 104 | 105 | 106 | 107 | 108 | 109 | 110 | 111 | 112 | 113 | 114 | 115 | -------------------------------------------------------------------------------- /old-docs/schema/wildfly/wildfly-feature-pack-build-1_1.xsd: -------------------------------------------------------------------------------- 1 | 2 | 3 | 18 | 19 | 24 | 25 | 26 | 27 | 28 | 29 | 30 | 31 | 32 | 33 | 34 | 35 | 36 | 37 | 38 | 39 | 40 | 41 | 42 | 43 | 44 | 45 | 46 | 47 | 48 | 49 | 50 | 51 | 52 | 53 | 54 | 55 | 56 | 57 | 58 | 59 | 60 | 61 | 62 | 63 | 64 | 65 | 66 | 67 | 68 | 69 | 70 | 71 | 72 | 73 | 74 | 75 | 76 | 77 | 78 | 79 | 80 | 81 | 82 | 83 | 84 | 85 | 86 | 87 | 88 | 89 | 90 | 91 | 92 | 93 | 94 | 95 | 96 | 97 | 98 | 99 | 100 | 101 | 102 | 103 | 104 | 105 | 106 | 107 | 108 | 109 | 110 | 111 | 112 | 113 | 114 | 115 | -------------------------------------------------------------------------------- /src/main/asciidoc/administrators/subscriptions.adoc: -------------------------------------------------------------------------------- 1 | === Subscribing to a feed for public calendars. 2 | ==== Data format 3 | The simplest data format is standard RFC5545 ics. For greater efficiency the 4 | service providing the data should set the Last-Modified or Etag header field 5 | when the data changes. This will allow the synch engine to skip a 6 | download for unchanged data. 7 | 8 | *Date/time format:* Times *should* beprovided as local times with a 9 | timezone - for example 10 | ---- 11 | DTSTART;TZID=America/New_York:20230330T200000 12 | ---- 13 | 14 | Note that while the standard specifies that a VTIMEZONE component is 15 | required for all referenced timezones, this can be ignored. Bedework 16 | will use its own set of timezone definitions. 17 | 18 | *UID:* This *must* be unique and unchanging for each event. It is the 19 | primary key to an event - and all its instances if recurring. 20 | 21 | *Images:* Images can be added to the feed and this will allow their 22 | display on the main web interface. Specify an x-property as below: 23 | ---- 24 | X-BEDEWORK-IMAGE;ALTREP=A title:https://example.edu/sites/default/files/images/fall2022_fun.png 25 | ---- 26 | 27 | *Categories:* You probably want the incoming events to all be flagged 28 | with a specific category or categories. This can be useful for 29 | filtering.It makes it easier to include the calendar collections 30 | imported by the sync engine. Before carrying out the following 31 | steps ensure these categories are created. 32 | 33 | For public events there are a few more options available when subscribing. 34 | 35 | *Process Locations and Contacts:* This causes locations and contacts to be moved into x-properties *"X-BEDEWORK-LOCATION"* and *"X-BEDEWORK-CONTACT"*. The receiving end (bedework) may carry out further actions to validate the location or contact and as a result may set a preexisting location or contact in the event. The x-property is always available for display but this process allows the system to validate the location/contact. 36 | 37 | *Process categories:* This does the same for categories. 38 | 39 | [NOTE] 40 | ==== 41 | If you don't select those options then categories, contacts and locations will be created in bedework. This is probably not what is wanted as these are uncurated. 42 | 43 | By setting the *Process....* flag you ensure that such locations and categories don't end up in the database. 44 | ==== 45 | 46 | *Suppress deletion of events?* This means that if events disappear from the feed they will stay in the database. This effectively turns the feed into a change feed and can significantly reduce the size of the data. It does mean that events that MUST be deleted will require help from an administrator with sufficient privileges. 47 | 48 | ==== Creating a public subscription 49 | 50 | As a super user 51 | 52 | * Switch to the System tab and select "Manage calendars and folders". 53 | * Open up "public" and click the "+" on the cals folder. 54 | * Set the name - e.g "Athletics" 55 | * Check off categories for filtering 56 | ** Click on "show/hide categories used for filtering" 57 | ** Scroll down and select a previously created category or categories 58 | * Check off any categories you want applied on input - 59 | ** Click on "show/hide categories for auto-tagging on input" 60 | ** Scroll down and select a previously created category or categories 61 | * Mark as a subscription 62 | * Set the URL in the URl field 63 | * Set an id/password if necessary 64 | * Select the "Process Locations and Contacts" and "Process Categories" checkboxes if desired (probably so) 65 | * Set the location key field name for mapping locations 66 | * Set the refresh rate in minutes 67 | * Save 68 | 69 | ==== Mapping Locations 70 | Locations created and stored within bedework are broken out into a number of fields. Out of these the following are used to create a combined address value which is used for export and import mapping: 71 | 72 | * Street address 73 | * Room 74 | * City 75 | * State 76 | * zip/postcode 77 | 78 | These values are separated by a comma and a space. Missing values are skipped. 79 | 80 | The update process matches the value of the supplied LOCATION property against that combined value. 81 | 82 | If there is an EXACT match then the bedework location will be attached to the syncronized event. Otherwise, the location will be left in an "X-BEDEWORK-LOCATION" 83 | x-property. Feeds and the front end display will normally display the x-property as the location for the event. 84 | 85 | ==== Mapping contacts 86 | Contacts are relatively simple and have a single value. 87 | If this value matches exactly a defined bedework contact 88 | it will be set as the contact value. In all cases an 89 | x-property "X-BEDEWORK-CONTACT" will be created 90 | 91 | ==== Mapping categories 92 | An equivalent process takes place with categories though again, the mapping is much simpler. Categories only have a single value. An exact match in the imported event will cause the bedework category to be applied. 93 | 94 | Incoming categories will be placed in "X-BEDEWORK-CATEGORIES" properties. 95 | 96 | The use of bedework categories is important for much of the front-end filtering of events as this is driven primarily by categories. 97 | 98 | As an example if we have the alias structure + 99 | `performances/comedy` + 100 | and comedy is tagged with the category *comedy* and performances with the category *performances* then the imported event needs both categories. 101 | 102 | ==== Recurring events 103 | These present some new issues for the feed. 104 | 105 | ==== Examples 106 | 107 | 108 | -------------------------------------------------------------------------------- /old-docs/schema/wildfly/wildfly-core-management_1_0.xsd: -------------------------------------------------------------------------------- 1 | 2 | 3 | 20 | 21 | 27 | 28 | 29 | 30 | 31 | 32 | 33 | 34 | 35 | Configuration for the history of configuration changes. 36 | 37 | 38 | 39 | 40 | 41 | 42 | Number of configuration changes that are available in history. 43 | 44 | 45 | 46 | 47 | 48 | 49 | 50 | 51 | Configuration for a process state listener. 52 | 53 | 54 | 55 | 56 | 57 | 58 | 59 | Configuration properties for the process state listener. 60 | 61 | 62 | 63 | 64 | 65 | 66 | 67 | Name of the process state listener. 68 | 69 | 70 | 71 | 72 | 73 | 74 | ControlledProcessStateListener class implementation. 75 | 76 | 77 | 78 | 79 | 80 | 81 | Module where the ControlledProcessStateListener implementation class may be found. 82 | 83 | 84 | 85 | 86 | 87 | 88 | Timeout used in seconds, for listener operations. 89 | If an individual listener operation takes longer than this timeout it will be canceled. 90 | 91 | 92 | 93 | 94 | 95 | 96 | 97 | 98 | 99 | 100 | 101 | 102 | 103 | 104 | 105 | 106 | 107 | 108 | 109 | 110 | -------------------------------------------------------------------------------- /old-docs/schema/wildfly/jboss-as-jmx_1_3.xsd: -------------------------------------------------------------------------------- 1 | 2 | 3 | 24 | 25 | 31 | 32 | 33 | 34 | 35 | 36 | 37 | 38 | 39 | 40 | 41 | 42 | 43 | 44 | 45 | 46 | 47 | 48 | 49 | 50 | 51 | 52 | 53 | 54 | 55 | 56 | 57 | 58 | If true then this connector will use the management endpoint, otherwise it will use the 59 | remoting subsystem endpoint. 60 | 61 | 62 | 63 | 64 | 65 | 66 | 67 | 68 | Declaration of management operation audit logging configuration. 69 | 70 | 71 | 72 | 73 | 74 | 75 | 76 | 77 | Whether operations should be logged on boot. 78 | 79 | 80 | 81 | 82 | 83 | 84 | Whether operations that do not modify the configuration or any runtime services should be logged. 85 | 86 | 87 | 88 | 89 | 90 | 91 | Whether audit logging is enabled. 92 | 93 | 94 | 95 | 96 | 97 | 98 | 99 | 100 | References to audit-log-handlers defined in the audit-log-handlers section 101 | 102 | 103 | 104 | 105 | 106 | 107 | 108 | 109 | 110 | 111 | A reference to an audit-log-handler defined in the audit-log-appenders section 112 | 113 | 114 | 115 | 116 | 117 | 118 | 119 | 120 | Configures access control sensititity for the mbeans in the jmx subsystem 121 | 122 | 123 | 124 | 125 | 126 | 127 | -------------------------------------------------------------------------------- /src/main/asciidoc/development/todo.adoc: -------------------------------------------------------------------------------- 1 | [[todo-list]] 2 | === Todo list 3 | 4 | This is a (moderately) sorted list of features/changes etc for bedework. Could be a set of tickets, but this is easier to read. 5 | 6 | ==== DumpRestore changes 7 | 8 | Already a separate module. Move DumpRestoreProperties out of common into the dumprestore module - it's the only place they are used. 9 | 10 | Remove all mention of dumprestore in ConfigurationsImpl.java. Add a sar to the dr module instead. 11 | 12 | This may act as a pattern for replacing ConfigurationsImpl.java with a bunch of sars. 13 | 14 | ==== CoreEvents exceptions 15 | Don't do this: 16 | 17 | [source] 18 | ---- 19 | if ((val.getEntityType() != IcalDefs.entityTypeAvailable) && 20 | (calendarNameExists(val, false, true) || 21 | calendarNameExists(val, true, true))) { 22 | throwException(CalFacadeErrorCode.duplicateName, val.getName()); 23 | } 24 | ---- 25 | Rollback and return an error indication. Should be a bad request - not a 500. 26 | 27 | ==== Index/updates after touch collection 28 | The lastmod db update is not versioned as we get a lot and it causes frequent stale state exceptions. 29 | 30 | The update should only take place if the new valueis after the old value. 31 | 32 | Also when indexing - if we're indexing because of a touch - we should ignore version conflict exceptions. 33 | 34 | ==== Filter x-properties 35 | Filter x-properties in public clients/feeds - list of x-props to retain. 36 | 37 | ==== Api changes 38 | Change the api to use response objects throughout. No exceptions. Allows for a better networked api. 39 | 40 | ==== Notifications 41 | Need to be indexed in ES so that finding a notification for an entity is efficient (need to merge multiple notifications for same entity) 42 | 43 | Change notifications for public events is probably not working correctly. We should be using the creator - or the owner of the alias - all public events have the same owner (public-user) and change notifications seem to be ending up in that bucket. 44 | 45 | ==== Limit interactions with db for updates. 46 | For this we would do all interactions with ES and connect to and update db only as needed. Use sequence numbers to ensure db and index correctness. Benefits are shorter db interactions - only at point we update. Less complexity in web clients - no need to have conversations stretching across multiple requests. This can build on the work of the previous item. The web client code is already structured to assume that it will do an explicit update of entities which should facilitate the change. 47 | 48 | ==== Move business logic out of webapps into core 49 | Move as much as possible out of the current webapps module into the core APi implementation - this potentially allows a more RESTful style of client - possibly using the new jmap style interface being developed. 50 | 51 | ==== Categories 52 | Use a larger category scheme as the basis for categories. Use SKOS based representation so that they are RDF friendly. Will allow for sub-categorization by event submitters. 53 | 54 | ==== Locations 55 | Allow for use of external location sources such as geonames. Will allow good locations on external events. 56 | 57 | ==== Searching improvements 58 | Search for events near a geo-location (requires locations to have geo) 59 | 60 | ===== Caching 61 | Implement caching of feeder data as a built in feature of the quickstart. 62 | 63 | ==== Deployment of ears 64 | Finish off the deployment process - it's THAT close (is there an emoticon for 2 fingers very close together?) to allowing deployers to just replace the ears from prebuilt ears on the site. No builds required - server can detect an update is available. 65 | 66 | ==== Deployment of wildfly modules 67 | If all - or many - required dependencies are deployed as wildfly modules it should reduce the size of the deployment and allow for even quicker startup. 68 | 69 | ==== Networked client api 70 | Subset of svci but can be used for web client interactions. 71 | 72 | ==== Groups 73 | Directory interface to directly interact with grouper for user and admin groups. Allow consumer only approach for external management of groups. Use extra ldap attributes to allow admin groups to be maintained in ldap. 74 | 75 | ==== Index logs in ES 76 | Use kibana to get metrics etc 77 | 78 | ==== Timezones 79 | Update UI to provide a search - possibly based on map. Use tzdist geo feature (being developed) 80 | 81 | ==== General work needed 82 | * Upgrade ES to latest - changes the query structure 83 | * Upgrade all libraries to latest 84 | * Preprocess the xsl to build the deployable language specific versions. 85 | 86 | ==== Recurring events 87 | Currently I'm indexing all of the instances we allow - that can be many. 88 | The ideal would be not to index any instances but only the master and 89 | overrides. This has some problems. 90 | 91 | Time range searches are easy. We have an indexed start and end and for 92 | the master we set it to be the entire (perhaps infinite) range so it 93 | always gets included in the result. For this case we could generate the 94 | instances based on the master. 95 | 96 | For a query involving other conditions - e.g. categories the master may not appear. 97 | 98 | ===== Entity only 99 | This is just the master 100 | 101 | ===== Overrides 102 | This is master + overrides - again it may be filtered so we need to pull 103 | in the master if absent. This is in line with CalDAV (I think). 104 | 105 | ===== Expanded 106 | This is a full expansion of all instances. If the master 107 | appears in the result we need to generate the appropriate instances for 108 | the selected time range. 109 | 110 | If it doesn't appear, but we have some members in the result - these 111 | are overrides and we need to carry out a secondary fetch of the master. 112 | 113 | However the real problem here is paged queries. For the web clients 114 | (mostly) we allow a paged query of full expansions. The result is 115 | ordered by start date. This is easy to achieve when we index the instances 116 | as it's just a time ranged query using ES paging. 117 | 118 | If the instances aren't indexed we need to retrieve all the events that 119 | match the query, at least produce the dtstarts and recurrence ids for 120 | every instance then deliver the matching instances in the batch. 121 | -------------------------------------------------------------------------------- /old-docs/schema/wildfly/wildfly-security-manager_1_0.xsd: -------------------------------------------------------------------------------- 1 | 2 | 3 | 24 | 25 | 31 | 32 | 33 | 34 | 35 | 36 | 37 | 38 | 41 | 42 | 43 | 44 | 45 | 46 | 47 | 48 | 49 | 50 | 51 | 72 | 73 | 74 | 75 | 76 | 77 | 78 | 79 | 80 | 81 | 82 | 83 | 87 | 88 | 89 | 90 | 91 | 92 | 93 | 94 | 95 | 96 | 97 | 105 | 106 | 107 | 108 | 109 | 110 | 111 | 112 | 113 | 114 | -------------------------------------------------------------------------------- /old-docs/deployers/databases.md: -------------------------------------------------------------------------------- 1 | # Setting up databases 2 | The quickstart is configured to use h2 for demonstration only. For production you will need to switch to something like postgresql or mysql. 3 | 4 | ## postgresql 5 | We'll describe the process for the main calendar engine. The others are very similar. 6 | 7 | All bedework and wildfly configuration files are in standalone/configuration/ - we'll just refer to the relative path. 8 | 9 | * Name: caldb (you can change that if you wish) 10 | * Configuration: bedework/bwcore/dbconfig.xml 11 | * datasource: CalendarDS 12 | 13 | #### Configure postgresql 14 | You'll probably need to configure postgres to allow your chosen role access to the server and databases. 15 | 16 | Depending on how you're running the system you may need to modify postgresql.conf and pg_haba.conf - both located by default in the daat directory. 17 | 18 | If you're running postgres on a separate system you may need to change the listen_addresses value and port: 19 | 20 | ``` 21 | listen_addresses = 'localhost' # what IP address(es) to listen on; 22 | # comma-separated list of addresses; 23 | # defaults to 'localhost'; use '*' for all 24 | # (change requires restart) 25 | port = 5432 # (change requires restart) 26 | ``` 27 | 28 | Change "localhost" to "*" or a list of addresses. 29 | 30 | 5432 is the default port. 31 | 32 | To allow your account access you will need to add a line or lines to pg_hba.conf near the end something like: 33 | 34 | ``` 35 | host all bedework 10.0.0.1/32 md5 36 | ``` 37 | This can be made more restrictive by naming the db. 38 | 39 | 40 | Create a database with a known id/password. Ensure it is accessible from the host you are running bedework on. 41 | 42 | The psql commands are something like: 43 | 44 | ``` 45 | create role bedework with login password 'xxxxxxxxx'; 46 | create database caldb owner bedework; 47 | ``` 48 | 49 | Set the hibernate dialect in the config file: 50 | ``` 51 | hibernate.dialect=org.hibernate.dialect.PostgreSQLDialect 52 | ``` 53 | 54 | In standalone.xml replace the datasource definition with something like: 55 | 56 | ``` 57 | 58 | jdbc:postgresql://localhost:5432/caldb 59 | postgresql 60 | 61 | 1 62 | 50 63 | true 64 | 65 | 66 | xxxxx 67 | xxxxx 68 | 69 | 70 | 15 71 | 72 | 73 | true 74 | 75 | 76 | 77 | 78 | 79 | false 80 | 81 | 82 | ``` 83 | 84 | Ensure you also have the driver loaded - for example the drivers section which usually follows the datasources shoudllook somethign like: 85 | 86 | You need to install the postgres driver - you're either missing the driver declaration - something like: 87 | 88 | ``` 89 | 90 | ... 91 | 92 | ... 93 | 94 | ``` 95 | 96 | Ensure the jdbc driver is installed in the modules directory - something like: 97 | 98 | ``` 99 | wildfly-10.1.0.Final/modules/org/postgresql/main/module.xml 100 | wildfly-10.1.0.Final/modules/org/postgresql/main/postgresql-8.4-701.jdbc4.jar 101 | ``` 102 | 103 | Module.xml for this example contains 104 | 105 | ``` 106 | 107 | 108 | 109 | 110 | 111 | 112 | 113 | 114 | 115 | 116 | 117 | 118 | ``` 119 | 120 | Modify it appropriately for different versions. 121 | 122 | Start wildfly and allow it to fully deploy. There will be many errors relating to the calendar database. 123 | 124 | Delete the file ***wildfly-10.1.0.Final/standalone/data/bedework/dumprestore/schema.sql*** 125 | 126 | ### Use the cli to install the schema. 127 | 128 | To run the cli you need the id and password you created when configuring wildfly. This id and password can also be used to access the hawtio console. 129 | 130 | ``` 131 | cd bw-cli/target/client/bin 132 | ./client -id admin-id -pw admin-pw 133 | calschema export 134 | ``` 135 | 136 | This should install the schema. It will also create a file which can be manually installed if need be - use the psql client application 137 | 138 | ``` 139 | psql caldb < wildfly-10.1.0.Final/standalone/data/bedework/dumprestore/schema.sql 140 | ``` 141 | 142 | Next you need to add some basic data. For this you need the full path to the initial data in wildfly-10.1.0.Final/standalone/data/bedework/dumprestore/initbedework.xml 143 | 144 | In the cli enter the command 145 | 146 | ``` 147 | restoreCal "/full/path/to/initbedework.xml" 148 | ``` 149 | The quotes are required. Some activity should ensue. 150 | 151 | Finally reindex the data - again use the cli 152 | 153 | ``` 154 | rebuildidx 155 | ``` 156 | 157 | wait for it to terminate - then enter 158 | 159 | ``` 160 | listidx 161 | ``` 162 | The alias ***bwuser*** should be pointing at the index before the last one just created. 163 | 164 | In the cli 165 | 166 | ``` 167 | makeidxprod index-name 168 | ``` 169 | replacing ***index-name*** with that last name - no quotes. 170 | 171 | ## MySQL 172 | 173 | TBD 174 | 175 | Set the hibernate dialect in the config file: 176 | ``` 177 | hibernate.dialect=org.hibernate.dialect.MySQL5InnoDBDialect 178 | ``` 179 | -------------------------------------------------------------------------------- /old-docs/schema/wildfly/jboss-as-deployment-scanner_2_0.xsd: -------------------------------------------------------------------------------- 1 | 2 | 23 | 24 | 25 | 26 | 27 | 28 | 29 | 30 | 31 | 34 | 35 | 36 | 37 | 38 | 39 | 40 | 41 | 42 | 43 | Allows configuration of an additional location where deployment 44 | content can be stored. 45 | 46 | 47 | 48 | 49 | 50 | The actual filesystem path. Treated as an absolute path, unless the 51 | 'relative-to' attribute is specified, in which case the value 52 | is treated as relative to that path. 53 | 54 | 55 | 56 | 57 | 58 | Reference to a filesystem path defined in the "paths" section 59 | of the server configuration. 60 | 61 | 62 | 63 | 64 | 65 | 66 | Flag indicating that all scanning (including initial scanning at startup) 67 | should be enabled or disabled. 68 | 69 | 70 | 71 | 72 | 73 | Periodic interval, in milliseconds, at which the repository 74 | should be scanned for changes. A value of less than 1 indicates the 75 | repository should only be scanned at initial startup. 76 | 77 | 78 | 79 | 80 | 81 | 82 | Controls whether zipped deployment content should be automatically deployed by 83 | the scanner without requiring the user to add a .dodeploy marker file. 84 | 85 | 86 | 87 | 88 | 89 | 90 | Controls whether exploded deployment content should be automatically deployed by 91 | the scanner without requiring the user to add a .dodeploy marker file. Setting 92 | this to 'true' is not recommended for anything but basic development scenarios, 93 | as there is no way to ensure that deployment will not occur in the middle of 94 | changes to the content. 95 | 96 | 97 | 98 | 99 | 100 | 101 | Controls whether xml deployment content should be automatically deployed by 102 | the scanner without requiring the user to add a .dodeploy marker file. 103 | 104 | 105 | 106 | 107 | 108 | 109 | Timeout used, in seconds, for deployment operations. If an individual deployment operation 110 | takes longer than this timeout it will be canceled and marked as failed. 111 | 112 | 113 | 114 | 115 | 116 | 117 | Controls whether a runtime failure of a deployment causes a rollback of the deployment as well 118 | as all other (maybe unrelated) deployments as part of the scan operation. 119 | 120 | 121 | 122 | 123 | 124 | 125 | -------------------------------------------------------------------------------- /src/main/asciidoc/overview/features.adoc: -------------------------------------------------------------------------------- 1 | [[features-of-Bedework]] 2 | === Features of Bedework 3 | 4 | Java:: Written completely in Java, Bedework is system independent. This version compiles and runs in Java 21. 5 | 6 | Standards based and interoperable:: Interoperability with other calendar systems and clients by way of standards compliance is a fundamental design goal of the Bedework system. The following standards are supported: 7 | ** iCalendar support (rfc5545) 8 | ** iTIP (rfc5546) 9 | ** CalDAV (rfc4791) 10 | ** CalDAV scheduling (rfc6638) 11 | ** CardDAV v.4 12 | ** VPoll (draft) 13 | 14 | CalDAV server:: a full CalDAV server is a core feature of Bedework. It can be used with any CalDAV capable client and has been shown to work with Mozilla Lightning, Apple's iCal, Evolution, and others. 15 | 16 | CardDAV server:: Bedework provides a CardDAV server providing personal and public contact stores for use in the personal client. A stand-alone JavaScript address book application is included with the personal web client suitable for deployment in other web applications such as email web clients. 17 | 18 | Web clients:: The Bedework web clients provide access to public events in guest mode and to public and personal events in authenticated mode. All web clients are easily skinned, allowing a high degree of customization. 19 | 20 | Public calendar suites:: Public events are displayed using "calendar suites" allowing multiple organizations to maintain their own public views of events with whatever degree of visibility is appropriate. A Bedework public calendaring installation may have one or many calendar suites. A calendar suite provides a customized view of events, custom theming, and control over how events are tagged by event administrators. 21 | 22 | Public calendar feeds:: embeddable JavaScript widgets, supporting ical, jcal, xcal, json, and XML. 23 | 24 | Personal calendars:: Bedework provides a web client for personal and group calendaring including scheduling. Using CalDAV desktop clients, users can see a fully synchronized view of their personal and subscribed events between their desktop client and the web client. 25 | 26 | Administrative client for public events:: Public event entry and maintenance is carried out through the administrative web client. The system supports three roles: Super Users control global system settings including user and calendar maintenance and the setup of calendar suites. Calendar Suite Owners can modify the settings of their calendar suite, and Event Administrators can add and edit events for the administrative groups to which they belong. 27 | 28 | Public event community submission:: Bedework provides a web client for submitting events to a public queue allowing members of your community who are not event administrators to suggest public events. 29 | 30 | Public events registration:: Bedework supports registration for public events with waitlisting, registrant caps, and notifications. Custom registration fields can be built and reused for any registerable event. 31 | 32 | Account Self-registration:: This client allows users to register for a Bedework calendar account to register for events or other features. 33 | 34 | Highly customizable look and feel and standards based:: The web clients are themed using CSS and a theme settings file, or by deeper manipulation of XSLT. Designers can theme Bedework for multiple clients and uses, without involving your programming staff. Bedework comes with skins for producing the web clients, data feeds, and displays suitable for handheld devices. Bedework provides a widget builder that makes it easy to embed dynamic event listings on static web sites. 35 | 36 | Database independence - Hibernate:: The core of the calendar uses Hibernate for all database transactions giving support of many database systems and enterprise level performance and reliability. A number of caching schemes are implemented for Hibernate including clustered systems giving further options for improving availability. 37 | 38 | Sharing:: Full CalDAV access control is available allowing the sharing of calendars and calendar entities based on authentication status and identity. 39 | 40 | Scheduling:: Bedework supports scheduling of meetings including invitations and their responses. Caldav scheduling and freebusy is supported, and the busy time is displayed as attendee lists are built. Access control allows users to determine who may attempt to schedule meetings with them. 41 | 42 | Import and export:: Events can be imported and exported in iCalendar (RFC5545) format. This provides an option for populating the calendar from external sources. A dump/restore utility provides a means to backup and restore xml data files. 43 | 44 | Calendar subscriptions:: Users may subscribe to calendars to which they have access, including public and personal calendars. iCalendar data feeds are available from the public web client. 45 | 46 | Multiple calendars:: The core system supports multiple calendars for users and for public events. 47 | 48 | Tagging & Filtering:: Events and folders can be tagged by any number of categories and event views, feeds, and widgets can be filtered by these. 49 | 50 | Internationalization:: Bedework supports full internationalization, including multilingual content (though multilingual content creation is not yet exposed in the web UI). 51 | 52 | Data feeds:: Bedework produces RSS, Javascript (e.g. json), iCalendar, and XML feeds. Custom feeds can be developed by writing an XSL skin. Feeds can be filtered by category or creator, and a feed and widget builder is available to help end users and developers design public feeds and embeddable event widgets. 53 | 54 | Timezone support:: Full timezone support is implemented. There is a set of system defined timezones based upon externally available sets of timezone definitions. 55 | 56 | Recurring events:: Full recurring event support is available via CalDAV and the web clients. 57 | 58 | Event references:: Users may add public event references to their personal calendars. Event references can be annotated by the user. 59 | 60 | Pluggable group support:: Bedework uses a pluggable class implementation to determine group membership for authenticated users allowing organizations to implement a class which uses an external directory. The default class uses internal tables to maintain group membership. Different implementations can be used for administrative and personal use allowing the separation of any given users roles. 61 | 62 | Container authentication:: There is no authentication code in Bedework. Rather, Bedework behaves as a standard servlet, and all authentication is carried out through external mechanisms. Standard container authentication via wildfly and filter based CAS authentication are used in production. The quickstart comes packaged with the Apache DS server against which the quickstart deployment of Bedework authenticates. In production, many deployers opt to authenticate against their organization's existing directory. 63 | 64 | Support for other calendar clients:: It is possible to access an entire calendar with a single url. This can be used to subscribe to a Bedework calendar from Google or Outlook. Bedework can also take advantage of the richness of CalDAV capable desktop clients such as Apple's iCal and Mozilla Lightning. 65 | -------------------------------------------------------------------------------- /old-docs/intro/features.md: -------------------------------------------------------------------------------- 1 | # Features of Bedework 2 | * Java: Written completely in Java, Bedework is system independent. This version compiles and runs in Java 11. 3 | 4 | * Standards based and interoperable: Interoperability with other calendar systems and clients by way of standards compliance is a fundamental design goal of the Bedework system. The following standards are supported: 5 | * iCalendar support (rfc5545) 6 | * iTIP (rfc2446) 7 | * CalDAV (rfc4791)CalDAV scheduling (draft) 8 | * CardDAV v.4 9 | * VPoll (draft) 10 | 11 | * CalDAV server : a full CalDAV server is a core feature of Bedework. It can be used with any CalDAV capable client and has been shown to work with Mozilla Lightning, Apple's iCal, Evolution, and others. 12 | 13 | * CardDAV server : Bedework provides a CardDAV server providing personal and public contact stores for use in the personal client. A stand-alone JavaScript address book application is included with the personal web client suitable for deployment in other web applications such as email web clients. 14 | 15 | * Web clients :The Bedework web clients provide access to public events in guest mode and to public and personal events in authenticated mode. All web clients are easily skinned allowing a high degree of customization. 16 | * Public calendar suites: Public events are displayed using "calendar suites" allowing multiple organizations to maintain their own public views of events with whatever degree of visibility is appropriate. A Bedework public calendaring installation may have one or many calendar suites. A calendar suite provides a customized view of events, custom theming, and control over how events are tagged by event administrators. 17 | * Public calendar feeds and embeddable JavaScript widgets, supporting ical, jcal, xcal, json, and XML. 18 | * Personal calendars: Bedework provides a web client for personal and group calendaring including scheduling. Using CalDAV desktop clients, users can see a fully synchronized view of their personal and subscribed events between their desktop client and the web client. 19 | * Administrative client for public events: Public event entry and maintenance is carried out through the administrative web client. The system supports three roles: Super Users control global system settings including user and calendar maintenance and the setup of calendar suites. Calendar Suite Owners can modify the settings of their calendar suite, and Event Administrators can add and edit events for the administrative groups to which they belong. 20 | * Public event community submission: Bedework provides a web client for submitting events to a public queue allowing members of your community who are not event administrators to suggest public events. 21 | * Public events registration: Bedework supports registration for public events with waitlisting, registrant caps, and notifications. Custom registration fields can be built and reused for any registerable event. 22 | * Account Self-registration: This client allows users to register for a Bedework calendar account to register for events or other features. 23 | * Highly customizable look and feel and standards based: The web clients are themed using CSS and a theme settings file, or by deeper manipulation of XSLT. Designers can theme Bedework for multiple clients and uses, without involving your programming staff. Bedework comes with skins for producing the web clients, data feeds, and displays suitable for handheld devices. Bedework provides a widget builder that makes it easy to embed dynamic event listings on static web sites. 24 | 25 | * Database independence - Hibernate : The core of the calendar uses Hibernate for all database transactions giving support of many database systems and enterprise level performance and reliability. A number of caching schemes are implemented for Hibernate including clustered systems giving further options for improving availability. 26 | 27 | * Sharing : Full CalDAV access control is available allowing the sharing of calendars and calendar entities based on authentication status and identity. 28 | 29 | * Scheduling : Bedework supports scheduling of meetings including invitations and their responses. Caldav scheduling (still in draft) is supported. Freebusy is supported and the busy time is displayed as attendee lists are built. Access control allows users to determine who may attempt to schedule meetings with them. 30 | 31 | * Import and export : Events can be imported and exported in iCalendar (RFC2445) format. This provides an option for populating the calendar from external sources. A dump/restore utility provides a means to backup and restore xml data files. 32 | 33 | * Calendar subscriptions : Users may subscribe to calendars to which they have access, including public and personal calendars. iCalendar data feeds are available from the public web client. 34 | 35 | * Multiple calendars : The core system supports multiple calendars for users and for public events. 36 | 37 | * Tagging & Filtering : Events and folders can be tagged by any number of categories and event views, feeds, and widgets can be filtered by these. 38 | 39 | * Internationalization : Bedework supports full internationalization, including multilingual content (though multilingual content creation is not yet exposed in the web UI). 40 | 41 | * Data feeds: Bedework produces RSS, Javascript (e.g. json), iCalendar, and XML feeds. Custom feeds can be developed by writing an XSL skin. Feeds can be filtered by category or creator, and a feed and widget builder is available to help end users and developers design public feeds and embeddable event widgets. 42 | 43 | * Portal support : Bedework has been shown to work as a JSR168 portlet in Jetspeed, uPortal and Liferay using the portal-struts bridge. 44 | 45 | * Timezone support : Full timezone support is implemented. There is a set of system defined timezones based upon externally available sets of timezone definitions. In addition users are able to store their own timezone definitions. 46 | 47 | * Recurring events : Extensive recurring event support is available via CalDAV and the web clients. 48 | 49 | * Event references : Users may add public event references to their personal calendars. Event references can be annotated by the user. 50 | 51 | * Pluggable group support : Bedework uses a pluggable class implementation to determine group membership for authenticated users allowing organizations to implement a class which uses an external directory. The default class uses internal tables to maintain group membership. Different implementations can be used for administrative and personal use allowing the separation of any given users roles. 52 | 53 | * Container authentication : There is no authentication code in Bedework. Rather, Bedework behaves as a standard servlet, and all authentication is carried out through external mechanisms. Standard container authentication (via Tomcat or Jboss) and filter based Yale CAS authentication are used in production. The quickstart comes packaged with the Apache DS server against which the quickstart deployment of Bedework authenticates. This server can be used in production, though many deployers opt to authenticate against their organization's existing directory. 54 | 55 | * Support for other calendar systems and clients : It is possible to access an entire calendar with a single url. This can be used to subscribe to a Bedework calendar from Google or Outlook. Bedework can also take advantage of the richness of CalDAV capable desktop clients such as Apple's iCal and Mozilla Lightning. 56 | -------------------------------------------------------------------------------- /old-docs/schema/wildfly/wildfly-io_3_0.xsd: -------------------------------------------------------------------------------- 1 | 2 | 3 | 20 | 21 | 27 | 28 | 29 | 30 | 31 | 32 | 35 | 36 | 37 | 38 | 39 | 40 | 41 | 42 | 43 | 44 | 45 | 46 | 47 | 48 | 49 | 52 | 53 | 54 | 55 | 56 | 57 | 58 | 62 | 63 | 64 | 65 | 66 | 67 | 68 | 71 | 72 | 73 | 74 | 75 | 76 | 77 | 80 | 81 | 82 | 83 | 84 | 85 | 86 | 92 | 93 | 94 | 95 | 96 | 97 | 98 | 101 | 102 | 103 | 104 | 105 | 106 | 107 | 108 | 109 | 112 | 113 | 114 | 115 | 116 | 117 | 118 | 121 | 122 | 123 | 124 | 125 | 126 | 127 | 130 | 131 | 132 | 133 | 134 | 135 | 136 | 139 | 140 | 141 | 142 | 143 | 144 | 145 | 146 | A configuration of a single outbound bind address. 147 | 148 | 149 | 150 | 151 | 152 | The name of the bind address sub-resource. 153 | 154 | 155 | 156 | 157 | 158 | 159 | The CIDR address string which matches the destination when this rule applies. 160 | 161 | 162 | 163 | 164 | 165 | 166 | The bind address to use if the destination address matches. 167 | 168 | 169 | 170 | 171 | 172 | 173 | The port number to bind to if the destination address matches. 174 | 175 | 176 | 177 | 178 | 179 | -------------------------------------------------------------------------------- /old-docs/schema/wildfly/jboss-as-naming_2_0.xsd: -------------------------------------------------------------------------------- 1 | 2 | 3 | 26 | 27 | 33 | 34 | 35 | 36 | 37 | 38 | 39 | 40 | Naming subsystem configurations 41 | 42 | 43 | 44 | 45 | 46 | 47 | 48 | 49 | 50 | 51 | 52 | This element activates the remote naming server, that allows access to items bound in the java:jboss/exported 53 | JNDI context. 54 | 55 | 56 | 57 | 58 | 59 | 60 | 61 | 62 | 63 | 64 | 65 | 66 | 67 | 68 | 69 | 70 | 71 | The JNDI name to bind to 72 | 73 | 74 | 75 | 76 | 77 | 78 | The value to bind 79 | 80 | 81 | 82 | 83 | 84 | 85 | The type of entry to bind. If not specified defaults to java.lang.String. 86 | 87 | 88 | 89 | 90 | 91 | 92 | 93 | 94 | 95 | 96 | 97 | 98 | The JNDI name to bind to 99 | 100 | 101 | 102 | 103 | 104 | 105 | The module to load the JNDI entry from 106 | 107 | 108 | 109 | 110 | 111 | 112 | The javax.naming.spi.ObjectFactory that provides the value. 113 | Note that when getObjectInstance is invoked the first Object parameter 114 | will be equal to the JNDI name of this binding. The second and third 115 | parameters will always be null, while the last one, the environment, may 116 | be populated using the environment type child element. 117 | 118 | 119 | 120 | 121 | 122 | 123 | 124 | 125 | 126 | 127 | 128 | 129 | 130 | The JNDI name to bind to 131 | 132 | 133 | 134 | 135 | 136 | 137 | The module to load the external context from. If this is not specified then 138 | the naming module will be used. 139 | 140 | 141 | 142 | 143 | 144 | 145 | The type of the context to bind 146 | 147 | 148 | 149 | 150 | 151 | 152 | If this is true them the resulting context will be cached and reused. 153 | 154 | 155 | 156 | 157 | 158 | 159 | 160 | 161 | 164 | 165 | 166 | 167 | 169 | 170 | 171 | 172 | 173 | 174 | 175 | 179 | 180 | 181 | 182 | 183 | 184 | 185 | 186 | 187 | 188 | 189 | The JNDI name to bind to 190 | 191 | 192 | 193 | 194 | 195 | 196 | The JNDI location to lookup 197 | 198 | 199 | 200 | 201 | 202 | 203 | -------------------------------------------------------------------------------- /docs/tocbot-3.0.2/tocbot-min.js: -------------------------------------------------------------------------------- 1 | !function(e){function t(o){if(n[o])return n[o].exports;var i=n[o]={i:o,l:!1,exports:{}};return e[o].call(i.exports,i,i.exports,t),i.l=!0,i.exports}var n={};t.m=e,t.c=n,t.i=function(e){return e},t.d=function(e,n,o){t.o(e,n)||Object.defineProperty(e,n,{configurable:!1,enumerable:!0,get:o})},t.n=function(e){var n=e&&e.__esModule?function(){return e.default}:function(){return e};return t.d(n,"a",n),n},t.o=function(e,t){return Object.prototype.hasOwnProperty.call(e,t)},t.p="",t(t.s=5)}([function(e,t){var n;n=function(){return this}();try{n=n||Function("return this")()||(0,eval)("this")}catch(e){"object"==typeof window&&(n=window)}e.exports=n},function(e,t,n){var o,i,r;!function(n,l){i=[],o=l(),void 0!==(r="function"==typeof o?o.apply(t,i):o)&&(e.exports=r)}(0,function(){"use strict";var e=function(e){return"getComputedStyle"in window&&"smooth"===window.getComputedStyle(e)["scroll-behavior"]};if("undefined"==typeof window||!("document"in window))return{};var t=function(t,n,o){n=n||999,o||0===o||(o=9);var i,r=function(e){i=e},l=function(){clearTimeout(i),r(0)},s=function(e){return Math.max(0,t.getTopOf(e)-o)},c=function(o,i,s){if(l(),0===i||i&&i<0||e(t.body))t.toY(o),s&&s();else{var c=t.getY(),a=Math.max(0,o)-c,u=(new Date).getTime();i=i||Math.min(Math.abs(a),n),function e(){r(setTimeout(function(){var n=Math.min(1,((new Date).getTime()-u)/i),o=Math.max(0,Math.floor(c+a*(n<.5?2*n*n:n*(4-2*n)-1)));t.toY(o),n<1&&t.getHeight()+ou?a(e,n,i):l+o>f?c(l-u+o,n,i):i&&i()},d=function(e,n,o,i){c(Math.max(0,t.getTopOf(e)-t.getHeight()/2+(o||e.getBoundingClientRect().height/2)),n,i)};return{setup:function(e,t){return(0===e||e)&&(n=e),(0===t||t)&&(o=t),{defaultDuration:n,edgeOffset:o}},to:a,toY:c,intoView:u,center:d,stop:l,moving:function(){return!!i},getY:t.getY,getTopOf:t.getTopOf}},n=document.documentElement,o=function(){return window.scrollY||n.scrollTop},i=t({body:document.scrollingElement||document.body,toY:function(e){window.scrollTo(0,e)},getY:o,getHeight:function(){return window.innerHeight||n.clientHeight},getTopOf:function(e){return e.getBoundingClientRect().top+o()-n.offsetTop}});if(i.createScroller=function(e,o,i){return t({body:e,toY:function(t){e.scrollTop=t},getY:function(){return e.scrollTop},getHeight:function(){return Math.min(e.clientHeight,window.innerHeight||n.clientHeight)},getTopOf:function(e){return e.offsetTop}},o,i)},"addEventListener"in window&&!window.noZensmooth&&!e(document.body)){var r="scrollRestoration"in history;r&&(history.scrollRestoration="auto"),window.addEventListener("load",function(){r&&(setTimeout(function(){history.scrollRestoration="manual"},9),window.addEventListener("popstate",function(e){e.state&&"zenscrollY"in e.state&&i.toY(e.state.zenscrollY)},!1)),window.location.hash&&setTimeout(function(){var e=i.setup().edgeOffset;if(e){var t=document.getElementById(window.location.href.split("#")[1]);if(t){var n=Math.max(0,i.getTopOf(t)-e),o=i.getY()-n;0<=o&&o<9&&window.scrollTo(0,n)}}},9)},!1);var l=new RegExp("(^|\\s)noZensmooth(\\s|$)");window.addEventListener("click",function(e){for(var t=e.target;t&&"A"!==t.tagName;)t=t.parentNode;if(!(!t||1!==e.which||e.shiftKey||e.metaKey||e.ctrlKey||e.altKey)){if(r)try{history.replaceState({zenscrollY:i.getY()},"")}catch(e){}var n=t.getAttribute("href")||"";if(0===n.indexOf("#")&&!l.test(t.className)){var o=0,s=document.getElementById(n.substring(1));if("#"!==n){if(!s)return;o=i.getTopOf(s)}e.preventDefault();var c=function(){window.location=n},a=i.setup().edgeOffset;a&&(o=Math.max(0,o-a),c=function(){history.pushState(null,"",n)}),i.toY(o,null,c)}}},!1)}return i})},function(e,t){e.exports=function(e){function t(e,n){var r=n.appendChild(o(e));if(e.children.length){var l=i(e.isCollapsed);e.children.forEach(function(e){t(e,l)}),r.appendChild(l)}}function n(e,n){var o=i(!1);n.forEach(function(e){t(e,o)});var r=document.querySelector(e);if(null!==r)return r.firstChild&&r.removeChild(r.firstChild),r.appendChild(o)}function o(t){var n=document.createElement("li"),o=document.createElement("a");return e.listItemClass&&n.setAttribute("class",e.listItemClass),e.includeHtml&&t.childNodes.length?u.call(t.childNodes,function(e){o.appendChild(e.cloneNode(!0))}):o.textContent=t.textContent,o.setAttribute("href","#"+t.id),o.setAttribute("class",e.linkClass+p+"node-name--"+t.nodeName+p+e.extraLinkClasses),n.appendChild(o),n}function i(t){var n=document.createElement("ul"),o=e.listClass+p+e.extraListClasses;return t&&(o+=p+e.collapsibleClass,o+=p+e.isCollapsedClass),n.setAttribute("class",o),n}function r(){var t=document.documentElement.scrollTop||f.scrollTop,n=document.querySelector(e.positionFixedSelector);"auto"===e.fixedSidebarOffset&&(e.fixedSidebarOffset=document.querySelector(e.tocSelector).offsetTop),t>e.fixedSidebarOffset?-1===n.className.indexOf(e.positionFixedClass)&&(n.className+=p+e.positionFixedClass):n.className=n.className.split(p+e.positionFixedClass).join("")}function l(t){var n=document.documentElement.scrollTop||f.scrollTop;e.positionFixedSelector&&r();var o,i=t;if(m&&null!==document.querySelector(e.tocSelector)&&i.length>0){d.call(i,function(t,r){if(t.offsetTop>n+e.headingsOffset+10){return o=i[0===r?r:r-1],!0}if(r===i.length-1)return o=i[i.length-1],!0});var l=document.querySelector(e.tocSelector).querySelectorAll("."+e.linkClass);u.call(l,function(t){t.className=t.className.split(p+e.activeLinkClass).join("")});var c=document.querySelector(e.tocSelector).querySelector("."+e.linkClass+".node-name--"+o.nodeName+'[href="#'+o.id+'"]');c.className+=p+e.activeLinkClass;var a=document.querySelector(e.tocSelector).querySelectorAll("."+e.listClass+"."+e.collapsibleClass);u.call(a,function(t){var n=p+e.isCollapsedClass;-1===t.className.indexOf(n)&&(t.className+=p+e.isCollapsedClass)}),c.nextSibling&&(c.nextSibling.className=c.nextSibling.className.split(p+e.isCollapsedClass).join("")),s(c.parentNode.parentNode)}}function s(t){return-1!==t.className.indexOf(e.collapsibleClass)?(t.className=t.className.split(p+e.isCollapsedClass).join(""),s(t.parentNode.parentNode)):t}function c(t){var n=t.target||t.srcElement;"string"==typeof n.className&&-1!==n.className.indexOf(e.linkClass)&&(m=!1)}function a(){m=!0}var u=[].forEach,d=[].some,f=document.body,m=!0,p=" ";return{enableTocAnimation:a,disableTocAnimation:c,render:n,updateToc:l}}},function(e,t){e.exports={tocSelector:".js-toc",contentSelector:".js-toc-content",headingSelector:"h1, h2, h3",ignoreSelector:".js-toc-ignore",linkClass:"toc-link",extraLinkClasses:"",activeLinkClass:"is-active-link",listClass:"toc-list",extraListClasses:"",isCollapsedClass:"is-collapsed",collapsibleClass:"is-collapsible",listItemClass:"toc-list-item",collapseDepth:0,smoothScroll:!0,smoothScrollDuration:420,scrollEndCallback:function(e){},headingsOffset:0,throttleTimeout:50,positionFixedSelector:null,positionFixedClass:"is-position-fixed",fixedSidebarOffset:"auto",includeHtml:!1}},function(e,t){e.exports=function(e){function t(e){return e[e.length-1]}function n(e){return+e.nodeName.split("H").join("")}function o(t){var o={id:t.id,children:[],nodeName:t.nodeName,headingLevel:n(t),textContent:t.textContent.trim()};return e.includeHtml&&(o.childNodes=t.childNodes),o}function i(i,r){for(var l=o(i),s=n(i),c=r,a=t(c),u=a?a.headingLevel:0,d=s-u;d>0;)a=t(c),a&&void 0!==a.children&&(c=a.children),d--;return s>=e.collapseDepth&&(l.isCollapsed=!0),c.push(l),c}function r(t,n){var o=n;e.ignoreSelector&&(o=n.split(",").map(function(t){return t.trim()+":not("+e.ignoreSelector+")"}));try{return document.querySelector(t).querySelectorAll(o)}catch(e){return console.warn("Element not found: "+t),null}}function l(e){return s.call(e,function(e,t){return i(o(t),e.nest),e},{nest:[]})}var s=[].reduce;return{nestHeadingsArray:l,selectHeadings:r}}},function(e,t,n){(function(o){var i,r,l;!function(n,o){r=[],i=o(n),void 0!==(l="function"==typeof i?i.apply(t,r):i)&&(e.exports=l)}(void 0!==o?o:this.window||this.global,function(e){"use strict";function t(){for(var e={},t=0;t