The M-Files Community will be updated on Tuesday, April 2, 2024 at 10:00 AM EST / 2:00 PM GMT and the update is expected to last for several hours. The site will be unavailable during this time.

This discussion has been locked.
You can no longer post new replies to this discussion. If you have a question you can start a new discussion

GitHub repository for supportive tools for M-Files deliveries

M-Files has shown some consultant tools like Vault comparer, Test tool, Vault documenter etc. - but they are all code-fixed and only to use as they are and without possibility for customization.

I'm just looking for enhanced deployment tools where metadata and configuration changes could be assigned to a implementation ticket and checked in into our local GIT version control. Then I can develop on my machine - a collegue works on an other problem on the same installation also locally. Then I would have to deploy all changes depending on it (new metadata, changing class properties, changing permission settings etc. etc. etc.)

When I'm ready with the task it should be to the approval system and if the feature is approved it should be deployed on production system where I have to decide if this can be during main office times or later in the evening. But I have to make sure that all changes are deployed and all check boxes of the NACL's are set correctly - main error: adding a group etc. but forget to set switch on the rights correctly. Export/Import structure has also no possibility for deploying "property should be removed".

That's why I would need some enhancement method for that - and I guess that other partners and even trained customer adminstrators would also need some of that.

Other example:

I have to add a lot of properties in 3rd level (Employee - user - substition user) to authorized all responsible people e.g. for budget data of their org unit - but hiding it for the others. This is a major manual work adding each property on third level due to scrolling through the properties etc. - and this depending on workflow state - multiple times. Lot of work but also hightly chance to make errors during that.

So I should write a tool using ComAPI and use some predefinitions and select multiple entries at one time - or even compare if PROD and TEST differ in that.

I guess everyone with more complex deliveries knows that problem. The question is if we can found a community implementation of supportive tools.

