Known Issues

The known issues listed below refer to the Customizing area. Further known issues can be found in the following documentation areas:

• Application

• Technology/Installation/Update

Known Issues

Known Issues with Solution

UUIDs in PLANTA link Data Tables

PLANTA link incorrectly requires a mandatory UUID for data tables that are used in interfaces and expects that the UUID possesses "uuid" as Python ID.

Solution: Please replace the following entry in the py/api/ppms/customizing/venus/ppms/interface/modules/mts.py file:

            uuid_di = dtp_record.get_di('uuid')

by

        try:
            uuid_di = dtp_record.get_di('uuid')
        except ppms.NonexistentDataItem:
            return

Problem with the Validation of New Individual Mapping Functions

New individual mapping functions are not recognized by the interface validation.

• Reason: The customizing was changed to use the category attribute for the class name, but there was still a place where the name attribute was searched for.

• Solution: Please replace the following entry in the src/Python/py/api/ppms/customizing/venus/ppms/interface/blocks/base.py file:

        for listbox_record in category_record.get_children(447, ['name', 'description']):
            name = listbox_record.name.get_value()

by

        for listbox_record in category_record.get_children(447, ['category', 'description']):
            name = listbox_record.category.get_value()

Problems with the CalculateDepartmentAbsence migration packet

After updating to DB 39.5.23, the CalculateDepartmentAbsence migration packet fails on MSSQL systems.

• Reason: In SQL Server, temporaray tables (#...) are session-specific. This means that they can only be used within the connection/session that has created them. We execute any instruction via our Java-based stack, with c3p0 acting as a "pooled connection manager".

• Workaround:

  • If you would like to update to DB 39.5.23, please activate the persistent_db_session parameter under config/globals.conf (set to "true") and deactivate it again after the update.

  • If the update has already been carried out and the migration package has failed, a customizer can edit the file and manually remove the "#" to convert the temporary tables into real tables and subsequently run the migration package again.

Problem with mod_obj.menu(91) / Action ID 91

The system crashes when menu item 91 is included in a module. This can be done using a Python macro or an action ID in the data area.

• In order to avoid errors, 91 should no longer be used as an action ID on a data field with DF beahvior = c2.

• In all macros in which mod_obj.menu(91) is used to insert child data areas you now have to explicitly specify in which data area a record is to be inserted. This is done via the DA Python ID.

• Solution:

Old: 
mod_obj=ppms.get_target_module()
mod_obj.menu(91)

New:
inv_rec=ppms.get_context_df().get_record()
inv_rec.insert_child(str(DA-Python-ID))

• The advantage of this procedure is that here you can decide precisely in which data area a record is inserted.

Database error message when saving in Q1B and Q2B after a CU deployment

When saving changes in the customizing schemas !Q1B and !Q2B (e.g. in the Modules or Data Areas modules), a database error message is displayed after CU deployment.

• Solution:

  • You have to manually set the HIBERNATE_SEQUENCE to the highest status of the data available in the history tables.

Overwrite More Complex Python Customizings

For information

• It is usually recommended that you use the Import Wrapper to change standard functionalities.

• For certain programming, however, this is not possible. In such cases you have to proceed as follows:

  • The code in the file that is stored under /planta_de/ must be adjusted.

  • The change must be documented in the ICOU.

  • Upon each update, the change must be restored.

Details

• Example of such a programming:

  • The apply_project_parameter_heredity function is opened by create_project_by_type in create_project.py.

  • This function in turn opens insert_project_child_records for copying the stakeholders of a main project to a subproject.

  • If the insert_project_child_records function is overwritten by the import wrappers, this will not have any influence on this behavior.

• Reason:

  • Both functions are located in the same module, which visualizes their local name space.

  • If the _apply_project_parameter_heredity function now wants to open the insert_project_child_records function, this function is first looked for in the local name space before the search is extended.

  • So if the function is overwritten in the customer directory, the code never gets to search there because the function is already found in the local namespace.

Fixed Issues