I want to use the (PDR) Pentaho Report Designer for a task a little different than what it was probably thought for: instead of reports, the documents I create with PRD represent ticket layouts for me, in the sense of tickets for event seats. I have used the PRD successfully and it will save a lot of time to my company. But for it to be the perfect tool, I need some changes, mainly constraints applied to the software as available in github.

I want any corporate user to be able to design a ticket layout for an event, but depending on the user role, they may be able to only see certain events, sessions, etc:

  • the user must authenticate in order to determine the access rights to data such as: facilities, events, sessions, etc.
  • instead of freely create new reports, the user will select Facility>Event>Session>Rate>Format and that will open an univocal document. This document is what I shall call Ticket Template. If it existed already, then open it in the state it last was; otherwise, open it in the initial state.
  • The initial state of the template ticket only shows the detail row (the structure tree tab can be hidden); the width and height as well as the guides are fixed according to the ticket format selected; the data source must be automatically set depending on the Rate.
  • When the ticket template is published (maybe using the Pentaho server), it should stay accessible by the PRD itself and other applications, e.g. later edition by the same or different user; thus it must remain properly identified.
  • Other unneeded functions shall remain hidden, e.g. datasource edition.

I have built and executed both the PRD and the Pentaho server successfully from the github sources; they look great!

I can start to dig into the codes and try to figure out how things work, but what I would really appreciate is some guidelines as to how best attain my goal and, even better, how could they serve the community.

Any comments will be appreciated. Cheers,