Skip to main content
K
khoppe15-Moonstone
15-Moonstone
October 9, 2013
Question

Integrity / Configuration Management / Create a notification for a Member Check in

  • October 9, 2013
  • 3 replies
  • 4555 views

Hello,

our users are asking for a functionality that allows to send a notification as soon a changed member will be checked in.

Does anyone have an idea how to implement such a functionality?

We figured out that "Set Member Rules .." seems to be no helping function.

Greetings,

Klaus

    3 replies

    A
    awalsh5-Regular Member
    5-Regular Member
    October 9, 2013

    Hi Klaus,

    While an administrator can set up triggers to do some e-mail notification (e.g. notify a project administrator whenever a member in a particular project is checked in, or notify the reviewer when a change package is submitted), I think the functionality you want is not possible. A user cannot set up notifications for when specific changed members are checked in. There is an existing change request. Please contact PTC Support to be added to RFC 128158.

    Regards,

    Ann

    K
    khoppe15-MoonstoneAuthor
    15-Moonstone
    October 10, 2013

    Hello,

    can you give me a hint WHERE this functionality is described in the documentation?

    With this info it should be possible to implement what I want.

    Greetings,

    Klaus

    S
    ssaul15-Moonstone
    15-Moonstone
    October 10, 2013

    We have implemented such a functionality via member attributes.

    Our users are allowed to change member attributes.

    When adding an attribute "email=username1, username2,...", there is a trigger script that is called on every checkin.

    It looks for the presence of this attribute, determines the email addresses of username1..x and sends an email to all users with some relevant information.

    So the users can modifiy the attribute of every member they want to be notified of.

    It is on member by member base, not for all members.

    Hope this helps.

    K
    khoppe15-MoonstoneAuthor
    15-Moonstone
    October 10, 2013

    This is a good idea to keep on eye on important files which are of basic interest for a project team (for e.g. project manual, or any files that needs to be monitored from aspects of functional safety based on ISO 26262).

    Do you use a script file developed by your own, or do you use one Integrity example file, maybe modified?

    Greetings,

    Klaus

    S
    ssaul15-Moonstone
    15-Moonstone
    October 10, 2013

    We are using a script developed by our own.

    M
    mrump16-Pearl
    16-Pearl
    October 11, 2013

    Hi all,

    @Klaus: We tried your aproach, but on a larger scale of "less skilled" users it was to risky to let them handle the Properties themselfs. Even a Custom Button based Tooling couldn'd solve it.

    Here's another approach we are working on.

    Since there is a new Field Type "Source Trace" in I10.2 and later, the idea is to create a "My Watchlist" Item Type that can be created by the user himself. The Item only contains one field "my files" which is of type source trace.

    A custom IM trigger script ensures that these items are singletons per user.

    Once created the user can Drag&Drop the members he's interested in into the "my files" fields.

    A simple IM trigger should then be able to recognize change on the files in the field and send an appropiate e-mail.

    Unfortunately all this works fine except for the IM trigger. At least in I10.2 there is no event fired, when the content of the source trace field updates, only when the list of traced members changes. Hopefully this is fixed in 10.4 (haven't checked yet).

    Alternatively you can use a SI trigger that fires on checkin event and "asks" the member for it's source traces to get the the "My Watchlist" Items, fetch their creators and finally get their email acounts.

    HTH Matthias

    M
    matt_giltaji1-Visitor
    1-Visitor
    October 23, 2013

    I think Matthias' solution with source traces and the "My Watchlist" is the most elegant and flexible way to go, but we are not using source traces so I don't know exactly how that works.

    With that said, we have built some mechanisms to get IM triggers to fire on SI events using api calls.

    At a high level:

    1) add a yes/no field (editable by admin only) to the item type that you want to act as the "delta" in your IM trigger

    2) set up the IM trigger to fire whenever the new field changes to "yes". After the trigger runs, it should change the field back to "No" or blank. (This can be using issueDeltaBean.setFieldValue([Field Name], "No") in the trigger script or through the IM trigger assignment tab, whatever is easiest for you)

    3) set up the SI trigger on the Si event desired. Inside this trigger you will need to do the below

    3a) get to your Integrity item ID by using the api to call a query with "im issues" or parsing the change package ID. You could use multiple API calls to hop through item relationships, but API calls are expensive in terms of performance.

    3b) make an "im editissue" api call on the integrity item ID from 3a and set the field value to "Yes". You can also set any other field values needed on the item at the same time.

    Some caveats to doing this:

    API calls are performance intensive. The call has to be processed by the API engine, including all the authorization logic, then go to the database to get results and return. Your source trigger will sit and wait for the API call to return before moving forward in its logic, so you want to make sure that the business value provided by the API call is worth the performance hit. If possible, try to limit when the API call is needed and only make the API call after validating data already present in the source trigger (such as member attributes, filenames & filepaths, change package or author details, etc).

    API calls can be dangerous. If the API call does not return, it can hang and crash your integrity server. (This is very likely if you have a trigger running via an API call make another API call using the same API username/password) Your API call is also likely to be running with some sort of admin or elevated permissions, so make sure that you are careful with any input from end users that changes how your api call behaves. For example, it is probably safe to take the filename and save it in a text field, but if you use the filename to determine if you need to do some potentially harmful action (like deleting an issue or clearing out some fields) then you run the risk of a typo causing that harmful action to fire.

    Back to the original challenge, if there is some sort of consistent patterns in the filename or filepath (like all the docs are in the "doc" subdirectory or something like that) start with, you could use regular expressions in the source trigger to determine when to send the email. Unfortunately that means that it would probably not be configurable by the end user.

    Hope that helps,

    Matt

      Terms & ConditionsAccessibility statement