Request Tracker: An Enterprise-grade Issue Tracking System with Perl

RT is an enterprise-grade issue tracking system. It allows organizations
to keep track of what needs to get done, who is working on which tasks,
what's already been done, and when tasks were (or weren't) completed.

RT doesn't cost anything to use, no matter how much you use it; it is
freely available under the terms of Version 2 of the GNU General Public
License.

RT is commercially-supported software. To purchase support, training,
custom development, or professional services, please get in touch with
us at <sales@bestpractical.com>.


REQUIRED PACKAGES
-----------------

o   Perl 5.10.1 or later (http://www.perl.org).

       RT won't start on versions of Perl older than 5.10.1.

o   A supported SQL database

       Currently supported:  MySQL 5.7 with InnoDB support
                             MariaDB 10.2 or later with InnoDB support
                             Postgres 9.5 or later
                             Oracle 12c or later
                             SQLite 3.0 or later; for testing only, no
                                          upgrade path guaranteed

o   Apache version 2.x (https://httpd.apache.org)
       with mod_fcgid -- (https://httpd.apache.org/mod_fcgid/mod/mod_fcgid.html)
       or mod_perl -- (http://perl.apache.org)
       or nginx -- (https://nginx.org/)
       or another webserver with FastCGI support

       RT's FastCGI handler needs to access RT's configuration file.

o   Various and sundry perl modules

       A tool included with RT takes care of the installation of most
       of these automatically during the install process.

       The tool supplied with RT uses Perl's CPAN (http://www.cpan.org)
       to install modules. Some operating systems package all or some
       of the modules required, and you may be better off installing
       the modules that way.

OPTIONAL DEPENDENCIES
---------------------

o   Full-text indexing support in your database

       The databases listed above all have options for full-text indexing
       (excluding SQLite). See docs/full_text_indexing.pod for details.

o   An external HTML converter

       Installing an external utility to convert HTML can improve performance.
       See the $HTMLFormatter configuration option for details.

GENERAL INSTALLATION
--------------------

1) Unpack this distribution other than where you want to install RT.
   Your home directory or /usr/local/src are both fine choices.
   Change to that directory and run the following command:

       tar xzvf rt.tar.gz

2) Run the "configure" script.  To see the list of options, run:

       ./configure --help

   Peruse the options, then rerun ./configure with the flags you want.

   RT defaults to installing in /opt/rt5 with MySQL as its database. It
   tries to guess which of www-data, www, apache or nobody your
   webserver will run as, but you can override that behavior.  Note
   that the default install directory in /opt/rt5 does not work under
   SELinux's default configuration.

   If you are upgrading from a previous version of RT, please review
   the upgrade notes for the appropriate versions, which can be found
   in docs/UPGRADING-* If you are coming from 4.4.x to 5.0.x you should
   review both the UPGRADING-4.4 and UPGRADING-5.0 files.  Similarly, if
   you were coming from 4.2.x, you would want to review the UPGRADING-4.2,
   UPGRADING-4.4 and UPGRADING-5.0 documents.

   Any upgrade steps given in version-specific UPGRADING files should
   be run after the rest of the steps below; however, please read the
   relevant documentation before beginning the upgrade, so as to be
   aware of important changes.

   RT stores the arguments given to ./configure at the top of the
   etc/RT_Config.pm file in case you need to recreate your previous use
   of ./configure.

3) Make sure that RT has the Perl and system libraries it needs to run.
   Check for missing dependencies by running:

       make testdeps

4) If the script reports any missing dependencies, install them by
   hand, or run the following command as a user who has permission to
   install perl modules on your system:

       make fixdeps

   Some modules require user input or environment variables to install
   correctly, so it may be necessary to install them manually. Some modules
   also require external source libraries, so you may need to install
   additional packages.

   If you are having trouble installing GD, refer to "Installing GD libraries"
   in docs/charts.pod.  Ticket relationship graphing requires the graphviz
   library which you should install using your distribution's package manager.

   See docs/rt_perl.pod for additional information about installing perl and
   RT's dependencies.

5) Check to make sure everything was installed properly.

       make testdeps

   It might sometimes be necessary to run "make fixdeps" several times
   to install all necessary perl modules.

6a) If this is a NEW installation (not an upgrade):

     As a user with permission to install RT in your chosen directory,
     type:

         make install

     To configure RT with the web installer, run:

         /opt/rt5/sbin/rt-server

     and follow the instructions.  Once completed, you should now have a
     working RT instance running with the standalone rt-server.  Press
     Ctrl-C to stop it, and proceed to Step 7 to configure a recommended
     deployment environment for production.

     To configure RT manually, you must setup etc/RT_SiteConfig.pm in
     your RT installation directory.  You'll need to add any values you
     need to change from the defaults in etc/RT_Config.pm

     As a user with permission to read RT's configuration file, type:

         make initialize-database

     If the make fails, type:

         make dropdb

     and re-run 'make initialize-database'.

