Re: is scarab at its end of lifetime ?

So, let me give you an overview about what i am currently planning with
Scarab. Actually some points have allready found their way into trunk 
by now, but i mention them for completeness. Most of this work should
officially be done within the next 14 days, but i know, i won't get this
ready at time. Anyways many points of what i describe below will come 
soon or has allready been implemented. If you got any opinions and
implementation ideas or severe complains about a feature, plese let
me know.

BTW the selfhost is currently on the newest trunk-version and no, the
issues below have partially not yet been created as separate entries in 
the self host. But that is on my todo-list.

1.) New parameters for visualising attributes (implemented):

     - display size (how long the field shall be on the screen)
     - style-class (add style='' or class='' to each field)
     - regex for testing syntactically correct input
     - hint (will be shown right to the input field as example input)



2.) history rework (partially implemented)

     - more clean display, IMHO better understandable
     - (optional) Maybe replace the current display by a dynamic
customizable table
       similar to the search-results table containing the columns:

       ATTRIBUTE_NAME
       CHANGED_BY
       CHANGE_DATE
       CHANGE_FROM
       CHANGE_TO



3.) rework of Scarab GUI (partially done, work in progress)

     Main issue here: minimal support for skins



4.) post entry hooks (to be implemented)

     Any input field for Attributes can be associated to a
     post processing-hook. The hook allows to process the input
     and create actions (e.g. modify other fields or make an ajax-call to
the backend ...)
     So the hook will be mainly something happening in the frontend. I
currently
     favorise prototype, but maybe i might end up going plain ajax (no
framework at all)
     I had a few bad experiences with dojo recently (much too complex IMHO).
     No idea yet,  how to implement that in a clever way.



5.) Enhance EMail Notifications

     - hide attributes in email, when they are not visible for a user
     - rework the plaintext email-layout.
     - take more care about changed comments, instead of just sending
       every single change as a complete comment dump
     - more elaborate definition of what gets into the "about" field.
       maybe add a template (per issue type) with a syntax like:
       "[$issueid]:$shorttext ($status) " and maybe add condition-based
templates:

      if (errorclass=='critical' and status=='new')
           "[$issueid]:$shorttext immediate action necessary"

      if (errorclass=='critical' and status=='assigned' and lastChangeDate
longer than 1 hour ago) 
           "[$issueid]:$shorttext escalated: immediate action necessary!"



6.) attachments

     - add support for "inbrowser" display (currently only download
possible)



7.) rework the personell settings

     currently these settings are controlled via the user attributes
     and the focus is on who will get an email as "to" or "cc". But IMHO
     the personell settings are something more complex. They should reflect,
     who is actually "working" on an issue and who is just "watching" it.
     There should be a more elaborate algorithm for deciding when exactly an
involved
     personell shall be notified. Hence i plan to add
notification-constraints here,
     something similar to the transition-constraints defined in the global
attributes.

     I also think, it is a good option to have a checkmark for "notify me on
changes".
     This checkmark will be enabled and readonly for the personell, who is
"working" on
     the issue. all other personell can enable/disable this checkmark on an
issue-by-issue
     basis. The default setting for this checkmark should be definable in
the module settings.


8.) user/module definable start page



9.) hierarchical organisation of drop-down lists (treeview)

     Should reflect the parent-child associations defined in the attribute
editor



10.) add permission constraints in issues

       It should be possible to define, that an issue can not be modified
any more, when
       a specific condition applies (e.g. status=='closed')



11.) Add reminder-notifications

      If an issue is not touched for a specific time, the current asigned
responsible personell
      shall receive a notification.
      If an issue is still not touched, the module owner shall receive a
notification.



12.) add visual hints in query results.

      the idea is to add conditions to queries, which allow to
      assign a query result row to a cdertain css-class if a specific
condition occurs.



13.) Enhance the conditions on attributes (and on other elements as noted
above)

      - add a timed condition (e.g.: if last changed date longer than 10
days)
      - add negative conditions (e.g.: if status is NOT "closed")


-- 
View this message in context: http://www.nabble.com/is-scarab-at-its-end-of-lifetime---tp23725597p23737850.html
Sent from the Scarab - User mailing list archive at Nabble.com.

------------------------------------------------------
http://scarab.tigris.org/ds/viewMessage.do?dsForumId=456&dsMessageId=2355676

To unsubscribe from this discussion, e-mail: [[email protected]].