WorkPoint 365 version 220.127.116.11 is being released on 2nd of April 2019
Several new features have been made for this release of WorkPoint.
This feature makes it possible to copy an existing entity. This is particular useful when a new entity that somewhat resembles an already existing one. Instead of having to input all data for for creation of the entity, as well as structuring of e.g. document library hierarchies, all of the necessary settings of the original entity can be copied over, depending on the choices made during the wizard's steps.
It is now possible to have several conditions for security rules in WorkPoint. This means that a security rule can activate based on one or multiple conditions that needs to be satisfied for the security rule to activate. It is also possible to reuse a condition on several different security rules, minimizing the need to do configuration.
WorkPoint can now have security rules applied to associated Office 365 Groups. This means that you can have members of an Office 365 group be affected by specific security rules which applied to that group alone. Office 365 Groups is a way to centralize or group members for multiple Microsoft products in a single place. When creating an Office 365 group it is stored in the tenants Active Directory, also referred to as Azure Active Directory. Therefore, security rules with this scope affects the Office 365 group in Active Directory.
One of the great benefits of using group-based security is automation. If security and permissions are based on groups, when members of the group change, the security system automatically recognizes the changes and grants or revokes permissions to members, based on their membership status of the group. This means that no other configuration needs to be done when a member leaves the group or joins the group. This is much more efficient and dynamic than having to grant or limit access for each individual user.
WorkPoint security rules can now target individual sites. In practice this means that WorkPoint can now control which users can access certain sites. For this scope, the personnel for which the rule applies as well as the permission level must be set. These permissions level include e.g. "Full control", "Design", and "View Only".
WorkPoint security rules can now target individual list items and documents. Using this scope, it is possible to set permissions on individual documents or items, e.g. documents with a yes/no-choice column “Confidential” and a value of “yes” could be restricted to only be accessible for the project manager.
One case where this scope can be useful is in the case of a rule based on managed meta data. One could set up a color code throughout an entire chain from Tenant, through the site collection and sites, all the way down to the individual documents and items. Access to these could be controlled via the color code.
Security rules can now be inherited throughout the solution. If a security rule type is set to inherit the rule is based on SharePoint permission inheritance. Items will inherit their permissions from their parent in the structural hierarchy of the solution. This means that, if set, documents/items will inherit permissions from their list/libraries, lists/libraries will inherit permissions from their sites, etc.
A case when this is useful is if a project has a confidential-field. If a project is confidential and only the project manager therefore can see inside it, but that confidentiality changes to be open to anyone, security rules can then be inherited again, so that anyone can now see inside the project. This makes the solution much more dynamic.
Restrictions have been put on Project Master Data such as Stages, so that these data cannot directly be changed and are now read-only. Changes can, however, still be made through a Wizard, which can have specialized security rules applied to them.
A useful case for this scope is when all project master data is read-only, but you want a project manager to be able to make changes to these data. Changes can be made through a wizard, which has its accessibility restricted by a security rule that grants access only to project managers. In effect, no one can make changes to project master data, unless they are in a project manager position.
Microsoft Teams is a complete chat and online meetings solution. With Microsoft Teams you can host audio and/or video and perform or attend online conferences. It also lets you communicate with other members of your organization, or even people outside your organization, through an intuitive chat feature.
By using automatic integration between Microsoft Teams and WorkPoint through Office 365 Groups, documents created, uploaded or edited are stored in the same location, regardless of whether the user is working through the Microsoft Teams interface, or through the WorkPoint/WorkPoint Express interface.
Furthermore, Microsoft Teams is integrated with Microsoft’s online office suite Office 365. This means that it Is tied together with other apps such as Word ad Excel, as well as cloud storage and services such as SharePoint, PowerPoint, OneNote, Planner, Power BI and Delve. As a consequence of this, any document, presentation, and spreadsheet shared within a Team are automatically synced with a copy stored in Microsoft’s OneDrive cloud storage as well as a local SharePoint environment. This makes it easier to keep track of all of the Team’s shared documents, and to not miss any updates, both in communication and in documents.
This feature allows the user to move entities from one business module to another. This is useful in various cases.
An example could be if a solution has a Projects business module which contains all active projects, and another Projects module used to store all archived projects. This feature makes it possible to move a finished project from the active Projects module to the Archived Projects module for storage. This makes the solution more scalable and help respect limitations on entity counts. WorkPoint Business Modules performs best if the entity count is below 5000 because of Microsoft SharePoint software boundaries and limitations. This is especially true if unique permissions are assigned to many entities. So, in case a solution approaches this count, but many of the entities are completed, it is now possible to move these to a separate storage module using this feature.
It is important to note that the site for the entity does not get copied. The site for the entity is still the same after moving the entity.
This feature makes it possible to display a disclaimer notification upon site entrance that the user needs to accept before granted access to the site content. The disclaimer notification can be set to display either on each visit or just once. The consent that any given user gives to the disclaimer presented to them is logged. This makes it easy to see who have given consent and when, if needed. This feature is useful n several cases. One example could be that a solution contains sensible data that is not to be shared outside the team working with the solution. In addition to security rules, a disclaimer notification can be set up, so that anyone that can access the data, must also accept to the no-sharing terms.
A new action has been added to the Action Management feature. This action will set the default view of the specified list. This makes it possible to have different default views for different stages of a project, for example.
A case where this action is useful is if a list of a solution has a lot of different views that are meant to be used at different stages of a project. Instead of having a basic default view and having to change view every time the project is visited, the default view of the list can be defined by the current stage of the project. This minimizes the work the user must do to view the current relevant information.
Wizards can now be used to create and modify entities, as well as change stage of an entity. This makes it possible to change who has the permission to do these actions via security rules that target the specific wizards. One could, e.g. set all entities to be read-only for all users. Modifications to entities can then be done through wizards, whom only certain people have access to.
Improvements and bugfixes
- Support for synchronization of page properties from master sites (#21566)
- Improved app delegation during install
- Change in EULA and Terms and Condition
- Update to SharePoint Framework 1.7
- Remove manual trigger page popup using action management
- Option to change stage from entity menu on business module (#20756)
- Select which business modules are shown in Modern UI Navigation
- Improved security trimming of manual trigger buttons for action management
- Security trimming of home/solution button
- Improved the user license check in the WebAPI
- Issue with selection of template in wizard if content type template is not word document
- Issue with item creation in action management when using inheritance (#20380)
- People picker does not filter on selection mode setting
- Error in user link in entity details (#20866)
- Issue with stage property on documents when moving/copying
- Issue with action management conditions when using lookup fields (#21126)
- Issue with content type properties on buffer sites (#20980)
- Language issues with task overview webpart
- MyTools missing in specific scenarios (#21328)
- Action Management "Item created" Trigger with Create Site Action causes infinite loop
- Missing security trimming in navigation menu (Modern UI)
- Site column provisioning fails if external user has role assignment on root site collection
- Aggregation does not include items from folders on site lists
- Issue with security replication if parent entity is empty (#21656)
- Issue while changing parent on entity (#21737)
- Changes to favorite display fields are not being updated (#21781)
- Issue with event log (#21841)
- Auditlog job throws OutOfMemoryException
- Entity lock declare records on too many lists (i.e. Apps for SharePoint) (#21820)
- Issue with entity attributes in My Tools links (#20327)