6b) If you are UPGRADING from a previous installation:

     Before upgrading, always ensure that you have a complete current
     backup. If you don't have a current backup, upgrading your database
     could accidentally damage it and lose data, or worse.

     If you are using MySQL, please read the instructions in
     docs/UPGRADING.mysql as well to ensure that you do not corrupt
     existing data.

     First, stop your webserver.  You may also wish to put incoming email
     into a hold queue, to avoid temporary delivery failure messages if
     your upgrade is expected to take several hours.

     Next, install new binaries, config files and libraries by running:

         make upgrade

     This will also prompt you to upgrade your database by running:

         make upgrade-database

     You should back up your database before running this command.
     When you run it, you will be prompted for your previous version of
     RT (such as 4.4.1) so that the appropriate set of database
     upgrades can be applied.

     If 'make upgrade-database' completes without error, your upgrade
     has been successful; you should now run any commands that were
     supplied in version-specific UPGRADING documentation.  You should
     then restart your webserver.

     Depending on the size and composition of your database, some upgrade
     steps may run for a long time. You may also need extra disk space or
     other resources while running upgrade steps. It's a good idea to run
     through the upgrade steps on a test server so you know what to expect
     before running on your production system.

7) Configure the web server, as described in docs/web_deployment.pod,
   and the email gateway, as described below.

   NOTE: The default credentials for RT are:
       User: root
       Pass: password
   Not changing the root password from the default is a SECURITY risk!

8) Set up users, groups, queues, scrips and access control.

   Until you do this, RT will not be able to send or receive email, nor
   will it be more than marginally functional.  This is not an optional
   step.

9) Set up automated recurring tasks (cronjobs):

   Depending on your configuration, RT stores sessions in the database
   or on the file system. In either case, sessions are only needed until
   a user logs out, so old sessions should be cleaned up with this utility:

       perldoc /opt/rt5/sbin/rt-clean-sessions

   To generate email digest messages, you must arrange for the provided
   utility to be run once daily, and once weekly. You may also want
   to arrange for the rt-email-dashboards utility to be run hourly.

   If your task scheduler is cron, you can configure it by
   adding the following lines as /etc/cron.d/rt:

       0 0 * * * root /opt/rt5/sbin/rt-clean-sessions
       0 0 * * * root /opt/rt5/sbin/rt-email-digest -m daily
       0 0 * * 0 root /opt/rt5/sbin/rt-email-digest -m weekly
       0 * * * * root /opt/rt5/sbin/rt-email-dashboards

   Other optional features like full text search indexes, external
   attachments, etc., may also have recurring jobs to schedule in cron.
   Follow the documentation for these features when you enable them.

10) Configure the RT email gateway.  To let email flow to your RT
   server, you need to add a few lines of configuration to your mail
   server's "aliases" file. These lines "pipe" incoming email messages
   from your mail server to RT.

   Add the following lines to /etc/aliases (or your local equivalent)
   on your mail server:

       rt:         "|/opt/rt5/bin/rt-mailgate --queue general --action correspond --url http://rt.example.com/"
       rt-comment: "|/opt/rt5/bin/rt-mailgate --queue general --action comment --url http://rt.example.com/"

   You'll need to add similar lines for each queue you want to be able to
   send email to. To find out more about how to configure RT's email
   gateway, type:

          perldoc /opt/rt5/bin/rt-mailgate

11) Set up full text search

   Full text search (FTS) without database indexing is a very slow operation,
   and is thus disabled by default. You'll need to follow the instructions in
   docs/full_text_indexing.pod to enable FTS.

12) Set up automatic backups for RT and its data as described in
   the docs/system_administration/database.pod document.

GETTING HELP
------------

If RT is mission-critical for you or if you use it heavily, we recommend
that you purchase a commercial support contract.  Details on support
contracts are available at http://www.bestpractical.com or by writing to
<sales@bestpractical.com>. We also offer managed hosting plans if you
prefer to have someone else manage the RT server.

If you're interested in having RT extended or customized or would like
more information about commercial support options, please send email to
<sales@bestpractical.com> to discuss rates and availability.


COMMUNITY FORUM AND WIKI
------------------------

To keep up to date on the latest RT tips, techniques and extensions, you
may wish to join the RT Community Forum website.  You can find it here:

     https://forum.bestpractical.com

You'll find many different categories of discussion there including the
RT Users category for general RT topics. If you're interested
in customizing RT code, there is a category for RT Developers with more
technical topics.

The RT wiki, at https://rt-wiki.bestpractical.com, is also a potential
resource.


SECURITY
--------

If you believe you've discovered a security issue in RT, please send an
email to <security@bestpractical.com> with a detailed description of the
issue, and a secure means to respond to you (such as your PGP public
key).  You can find our PGP key and fingerprint at
https://bestpractical.com/security/


BUGS
----

RT's a pretty complex application, and as you get up to speed, you might
run into some trouble. Generally, it's best to ask about things you run
into on the Community Forum (or pick up a commercial support
contract from Best Practical). But, sometimes people do run into
bugs. In the exceedingly unlikely event that you hit a bug in RT, please
report it! We'd love to hear about problems you have with RT, so we can
fix them.  To report a bug, send email to <rt-bugs@bestpractical.com>.

