[magnolia-dev] [JIRA] (SUGGEST-80) Add sorting order for defaultOrder in browser app
Title: Message Title Jordie Diepeveen created an issue Suggestion Box / SUGGEST-80 Add sorting order for defaultOrder in browser app Issue Type: Improvement Assignee: Unassigned Created: 15/Mar/17 1:31 PM Environment: Labels: collector-0cf1239d Reporter: Jordie Diepeveen Currently it's not possible to set the default sorting order to descending. According to AbstractJcrContainer, when no sorters are set (and that's always true for a browser subApp when using the classes provided by Magnolia) the defaultOrder property is always set to ascending. For a simple blog app, it's useful to set the default sorting for publication date on descending so the latest item is on top. e.g.: contentConnector: nodeTypes: - name: mgnl:page defaultOrder: publicationDate includeProperties: false rootPath: / workspace: website Would be great to also have the possibility to set the sorters or at lease set the sorting order of the defaultOrder property: e.g. contentConnector: nodeTypes: - name: mgnl:page defaultOrder: publicationDate defaultOrderSorting: desc includeProperties: false rootPath: / workspace: website
[magnolia-dev] [JIRA] (SUGGEST-79) Make Pagination available for lists of results in templates
Title: Message Title Jordie Diepeveen created an issue Suggestion Box / SUGGEST-79 Make Pagination available for lists of results in templates Issue Type: New Feature Assignee: Unassigned Created: 15/Mar/17 10:20 AM Priority: Neutral Reporter: Jordie Diepeveen Magnolia provides a simple Pagination object (info.magnolia.templating.models.util.Pagination) which is easy in use. It would be great to have the Pagination object available by default to wrap around a list of ContentMaps in the template. For e.g. search results, big lists of data, etc.. cmsfn.pagination(List contentList) would be great! Add Comment This message was sent by Atlassian JIRA (v7.2.6#72008-sha1:26175bf)
[magnolia-dev] [JIRA] (SUGGEST-78) Make LinkUtil.externalLink() available through cmsfn
Title: Message Title Jordie Diepeveen created an issue Suggestion Box / SUGGEST-78 Make LinkUtil.externalLink() available through cmsfn Issue Type: New Feature Assignee: Unassigned Created: 15/Mar/17 9:37 AM Priority: Neutral Reporter: Jordie Diepeveen It's currently not possible to simple create an absolutie link to a page. This is needed to create e.g. og-tags and social share links. The LinkUtil.externalLink() provides this functionality but is not directly accessible in freemarker. Add Comment This message was sent by Atlassian JIRA (v7.2.6#72008-sha1:26175bf)
[magnolia-dev] [JIRA] (SUGGEST-74) Allow override sample content (without uuid conflicts) by using magnolia.properties
Title: Message Title Jordie Diepeveen created an issue Suggestion Box / SUGGEST-74 Allow override sample content (without uuid conflicts) by using magnolia.properties Issue Type: New Feature Assignee: Unassigned Created: 13/Feb/17 8:23 AM Priority: Neutral Reporter: Jordie Diepeveen When we are developing a new project, we enable the property magnolia.bootstrap.samples to bootstrap website, dam and other samples content. During development we are constantly updating the sample content so other developers (and the test-environment) wel get a fresh set of fully working sample content. The problem with the bootstrap samples is that it will only bootstrap the content the first time when the content is no yet imported. To refresh the set of content, removing the module in the configuration workspace is not enough because you will get a UUID conflict because the content is stil there. It will take a lot of time to constantly remove the module configuration + the already bootstrapped content in multiple workspaces. It would be great to have a new option in magnolia.properties to specify if the bootstrap contact can be imported when the uuids already exists. Add Comment
[magnolia-dev] [JIRA] (MGNLUI-4017) Selected option in SelectFieldOptionDefinition is ignored
Title: Message Title Jordie Diepeveen created an issue Magnolia UI / MGNLUI-4017 Selected option in SelectFieldOptionDefinition is ignored Issue Type: Bug Affects Versions: 5.4.8 Assignee: Unassigned Attachments: Schermafbeelding 2016-09-14 om 16.18.22.png Components: forms Created: 14/Sep/16 4:31 PM Priority: Major Reporter: Jordie Diepeveen Security Level: Public It seems that the default selected option for all SelectFieldDefinition does not work anymore. When opening the dialog, the value in the option list is not pre-selected according to the field definition (See sample code below).
[magnolia-dev] [JIRA] (MGNLREST-73) When one endpoint definition fails to register, the rest of the to-be-registered endpoint will not get registered.
Title: Message Title Jordie Diepeveen created an issue Magnolia REST Framework / MGNLREST-73 When one endpoint definition fails to register, the rest of the to-be-registered endpoint will not get registered. Issue Type: Bug Affects Versions: 1.1.1 Assignee: Unassigned Created: 24/Aug/16 7:43 AM Priority: Neutral Reporter: Jordie Diepeveen Security Level: Public In the RestDispatcherServlet#init (line 112), all currently registered endpoints are being registered to the servlet. During this process, the Endpoint will be initialized. We had a scenario were one of the endpoint could not be initialized properly due to a wrong Generic type. The initialization process did throw a guice error without any real description of the failure, but this was not really the problem. The servlet threw an exception and did not register the rest of the valid endpoint keeping us in the dark about what in which endpoint did do wrong. I would like to suggest a try..catch around the line "registerEndpoint(endpointDefinition)" so developers know which Endpoint definition failed to register, and so that the rest of the endpoint are correctly registered (because they are fine).
[magnolia-dev] [JIRA] (MGNLPUR-168) PUR is not OWASP compliant because it's informing about the status of an account.
Title: Message Title Jordie Diepeveen created an issue Magnolia Public User Registration / MGNLPUR-168 PUR is not OWASP compliant because it's informing about the status of an account. Issue Type: Bug Affects Versions: 2.5.2 Assignee: Unassigned Components: registration Created: 23/Jun/16 4:26 PM Priority: Major Reporter: Jordie Diepeveen We are integrating the PUR module in a "simple" website with a registration form. During the integration and test round of the registration process we found some security--related results. PasswordProcessor#internalProcess() is returning "user not exist" when the user does not exists. TokenPasswordProcessor#internalProcess() is returning information like "user not exist", According to the OWASP Cheat Sheet: https://www.owasp.org/index.php/Authentication_Cheat_Sheet: Authentication and Error Messages Incorrectly implemented error messages in the case of authentication functionality can be used for the purposes of user ID and password enumeration. An application should respond (both HTTP and HTML) in a generic manner. Authentication Responses An application should respond with a generic error message regardless of whether the user ID or password was incorrect. It should
[magnolia-dev] [JIRA] (MGNLUI-3907) Edit page properties cannot be used anymore after selecting an area or component.
Title: Message Title Jordie Diepeveen created an issue Magnolia UI / MGNLUI-3907 Edit page properties cannot be used anymore after selecting an area or component. Issue Type: Bug Affects Versions: 5.4.6 Assignee: Unassigned Components: actionbar Created: 12/Jun/16 6:55 PM Priority: Neutral Reporter: Jordie Diepeveen Security Level: Public When opening a page in de Pages App, the action "edit page properties" is visible but after selecting an area or component, the action bar is updated based on the new selection. After this selection, it's not possible anymore to go back to the "begin" state of opening the editor of a page so the action will be visible again. Only after re-opening the page or switching back and forwards between tabs in the Pages app, the action will be visible again. This behavior is confusing for our editors.
[magnolia-dev] [JIRA] (MGNLUI-3859) Make buttonLabel for a Checkbox field resolve into fields..buttonLabel
Title: Message Title Jordie Diepeveen created an issue Magnolia UI / MGNLUI-3859 Make buttonLabel for a Checkbox field resolve into fields..buttonLabel Issue Type: Improvement Affects Versions: 5.4.6 Assignee: Unassigned Components: forms Created: 24/Apr/16 2:55 PM Priority: Neutral Reporter: Jordie Diepeveen Security Level: Public Would be nice to auto resolve the buttonLabel for a checkbox into fields..buttonLabel so we do not have to define the buttonLabel in the dialog definition (just like label and description).
[magnolia-dev] [JIRA] (JCRTOOLS-31) Making the statement field "full screen" will result in moving the field instead of expanding it
Title: Message Title Jordie Diepeveen created an issue Jcr Tools / JCRTOOLS-31 Making the statement field "full screen" will result in moving the field instead of expanding it Issue Type: Bug Affects Versions: 1.0 Assignee: Unassigned Attachments: expanding statement field jcr-utils.png Created: 24/Apr/16 11:10 AM Environment: Mac OS X 10.11.4, Safari + Chrome Priority: Neutral Reporter: Jordie Diepeveen When clicking on the full screen icon, the statement field will move to the top instead of making it full width.
[magnolia-dev] [JIRA] (SUGGEST-34) Allow multiple items to be selected in a multiselect field
Title: Message Title Jordie Diepeveen created an issue Suggestion Box / SUGGEST-34 Allow multiple items to be selected in a multiselect field Issue Type: Improvement Assignee: Unassigned Created: 07/Apr/16 5:18 PM Environment: Labels: collector-0cf1239d Reporter: Jordie Diepeveen It would be nice to select more then one item in a MultiValueFieldDefinition with a LinkFieldDefinition in it for e.g. selecting multiple contacts at one. Add Comment
[magnolia-dev] [JIRA] (SUGGEST-30) Simpler support for handling a POST request in a component model
Title: Message Title Jordie Diepeveen created an issue Suggestion Box / SUGGEST-30 Simpler support for handling a POST request in a component model Issue Type: Improvement Assignee: Unassigned Created: 01/Apr/16 3:58 PM Environment: Labels: collector-0cf1239d Reporter: Jordie Diepeveen Currently it's needed in e.g. the execute() method of a model to check if the request method is of the type "post" so we can handle our incoming request. With modules like blossom it's very easy to keep the get and post method separated. It would be nice if the model already provide an (abstract?) method for it so we only have to override it to handle the request. Also a POST request goes through all execute methods of all components on a page, so it's also needed to add some kind of hidden action field so the model knows the POST request is destined for that model. It will be great if the model is already knowing that the POST request is destined to be processed by the model so we only need to add the code to the handlePost (or what a good name will be) method. Reporter: Jordie Diepeveen E-mail: jordie.diepev...@trimm.nl
[magnolia-dev] [JIRA] (SUGGEST-28) Change the default location of magnolia.home to be placed outside the exploded war folder
Title: Message Title
Jordie Diepeveen created an issue
Suggestion Box / SUGGEST-28
Change the default location of magnolia.home to be placed outside the exploded war folder
Issue Type:
Improvement
Assignee:
Christopher Zimmermann
Created:
31/Mar/16 8:16 AM
Environment:
Labels:
collector-0cf1239d
Reporter:
Jordie Diepeveen
Currently the default location of the repositories, logs, cache, etc.. are placed inside the /src/main/webapp. Without changing this property, the data (when using derby) is removed when a new war file is deployed.
The first thing we always change when starting a new project is to set the magnolia.home property in /src/main/webapp/WEB-INF/config/default/magnolia.properties to $ {magnolia.app.rootdir}
-data
I think this should be done by default.
Add Comment
[magnolia-dev] [JIRA] (SUGGEST-27) Requesting more documentation for creating unit test for version handlers, rendering models, etc.
Title: Message Title Jordie Diepeveen created an issue Suggestion Box / SUGGEST-27 Requesting more documentation for creating unit test for version handlers, rendering models, etc. Issue Type: Improvement Assignee: Christopher Zimmermann Created: 31/Mar/16 8:10 AM Environment: Labels: collector-0cf1239d Reporter: Jordie Diepeveen We are trying to create more Unit tests for our Magnolia projects, but it's not always clear (even with the existing documentation) how and when to use what test class and how to mock the components for e.g. testing rendering models, version handlers, etc.. I would like to request more documentation about creating unit test for different kind of Magnolia entities. Add Comment
[magnolia-dev] [JIRA] (SUGGEST-26) It should be easier to create a config sub-app
Title: Message Title Jordie Diepeveen created an issue Suggestion Box / SUGGEST-26 It should be easier to create a config sub-app Issue Type: Improvement Assignee: Christopher Zimmermann Created: 31/Mar/16 8:06 AM Environment: Labels: collector-0cf1239d Reporter: Jordie Diepeveen Some settings in Magnolia (or your own module) are stored in JCR and can be changed by using the JCR browser from the Configuration App. To let "end-users" or "administrators" access to the Configuration App is a bad idea because it's the complex. The Mail App e.g. is a good example of a config app performing as a "wrapper" around a configuration node and some properties. This is a user friendly approach of configuring some part of the platform. I would really like to create more configuration app like the mail, backup and cache app, where some users can switch settings on/off, or select options, etc.. Creating a detail (form) sub-app for a content app is very easy in Magnolia 5.4+ using yaml, but a config app, like the backup/cache app, is not really possible without creating a lot of Java classes. It would be nice to have some basic config app definition to use as sub-app class and populate the form using the field definitions like we are doing now for detail sub-apps of a content app. The fields will then be saved to the given config node as properties.
[magnolia-dev] [JIRA] (SUGGEST-25) Specify fields to search and boosting by configuration for searchfn
Title: Message Title Jordie Diepeveen created an issue Suggestion Box / SUGGEST-25 Specify fields to search and boosting by configuration for searchfn Issue Type: Improvement Assignee: Christopher Zimmermann Created: 31/Mar/16 7:51 AM Environment: Labels: collector-0cf1239d Reporter: Jordie Diepeveen With the current implementation of the searchfn the nodes, field and boosting can be configured by manually modifying the workspace.xml files for each workspace It would be nice to specify the fields (and boosting, etc..) to index somewhere in the configuration. I know it can be done in the workspace.xlm for each workspace. And I know that I can create my own search model with my own custom queries, by I think to support a better out-of-the-box search-functionality for light-modules, this should be configurable somewhere so no "complex" tasks need to be performed for non-java-developers to get nice search functionality out-of-the-box Add Comment
[magnolia-dev] [JIRA] (MGNLUI-3608) CompositeTransformer is adding basePropertyName to the property name, resulting in incorrect properties
Title: Message Title
Jordie Diepeveen updated an issue
Magnolia UI / MGNLUI-3608
CompositeTransformer is adding basePropertyName to the property name, resulting in incorrect properties
Change By:
Jordie Diepeveen
Somehow, when using the SwitchableFieldDefinition (link from the MTE), the properties are stored incorrect. The LinkModel from the MTE cannot read the correct properties and no link and title are shown. It seems to be in the CompositeTransformer#getCompositePropertyName() method.The field definition is i18n, so the propertyName (linkTypeexternal) will be appended by the basePropertyName ('linkType'). This results in the field 'linkTypeexternallinkType'.See issue MTE-46.
Add Comment
This message was sent by Atlassian JIRA (v6.4.11#64026-sha1:78f6ec4)
For list details, see: http://www.magnolia-cms.com/community/mailing-lists.html
Alternatively, use our forums: http://forum.magnolia-cms.com/
To unsubscribe, E-mail to:
[magnolia-dev] [JIRA] (MTE-46) Link component is adding 'linkType' as suffix to properties
Title: Message Title Jordie Diepeveen created an issue Magnolia Templating Essentials / MTE-46 Link component is adding 'linkType' as suffix to properties Issue Type: Bug Affects Versions: 0.6 Assignee: Unassigned Attachments: linkType storage.png Components: ftl-templates, models Created: 23/Sep/15 1:55 PM Priority: Critical Reporter: Jordie Diepeveen When using the link component, the fields linkType and linkTypeinternal are stored as 'linkTypelinkType' and 'linkTypeinternallinkType'. The displaying of the field in the dialog is working, but the rendering is broken because the fields cannot be read.
[magnolia-dev] [JIRA] (MGNLUI-3557) App definitions downloaded as yaml will result in incorrect yaml definition
Title: Message Title Jordie Diepeveen created an issue Magnolia UI / MGNLUI-3557 App definitions downloaded as yaml will result in incorrect yaml definition Issue Type: Bug Affects Versions: 5.4.1 Assignee: Unassigned Components: admincentral Created: 07/Sep/15 5:01 PM Priority: Neutral Reporter: Jordie Diepeveen Security Level: Public Using the download as yaml functionality in AdminCentral for a App definition will result in an incorrect, not working yaml file. Item like: availability: roles: superuser it exported as roles: superuser:
[magnolia-dev] [JIRA] (MGNLUI-3544) Hover text in Rich text field for link to asset is showing 'Link to DAM document'
Title: Message Title Jordie Diepeveen created an issue Magnolia UI / MGNLUI-3544 Hover text in Rich text field for link to asset is showing 'Link to DAM document' Issue Type: Bug Assignee: Unassigned Attachments: Schermafbeelding 2015-09-03 om 15.53.41.png Created: 03/Sep/15 4:05 PM Priority: Neutral Reporter: Jordie Diepeveen Security Level: Public During a demo we did today with a customer, we showed them how to add assets. In a rich text field, it's possible to create a link to an uploaded asset. We found out that the text was referring to an asset as a 'DAM document'. The term 'DAM document' is not known by customers, only the term 'asset'. To keep things in line and consistent, something like 'Link to asset' would be clearer?
[magnolia-dev] [JIRA] (MTE-42) Searching below root path '/' will result in no results
Title: Message Title Jordie Diepeveen created an issue Magnolia Templating Essentials / MTE-42 Searching below root path '/' will result in no results Issue Type: Bug Affects Versions: 0.5 Assignee: Unassigned Created: 27/Aug/15 2:35 PM Priority: Major Reporter: Jordie Diepeveen When using SearchTemplatingFunctions#searchContent(String, String, String, String) with the following settings: (educations, antropologie, /, mgnl:education), the results are always 0. The query which is internally used by the searchContent method is: SELECT rep:excerpt() from mgnl:education WHERE jcr:path like '//%' AND contains(., 'antropologie') ORDER BY jcr:score() DESC The problem is the like '//%' part. When changing it to like '/%' , it's working. E.g. SELECT rep:excerpt() from mgnl:education WHERE jcr:path like '/%' AND contains(., 'antropologie') ORDER BY jcr:score() DESC Add Comment
[magnolia-dev] [JIRA] (MTE-37) Allow pages to be excluded from search results when using searchfn
Title: Message Title Jordie Diepeveen created an issue Magnolia Templating Essentials / MTE-37 Allow pages to be excluded from search results when using searchfn Issue Type: New Feature Affects Versions: 0.5 Assignee: Unassigned Components: models Created: 11/Jul/15 9:52 PM Priority: Neutral Reporter: Jordie Diepeveen By default, the searchfn#searchContent will search through all nodes/pages/items in the given workspace. This will result in displaying pages like meta (in the Magnolia demo site) and the placeholder page for tours, etc.. These results are not very useful for the end-user. It would be nice to allow a page to be excluded from the search results. Maybe placing a checkbox in the page dialog? The searchfn will then filter out the pages with this checkbox checked from the results.