Here the example which I descibed where I don't even see all assigned entries on one page - not talking about security concept which we need for ISO 9001, ISO 27000 etc.

  • Hi Falk,

    I agree with you in regard with vault configuration and deployments. We have multiple vaults having sometimes pretty different configurations but with tendency to get merged to the same level in time. We have development, testing, prod vaults and it is always a worry if we merged everything correctly, if we forgot something from config etc. Sometimes when we develop we tend to have multiple development vaults for different features and than re-sharing new structural features around is well a trouble, we always need to synchronize well to be sure that we do not overwrite each other work (e.g. if my colleague perhaps changed the same metadata card rules on other dev vault as me on the other vault how to merge those changes?). It would be good to have at least merging tool within an admin tool which would merge your changes with changes you bring from other vaults and let you know about conflicts and would let you know when you need manually to merge. Currently, you get a list of changes but no opportunity to adapt/merge, and also ACLs and MD cards are even not compared before deployment. CI/CD pipeline would be the next step probably.

    Related to ACLs: the metadata tree and selecting of indirect metadata can be tricky as each metadata provides all metadata underneath even though those metadata are not defined in those objects, so you need to be careful. Also if you have properties with same names, you are in trouble which one to select, usually you need to try couple of times until you find the correct one. Having alias in a bracket near to the name of property would be useful (of course you would try to have different names for properties but it happens during the growth of the vault). It would be also good to know where property is used also in which ACLs, workflow conditions etc. (Simple right click on property). It think I even created once a wish request for that as I got frustrated when I needed to clean up some properties but forgot they were also used in some ACLs.

    I see you have a lot of ACLs, maintaining those can be very challenging.

    Admin need improvements definitely.

    Dejan

  • Perhaps M-Files could support such a community driven development. But it has to be managed somehow. I guess the problems you describe are quite similar - it would be interesting to design a feature road map how this could be implemented and split up the tasks between the participants that we get to the goal faster than being implemented alone by each partner. Priority of developer helper tools is always low because customer features bring money. Then it should be calculate how many money developers lose if they make little errors with big effects.

    Also developing best practices would be good if they can be extracted. How is the best practice to develop with simultaneaous tasks like with branches in GIT. How to split up work on the same vault avoiding conflicts 

  • Hi Falk,

    Whilst I've been on vacation this week, I'd like to highlight one point you made.

    You said "Priority of Developer helper tools is always low because customer features bring money".  As someone heavily involved in these things, I don't think that's entirely accurate. Not only do we have a number of people involved in building and maintaining developer tooling and tool, but we are normally willing to share non-productised solutions with partners (as I believe we have with EWERK before).

    Where we do have some ground to gain is on how we formalise these arrangements, whether that is via secured sharing of these tools with partners or via open sourcing their development. Open source is one option we're keen to move forward with, but - as you know - there are sometimes wider concerns than simply the code. 

    If you have partner-specific requirements around tooling then please do continue to work with the channel teams and we will honestly do our best to support you in your needs. 

    Regards,

    Craig 

  • Hi Craig,

    you are right that the quoted passage may lead to misunderstanding. It should be better "lower priority than frontend features". Just as a clear statement again to avoid misunderstandings:

    I am happy about the development especially in the area Vault Application Framework including the Community Extension projects for VAF / ComAPI - and of course the growing sample library where you can pick out sample implementations for various topics and technologies and fit it into your other methods/classes. That's the point I have the idea where it could be started. Also the other topics described in Developer Portal like UIX and External Repositories for example. Also in Admin Client itself some new features are available form time to time - e.g. Ole DB or smal things like filter in lists. -- My developer mind was too much involved here that strikes out the most import new requirement in Modern Leadership "Appreciation" for that all and also for whole supportive actions - as the community here for example.

    The basic idea that development supportive tools are used only by partners and a very small number of (admin) customer users.

    Beside this I named some problems which are difficult to configure like the ACL example about - or small things like adding properties to a class if you don't have only the demo vault property definitions but a grown customer's system list of property definition for various use cases in one vault where I would prefer also to have a filter like in flat hierarchy and not only the name column - e.g. to divide into columns as shown in Flat Hierarchy.

    Some tools are already available as Consultant Tools like the Vault documentator - but this is documentation as it - which has the problem that it can only be supported by this small team. New features in M-Files could be ignored by Configuration.

    ----

    Phases:

    1. Definition of additional small features and Big Problems

    2. Definition of additional features like comparing the metadata structure of vaults (e.g. DEV, TEST, PROD in simple cases) like in Git / Gibt Hub

    3. Review M-Files / Partners (Legal, Charging, Controlling, CFO, CEO - as defined in the specific company.

    3. Approval / Transition into implementation project - parts can be implemented either by M-Files core- or tools-development itself or by a specific M-Files-partner or set up as community project in the same way like Community-Extensions for VAF/ComAPI.

    GOALS:

    • M-Files knows the partners needs. - in Detail! - with underlying thoughts about use cases
    • Partners can learn from each other - even by discussing several implementation projects in meaning of the development and deployment process
    • Concepts are reviewed also from other participants (M-Files / Partners)
    • Implementation will get faster
    • QS / Tests are available and not stroke out

    tbc

    Feedback - other opinions welcome - Result is important - and time

  • Possible alternative development project setup - status update follows when available:

    - Handling of open source communities leaves the question open who is responsible for coordinating the requirements and development inkl. ensuring that the necessary security level will be reached by development, QS and deployment.

    Therefore I want to offer to customer a split of costs for such a tool. To ensure that the tool will kept up-to-date at least according to the technogy but also according to M-Files updates we need to define a monthly description fee depending on .... (to be defined!)

    With subscription fee it would be possible to share this tool also with other M-Files partners including option to resell it to customer's M-Files administrators.

    DISCLAIMER: This is only an idea and not warrenty at all that we start such a project. If we do so we would clarify the conditions with M-Files Germany and inform as soon as the final decision about this development project is made by customer and EWERK with agreement of M-Files.

  • Nr 2) would be definitely feature Admin tool would need. Parallel working on the same vault is almost not possible (developers/admins (actually same persons on DEV) need to be conscious not to delete/overwrite each others). Merging is only possible if you follow up what you have changed and have a good communication among the team. This makes parallel development relative ineffective. Any tooling which could improve it would be quite useful (preventing of overwriting, keeping multiple configurations and than "commiting" and merging them etc.). I understand that we talk hear about static configuration but this configuration is also part of development process, not only VAF applications etc.