Note that this sends email to our public RT instance. Do not include any
information in your email that you don't want shown publicly, including
contact information in your email signature.

# BEGIN BPS TAGGED BLOCK {{{
#
# COPYRIGHT:
#
# This software is Copyright (c) 1996-2022 Best Practical Solutions, LLC
#                                          <sales@bestpractical.com>
#
# (Except where explicitly superseded by other copyright notices)
#
#
# LICENSE:
#
# This work is made available to you under the terms of Version 2 of
# the GNU General Public License. A copy of that license should have
# been provided with this software, but in any event can be snarfed
# from www.gnu.org.
#
# This work is distributed in the hope that it will be useful, but
# WITHOUT ANY WARRANTY; without even the implied warranty of
# MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the GNU
# General Public License for more details.
#
# You should have received a copy of the GNU General Public License
# along with this program; if not, write to the Free Software
# Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA
# 02110-1301 or visit their web page on the internet at
# http://www.gnu.org/licenses/old-licenses/gpl-2.0.html.
#
#
# CONTRIBUTION SUBMISSION POLICY:
#
# (The following paragraph is not intended to limit the rights granted
# to you to modify and distribute this software under the terms of
# the GNU General Public License and is only of importance to you if
# you choose to contribute your changes and enhancements to the
# community by submitting them to Best Practical Solutions, LLC.)
#
# By intentionally submitting any modifications, corrections or
# derivatives to this work, or any other work intended for use with
# Request Tracker, to Best Practical Solutions, LLC, you confirm that
# you are the copyright holder for those contributions and you grant
# Best Practical Solutions,  LLC a nonexclusive, worldwide, irrevocable,
# royalty-free, perpetual, license to use, copy, create derivative
# works based on those contributions, and sublicense and distribute
# those contributions and any derivatives thereof.
#
# END BPS TAGGED BLOCK }}}


Download Details:

Author: bestpractical
Source Code: https://github.com/bestpractical/rt

License: GPL-2.0 license

#perl 

What is GEEK

Buddha Community

Request Tracker: An Enterprise-grade Issue Tracking System with Perl

Spring: A Static Web Site Generator Written By GitHub Issues

Spring

Spring is a blog engine written by GitHub Issues, or is a simple, static web site generator. No more server and database, you can setup it in free hosting with GitHub Pages as a repository, then post the blogs in the repository Issues.

You can add some labels in your repository Issues as the blog category, and create Issues for writing blog content through Markdown.

Spring has responsive templates, looking good on mobile, tablet, and desktop.Gracefully degrading in older browsers. Compatible with Internet Explorer 10+ and all modern browsers.

Get up and running in seconds.

中文介绍

Quick start guide

For the impatient, here's how to get a Spring blog site up and running.

First of all

  • Fork the Spring repository as yours.
  • Goto your repository settings page to rename Repository Name.
  • Hosted directly on GitHub Pages from your project repository, you can take it as User or organization site or Project site(create a gh-pages branch).
  • Also, you can set up a custom domain with Pages.

Secondly

  • Open the index.html file to edit the config variables with yours below.
$.extend(spring.config, {
  // my blog title
  title: 'Spring',
  // my blog description
  desc: "A blog engine written by github issues [Fork me on GitHub](https://github.com/zhaoda/spring)",
  // my github username
  owner: 'zhaoda',
  // creator's username
  creator: 'zhaoda',
  // the repository name on github for writting issues
  repo: 'spring',
  // custom page
  pages: [
  ]
})
  • Put your domain into the CNAME file if you have.
  • Commit your change and push it.

And then

  • Goto your repository settings page to turn on the Issues feature.
  • Browser this repository's issues page, like this https://github.com/your-username/your-repo-name/issues?state=open.
  • Click the New Issue button to just write some content as a new one blog.

Finally

  • Browser this repository's GitHub Pages url, like this http://your-username.github.io/your-repo-name, you will see your Spring blog, have a test.
  • And you're done!

Custom development

Installation

  • You will need a web server installed on your system, for example, Nginx, Apache etc.
  • Configure your spring project to your local web server directory.
  • Run and browser it, like http://localhost/spring/dev.html .
  • dev.html is used to develop, index.html is used to runtime.

Folder Structure

spring/
├── css/
|    ├── boot.less  #import other less files
|    ├── github.less  #github highlight style
|    ├── home.less  #home page style
|    ├── issuelist.less #issue list widget style
|    ├── issues.less #issues page style
|    ├── labels.less #labels page style
|    ├── main.less #commo style
|    ├── markdown.less #markdown format style
|    ├── menu.less #menu panel style
|    ├── normalize.less #normalize style
|    ├── pull2refresh.less #pull2refresh widget style
|    └── side.html  #side panel style
├── dist/
|    ├── main.min.css  #css for runtime
|    └── main.min.js  #js for runtime
├── img/  #some icon, startup images
├── js/
|    ├── lib/  #some js librarys need to use
|    ├── boot.js  #boot
|    ├── home.js  #home page
|    ├── issuelist.js #issue list widget
|    ├── issues.js #issues page
|    ├── labels.js #labels page
|    ├── menu.js #menu panel
|    ├── pull2refresh.less #pull2refresh widget
|    └── side.html  #side panel
├── css/
|    ├── boot.less  #import other less files
|    ├── github.less  #github highlight style
|    ├── home.less  #home page style
|    ├── issuelist.less #issue list widget style
|    ├── issues.less #issues page style
|    ├── labels.less #labels page style
|    ├── main.less #commo style
|    ├── markdown.less #markdown format style
|    ├── menu.less #menu panel style
|    ├── normalize.less #normalize style
|    ├── pull2refresh.less #pull2refresh widget style
|    └── side.html  #side panel style
├── dev.html #used to develop
├── favicon.ico #website icon
├── Gruntfile.js #Grunt task config
├── index.html #used to runtime
└── package.json  #nodejs install config

