Bad Practice in using Polarion
Here we give you some examples what you shall not do when using Polarion at your company.
Im Gegensatz zu best practice stehen Beispiele, die als worst practice bezeichnet werden müssen, weil sie ineffizient und unproduktiv waren und schlimmstenfalls zum Scheitern einer Aufgabe geführt haben. Darin drückt sich eine A-posteriori-Perspektive aus, d. h. es wurden identifizierbare Fehler begangen.
Monster Workflow
Do not create workflows which allow transitions from any status to any status. This kills the whole idea of workflow as predefined sequence of steps to control "work flow".
It makes sequence of transitions unpredictable for managers and not undestandable for end users. They see "unlimited possibilities" of transitions, but they do not see the "workflow".
Everyone can do Anything (Access Rights Freedom - leads to Anarchy)
Giving too much freedom (access rights) to the users will lead to a Mess.
Polarion has an advanced and easy to handle Access & Permissions Management. It is always good practice to restrict user access rights. Not everyone shall be able to do some actions.
Too many special Permission rules can overload Polarion
Having too many special rules (exceptions) for "permissions" to work items, documents, spaces, etc. - can overload Polarion.
All these rules about access rights shall be evaluated before the data is displayed to the user. Polarion has to check first if the userreally has access rights
to see the data and to perform edit operations.
Especially this is important for Report Pages. If Polarion has to analyse hundreds or thousands or work item, and for each it needs to calculate
complex access rights - then teh system will considerably slow down.
SOLUTION: keep permissions simple. Do not over-complicate.