[magnolia-dev] [JIRA] Created: (MGNLFORM-91) Add back button to be used in multistep forms
Add back button to be used in multistep forms - Key: MGNLFORM-91 URL: http://jira.magnolia-cms.com/browse/MGNLFORM-91 Project: Magnolia Form Module Issue Type: Improvement Affects Versions: 1.2.2 Reporter: Teresa Miyar Assignee: Teresa Miyar -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.magnolia-cms.com/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira For list details see http://www.magnolia-cms.com/home/community/mailing-lists.html To unsubscribe, E-mail to: dev-list-unsubscr...@magnolia-cms.com
[magnolia-dev] [JIRA] Reopened: (MAGNOLIA-3602) Deleting a role that is reffered by a group
[
http://jira.magnolia-cms.com/browse/MAGNOLIA-3602?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jan Haderka reopened MAGNOLIA-3602:
---
Would not rewriting the loops using {{while}} and {{iterator}} work better then
manually taking care of indexes are {{remove()}}? If nothing else it would make
code easier to read.
Deleting a role that is reffered by a group
---
Key: MAGNOLIA-3602
URL: http://jira.magnolia-cms.com/browse/MAGNOLIA-3602
Project: Magnolia
Issue Type: Bug
Affects Versions: 4.0, 4.1, 4.2, 4.3, 4.4, 4.4.2
Reporter: Zdenek Skodik
Assignee: Ondřej Chytil
Fix For: 4.4.4, 5.0
Attachments: roles.png
can end up in a situation that other role/s, assigned to the group, is/are
suddenly showed up as uuids, not as names.
To reproduce:
# create a test role
# create a test group, assign roles in this order: test, demo-project-base,
contact-base, workflow-base, demo-project-publisher. Save.
# delete the test role, edit the test group and you should see something
similar to attached roles.png
\\
\\
The same behavior affects also the rest of possible assignments - Groups for
Group and Groups for User.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://jira.magnolia-cms.com/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
For list details see
http://www.magnolia-cms.com/home/community/mailing-lists.html
To unsubscribe, E-mail to: dev-list-unsubscr...@magnolia-cms.com
[magnolia-dev] [JIRA] Reopened: (MAGNOLIA-3588) Workflow mappings: work just once, never again until server restart
[
http://jira.magnolia-cms.com/browse/MAGNOLIA-3588?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jan Haderka reopened MAGNOLIA-3588:
---
{{release}} is called when command is returned to the pool. There is no
guarantee that the same instance of the command will be used for next
activation so the cleanup has to happen. The issue has to be solved by setting
the mappings prior to command execution.
Workflow mappings: work just once, never again until server restart
---
Key: MAGNOLIA-3588
URL: http://jira.magnolia-cms.com/browse/MAGNOLIA-3588
Project: Magnolia
Issue Type: Bug
Components: workflow
Affects Versions: 4.4.2
Reporter: Christian Ringele
Assignee: Ondřej Chytil
Priority: Critical
Fix For: 4.4.4
Attachments: Screen shot 2011-03-07 at 2.19.13 PM.png, Screen shot
2011-03-07 at 2.23.14 PM.png, workflow_mappings.zip
Having in the activation command/startFlow workflow mappings for certain
paths work only once.
I configured two special flows for two sites.
On the very first activation, the spacial flow is picked up, but after the
first activation never again.
Only a restart of the server makes, that the right special workflow is used
again, but only for the first time again.
I added as a zip the flows, the configuration and all the users and roles.
Like this it should be easy to reproduce the problem.
I'm quite sure, its not a configuration error I did, but a bug.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://jira.magnolia-cms.com/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
For list details see
http://www.magnolia-cms.com/home/community/mailing-lists.html
To unsubscribe, E-mail to: dev-list-unsubscr...@magnolia-cms.com
[magnolia-dev] [JIRA] Created: (MAGNOLIA-3693) Allowed types should be in HashSet
Allowed types should be in HashSet
--
Key: MAGNOLIA-3693
URL: http://jira.magnolia-cms.com/browse/MAGNOLIA-3693
Project: Magnolia
Issue Type: Improvement
Components: activation
Affects Versions: 4.4.3
Reporter: Ondřej Chytil
Assignee: Philipp Bärfuss
Fix For: 4.4.5
Currently {{info.magnolia.cms.util.Rule}} keeps allowed types in string array
which can cause troubles with duplicite entries. This can be solved by changing
to HashSet.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://jira.magnolia-cms.com/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
For list details see
http://www.magnolia-cms.com/home/community/mailing-lists.html
To unsubscribe, E-mail to: dev-list-unsubscr...@magnolia-cms.com
[magnolia-dev] [JIRA] Updated: (MAGNOLIA-3354) Extends Templates: Registered teamplates get lost below wrong configuration
[ http://jira.magnolia-cms.com/browse/MAGNOLIA-3354?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jan Haderka updated MAGNOLIA-3354: -- Affects Version/s: 4.3.8 (was: 4.3.2) Extends Templates: Registered teamplates get lost below wrong configuration --- Key: MAGNOLIA-3354 URL: http://jira.magnolia-cms.com/browse/MAGNOLIA-3354 Project: Magnolia Issue Type: Sub-task Components: core Affects Versions: 4.3.8 Reporter: Christian Ringele Assignee: Ondřej Chytil Priority: Major Fix For: 4.4.4 Attachments: Screen shot 2010-11-02 at 10.49.55 AM.png, Screen shot 2010-11-02 at 10.51.44 AM.png, Screen shot 2010-11-02 at 10.52.11 AM.png Base setup: Adding a template definition, which extends another template definition (see print screen). Problem: If the value of the extends property is set wrong, all template definitions registered below the wrong node are invalid. So if placed for example below the stkSection (see print screen), all template below are not found anymore (print screen). Behavior on correct reconfiguration: When correcting the wrong extends value, all templates are registered correct again. What should be changed: Following template definitions of a wrong definition should be still registered. and usable. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.magnolia-cms.com/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira For list details see http://www.magnolia-cms.com/home/community/mailing-lists.html To unsubscribe, E-mail to: dev-list-unsubscr...@magnolia-cms.com
[magnolia-dev] [JIRA] Updated: (MAGNOLIA-3354) Extends Templates: Registered teamplates get lost below wrong configuration
[ http://jira.magnolia-cms.com/browse/MAGNOLIA-3354?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jan Haderka updated MAGNOLIA-3354: -- Affects Version/s: (was: 4.3.8) (was: 4.3.7) (was: 4.3.6) (was: 4.3.5) (was: 4.3.4) (was: 4.3.3) Extends Templates: Registered teamplates get lost below wrong configuration --- Key: MAGNOLIA-3354 URL: http://jira.magnolia-cms.com/browse/MAGNOLIA-3354 Project: Magnolia Issue Type: Sub-task Components: core Affects Versions: 4.3.8 Reporter: Christian Ringele Assignee: Ondřej Chytil Priority: Major Fix For: 4.4.4 Attachments: Screen shot 2010-11-02 at 10.49.55 AM.png, Screen shot 2010-11-02 at 10.51.44 AM.png, Screen shot 2010-11-02 at 10.52.11 AM.png Base setup: Adding a template definition, which extends another template definition (see print screen). Problem: If the value of the extends property is set wrong, all template definitions registered below the wrong node are invalid. So if placed for example below the stkSection (see print screen), all template below are not found anymore (print screen). Behavior on correct reconfiguration: When correcting the wrong extends value, all templates are registered correct again. What should be changed: Following template definitions of a wrong definition should be still registered. and usable. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.magnolia-cms.com/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira For list details see http://www.magnolia-cms.com/home/community/mailing-lists.html To unsubscribe, E-mail to: dev-list-unsubscr...@magnolia-cms.com
[magnolia-dev] Product Team Meeting (2011.04.16)
Testing (BDD) JBehave stopped the experiment introduced Hamcrest Mockito BDD given() instead of when() Maintenance 4.4.4 about to release MAGNOLIA-3671 promoted a blocker some modules will have to wait but are going to release fixes related to tickets for SLA-1 customers start closing the tickets NTLM ready for the first official release synchronization module MGNLSYNC-2 - recursive synchronization upon dms workspace MGNLSYNC-4 - update list of workspaces postponed next focus once 4.4.4 has been released Magnolia 5.0 design/theme 8. proposal approaching a final state implementation in June M4/Sprint II page editing implement new templating be ready for the STK migration STK migration meeting this week do our best list/tree performance issues Federico/Marlon Jan helps as soon 4.4.4 is out page editing toolbox works bars are connected basic editing is working templating/rendering rendering not yet started basic directives are there custom vaadin classes extra module needed avoid cyclic dependencies For list details see http://www.magnolia-cms.com/home/community/mailing-lists.html To unsubscribe, E-mail to: dev-list-unsubscr...@magnolia-cms.com
[magnolia-dev] [JIRA] Created: (MAGNOLIA-3694) Provided Mock-Implementations for JCR-Api (Node, Property etc.) that are independent from Content-API
Provided Mock-Implementations for JCR-Api (Node, Property etc.) that are independent from Content-API - Key: MAGNOLIA-3694 URL: http://jira.magnolia-cms.com/browse/MAGNOLIA-3694 Project: Magnolia Issue Type: Task Components: core Reporter: Daniel Lipp Assignee: Philipp Bärfuss Priority: Major Before Mgnl 5.0 the Content-API was the master - basically all code was relying on it and hence there was proper Mock-Implementations for it. Direct access was the exception so the few available Mock-Implementations for JCR-Types are based on the Content-API. With Mgnl 5.0 (and JCR 2.0) we want to change strategies - use JCR-API where possible. So now we need a full set of Mock-JCR-Implementations - all of them being independant of the Content-API mocks'. These could/should now rely on the JCR-mocks. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.magnolia-cms.com/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira For list details see http://www.magnolia-cms.com/home/community/mailing-lists.html To unsubscribe, E-mail to: dev-list-unsubscr...@magnolia-cms.com
[magnolia-dev] [JIRA] Created: (MAGNOLIA-3695) magnolia.repositories.home system property ignored if not set in magnolia.properties file
magnolia.repositories.home system property ignored if not set in
magnolia.properties file
-
Key: MAGNOLIA-3695
URL: http://jira.magnolia-cms.com/browse/MAGNOLIA-3695
Project: Magnolia
Issue Type: Bug
Affects Versions: 4.4.1
Environment: Java 1.6, OS/X
Reporter: Ben Strawson
Priority: Minor
If you do not have a magnolia.repositories.home setting in any
magnolia.properties file, but set it as a system property, then Magnolia treats
it as unset. The effect is that the repository location is a location relative
to the working directory and called literally
${magnolia.repositories.home}/magnoliaAuthor (or whatever
${magnolia.repository.name} is set to).
A workaround is to ensure that the value magnolia.repositories.home is always
set in magnolia.properties, even if set to an empty string. Magnolia then does
override this value with the one from your system property.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://jira.magnolia-cms.com/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
For list details see
http://www.magnolia-cms.com/home/community/mailing-lists.html
To unsubscribe, E-mail to: dev-list-unsubscr...@magnolia-cms.com
[magnolia-dev] [JIRA] Updated: (MAGNOLIA-3694) Provide Mock-Implementations for JCR-Api (Node, Property etc.) that are independent from Content-API
[ http://jira.magnolia-cms.com/browse/MAGNOLIA-3694?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Daniel Lipp updated MAGNOLIA-3694: -- Summary: Provide Mock-Implementations for JCR-Api (Node, Property etc.) that are independent from Content-API (was: Provided Mock-Implementations for JCR-Api (Node, Property etc.) that are independent from Content-API) Provide Mock-Implementations for JCR-Api (Node, Property etc.) that are independent from Content-API Key: MAGNOLIA-3694 URL: http://jira.magnolia-cms.com/browse/MAGNOLIA-3694 Project: Magnolia Issue Type: Task Components: core Reporter: Daniel Lipp Assignee: Philipp Bärfuss Priority: Major Before Mgnl 5.0 the Content-API was the master - basically all code was relying on it and hence there was proper Mock-Implementations for it. Direct access was the exception so the few available Mock-Implementations for JCR-Types are based on the Content-API. With Mgnl 5.0 (and JCR 2.0) we want to change strategies - use JCR-API where possible. So now we need a full set of Mock-JCR-Implementations - all of them being independant of the Content-API mocks'. These could/should now rely on the JCR-mocks. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.magnolia-cms.com/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira For list details see http://www.magnolia-cms.com/home/community/mailing-lists.html To unsubscribe, E-mail to: dev-list-unsubscr...@magnolia-cms.com
[magnolia-dev] [JIRA] Updated: (MGNLFORM-90) In multistep forms state is lost when going back and forward using the next step button
[ http://jira.magnolia-cms.com/browse/MGNLFORM-90?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Philipp Bärfuss updated MGNLFORM-90: Assignee: Tobias Mattsson (was: Teresa Miyar) Fix Version/s: 1.2.3 In multistep forms state is lost when going back and forward using the next step button --- Key: MGNLFORM-90 URL: http://jira.magnolia-cms.com/browse/MGNLFORM-90 Project: Magnolia Form Module Issue Type: Bug Affects Versions: 1.2.2 Reporter: Teresa Miyar Assignee: Tobias Mattsson Priority: Major Fix For: 1.2.3 -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.magnolia-cms.com/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira For list details see http://www.magnolia-cms.com/home/community/mailing-lists.html To unsubscribe, E-mail to: dev-list-unsubscr...@magnolia-cms.com