Customization

  • Browser http://localhost/spring/dev.html, enter the development mode.
  • Changes you want to modify the source code, like css, js etc.
  • Refresh dev.html view change.

Building

  • You will need Node.js installed on your system.
  • Installation package.
bash

$ npm install

*   Run grunt task.

    ```bash
$ grunt
  • Browser http://localhost/spring/index.html, enter the runtime mode.
  • If there is no problem, commit and push the code.
  • Don't forget to merge master branch into gh-pages branch if you have.
  • And you're done! Good luck!

Report a bug

Who used

If you are using, please tell me.

Download Details:
Author: zhaoda
Source Code: https://github.com/zhaoda/spring
License: MIT License

#spring #spring-framework #spring-boot #java 

Request Tracker: An Enterprise-grade Issue Tracking System with Perl

RT is an enterprise-grade issue tracking system. It allows organizations
to keep track of what needs to get done, who is working on which tasks,
what's already been done, and when tasks were (or weren't) completed.

RT doesn't cost anything to use, no matter how much you use it; it is
freely available under the terms of Version 2 of the GNU General Public
License.

RT is commercially-supported software. To purchase support, training,
custom development, or professional services, please get in touch with
us at <sales@bestpractical.com>.


REQUIRED PACKAGES
-----------------

o   Perl 5.10.1 or later (http://www.perl.org).

       RT won't start on versions of Perl older than 5.10.1.

o   A supported SQL database

       Currently supported:  MySQL 5.7 with InnoDB support
                             MariaDB 10.2 or later with InnoDB support
                             Postgres 9.5 or later
                             Oracle 12c or later
                             SQLite 3.0 or later; for testing only, no
                                          upgrade path guaranteed

o   Apache version 2.x (https://httpd.apache.org)
       with mod_fcgid -- (https://httpd.apache.org/mod_fcgid/mod/mod_fcgid.html)
       or mod_perl -- (http://perl.apache.org)
       or nginx -- (https://nginx.org/)
       or another webserver with FastCGI support

       RT's FastCGI handler needs to access RT's configuration file.

o   Various and sundry perl modules

       A tool included with RT takes care of the installation of most
       of these automatically during the install process.

       The tool supplied with RT uses Perl's CPAN (http://www.cpan.org)
       to install modules. Some operating systems package all or some
       of the modules required, and you may be better off installing
       the modules that way.

OPTIONAL DEPENDENCIES
---------------------

o   Full-text indexing support in your database

       The databases listed above all have options for full-text indexing
       (excluding SQLite). See docs/full_text_indexing.pod for details.

o   An external HTML converter

       Installing an external utility to convert HTML can improve performance.
       See the $HTMLFormatter configuration option for details.

GENERAL INSTALLATION
--------------------

1) Unpack this distribution other than where you want to install RT.
   Your home directory or /usr/local/src are both fine choices.
   Change to that directory and run the following command:

       tar xzvf rt.tar.gz

2) Run the "configure" script.  To see the list of options, run:

       ./configure --help

   Peruse the options, then rerun ./configure with the flags you want.

   RT defaults to installing in /opt/rt5 with MySQL as its database. It
   tries to guess which of www-data, www, apache or nobody your
   webserver will run as, but you can override that behavior.  Note
   that the default install directory in /opt/rt5 does not work under
   SELinux's default configuration.

   If you are upgrading from a previous version of RT, please review
   the upgrade notes for the appropriate versions, which can be found
   in docs/UPGRADING-* If you are coming from 4.4.x to 5.0.x you should
   review both the UPGRADING-4.4 and UPGRADING-5.0 files.  Similarly, if
   you were coming from 4.2.x, you would want to review the UPGRADING-4.2,
   UPGRADING-4.4 and UPGRADING-5.0 documents.

   Any upgrade steps given in version-specific UPGRADING files should
   be run after the rest of the steps below; however, please read the
   relevant documentation before beginning the upgrade, so as to be
   aware of important changes.

   RT stores the arguments given to ./configure at the top of the
   etc/RT_Config.pm file in case you need to recreate your previous use
   of ./configure.

3) Make sure that RT has the Perl and system libraries it needs to run.
   Check for missing dependencies by running:

       make testdeps

4) If the script reports any missing dependencies, install them by
   hand, or run the following command as a user who has permission to
   install perl modules on your system:

       make fixdeps

   Some modules require user input or environment variables to install
   correctly, so it may be necessary to install them manually. Some modules
   also require external source libraries, so you may need to install
   additional packages.

   If you are having trouble installing GD, refer to "Installing GD libraries"
   in docs/charts.pod.  Ticket relationship graphing requires the graphviz
   library which you should install using your distribution's package manager.

   See docs/rt_perl.pod for additional information about installing perl and
   RT's dependencies.

5) Check to make sure everything was installed properly.

       make testdeps

   It might sometimes be necessary to run "make fixdeps" several times
   to install all necessary perl modules.

6a) If this is a NEW installation (not an upgrade):

     As a user with permission to install RT in your chosen directory,
     type:

         make install

     To configure RT with the web installer, run:

         /opt/rt5/sbin/rt-server

     and follow the instructions.  Once completed, you should now have a
     working RT instance running with the standalone rt-server.  Press
     Ctrl-C to stop it, and proceed to Step 7 to configure a recommended
     deployment environment for production.

     To configure RT manually, you must setup etc/RT_SiteConfig.pm in
     your RT installation directory.  You'll need to add any values you
     need to change from the defaults in etc/RT_Config.pm

     As a user with permission to read RT's configuration file, type:

         make initialize-database

     If the make fails, type:

         make dropdb

     and re-run 'make initialize-database'.

6b) If you are UPGRADING from a previous installation:

     Before upgrading, always ensure that you have a complete current
     backup. If you don't have a current backup, upgrading your database
     could accidentally damage it and lose data, or worse.

     If you are using MySQL, please read the instructions in
     docs/UPGRADING.mysql as well to ensure that you do not corrupt
     existing data.

     First, stop your webserver.  You may also wish to put incoming email
     into a hold queue, to avoid temporary delivery failure messages if
     your upgrade is expected to take several hours.

     Next, install new binaries, config files and libraries by running:

         make upgrade

     This will also prompt you to upgrade your database by running:

         make upgrade-database

     You should back up your database before running this command.
     When you run it, you will be prompted for your previous version of
     RT (such as 4.4.1) so that the appropriate set of database
     upgrades can be applied.

     If 'make upgrade-database' completes without error, your upgrade
     has been successful; you should now run any commands that were
     supplied in version-specific UPGRADING documentation.  You should
     then restart your webserver.

     Depending on the size and composition of your database, some upgrade
     steps may run for a long time. You may also need extra disk space or
     other resources while running upgrade steps. It's a good idea to run
     through the upgrade steps on a test server so you know what to expect
     before running on your production system.

7) Configure the web server, as described in docs/web_deployment.pod,
   and the email gateway, as described below.

   NOTE: The default credentials for RT are:
       User: root
       Pass: password
   Not changing the root password from the default is a SECURITY risk!

8) Set up users, groups, queues, scrips and access control.

   Until you do this, RT will not be able to send or receive email, nor
   will it be more than marginally functional.  This is not an optional
   step.

9) Set up automated recurring tasks (cronjobs):

   Depending on your configuration, RT stores sessions in the database
   or on the file system. In either case, sessions are only needed until
   a user logs out, so old sessions should be cleaned up with this utility:

       perldoc /opt/rt5/sbin/rt-clean-sessions

   To generate email digest messages, you must arrange for the provided
   utility to be run once daily, and once weekly. You may also want
   to arrange for the rt-email-dashboards utility to be run hourly.

   If your task scheduler is cron, you can configure it by
   adding the following lines as /etc/cron.d/rt:

       0 0 * * * root /opt/rt5/sbin/rt-clean-sessions
       0 0 * * * root /opt/rt5/sbin/rt-email-digest -m daily
       0 0 * * 0 root /opt/rt5/sbin/rt-email-digest -m weekly
       0 * * * * root /opt/rt5/sbin/rt-email-dashboards

   Other optional features like full text search indexes, external
   attachments, etc., may also have recurring jobs to schedule in cron.
   Follow the documentation for these features when you enable them.

10) Configure the RT email gateway.  To let email flow to your RT
   server, you need to add a few lines of configuration to your mail
   server's "aliases" file. These lines "pipe" incoming email messages
   from your mail server to RT.

   Add the following lines to /etc/aliases (or your local equivalent)
   on your mail server:

       rt:         "|/opt/rt5/bin/rt-mailgate --queue general --action correspond --url http://rt.example.com/"
       rt-comment: "|/opt/rt5/bin/rt-mailgate --queue general --action comment --url http://rt.example.com/"

   You'll need to add similar lines for each queue you want to be able to
   send email to. To find out more about how to configure RT's email
   gateway, type:

          perldoc /opt/rt5/bin/rt-mailgate

11) Set up full text search

   Full text search (FTS) without database indexing is a very slow operation,
   and is thus disabled by default. You'll need to follow the instructions in
   docs/full_text_indexing.pod to enable FTS.

12) Set up automatic backups for RT and its data as described in
   the docs/system_administration/database.pod document.

GETTING HELP
------------

If RT is mission-critical for you or if you use it heavily, we recommend
that you purchase a commercial support contract.  Details on support
contracts are available at http://www.bestpractical.com or by writing to
<sales@bestpractical.com>. We also offer managed hosting plans if you
prefer to have someone else manage the RT server.

If you're interested in having RT extended or customized or would like
more information about commercial support options, please send email to
<sales@bestpractical.com> to discuss rates and availability.


COMMUNITY FORUM AND WIKI
------------------------

To keep up to date on the latest RT tips, techniques and extensions, you
may wish to join the RT Community Forum website.  You can find it here:

     https://forum.bestpractical.com

You'll find many different categories of discussion there including the
RT Users category for general RT topics. If you're interested
in customizing RT code, there is a category for RT Developers with more
technical topics.

The RT wiki, at https://rt-wiki.bestpractical.com, is also a potential
resource.


SECURITY
--------

If you believe you've discovered a security issue in RT, please send an
email to <security@bestpractical.com> with a detailed description of the
issue, and a secure means to respond to you (such as your PGP public
key).  You can find our PGP key and fingerprint at
https://bestpractical.com/security/


BUGS
----

RT's a pretty complex application, and as you get up to speed, you might
run into some trouble. Generally, it's best to ask about things you run
into on the Community Forum (or pick up a commercial support
contract from Best Practical). But, sometimes people do run into
bugs. In the exceedingly unlikely event that you hit a bug in RT, please
report it! We'd love to hear about problems you have with RT, so we can
fix them.  To report a bug, send email to <rt-bugs@bestpractical.com>.

Note that this sends email to our public RT instance. Do not include any
information in your email that you don't want shown publicly, including
contact information in your email signature.

# BEGIN BPS TAGGED BLOCK {{{
#
# COPYRIGHT:
#
# This software is Copyright (c) 1996-2022 Best Practical Solutions, LLC
#                                          <sales@bestpractical.com>
#
# (Except where explicitly superseded by other copyright notices)
#
#
# LICENSE:
#
# This work is made available to you under the terms of Version 2 of
# the GNU General Public License. A copy of that license should have
# been provided with this software, but in any event can be snarfed
# from www.gnu.org.
#
# This work is distributed in the hope that it will be useful, but
# WITHOUT ANY WARRANTY; without even the implied warranty of
# MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the GNU
# General Public License for more details.
#
# You should have received a copy of the GNU General Public License
# along with this program; if not, write to the Free Software
# Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA
# 02110-1301 or visit their web page on the internet at
# http://www.gnu.org/licenses/old-licenses/gpl-2.0.html.
#
#
# CONTRIBUTION SUBMISSION POLICY:
#
# (The following paragraph is not intended to limit the rights granted
# to you to modify and distribute this software under the terms of
# the GNU General Public License and is only of importance to you if
# you choose to contribute your changes and enhancements to the
# community by submitting them to Best Practical Solutions, LLC.)
#
# By intentionally submitting any modifications, corrections or
# derivatives to this work, or any other work intended for use with
# Request Tracker, to Best Practical Solutions, LLC, you confirm that
# you are the copyright holder for those contributions and you grant
# Best Practical Solutions,  LLC a nonexclusive, worldwide, irrevocable,
# royalty-free, perpetual, license to use, copy, create derivative
# works based on those contributions, and sublicense and distribute
# those contributions and any derivatives thereof.
#
# END BPS TAGGED BLOCK }}}


Download Details:

Author: bestpractical
Source Code: https://github.com/bestpractical/rt

License: GPL-2.0 license

#perl 

Ruth  Nabimanya

Ruth Nabimanya

1620633584

System Databases in SQL Server

Introduction

In SSMS, we many of may noticed System Databases under the Database Folder. But how many of us knows its purpose?. In this article lets discuss about the System Databases in SQL Server.

System Database

Fig. 1 System Databases

There are five system databases, these databases are created while installing SQL Server.

  • Master
  • Model
  • MSDB
  • Tempdb
  • Resource
Master
  • This database contains all the System level Information in SQL Server. The Information in form of Meta data.
  • Because of this master database, we are able to access the SQL Server (On premise SQL Server)
Model
  • This database is used as a template for new databases.
  • Whenever a new database is created, initially a copy of model database is what created as new database.
MSDB
  • This database is where a service called SQL Server Agent stores its data.
  • SQL server Agent is in charge of automation, which includes entities such as jobs, schedules, and alerts.
TempDB
  • The Tempdb is where SQL Server stores temporary data such as work tables, sort space, row versioning information and etc.
  • User can create their own version of temporary tables and those are stored in Tempdb.
  • But this database is destroyed and recreated every time when we restart the instance of SQL Server.
Resource
  • The resource database is a hidden, read only database that holds the definitions of all system objects.
  • When we query system object in a database, they appear to reside in the sys schema of the local database, but in actually their definitions reside in the resource db.

#sql server #master system database #model system database #msdb system database #sql server system databases #ssms #system database #system databases in sql server #tempdb system database

Security issues in enterprise mobility development and how to overcome it?

Enterprise mobility is responsible for improving flexibility in the workplace. But, enterprises face security issues during the implementation of enterprise app development. So, What are solutions for security issues?

#challenges of enterprise mobility #solution of enterprise mobility #enterprise mobility development #enterprise mobility security #enterprise app development #security issues

Beth  Cooper

Beth Cooper

1659694200

Easy Activity Tracking for Models, Similar to Github's Public Activity

PublicActivity

public_activity provides easy activity tracking for your ActiveRecord, Mongoid 3 and MongoMapper models in Rails 3 and 4.

Simply put: it can record what happens in your application and gives you the ability to present those recorded activities to users - in a similar way to how GitHub does it.

!! WARNING: README for unreleased version below. !!

You probably don't want to read the docs for this unreleased version 2.0.

For the stable 1.5.X readme see: https://github.com/chaps-io/public_activity/blob/1-5-stable/README.md

About

Here is a simple example showing what this gem is about:

Example usage

Tutorials

Screencast

Ryan Bates made a great screencast describing how to integrate Public Activity.

Tutorial

A great step-by-step guide on implementing activity feeds using public_activity by Ilya Bodrov.

Online demo

You can see an actual application using this gem here: http://public-activity-example.herokuapp.com/feed

The source code of the demo is hosted here: https://github.com/pokonski/activity_blog

Setup

Gem installation

You can install public_activity as you would any other gem:

gem install public_activity

or in your Gemfile:

gem 'public_activity'

Database setup

By default public_activity uses Active Record. If you want to use Mongoid or MongoMapper as your backend, create an initializer file in your Rails application with the corresponding code inside:

For Mongoid:

# config/initializers/public_activity.rb
PublicActivity.configure do |config|
  config.orm = :mongoid
end

For MongoMapper:

# config/initializers/public_activity.rb
PublicActivity.configure do |config|
  config.orm = :mongo_mapper
end

(ActiveRecord only) Create migration for activities and migrate the database (in your Rails project):

rails g public_activity:migration
rake db:migrate

Model configuration

Include PublicActivity::Model and add tracked to the model you want to keep track of:

For ActiveRecord:

class Article < ActiveRecord::Base
  include PublicActivity::Model
  tracked
end

For Mongoid:

class Article
  include Mongoid::Document
  include PublicActivity::Model
  tracked
end

For MongoMapper:

class Article
  include MongoMapper::Document
  include PublicActivity::Model
  tracked
end

And now, by default create/update/destroy activities are recorded in activities table. This is all you need to start recording activities for basic CRUD actions.

Optional: If you don't need #tracked but still want the comfort of #create_activity, you can include only the lightweight Common module instead of Model.

Custom activities

You can trigger custom activities by setting all your required parameters and triggering create_activity on the tracked model, like this:

@article.create_activity key: 'article.commented_on', owner: current_user

See this entry http://rubydoc.info/gems/public_activity/PublicActivity/Common:create_activity for more details.

Displaying activities

To display them you simply query the PublicActivity::Activity model:

# notifications_controller.rb
def index
  @activities = PublicActivity::Activity.all
end

And in your views:

<%= render_activities(@activities) %>

Note: render_activities is an alias for render_activity and does the same.

Layouts

You can also pass options to both activity#render and #render_activity methods, which are passed deeper to the internally used render_partial method. A useful example would be to render activities wrapped in layout, which shares common elements of an activity, like a timestamp, owner's avatar etc:

<%= render_activities(@activities, layout: :activity) %>

The activity will be wrapped with the app/views/layouts/_activity.html.erb layout, in the above example.

Important: please note that layouts for activities are also partials. Hence the _ prefix.

Locals

Sometimes, it's desirable to pass additional local variables to partials. It can be done this way:

<%= render_activity(@activity, locals: {friends: current_user.friends}) %>

Note: Before 1.4.0, one could pass variables directly to the options hash for #render_activity and access it from activity parameters. This functionality is retained in 1.4.0 and later, but the :locals method is preferred, since it prevents bugs from shadowing variables from activity parameters in the database.

Activity views

public_activity looks for views in app/views/public_activity.

For example, if you have an activity with :key set to "activity.user.changed_avatar", the gem will look for a partial in app/views/public_activity/user/_changed_avatar.html.(|erb|haml|slim|something_else).

Hint: the "activity." prefix in :key is completely optional and kept for backwards compatibility, you can skip it in new projects.

If you would like to fallback to a partial, you can utilize the fallback parameter to specify the path of a partial to use when one is missing:

<%= render_activity(@activity, fallback: 'default') %>

When used in this manner, if a partial with the specified :key cannot be located it will use the partial defined in the fallback instead. In the example above this would resolve to public_activity/_default.html.(|erb|haml|slim|something_else).

If a view file does not exist then ActionView::MisingTemplate will be raised. If you wish to fallback to the old behaviour and use an i18n based translation in this situation you can specify a :fallback parameter of text to fallback to this mechanism like such:

<%= render_activity(@activity, fallback: :text) %>

i18n

Translations are used by the #text method, to which you can pass additional options in form of a hash. #render method uses translations when view templates have not been provided. You can render pure i18n strings by passing {display: :i18n} to #render_activity or #render.

Translations should be put in your locale .yml files. To render pure strings from I18n Example structure:

activity:
  article:
    create: 'Article has been created'
    update: 'Someone has edited the article'
    destroy: 'Some user removed an article!'

This structure is valid for activities with keys "activity.article.create" or "article.create". As mentioned before, "activity." part of the key is optional.

Testing

For RSpec you can first disable public_activity and add require helper methods in the rails_helper.rb with:

#rails_helper.rb
require 'public_activity/testing'

PublicActivity.enabled = false

In your specs you can then blockwise decide whether to turn public_activity on or off.

# file_spec.rb
PublicActivity.with_tracking do
  # your test code goes here
end

PublicActivity.without_tracking do
  # your test code goes here
end

Documentation

For more documentation go here

Common examples

Set the Activity's owner to current_user by default

You can set up a default value for :owner by doing this:

  1. Include PublicActivity::StoreController in your ApplicationController like this:
class ApplicationController < ActionController::Base
  include PublicActivity::StoreController
end
  1. Use Proc in :owner attribute for tracked class method in your desired model. For example:
class Article < ActiveRecord::Base
  tracked owner: Proc.new{ |controller, model| controller.current_user }
end

Note: current_user applies to Devise, if you are using a different authentication gem or your own code, change the current_user to a method you use.

Disable tracking for a class or globally

If you need to disable tracking temporarily, for example in tests or db/seeds.rb then you can use PublicActivity.enabled= attribute like below:

# Disable p_a globally
PublicActivity.enabled = false

# Perform some operations that would normally be tracked by p_a:
Article.create(title: 'New article')

# Switch it back on
PublicActivity.enabled = true

You can also disable public_activity for a specific class:

# Disable p_a for Article class
Article.public_activity_off

# p_a will not do anything here:
@article = Article.create(title: 'New article')

# But will be enabled for other classes:
# (creation of the comment will be recorded if you are tracking the Comment class)
@article.comments.create(body: 'some comment!')

# Enable it again for Article:
Article.public_activity_on

Create custom activities

Besides standard, automatic activities created on CRUD actions on your model (deactivatable), you can post your own activities that can be triggered without modifying the tracked model. There are a few ways to do this, as PublicActivity gives three tiers of options to be set.

Instant options

Because every activity needs a key (otherwise: NoKeyProvided is raised), the shortest and minimal way to post an activity is:

@user.create_activity :mood_changed
# the key of the action will be user.mood_changed
@user.create_activity action: :mood_changed # this is exactly the same as above

Besides assigning your key (which is obvious from the code), it will take global options from User class (given in #tracked method during class definition) and overwrite them with instance options (set on @user by #activity method). You can read more about options and how PublicActivity inherits them for you here.

Note the action parameter builds the key like this: "#{model_name}.#{action}". You can read further on options for #create_activity here.

To provide more options, you can do:

@user.create_activity action: 'poke', parameters: {reason: 'bored'}, recipient: @friend, owner: current_user

In this example, we have provided all the things we could for a standard Activity.

Use custom fields on Activity

Besides the few fields that every Activity has (key, owner, recipient, trackable, parameters), you can also set custom fields. This could be very beneficial, as parameters are a serialized hash, which cannot be queried easily from the database. That being said, use custom fields when you know that you will set them very often and search by them (don't forget database indexes :) ).

Set owner and recipient based on associations

class Comment < ActiveRecord::Base
  include PublicActivity::Model
  tracked owner: :commenter, recipient: :commentee

  belongs_to :commenter, :class_name => "User"
  belongs_to :commentee, :class_name => "User"
end

Resolve parameters from a Symbol or Proc

class Post < ActiveRecord::Base
  include PublicActivity::Model
  tracked only: [:update], parameters: :tracked_values
  
  def tracked_values
   {}.tap do |hash|
     hash[:tags] = tags if tags_changed?
   end
  end
end

Setup

Skip this step if you are using ActiveRecord in Rails 4 or Mongoid

The first step is similar in every ORM available (except mongoid):

PublicActivity::Activity.class_eval do
  attr_accessible :custom_field
end

place this code under config/initializers/public_activity.rb, you have to create it first.

To be able to assign to that field, we need to move it to the mass assignment sanitizer's whitelist.

Migration

If you're using ActiveRecord, you will also need to provide a migration to add the actual field to the Activity. Taken from our tests:

class AddCustomFieldToActivities < ActiveRecord::Migration
  def change
    change_table :activities do |t|
      t.string :custom_field
    end
  end
end

Assigning custom fields

Assigning is done by the same methods that you use for normal parameters: #tracked, #create_activity. You can just pass the name of your custom variable and assign its value. Even better, you can pass it to #tracked to tell us how to harvest your data for custom fields so we can do that for you.

class Article < ActiveRecord::Base
  include PublicActivity::Model
  tracked custom_field: proc {|controller, model| controller.some_helper }
end

Help

If you need help with using public_activity please visit our discussion group and ask a question there:

https://groups.google.com/forum/?fromgroups#!forum/public-activity

Please do not ask general questions in the Github Issues.


Author: public-activity
Source code: https://github.com/public-activity/public_activity
License: MIT license

#ruby  #ruby-on-rails